CVE-2025-54590: 
JavaScript vulnerability analysis and mitigation

CVE-2025-54590 is a blind Server-Side Request Forgery (SSRF) vulnerability in webfinger.js, a TypeScript-based WebFinger client for browsers and Node.js environments. Affecting versions 2.8.0 and below, the flaw allows unauthenticated remote attackers to cause a server using the library to issue GET requests to arbitrary hosts, paths, and ports — including localhost and LAN addresses — by supplying a crafted user address to the lookup function. The vulnerability was discovered by Ori Hollander of the JFrog Vulnerability Research team and disclosed on July 27, 2025, with a CVE published on August 1, 2025. It carries a CVSS v4.0 base score of 6.9 (Medium) (GitHub Advisory, Red Hat CVE).

The root cause is insufficient input validation in the lookup function's host-parsing logic (CWE-918: Server-Side Request Forgery). The library extracts the host from a user address by splitting on @ and taking everything after the first occurrence, with no further sanitization. The only localhost check tests whether the host string starts with "localhost" and ends with a port number, meaning inputs like 127.0.0.1, localhost:1234/abc, or private LAN ranges (e.g., 192.168.x.x) bypass the check entirely. An attacker can craft an address such as user@localhost:7000/admin/restricted_page?, causing the library to construct and issue a request to https://localhost:7000/admin/restricted_page?/.well-known/webfinger?resource=acct:user@localhost:7000/admin/restricted_page? — effectively reaching arbitrary paths on the host or internal network. The vulnerability is exploitable by any user who can submit a WebFinger lookup request to an application using the library (GitHub Advisory).

Successful exploitation enables blind SSRF attacks, allowing an unauthenticated attacker to probe internal services running on the server's host or local network (e.g., admin panels, metadata endpoints, internal APIs) by controlling the host, path, and port of outbound GET requests. While the attacker cannot directly read responses (blind SSRF), they can infer service availability and potentially chain the attack with known vulnerabilities in locally running services. The confidentiality impact is limited to information leakage about internal network topology and service availability; integrity and availability of the host system are not directly affected (GitHub Advisory).

A proof-of-concept is publicly documented in the GitHub Security Advisory, demonstrating exploitation using a simple curl command against a server running the vulnerable library. No exploit kits or in-the-wild exploitation have been reported. The vulnerability requires no authentication and no user interaction, making it trivially exploitable against any internet-facing application using webfinger.js ≤ 2.8.0. The EPSS score is approximately 0.039% (low probability of near-term exploitation). It is not listed in the CISA Known Exploited Vulnerabilities catalog (GitHub Advisory).

1. Reconnaissance: Identify internet-facing applications (e.g., ActivityPub/Fediverse servers) that accept user-supplied WebFinger lookup addresses and use webfinger.js ≤ 2.8.0 as a dependency.
2. Identify the lookup endpoint: Locate the API endpoint that triggers a WebFinger lookup (e.g., /api/v1/search_user?search=<address>).
3. Craft a malicious address: Construct a user address that embeds a target internal host, port, and path after the @ symbol, such as user@127.0.0.1:8080/admin/secret? or user@192.168.1.100:9200/_cat/indices?.
4. Send the request: Issue a GET request to the vulnerable endpoint with the crafted address: curl "http://target.example.com/api/v1/search_user?search=user@127.0.0.1:8080/admin/secret?"
5. Observe blind SSRF: The server will issue a GET request to https://127.0.0.1:8080/admin/secret?/.well-known/webfinger?resource=acct:user@127.0.0.1:8080/admin/secret?. Infer service availability from timing differences or error responses returned to the attacker.
6. Chain with local vulnerabilities: If a known vulnerable service (e.g., an unauthenticated admin panel or cloud metadata endpoint at 169.254.169.254) is running locally, use the SSRF to trigger actions against it (GitHub Advisory).

• Network: Outbound GET requests from the application server to 127.x.x.x, 10.x.x.x, 172.16-31.x.x, 192.168.x.x, or 169.254.x.x addresses, particularly to non-standard ports or paths not matching /.well-known/webfinger.
• Logs: Application or web server access logs showing WebFinger lookup requests with user addresses containing IP literals, path segments, or query string characters after the @ symbol (e.g., user@127.0.0.1:PORT/path?).
• Logs: Internal service logs (e.g., admin panels, databases, metadata services) showing unexpected GET requests with query strings containing /.well-known/webfinger?resource=acct: from the application server's IP.
• Network: Unusual DNS queries or direct IP connections originating from the Node.js application process to internal RFC 1918 address space.

Upgrade webfinger.js to version 2.8.1, which introduces comprehensive SSRF protection including blocking of all private/loopback IPv4 and IPv6 ranges, DNS resolution in Node.js environments to catch domains resolving to private IPs, path injection prevention, and redirect validation. The fix is available via npm (npm install webfinger.js@2.8.1), yarn, or bun. No configuration-based workaround exists for the vulnerable versions; upgrading is the only recommended remediation. If upgrading is temporarily not possible, applications should implement server-side input validation to reject user addresses containing IP literals, path segments, or query characters before passing them to the library (GitHub Release v2.8.1, Security Fix Commit).

The vulnerability was discovered and responsibly disclosed by Ori Hollander of the JFrog Vulnerability Research team, credited in the GitHub Security Advisory. The maintainer (silverbucket) promptly released version 2.8.1 with a comprehensive security overhaul, including new SSRF protection documentation. Red Hat tracked the CVE as part of their security advisories. No significant broader media coverage or social media discussion has been identified beyond standard vulnerability database entries (GitHub Advisory, Red Hat CVE).