Wallos EUVD-2026-68886

No authentication is required - endpoints/payments/search.php is explicitly described in the CVE as an unauthenticated endpoint, consistent with the CVSS PR:N metric. The deployment must expose this endpoint to the network (default for self-hosted instances with external access). The web server or PHP runtime must propagate the HTTP Proxy: request header as the HTTP_PROXY environment variable - standard behavior in CGI and PHP-FPM deployments. No non-default configuration is needed. Exploitation is bounded by the Wallos server's own network position: the attacker can only reach internal resources accessible to the Wallos host, not arbitrary internet hosts. Instances that are strictly private (no internet exposure) are not remotely exploitable.

The provided CVSS 3.1 score of 8.2 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N) accurately reflects the technical profile: the endpoint is network-reachable, requires no authentication, and no special server configuration is needed beyond a default Wallos deployment. The high confidentiality rating is justified by the SSRF primitive's ability to proxy outbound requests into internal network segments otherwise inaccessible to the attacker. Real-world priority is moderated by Wallos being a niche self-hosted personal application with a small global deployment footprint, meaning mass exploitation is unlikely; however, any instance exposed to the internet is trivially exploitable. No EPSS data was supplied, no CISA KEV listing is referenced, and no POC is cited - absence of these signals suggests this has not yet seen opportunistic scanning, though the attack class is simple and well-documented. The incomplete-fix pattern (a missed sibling endpoint) is a common source of bypasses and warrants careful review of whether any other endpoints share the same unpatched pattern.

An unauthenticated attacker sends an HTTP GET or POST request to the publicly exposed endpoints/payments/search.php endpoint with a Proxy: header pointing to an attacker-controlled host. PHP propagates this as the HTTP_PROXY environment variable, which Wallos passes directly to cURL, causing all subsequent outbound requests from that cURL handle to route through the attacker's proxy server. The attacker can then intercept request contents - including any URLs, tokens, or internal service responses - and use the Wallos server as a pivot to probe internal network resources not otherwise reachable.