A security researcher has publicly disclosed a high-severity server-side request forgery issue in bitcoinj’s implementation of the legacy BIP-70 Bitcoin Payment Protocol, arguing that an attacker-controlled payment request can cause a wallet to make outbound requests to internal or otherwise unintended network destinations.
The public disclosure, filed on September 29, says the researcher moved the report into bitcoinj’s public GitHub issue tracker after receiving no response through the project’s private vulnerability-reporting channel. The issue remained open without a maintainer response when checked shortly after publication.
The researcher assigned the flaw a CVSS 3.1 score of 8.6, or High. That score is the researcher’s assessment rather than an official CVE or maintainer severity rating, and there is no evidence at this stage that the vulnerability has been actively exploited against wallet users.
The Problem Sits Inside bitcoinj’s BIP-70 PaymentSession Flow
The reported weakness centers on PaymentSession, bitcoinj’s implementation of the BIP-70 payment workflow. Under the protocol, a wallet can receive a PaymentRequest containing a payment_url. After the user approves the payment, the wallet sends a BIP-70 Payment message to that destination and waits for a PaymentACK response.
According to the disclosure, bitcoinj constructs a URL directly from the supplied payment_url and opens the connection without checking whether the destination points to loopback addresses, private networks, link-local infrastructure or another sensitive internal service. The researcher dynamically reproduced the behavior against bitcoinj 0.11.3 and 0.17.
There is an important release detail. bitcoinj’s current latest tagged release is 0.17.1, not 0.17. A source review of the 0.17.1 tag shows the same basic path remains present: PaymentSession takes the PaymentRequest URL, creates a Java URL from it and later calls openConnection(). The same release also retains BIP-70’s handling of pki_type="none". That is source-level evidence that the relevant code pattern remains in 0.17.1, although the researcher’s published dynamic test specifically names 0.17 and 0.11.3 rather than 0.17.1.
The PKI point is more nuanced than saying certificate validation is simply “broken.” BIP-70 itself permits a PaymentRequest to declare pki_type="none". When that happens, there is no merchant certificate to verify. As a result, enabling bitcoinj’s verifyPki option does not guarantee that every PaymentRequest is authenticated. The researcher’s argument is that an unauthenticated request can therefore still supply the destination later used by sendPayment().
A Successful Request Can Carry More Than a Simple Network Probe
The potential impact comes from what bitcoinj sends after a payment is approved. BIP-70 Payment messages can contain signed Bitcoin transactions, refund outputs and other transaction-related information. If the destination is attacker-controlled or unexpectedly points into internal infrastructure, the wallet can transmit that data to a location the user did not intend.
The attacker does not automatically gain arbitrary control of an internal service. Some cloud metadata systems, administrative interfaces and other internal endpoints will reject the POST request, require special headers or return data that bitcoinj cannot parse as a PaymentACK. That makes the practical impact environment-dependent and is one reason the CVSS score should not be read as a measure of how many wallets are realistically exploitable.
The user also has to reach the vulnerable workflow and approve the payment. This is not described as a zero-click compromise of every application carrying bitcoinj. Exposure depends on whether an application still supports BIP-70 and whether it actually invokes the affected payment-sending path.
Which Wallets and Services Still Expose the Legacy Path?
That downstream question is the most important part of the disclosure.
The researcher’s survey says bitcoinj’s own WalletTool reaches the vulnerable sendPayment() flow without the proposed destination filtering. The report also identifies older ACINQ and cash.bitcoinj forks where the same pattern remains in source code, while more than 40 altcoin forks are described as carrying code-identical copies. Those wider fork findings were based largely on source inspection rather than individual end-to-end exploitation.
At the same time, simply finding bitcoinj inside an application does not prove exploitation. The researcher says Bitcoin Wallet for Android, for example, does not use the exact PaymentSession.sendPayment() sink. It parses the request and performs the outbound payment through its own networking logic. The report argues that this separate path still lacks private-address filtering, but that is distinct from the bitcoinj sink at the center of the disclosure.
This distinction matters for anyone assessing wallet risk. Crypto security problems often become exaggerated when a vulnerable dependency is treated as equivalent to a vulnerable product. The same issue has appeared in other forms of self-custody security, where identifying the actual affected users can be much harder than identifying the underlying technical defect.
BIP-70’s Decline Makes the Bug Smaller — but Also More Interesting
BIP-70 is no longer a mainstream Bitcoin payment mechanism. Bitcoin Core disabled it by default before removing support entirely in version 0.20.0, and many modern wallets moved toward simpler payment URI workflows instead.
That sharply limits the likely blast radius compared with a vulnerability in a payment mechanism used by almost every current Bitcoin wallet. A High CVSS score can coexist with relatively narrow real-world exposure if the vulnerable feature is rarely enabled.
But that is also why this disclosure is worth paying attention to. Old financial infrastructure rarely disappears cleanly. It survives in libraries, old integrations, forks, merchant tools and applications that have not revisited a code path in years. What looks obsolete at the protocol level can remain reachable inside software long after the broader ecosystem has moved on.
Crypto has already shown how obscure implementation layers can become operationally important. Dave Finances recently examined how integration-layer vulnerabilities can force much wider recovery measures than the feature’s original scope suggests, while a separate payments infrastructure failure demonstrated how a problem deep in the stack can ultimately interrupt user-facing payment services.
The Most Useful Next Step Is a Downstream Inventory, Not Panic
The immediate engineering fix is conceptually straightforward: validate payment destinations before connecting, restrict allowed schemes, block loopback, private and link-local addresses, handle redirects safely and account for DNS rebinding. Maintainers could also decide that the better solution is to disable or remove a deprecated payment protocol rather than continue maintaining its network-facing behavior.
The harder job is finding every application that still exposes it.
Wallet developers using bitcoinj should determine whether their software accepts BIP-70 or BIP-72 payment requests, whether it calls PaymentSession.sendPayment(), and whether any custom implementation takes getPaymentUrl() and connects to it independently. Applications that bundle bitcoinj but never expose that path are a very different risk category from software that still accepts merchant-supplied payment URLs.
Users should also avoid turning the disclosure into a reason to download unofficial replacement wallets or emergency builds. Security incidents routinely create secondary threats around software provenance, particularly when users begin searching urgently for patches before maintainers have published verified releases.
For now, there is no confirmed exploitation campaign and no announced bitcoinj fix tied to the September 29 report. The more significant question is whether maintainers and downstream wallet developers can establish how much of this legacy BIP-70 pathway is still alive in production. If usage is minimal, the incident may remain a high-severity flaw with a small practical footprint. If old integrations are still quietly processing BIP-70 requests, the real exposure could be broader than the age of the protocol suggests.
Shane Neagle is a financial markets analyst and digital assets journalist specializing in cryptocurrencies, memecoins, prediction markets, and blockchain-based financial systems. His work focuses on market structure, incentive design, liquidity dynamics, and how speculative behavior emerges across decentralized platforms.
He closely covers emerging crypto narratives, including memecoin ecosystems, on-chain activity, and the role of prediction markets in pricing political, economic, and technological outcomes. His analysis examines how capital flows, trader psychology, and platform design interact to create rapid market cycles across Web3 environments.
Alongside digital assets, Shane follows broader fintech and online trading developments, particularly where traditional financial infrastructure intersects with blockchain technology. His research-driven approach emphasizes understanding why markets behave the way they do, rather than short-term price movements, helping readers navigate fast-evolving crypto and speculative markets with clearer context.