surya EUVD-2026-71136

The surya screenshot server (screenshot_app.py) must be running and reachable by the attacker over the network - this server is an optional component not started during normal library usage, so it must have been deliberately launched. No authentication, special headers, session tokens, or pre-existing access are required on any of the three vulnerable routes. Exploitation is constrained to file types that Pillow's Image.open or pypdfium2.PdfDocument will successfully parse (image formats and PDFs); arbitrary binary or text files outside those formats cannot be directly rendered but the /info oracle can still confirm their existence. The attack does not apply if the screenshot server is not running or is bound exclusively to 127.0.0.1. Files must be readable by the OS user account under which the screenshot server process runs.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N) accurately reflects the mechanics: zero-complexity, zero-authentication network exploitation with full confidentiality impact on the vulnerable system. In absolute terms this is a straightforward high-severity information disclosure. Real-world risk is bounded, however, by the niche deployment footprint of surya and by the fact that the screenshot server is an optional component - it is not started during normal library use and is unlikely to be internet-facing in typical ML research workflows. No CISA KEV listing and no public exploit code are identified; EPSS data was not supplied. The VulnCheck advisory and GitHub issue #518 represent initial researcher disclosure without confirmed active exploitation. Priority should be high for any environment that has deployed the screenshot server in a network-accessible position, but the overall population of such deployments is likely small.

An attacker scans for or identifies a host with the surya screenshot server listening on a network-accessible port and sends an HTTP request to /info with file_path set to a sensitive target such as /home/user/.ssh/id_rsa or an application secrets file, confirming the file's existence via the oracle response. The attacker then requests /page or /process with the same path, receiving the file's contents rendered and base64-encoded in the HTTP response body, completing exfiltration without any credentials or prior access. No exploit code is required beyond a standard HTTP client.