{"id":"CVE-2026-66296","aliases":["EEF-CVE-2026-66296","EUVD-2026-52407","GHSA-5rgx-mcq5-r7wv","GHSA-h7xw-x8wr-xpcc"],"status":"published","title":"Reflected XSS in oaskit's default HTML error handler","description":"Improper Neutralization of Input During Web Page Generation (XSS) vulnerability in lud oaskit allows reflected cross-site scripting via the default HTML error handler.\n\nOaskit.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.\n\nBecause 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[\u003c/code\u003e\u003c/h2\u003e\u003cscript\u003ealert(document.domain)\u003c/script\u003e]=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.\n\nBoth 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.\n\nThis issue affects oaskit: from 0.1.0 before 0.14.1.","severity":{"version":"4.0","score":5.1,"vector":"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","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-09","score":0.00367,"percentile":0.3079,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-79"],"published":"2026-08-03T19:04:30Z","modified":"2026-10-28T02:30:40Z","fixes":[{"ecosystem":"Hex","package":"oaskit","fixed_in":["0.14.1"],"sources":["osv"]}],"affected":[{"source":"osv","ecosystem":"Hex","package":"oaskit","ranges":[{"type":"SEMVER","events":[{"introduced":"0.1.0"},{"fixed":"0.14.1"}]}],"versions":["0.1.0","0.1.1","0.1.2","0.10.0","0.10.1","0.11.0","0.12.0","0.13.0","0.13.1","0.13.2","0.14.0","0.2.0","0.3.0","0.3.1","0.4.0","0.4.1","0.5.0","0.5.1","0.6.0","0.7.0","0.8.0","0.9.0","0.9.1"]}],"products":[{"vendor":"lud","product":"oaskit"}],"references":[{"url":"https://github.com/lud/oaskit/security/advisories/GHSA-h7xw-x8wr-xpcc","tags":["vendor-advisory","related","exploit","Exploit","Vendor Advisory","advisory"]},{"url":"https://cna.erlef.org/cves/CVE-2026-66296.html","tags":["related","Patch","Third Party Advisory","web"]},{"url":"https://osv.dev/vulnerability/EEF-CVE-2026-66296","tags":["related","Patch","Third Party Advisory","web"]},{"url":"https://github.com/lud/oaskit/commit/b70c6b2eaf0b11bdd0bbb21b8a87dbb3d46918a1","tags":["patch","Patch","fix"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-66296","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-5rgx-mcq5-r7wv"},{"url":"https://github.com","tags":["web"]},{"url":"https://repo.hex.pm","tags":["web"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/66xxx/CVE-2026-66296.json","tags":["advisory"]},{"url":"https://github.com/lud/oaskit","tags":["package"]},{"url":"https://hex.pm/packages/oaskit","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-66296","title":"Reflected XSS in oaskit's default HTML error handler","description":"Improper Neutralization of Input During Web Page Generation (XSS) vulnerability in lud oaskit allows reflected cross-site scripting via the default HTML error handler.\n\nOaskit.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.\n\nBecause 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[\u003c/code\u003e\u003c/h2\u003e\u003cscript\u003ealert(document.domain)\u003c/script\u003e]=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.\n\nBoth 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.\n\nThis issue affects oaskit: from 0.1.0 before 0.14.1.","status":"published","published":"2026-08-03T19:04:30.556Z","modified":"2026-08-03T19:50:27.86Z","cvss":[{"version":"4.0","score":5.1,"vector":"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","level":"medium","assessor":"cna"}],"cwes":["CWE-79"],"updated_at":"2026-11-02T14:20:12.939084Z"}],"euvd":[{"id":"EUVD-2026-52407","description":"Improper Neutralization of Input During Web Page Generation (XSS) vulnerability in lud oaskit allows reflected cross-site scripting via the default HTML error handler.\n\nOaskit.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.\n\nBecause 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[\u003c/code\u003e\u003c/h2\u003e\u003cscript\u003ealert(document.domain)\u003c/script\u003e]=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.\n\nBoth 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.\n\nThis issue affects oaskit: from 0.1.0 before 0.14.1.","status":"published","published":"2026-08-03T19:04:30Z","modified":"2026-08-03T19:50:27Z","cvss":[{"version":"4.0","score":5.1,"vector":"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","level":"medium"}],"updated_at":"2026-11-02T18:02:23.68186Z"}],"ghsa":[{"id":"GHSA-5rgx-mcq5-r7wv","title":"Improper Neutralization of Input During Web Page Generation (XSS) vulnerability in lud oaskit...","description":"Improper Neutralization of Input During Web Page Generation (XSS) vulnerability in lud oaskit allows reflected cross-site scripting via the default HTML error handler.\n\nOaskit.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.\n\nBecause 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[\u003c/code\u003e\u003c/h2\u003e\u003cscript\u003ealert(document.domain)\u003c/script\u003e]=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.\n\nBoth 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.\n\nThis issue affects oaskit: from 0.1.0 before 0.14.1.","status":"published","published":"2026-08-03T21:31:37Z","modified":"2026-08-17T21:31:13Z","cvss":[{"version":"4.0","score":5.1,"vector":"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","level":"medium"},{"version":"3.1","score":6.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N","level":"medium"}],"cwes":["CWE-79"],"updated_at":"2026-11-02T15:10:34.652326Z"}],"nvd":[{"id":"CVE-2026-66296","description":"Improper Neutralization of Input During Web Page Generation (XSS) vulnerability in lud oaskit allows reflected cross-site scripting via the default HTML error handler.\n\nOaskit.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.\n\nBecause 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[\u003c/code\u003e\u003c/h2\u003e\u003cscript\u003ealert(document.domain)\u003c/script\u003e]=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.\n\nBoth 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.\n\nThis issue affects oaskit: from 0.1.0 before 0.14.1.","status":"published","published":"2026-08-03T20:17:25.72Z","modified":"2026-10-23T21:10:00.157Z","cvss":[{"version":"4.0","score":5.1,"vector":"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","level":"medium","assessor":"secondary"},{"version":"3.1","score":6.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N","level":"medium","assessor":"primary"}],"cwes":["CWE-79"],"updated_at":"2026-11-02T14:12:34.643497Z"}],"osv":[{"id":"CVE-2026-66296","title":"Reflected XSS in oaskit's default HTML error handler","description":"Improper Neutralization of Input During Web Page Generation (XSS) vulnerability in lud oaskit allows reflected cross-site scripting via the default HTML error handler.\n\nOaskit.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.\n\nBecause 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[\u003c/code\u003e\u003c/h2\u003e\u003cscript\u003ealert(document.domain)\u003c/script\u003e]=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.\n\nBoth 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.\n\nThis issue affects oaskit: from 0.1.0 before 0.14.1.","status":"published","published":"2026-08-03T19:04:30.556Z","modified":"2026-10-28T02:30:40.547590777Z","cvss":[{"version":"4.0","score":5.1,"vector":"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","level":"medium"}],"cwes":["CWE-79"],"updated_at":"2026-11-02T15:45:14.46177Z"},{"id":"EEF-CVE-2026-66296","title":"Reflected XSS in oaskit's default HTML error handler","description":"## Summary\n\nImproper Neutralization of Input During Web Page Generation (XSS) vulnerability in lud oaskit allows reflected cross-site scripting via the default HTML error handler.\n\n`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.\n\nBecause 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[\u003c/code\u003e\u003c/h2\u003e\u003cscript\u003ealert(document.domain)\u003c/script\u003e]=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.\n\nBoth 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.\n\nThis issue affects oaskit: from 0.1.0 before 0.14.1.\n\n## Workarounds\n\nDisable HTML error rendering so that validation failures are returned as JSON only:\n\n```elixir\nplug Oaskit.Plugs.ValidateRequest, html_errors: false\n```\n\nThis prevents the vulnerable HTML page from being rendered at all, on any oaskit version. Alternatively, configure a custom `:error_handler` that does not emit HTML built from request-derived values.","status":"published","published":"2026-08-03T19:04:30.556Z","modified":"2026-09-08T08:30:06.87929829Z","cvss":[{"version":"4.0","score":5.1,"vector":"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","level":"medium"}],"cwes":["CWE-79"],"updated_at":"2026-11-02T15:46:33.520522Z"}]}}