Vulnerabilities

oaskit versions 0.1.0 through before 0.14.1 contain a reflected cross-site scripting flaw in Oaskit.ErrorHandler.Default (format_reason/4 and reason_to_html/1), which renders request-validation failures as an HTML page whenever the request's Accept header includes html and interpolates request-controlled strings without HTML escaping. The unescaped values are object keys from the request body or from object/deepObject query parameters (reflected in the JSON Schema error's instance path, e.g. when a schema uses additionalProperties: false) and the raw Content-Type header (reflected in unsupported-media-type errors); because browsers send Accept: text/html on ordinary navigation, a single crafted GET link such as one carrying a key like filter[ ]=x is sufficient to inject and execute script, with no form POST or attacker-hosted script required. The injected script runs in the origin of the application using oaskit, giving the attacker access to that origin's cookies, session, and same-origin responses as the victim. Any Elixir/Phoenix application using an affected oaskit version is exposed by default, since Oaskit.Plugs.ValidateRequest defaults :html_errors to true and :error_handler to the vulnerable default handler, so no opt-in is needed. No exploitation in the wild is known at this time; the flaw has a CVSS 4.0 score of 5.1 (medium), EPSS of 0.2% over 30 days, is not in CISA KEV, and a public advisory/PoC exists (GHSA-h7xw-x8wr-xpcc).

Do: Upgrade oaskit to 0.14.1 or later. Applications that cannot upgrade immediately should set :html_errors to false (or supply a custom error handler that HTML-escapes reflected values) on Oaskit.Plugs.ValidateRequest, since the vulnerable default handler is enabled by default. Audit whether your application renders validation errors to browser navigations (e.g., GET endpoints with object/deepObject query parameters rejected under additionalProperties: false) and whether links to them could be attacker-crafted.

Kludex Starlette prior to version 1.0.1 did not validate the HTTP Host request header before using it to reconstruct request.url, an inconsistency classified as HTTP request/response smuggling (CWE-444). Because routing operates on the raw ASGI scope path while request.url is rebuilt from the unvalidated Host header, an attacker can send a malformed Host header so that request.url.path differs from the path the router actually processed. Any middleware or endpoint that enforces security restrictions based on request.url rather than the raw scope path can then be tricked into approving requests that should have been blocked, bypassing those controls. All Starlette deployments below 1.0.1 are affected, both direct users and downstream products that bundle the library, including Red Hat offerings such as Ansible Automation Platform, OpenShift AI, OpenShift Lightspeed, Satellite, AI Inference Server, Migration Toolkit for Applications, and Enterprise Linux AI. CISA added the flaw to the Known Exploited Vulnerabilities catalog on 2026-09-02, confirming active exploitation; related reporting describes attackers deploying reverse shells and crypto miners, and EPSS ranks it in the 98th percentile with a 36.3% probability of exploitation within 30 days.

Do: Upgrade Starlette to 1.0.1 or later, which validates the Host header against RFC 9112/RFC 3986 grammar and falls back to scope['server'] for malformed values, and apply the corresponding Red Hat updates for each bundled product listed above. Until patched, review middleware and endpoints that enforce security decisions from request.url and validate or pin the Host header at your reverse proxy or load balancer. As a KEV entry, federal agencies must patch per BOD 26-04 timelines based on each asset's internet exposure, and operators of internet-facing AI infrastructure should verify their Starlette/FastAPI dependency versions.