EUVD-2026-52407
GHSA-5rgx-mcq5-r7wv
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Network-delivered reflected XSS requiring victim browser navigation (UI:R); scope changes to browser context (S:C); low confidentiality and integrity impact on victim's session data.
Primary rating from Vendor (EEF).
CVSS VectorVendor: EEF
Lifecycle Timeline
2DescriptionCVE.org
Improper Neutralization of Input During Web Page Generation (XSS) vulnerability in lud oaskit allows reflected cross-site scripting via the default HTML error handler.
Oaskit.ErrorHandler.Default.format_reason/4 and Oaskit.ErrorHandler.Default.reason_to_html/1 in lib/oaskit/error_handler/default.ex render request-validation failures as an HTML page whenever the request's Accept header contains html, interpolating request-controlled strings into that page without HTML escaping. The unescaped values are object keys taken from a request body or from an object or deepObject query parameter, which appear in the JSON Schema error's instance path when a schema rejects them (for example under additionalProperties: false), and the raw Content-Type header, reflected in unsupported-media-type errors when it fails to parse.
Because browsers send Accept: text/html on ordinary top-level navigation, a crafted GET link is sufficient to trigger the error page; no form submission, custom Content-Type, or attacker-controlled script on the victim's side is required. A payload such as filter[</code></h2><script>alert(document.domain)</script>]=x terminates the enclosing markup and the injected script executes in the origin of the application using oaskit, giving it access to that origin's cookies, session, and same-origin responses.
Both HTML error rendering and the vulnerable handler are enabled by default: Oaskit.Plugs.ValidateRequest defaults :html_errors to true and :error_handler to Oaskit.ErrorHandler.Default, so applications following the documented usage are affected without any opt-in.
This issue affects oaskit: from 0.1.0 before 0.14.1.
AnalysisAI
Reflected XSS in oaskit (Elixir/Plug OpenAPI request-validation library) versions 0.1.0 through 0.14.0 allows an unauthenticated remote attacker to execute arbitrary JavaScript in a victim's browser by inducing them to navigate to a crafted GET URL. The default HTML error handler interpolates request-controlled strings - object keys from query parameters or request bodies that appear in JSON Schema instance paths, and the raw Content-Type header - directly into HTML error pages without escaping. Both HTML error rendering and the vulnerable handler are enabled by default, so all applications following documented oaskit usage are exposed without any opt-in configuration; no public exploit tool is identified at time of analysis, though the advisory contains a working payload example demonstrating trivial exploitability.
Technical ContextAI
Oaskit is an Elixir library integrating with the Plug web framework to validate HTTP requests against OpenAPI 3.x specifications. The vulnerable code resides in Oaskit.ErrorHandler.Default (lib/oaskit/error_handler/default.ex), specifically the format_reason/4 and reason_to_html/1 functions. When request validation fails and the request's Accept header contains 'html', the handler renders an HTML error page. The root cause is CWE-79 (Improper Neutralization of Input During Web Page Generation): object keys from request bodies or deepObject/object-typed query parameters appear in JSON Schema instance paths when additionalProperties: false rejects them, and the raw Content-Type header is reflected in unsupported-media-type errors - both are interpolated into the HTML response via Elixir string templates without HTML escaping. The fix in commit b70c6b2 introduces a private esc/1 helper wrapping Plug.HTML.html_escape/1 and applies it to every request-derived interpolation site across the template. The affected CPE is cpe:2.3:a:lud:oaskit:*:*:*:*:*:*:*:*.
RemediationAI
Upgrade oaskit to version 0.14.1 or later; the fix is confirmed in commit b70c6b2 (https://github.com/lud/oaskit/commit/b70c6b2eaf0b11bdd0bbb21b8a87dbb3d46918a1), which applies Plug.HTML.html_escape/1 to all request-derived values before HTML interpolation. Consult the official advisory at https://github.com/lud/oaskit/security/advisories/GHSA-h7xw-x8wr-xpcc for upgrade guidance. If an immediate upgrade is not possible, the most effective workaround is to disable HTML error rendering by setting the :html_errors option to false on Oaskit.Plugs.ValidateRequest - this fully eliminates the vulnerable code path, though browser clients will no longer receive human-readable HTML validation error pages. As an alternative, replacing the :error_handler option with a custom implementation that does not render HTML bypasses the vulnerable default handler entirely. Both workarounds trade away error-page ergonomics for browser clients but completely mitigate the injection risk.
Same weakness CWE-79 – Cross-site Scripting (XSS)
View allShare
External POC / Exploit Code
Leaving vuln.today