bitcoinj EUVD-2026-102547

Exploitation requires that the target application actually uses bitcoinj's PaymentSession / Payment Request Handler to parse a BIP70-style payment request, and that the attacker can supply or influence that request (including the pki_type argument) so url.openConnection resolves to an attacker-chosen endpoint. Limiting factors: the BIP70 payment-request protocol is deprecated and disabled or unused in many modern deployments, so applications that never process payment requests are not exposed; impact is bounded to SSRF (Low confidentiality/integrity/availability per CVSS, no code execution), and realized damage depends on what internal services or metadata endpoints are reachable from the host. No OS-level authentication is needed (PR:N), but the application-level prerequisite of invoking payment-request parsing is a genuine constraint.

This is a moderate-risk SSRF (CWE-918) in the bitcoinj library's BIP70 Payment Request Handler, rated CVSS 4.0 6.9 (MEDIUM). The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) signals network-reachable, low-complexity, unauthenticated triggering, but all impact sub-scores are Low (VC:L/VI:L/VA:L) and subsequent-system impacts are None - consistent with a classic SSRF that lets an attacker coerce outbound connections rather than achieve code execution. The E:P exploit-maturity flag marks a proof-of-concept, which aligns with the input signal that POC/exploit code is publicly available via the bitcoinj issue tracker. No EPSS score was supplied, so exploitation probability cannot be quantified, and the CVE is NOT in CISA KEV, so there is no evidence of active exploitation. The disclosing source is VulDB (a third party), and the project 'has not responded yet' - so affected-version and fix data are unconfirmed by the vendor. Net assessment: a real but lower-tier priority - the AV:N/PR:N vector looks alarming in isolation, yet the vulnerability only manifests when an application actually invokes PaymentSession to process an attacker-influenced payment request, and the BIP70 payment-request protocol it depends on is largely deprecated, which materially narrows real-world exposure. Prioritize patching/removal where bitcoinj payment-request handling is enabled, but this is not an emergency widespread-exploitation scenario.

An attacker crafts a malicious BIP70 payment request and delivers it to a bitcoinj-based wallet or service that parses it via PaymentSession; a manipulated pki_type value causes url.openConnection to connect to an attacker-chosen URL, forcing the server to make requests to internal/metadata endpoints. A proof-of-concept has been publicly disclosed on the bitcoinj issue tracker, so the trigger is known. Given CVSS AC:L and PR:N, no special complexity or authentication is required to drive the outbound request, though the application must be configured to process the payment request.