ERPNext EUVD-2026-30194

Exploitation requires a valid ERPNext user account with at minimum low-privilege access, as confirmed by the CVSS PR:L vector - unauthenticated exploitation is not possible. The attacker must have the ability to send crafted HTTP requests to the specific endpoint that triggers outbound server-side HTTP calls; the exact endpoint name is not disclosed in the public advisory, meaning attackers must identify it through source code review or probing. No non-default configuration is described as required beyond having an affected ERPNext version deployed. Exploitation impact is bounded by what services are reachable from the ERPNext server's network position - environments with strict egress controls or no access to internal metadata services will experience reduced impact. The SSVC automatable=no assessment indicates exploitation requires attacker-specific interaction and cannot be mass-exploited via automated scanning.

The CVSS 5.0 score reflects a medium-severity finding: network-reachable (AV:N), low complexity (AC:L), requiring low privileges (PR:L), no user interaction (UI:N), but with Changed scope (S:C) and only partial confidentiality impact (C:L) with no integrity or availability impact. The PR:L requirement meaningfully raises the bar above unauthenticated exploitation. EPSS at 0.02% (7th percentile) signals negligible observed real-world exploitation probability. The SSVC framework further characterizes this as exploitation=none, automatable=no, technical impact=partial - consistent with a vulnerability that poses theoretical risk but has not been operationalized in attack campaigns. There is no CISA KEV listing and no public exploit code identified. The most significant residual risk is in environments where ERPNext is accessible to untrusted authenticated users (e.g., multi-tenant deployments, customer-facing portals) and where the application server has unfiltered egress to internal infrastructure. In hardened, single-tenant, or egress-filtered environments, real-world risk is further reduced.

An authenticated ERPNext user with low-privilege access identifies the SSRF-vulnerable endpoint and submits a crafted request with a URL pointing to an internal cloud metadata service (e.g., http://169.254.169.254/latest/meta-data/iam/security-credentials/). The ERPNext server, lacking proper URL validation, initiates the HTTP call and the attacker receives the response - potentially leaking IAM credentials, instance identity data, or internal API tokens. No public exploit code is known at time of analysis, and SSVC confirms the technique is not automatable, requiring targeted exploitation by a determined authenticated user.