oaskit

Version	Released
`0.14.2` patch	Jul 06, 2026
`0.14.1` patch	Jul 05, 2026
`0.14.0` minor 1 CVE	Jun 28, 2026
`0.13.2` patch 1 CVE	Jun 26, 2026
`0.13.1` patch 1 CVE	May 29, 2026
`0.13.0` minor 1 CVE	May 10, 2026
`0.12.0` minor 1 CVE	Mar 19, 2026
`0.11.0` minor 1 CVE	Jan 20, 2026
`0.10.1` patch 1 CVE	Jan 15, 2026
`0.10.0` minor 1 CVE	Jan 08, 2026
`0.9.1` patch 1 CVE	Dec 31, 2025
`0.9.0` minor 1 CVE	Dec 11, 2025
`0.8.0` minor 1 CVE	Nov 21, 2025
`0.7.0` minor 1 CVE	Nov 13, 2025
`0.6.0` minor 1 CVE	Oct 11, 2025
`0.5.1` patch 1 CVE	Oct 10, 2025
`0.5.0` minor 1 CVE	Sep 16, 2025
`0.4.1` patch 1 CVE	Aug 25, 2025
`0.4.0` minor 1 CVE	Aug 21, 2025
`0.3.1` patch 1 CVE	Jul 18, 2025
`0.3.0` minor 1 CVE	Jul 10, 2025
`0.2.0` minor 1 CVE	Jul 05, 2025
`0.1.2` patch 1 CVE	Jun 30, 2025
`0.1.1` patch 1 CVE	Jun 29, 2025
`0.1.0` initial 1 CVE	Jun 29, 2025

0.14.2 patch

Jul 06, 2026

0.14.1 patch

Jul 05, 2026

0.14.0 minor

1 CVE

CVE-2026-66296 EEF-CVE-2026-66296 GHSA-h7xw-x8wr-xpcc Aug 03, 2026

Reflected XSS in oaskit's default HTML error handler

Low

Network Low None

Summary

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.

Workarounds

Disable HTML error rendering so that validation failures are returned as JSON only:

plug Oaskit.Plugs.ValidateRequest, html_errors: false

This 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.

Affected 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

+ 11 more


            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

Fixed in


          0.14.1

References

Updated Sep 08, 2026 · Source: OSV.dev

Jun 28, 2026

0.13.2 patch

1 CVE

CVE-2026-66296 EEF-CVE-2026-66296 GHSA-h7xw-x8wr-xpcc Aug 03, 2026

Reflected XSS in oaskit's default HTML error handler

Low

Network Low None

Summary

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.

Workarounds

Disable HTML error rendering so that validation failures are returned as JSON only:

plug Oaskit.Plugs.ValidateRequest, html_errors: false

This 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.

Affected 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

+ 11 more


            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

Fixed in


          0.14.1

References

Updated Sep 08, 2026 · Source: OSV.dev

Jun 26, 2026

0.13.1 patch

1 CVE

CVE-2026-66296 EEF-CVE-2026-66296 GHSA-h7xw-x8wr-xpcc Aug 03, 2026

Reflected XSS in oaskit's default HTML error handler

Low

Network Low None

Summary

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.

Workarounds

Disable HTML error rendering so that validation failures are returned as JSON only:

plug Oaskit.Plugs.ValidateRequest, html_errors: false

This 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.

Affected 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

+ 11 more


            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

Fixed in


          0.14.1

References

Updated Sep 08, 2026 · Source: OSV.dev

May 29, 2026

0.13.0 minor

1 CVE

CVE-2026-66296 EEF-CVE-2026-66296 GHSA-h7xw-x8wr-xpcc Aug 03, 2026

Reflected XSS in oaskit's default HTML error handler

Low

Network Low None

Summary

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.

Workarounds

Disable HTML error rendering so that validation failures are returned as JSON only:

plug Oaskit.Plugs.ValidateRequest, html_errors: false

This 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.

Affected 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

+ 11 more


            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

Fixed in


          0.14.1

References

Updated Sep 08, 2026 · Source: OSV.dev

May 10, 2026

0.12.0 minor

1 CVE

CVE-2026-66296 EEF-CVE-2026-66296 GHSA-h7xw-x8wr-xpcc Aug 03, 2026

Reflected XSS in oaskit's default HTML error handler

Low

Network Low None

Summary

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.

Workarounds

Disable HTML error rendering so that validation failures are returned as JSON only:

plug Oaskit.Plugs.ValidateRequest, html_errors: false

This 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.

Affected 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

+ 11 more


            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

Fixed in


          0.14.1

References

Updated Sep 08, 2026 · Source: OSV.dev

Mar 19, 2026

0.11.0 minor

1 CVE

CVE-2026-66296 EEF-CVE-2026-66296 GHSA-h7xw-x8wr-xpcc Aug 03, 2026

Reflected XSS in oaskit's default HTML error handler

Low

Network Low None

Summary

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.

Workarounds

Disable HTML error rendering so that validation failures are returned as JSON only:

plug Oaskit.Plugs.ValidateRequest, html_errors: false

This 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.

Affected 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

+ 11 more


            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

Fixed in


          0.14.1

References

Updated Sep 08, 2026 · Source: OSV.dev

Jan 20, 2026

0.10.1 patch

1 CVE

CVE-2026-66296 EEF-CVE-2026-66296 GHSA-h7xw-x8wr-xpcc Aug 03, 2026

Reflected XSS in oaskit's default HTML error handler

Low

Network Low None

Summary

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.

Workarounds

Disable HTML error rendering so that validation failures are returned as JSON only:

plug Oaskit.Plugs.ValidateRequest, html_errors: false

This 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.

Affected 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

+ 11 more


            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

Fixed in


          0.14.1

References

Updated Sep 08, 2026 · Source: OSV.dev

Jan 15, 2026

0.10.0 minor

1 CVE

CVE-2026-66296 EEF-CVE-2026-66296 GHSA-h7xw-x8wr-xpcc Aug 03, 2026

Reflected XSS in oaskit's default HTML error handler

Low

Network Low None

Summary

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.

Workarounds

Disable HTML error rendering so that validation failures are returned as JSON only:

plug Oaskit.Plugs.ValidateRequest, html_errors: false

This 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.

Affected 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

+ 11 more


            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

Fixed in


          0.14.1

References

Updated Sep 08, 2026 · Source: OSV.dev

Jan 08, 2026

0.9.1 patch

1 CVE

CVE-2026-66296 EEF-CVE-2026-66296 GHSA-h7xw-x8wr-xpcc Aug 03, 2026

Reflected XSS in oaskit's default HTML error handler

Low

Network Low None

Summary

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.

Workarounds

Disable HTML error rendering so that validation failures are returned as JSON only:

plug Oaskit.Plugs.ValidateRequest, html_errors: false

This 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.

Affected 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

+ 11 more


            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

Fixed in


          0.14.1

References

Updated Sep 08, 2026 · Source: OSV.dev

Dec 31, 2025

0.9.0 minor

1 CVE

CVE-2026-66296 EEF-CVE-2026-66296 GHSA-h7xw-x8wr-xpcc Aug 03, 2026

Reflected XSS in oaskit's default HTML error handler

Low

Network Low None

Summary

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.

Workarounds

Disable HTML error rendering so that validation failures are returned as JSON only:

plug Oaskit.Plugs.ValidateRequest, html_errors: false

This 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.

Affected 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

+ 11 more


            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

Fixed in


          0.14.1

References

Updated Sep 08, 2026 · Source: OSV.dev

Dec 11, 2025

0.8.0 minor

1 CVE

CVE-2026-66296 EEF-CVE-2026-66296 GHSA-h7xw-x8wr-xpcc Aug 03, 2026

Reflected XSS in oaskit's default HTML error handler

Low

Network Low None

Summary

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.

Workarounds

Disable HTML error rendering so that validation failures are returned as JSON only:

plug Oaskit.Plugs.ValidateRequest, html_errors: false

This 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.

Affected 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

+ 11 more


            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

Fixed in


          0.14.1

References

Updated Sep 08, 2026 · Source: OSV.dev

Nov 21, 2025

0.7.0 minor

1 CVE

CVE-2026-66296 EEF-CVE-2026-66296 GHSA-h7xw-x8wr-xpcc Aug 03, 2026

Reflected XSS in oaskit's default HTML error handler

Low

Network Low None

Summary

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.

Workarounds

Disable HTML error rendering so that validation failures are returned as JSON only:

plug Oaskit.Plugs.ValidateRequest, html_errors: false

This 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.

Affected 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

+ 11 more


            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

Fixed in


          0.14.1

References

Updated Sep 08, 2026 · Source: OSV.dev

Nov 13, 2025

0.6.0 minor

1 CVE

CVE-2026-66296 EEF-CVE-2026-66296 GHSA-h7xw-x8wr-xpcc Aug 03, 2026

Reflected XSS in oaskit's default HTML error handler

Low

Network Low None

Summary

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.

Workarounds

Disable HTML error rendering so that validation failures are returned as JSON only:

plug Oaskit.Plugs.ValidateRequest, html_errors: false

This 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.

Affected 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

+ 11 more


            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

Fixed in


          0.14.1

References

Updated Sep 08, 2026 · Source: OSV.dev

Oct 11, 2025

0.5.1 patch

1 CVE

CVE-2026-66296 EEF-CVE-2026-66296 GHSA-h7xw-x8wr-xpcc Aug 03, 2026

Reflected XSS in oaskit's default HTML error handler

Low

Network Low None

Summary

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.

Workarounds

Disable HTML error rendering so that validation failures are returned as JSON only:

plug Oaskit.Plugs.ValidateRequest, html_errors: false

This 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.

Affected 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

+ 11 more


            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

Fixed in


          0.14.1

References

Updated Sep 08, 2026 · Source: OSV.dev

Oct 10, 2025

0.5.0 minor

1 CVE

CVE-2026-66296 EEF-CVE-2026-66296 GHSA-h7xw-x8wr-xpcc Aug 03, 2026

Reflected XSS in oaskit's default HTML error handler

Low

Network Low None

Summary

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.

Workarounds

Disable HTML error rendering so that validation failures are returned as JSON only:

plug Oaskit.Plugs.ValidateRequest, html_errors: false

This 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.

Affected 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

+ 11 more


            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

Fixed in


          0.14.1

References

Updated Sep 08, 2026 · Source: OSV.dev

Sep 16, 2025

0.4.1 patch

1 CVE

CVE-2026-66296 EEF-CVE-2026-66296 GHSA-h7xw-x8wr-xpcc Aug 03, 2026

Reflected XSS in oaskit's default HTML error handler

Low

Network Low None

Summary

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.

Workarounds

Disable HTML error rendering so that validation failures are returned as JSON only:

plug Oaskit.Plugs.ValidateRequest, html_errors: false

This 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.

Affected 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

+ 11 more


            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

Fixed in


          0.14.1

References

Updated Sep 08, 2026 · Source: OSV.dev

Aug 25, 2025

0.4.0 minor

1 CVE

CVE-2026-66296 EEF-CVE-2026-66296 GHSA-h7xw-x8wr-xpcc Aug 03, 2026

Reflected XSS in oaskit's default HTML error handler

Low

Network Low None

Summary

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.

Workarounds

Disable HTML error rendering so that validation failures are returned as JSON only:

plug Oaskit.Plugs.ValidateRequest, html_errors: false

This 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.

Affected 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

+ 11 more


            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

Fixed in


          0.14.1

References

Updated Sep 08, 2026 · Source: OSV.dev

Aug 21, 2025

0.3.1 patch

1 CVE

CVE-2026-66296 EEF-CVE-2026-66296 GHSA-h7xw-x8wr-xpcc Aug 03, 2026

Reflected XSS in oaskit's default HTML error handler

Low

Network Low None

Summary

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.

Workarounds

Disable HTML error rendering so that validation failures are returned as JSON only:

plug Oaskit.Plugs.ValidateRequest, html_errors: false

This 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.

Affected 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

+ 11 more


            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

Fixed in


          0.14.1

References

Updated Sep 08, 2026 · Source: OSV.dev

Jul 18, 2025

0.3.0 minor

1 CVE

CVE-2026-66296 EEF-CVE-2026-66296 GHSA-h7xw-x8wr-xpcc Aug 03, 2026

Reflected XSS in oaskit's default HTML error handler

Low

Network Low None

Summary

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.

Workarounds

Disable HTML error rendering so that validation failures are returned as JSON only:

plug Oaskit.Plugs.ValidateRequest, html_errors: false

This 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.

Affected 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

+ 11 more


            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

Fixed in


          0.14.1

References

Updated Sep 08, 2026 · Source: OSV.dev

Jul 10, 2025

0.2.0 minor

1 CVE

CVE-2026-66296 EEF-CVE-2026-66296 GHSA-h7xw-x8wr-xpcc Aug 03, 2026

Reflected XSS in oaskit's default HTML error handler

Low

Network Low None

Summary

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.

Workarounds

Disable HTML error rendering so that validation failures are returned as JSON only:

plug Oaskit.Plugs.ValidateRequest, html_errors: false

This 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.

Affected 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

+ 11 more


            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

Fixed in


          0.14.1

References

Updated Sep 08, 2026 · Source: OSV.dev

Jul 05, 2025

0.1.2 patch

1 CVE

CVE-2026-66296 EEF-CVE-2026-66296 GHSA-h7xw-x8wr-xpcc Aug 03, 2026

Reflected XSS in oaskit's default HTML error handler

Low

Network Low None

Summary

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.

Workarounds

Disable HTML error rendering so that validation failures are returned as JSON only:

plug Oaskit.Plugs.ValidateRequest, html_errors: false

This 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.

Affected 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

+ 11 more


            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

Fixed in


          0.14.1

References

Updated Sep 08, 2026 · Source: OSV.dev

Jun 30, 2025

0.1.1 patch

1 CVE

CVE-2026-66296 EEF-CVE-2026-66296 GHSA-h7xw-x8wr-xpcc Aug 03, 2026

Reflected XSS in oaskit's default HTML error handler

Low

Network Low None

Summary

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.

Workarounds

Disable HTML error rendering so that validation failures are returned as JSON only:

plug Oaskit.Plugs.ValidateRequest, html_errors: false

This 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.

Affected 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

+ 11 more


            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

Fixed in


          0.14.1

References

Updated Sep 08, 2026 · Source: OSV.dev

Jun 29, 2025

0.1.0 initial

1 CVE

CVE-2026-66296 EEF-CVE-2026-66296 GHSA-h7xw-x8wr-xpcc Aug 03, 2026

Reflected XSS in oaskit's default HTML error handler

Low

Network Low None

Summary

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.

Workarounds

Disable HTML error rendering so that validation failures are returned as JSON only:

plug Oaskit.Plugs.ValidateRequest, html_errors: false

This 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.

Affected 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

+ 11 more


            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

Fixed in


          0.14.1

References

Updated Sep 08, 2026 · Source: OSV.dev

Jun 29, 2025

Activity

Reach

Details