CWE-1289
AllowedImproper Validation of Unsafe Equivalence in Input
Abstraction: Base · Status: Incomplete
The product receives an input value that is used as a resource identifier or other type of reference, but it does not validate or incorrectly validates that the input is equivalent to a potentially-unsafe value.
61 vulnerabilities reference this CWE, most recent first.
GHSA-CRV5-9VWW-Q3G8
Vulnerability from github – Published: 2026-04-22 17:32 – Updated: 2026-04-27 16:32Summary
| Field | Value |
|---|---|
| Severity | Medium |
| Affected | DOMPurify main at 883ac15, introduced in v1.0.10 (7fc196db) |
SAFE_FOR_TEMPLATES strips {{...}} expressions from untrusted HTML. This works in string mode but not with RETURN_DOM or RETURN_DOM_FRAGMENT, allowing XSS via template-evaluating frameworks like Vue 2.
Technical Details
DOMPurify strips template expressions in two passes:
- Per-node — each text node is checked during the tree walk (
purify.ts:1179-1191):
// pass #1: runs on every text node during tree walk
if (SAFE_FOR_TEMPLATES && currentNode.nodeType === NODE_TYPE.text) {
content = currentNode.textContent;
content = content.replace(MUSTACHE_EXPR, ' '); // {{...}} -> ' '
content = content.replace(ERB_EXPR, ' '); // <%...%> -> ' '
content = content.replace(TMPLIT_EXPR, ' '); // ${... -> ' '
currentNode.textContent = content;
}
- Final string scrub — after serialization, the full HTML string is scrubbed again (
purify.ts:1679-1683). This is the safety net that catches expressions that only form after the DOM settles.
The RETURN_DOM path returns before pass #2 ever runs (purify.ts:1637-1661):
// purify.ts (simplified)
if (RETURN_DOM) {
// ... build returnNode ...
return returnNode; // <-- exits here, pass #2 never runs
}
// pass #2: only reached by string-mode callers
if (SAFE_FOR_TEMPLATES) {
serializedHTML = serializedHTML.replace(MUSTACHE_EXPR, ' ');
}
return serializedHTML;
The payload {<foo></foo>{constructor.constructor('alert(1)')()}<foo></foo>} exploits this:
- Parser creates:
TEXT("{")→<foo>→TEXT("{payload}")→<foo>→TEXT("}")— no single node contains{{, so pass #1 misses it <foo>is not allowed, so DOMPurify removes it but keeps surrounding text- The three text nodes are now adjacent —
.outerHTMLreads them as{{payload}}, which Vue 2 compiles and executes
Reproduce
Open the following html in any browser and alert(1) pops up.
<!DOCTYPE html>
<html>
<body>
<script src="https://cdn.jsdelivr.net/npm/dompurify@3.3.3/dist/purify.min.js"></script>
<script src="https://cdn.jsdelivr.net/npm/vue@2.7.16/dist/vue.min.js"></script>
<script>
var dirty = '<div id="app">{<foo></foo>{constructor.constructor("alert(1)")()}<foo></foo>}</div>';
var dom = DOMPurify.sanitize(dirty, { SAFE_FOR_TEMPLATES: true, RETURN_DOM: true });
document.body.appendChild(dom.firstChild);
new Vue({ el: '#app' });
</script>
</body>
</html>
Impact
Any application that sanitizes attacker-controlled HTML with SAFE_FOR_TEMPLATES: true and RETURN_DOM: true (or RETURN_DOM_FRAGMENT: true), then mounts the result into a template-evaluating framework, is vulnerable to XSS.
Recommendations
Fix
normalize() merges the split text nodes, then the same regex from the string path catches the expression. Placed before the fragment logic, this fixes both RETURN_DOM and RETURN_DOM_FRAGMENT.
if (RETURN_DOM) {
+ if (SAFE_FOR_TEMPLATES) {
+ body.normalize();
+ let html = body.innerHTML;
+ arrayForEach([MUSTACHE_EXPR, ERB_EXPR, TMPLIT_EXPR], (expr: RegExp) => {
+ html = stringReplace(html, expr, ' ');
+ });
+ body.innerHTML = html;
+ }
+
if (RETURN_DOM_FRAGMENT) {
returnNode = createDocumentFragment.call(body.ownerDocument);
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "dompurify"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.10"
},
{
"fixed": "3.4.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-41239"
],
"database_specific": {
"cwe_ids": [
"CWE-1289",
"CWE-79"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-22T17:32:54Z",
"nvd_published_at": "2026-04-23T16:16:26Z",
"severity": "MODERATE"
},
"details": "## Summary\n\n| Field | Value |\n|:------|:------|\n| **Severity** | Medium |\n| **Affected** | DOMPurify `main` at [`883ac15`](https://github.com/cure53/DOMPurify/tree/883ac15d47f907cb1a3b5a152fe90c4d8c10f9e6), introduced in v1.0.10 ([`7fc196db`](https://github.com/cure53/DOMPurify/commit/7fc196db0b42a0c360262dba0cc39c9c91bfe1ec)) |\n\n`SAFE_FOR_TEMPLATES` strips `{{...}}` expressions from untrusted HTML. This works in string mode but not with `RETURN_DOM` or `RETURN_DOM_FRAGMENT`, allowing XSS via template-evaluating frameworks like Vue 2.\n\n## Technical Details\n\nDOMPurify strips template expressions in two passes:\n\n1. **Per-node** \u2014 each text node is checked during the tree walk ([`purify.ts:1179-1191`](https://github.com/cure53/DOMPurify/blob/883ac15d47f907cb1a3b5a152fe90c4d8c10f9e6/src/purify.ts#L1179-L1191)):\n\n```js\n// pass #1: runs on every text node during tree walk\nif (SAFE_FOR_TEMPLATES \u0026\u0026 currentNode.nodeType === NODE_TYPE.text) {\n content = currentNode.textContent;\n content = content.replace(MUSTACHE_EXPR, \u0027 \u0027); // {{...}} -\u003e \u0027 \u0027\n content = content.replace(ERB_EXPR, \u0027 \u0027); // \u003c%...%\u003e -\u003e \u0027 \u0027\n content = content.replace(TMPLIT_EXPR, \u0027 \u0027); // ${... -\u003e \u0027 \u0027\n currentNode.textContent = content;\n}\n```\n\n2. **Final string scrub** \u2014 after serialization, the full HTML string is scrubbed again ([`purify.ts:1679-1683`](https://github.com/cure53/DOMPurify/blob/883ac15d47f907cb1a3b5a152fe90c4d8c10f9e6/src/purify.ts#L1679-L1683)). This is the safety net that catches expressions that only form after the DOM settles.\n\nThe `RETURN_DOM` path returns before pass #2 ever runs ([`purify.ts:1637-1661`](https://github.com/cure53/DOMPurify/blob/883ac15d47f907cb1a3b5a152fe90c4d8c10f9e6/src/purify.ts#L1637-L1661)):\n\n```js\n// purify.ts (simplified)\n\nif (RETURN_DOM) {\n // ... build returnNode ...\n return returnNode; // \u003c-- exits here, pass #2 never runs\n}\n\n// pass #2: only reached by string-mode callers\nif (SAFE_FOR_TEMPLATES) {\n serializedHTML = serializedHTML.replace(MUSTACHE_EXPR, \u0027 \u0027);\n}\nreturn serializedHTML;\n```\n\nThe payload `{\u003cfoo\u003e\u003c/foo\u003e{constructor.constructor(\u0027alert(1)\u0027)()}\u003cfoo\u003e\u003c/foo\u003e}` exploits this:\n\n1. Parser creates: `TEXT(\"{\")` \u2192 `\u003cfoo\u003e` \u2192 `TEXT(\"{payload}\")` \u2192 `\u003cfoo\u003e` \u2192 `TEXT(\"}\")` \u2014 no single node contains `{{`, so pass #1 misses it\n2. `\u003cfoo\u003e` is not allowed, so DOMPurify removes it but keeps surrounding text\n3. The three text nodes are now adjacent \u2014 `.outerHTML` reads them as `{{payload}}`, which Vue 2 compiles and executes\n\n## Reproduce\n\nOpen the following html in any browser and `alert(1)` pops up.\n\n```html\n\u003c!DOCTYPE html\u003e\n\u003chtml\u003e\n\n\u003cbody\u003e\n \u003cscript src=\"https://cdn.jsdelivr.net/npm/dompurify@3.3.3/dist/purify.min.js\"\u003e\u003c/script\u003e\n \u003cscript src=\"https://cdn.jsdelivr.net/npm/vue@2.7.16/dist/vue.min.js\"\u003e\u003c/script\u003e\n \u003cscript\u003e\n var dirty = \u0027\u003cdiv id=\"app\"\u003e{\u003cfoo\u003e\u003c/foo\u003e{constructor.constructor(\"alert(1)\")()}\u003cfoo\u003e\u003c/foo\u003e}\u003c/div\u003e\u0027;\n var dom = DOMPurify.sanitize(dirty, { SAFE_FOR_TEMPLATES: true, RETURN_DOM: true });\n document.body.appendChild(dom.firstChild);\n new Vue({ el: \u0027#app\u0027 });\n \u003c/script\u003e\n\u003c/body\u003e\n\n\u003c/html\u003e\n```\n\n## Impact\n\nAny application that sanitizes attacker-controlled HTML with `SAFE_FOR_TEMPLATES: true` and `RETURN_DOM: true` (or `RETURN_DOM_FRAGMENT: true`), then mounts the result into a template-evaluating framework, is vulnerable to XSS.\n\n## Recommendations\n\n### Fix\n\n`normalize()` merges the split text nodes, then the same regex from the string path catches the expression. Placed before the fragment logic, this fixes both `RETURN_DOM` and `RETURN_DOM_FRAGMENT`.\n\n```diff\n if (RETURN_DOM) {\n+ if (SAFE_FOR_TEMPLATES) {\n+ body.normalize();\n+ let html = body.innerHTML;\n+ arrayForEach([MUSTACHE_EXPR, ERB_EXPR, TMPLIT_EXPR], (expr: RegExp) =\u003e {\n+ html = stringReplace(html, expr, \u0027 \u0027);\n+ });\n+ body.innerHTML = html;\n+ }\n+\n if (RETURN_DOM_FRAGMENT) {\n returnNode = createDocumentFragment.call(body.ownerDocument);\n```",
"id": "GHSA-crv5-9vww-q3g8",
"modified": "2026-04-27T16:32:12Z",
"published": "2026-04-22T17:32:54Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/cure53/DOMPurify/security/advisories/GHSA-crv5-9vww-q3g8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41239"
},
{
"type": "PACKAGE",
"url": "https://github.com/cure53/DOMPurify"
},
{
"type": "WEB",
"url": "https://github.com/cure53/DOMPurify/releases/tag/3.4.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "DOMPurify has a SAFE_FOR_TEMPLATES bypass in RETURN_DOM mode"
}
GHSA-FFF7-GX98-VR3G
Vulnerability from github – Published: 2026-06-04 18:30 – Updated: 2026-06-04 21:31Net::CIDR::Set versions through 0.20 for Perl did not validate network masks.
The mask portion of a network mask could contain Unicode digits such as the Arabic-Indic One (U+0661), or non-digits, which were ignored. This could allow network masks to accept larger networks.
Leading zeros were also accepted, but treated as decimal instead of octal. This could lead to confusion about what networks are acceptable.
{
"affected": [],
"aliases": [
"CVE-2026-49942"
],
"database_specific": {
"cwe_ids": [
"CWE-1289"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-04T17:16:33Z",
"severity": "HIGH"
},
"details": "Net::CIDR::Set versions through 0.20 for Perl did not validate network masks.\n\nThe mask portion of a network mask could contain Unicode digits such as the Arabic-Indic One (U+0661), or non-digits, which were ignored. This could allow network masks to accept larger networks.\n\nLeading zeros were also accepted, but treated as decimal instead of octal. This could lead to confusion about what networks are acceptable.",
"id": "GHSA-fff7-gx98-vr3g",
"modified": "2026-06-04T21:31:21Z",
"published": "2026-06-04T18:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40911"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45191"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-49942"
},
{
"type": "WEB",
"url": "https://metacpan.org/release/RRWO/Net-CIDR-Set-0.21/changes"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-FRQ3-H54X-6725
Vulnerability from github – Published: 2024-08-06 21:30 – Updated: 2024-08-08 15:311Password 8 before 8.10.38 for macOS allows local attackers to exfiltrate vault items by bypassing macOS-specific security mechanisms.
{
"affected": [],
"aliases": [
"CVE-2024-42218"
],
"database_specific": {
"cwe_ids": [
"CWE-1289"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-06T21:16:03Z",
"severity": "MODERATE"
},
"details": "1Password 8 before 8.10.38 for macOS allows local attackers to exfiltrate vault items by bypassing macOS-specific security mechanisms.",
"id": "GHSA-frq3-h54x-6725",
"modified": "2024-08-08T15:31:28Z",
"published": "2024-08-06T21:30:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42218"
},
{
"type": "WEB",
"url": "https://app-updates.agilebits.com"
},
{
"type": "WEB",
"url": "https://support.1password.com/kb/202408"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-FV83-X2XW-2J55
Vulnerability from github – Published: 2026-04-08 03:32 – Updated: 2026-09-10 15:32When verifying a certificate chain containing excluded DNS constraints, these constraints are not correctly applied to wildcard DNS SANs which use a different case than the constraint. This only affects validation of otherwise trusted certificate chains, issued by a root CA in the VerifyOptions.Roots CertPool, or in the system certificate pool.
{
"affected": [],
"aliases": [
"CVE-2026-33810"
],
"database_specific": {
"cwe_ids": [
"CWE-1289",
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-08T02:16:03Z",
"severity": "HIGH"
},
"details": "When verifying a certificate chain containing excluded DNS constraints, these constraints are not correctly applied to wildcard DNS SANs which use a different case than the constraint. This only affects validation of otherwise trusted certificate chains, issued by a root CA in the VerifyOptions.Roots CertPool, or in the system certificate pool.",
"id": "GHSA-fv83-x2xw-2j55",
"modified": "2026-09-10T15:32:33Z",
"published": "2026-04-08T03:32:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33810"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:61313"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:61253"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:59546"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:57649"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:57126"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:56223"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:56143"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:54757"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:51288"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:51033"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:49712"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:49703"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:49702"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:47952"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:42051"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:42050"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:42049"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:42047"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:42043"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-33810.json"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2026-4866"
},
{
"type": "WEB",
"url": "https://groups.google.com/g/golang-announce/c/0uYbvbPZRWU"
},
{
"type": "WEB",
"url": "https://go.dev/issue/78332"
},
{
"type": "WEB",
"url": "https://go.dev/cl/763763"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2456335"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-33810"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:9385"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:7291"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:66327"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:65895"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:65880"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:65534"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:65359"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:65126"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:63332"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:62578"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:62577"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:61907"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:41928"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:22960"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:22959"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:22958"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:22862"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:22485"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:22347"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:21772"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:21769"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19721"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19720"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19719"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19714"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19353"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19144"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19135"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:14391"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:13545"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:10158"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:10155"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:40945"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:40118"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:39810"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:36796"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:36651"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:34365"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:34197"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:34196"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:34192"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:29854"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:28047"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:26585"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:26571"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:26568"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:25089"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:24478"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:23345"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:22962"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:22961"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/04/19/4"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/04/20/1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-FW62-67J2-4WMC
Vulnerability from github – Published: 2026-05-10 21:30 – Updated: 2026-05-11 18:31Net::CIDR::Lite versions before 0.24 for Perl does not properly consider extraneous zero characters in CIDR mask values, which may allow IP ACL bypass.
Mask forms like "/00" and "/01" pass validation and parse to the same prefix as their unpadded value.
See also CVE-2026-45190.
{
"affected": [],
"aliases": [
"CVE-2026-45191"
],
"database_specific": {
"cwe_ids": [
"CWE-1289"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-10T21:16:29Z",
"severity": "MODERATE"
},
"details": "Net::CIDR::Lite versions before 0.24 for Perl does not properly consider extraneous zero characters in CIDR mask values, which may allow IP ACL bypass.\n\nMask forms like \"/00\" and \"/01\" pass validation and parse to the same prefix as their unpadded value.\n\nSee also CVE-2026-45190.",
"id": "GHSA-fw62-67j2-4wmc",
"modified": "2026-05-11T18:31:43Z",
"published": "2026-05-10T21:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45191"
},
{
"type": "WEB",
"url": "https://github.com/stigtsp/Net-CIDR-Lite/commit/24e2c439ec405e5256024b9acefd4f7008c5ed0c.patch"
},
{
"type": "WEB",
"url": "https://metacpan.org/release/STIGTSP/Net-CIDR-Lite-0.24/changes"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45190"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-GX25-V2F3-PPXQ
Vulnerability from github – Published: 2026-03-17 21:31 – Updated: 2026-03-17 21:31Improper input validation in the apps and endpoints configuration in PowerShell Universal before 2026.1.4 allows an authenticated user with permissions to create or modify Apps or Endpoints to override existing application or system routes, resulting in unintended request routing and denial of service via a conflicting URL path.
{
"affected": [],
"aliases": [
"CVE-2026-3563"
],
"database_specific": {
"cwe_ids": [
"CWE-1289"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-17T20:16:14Z",
"severity": "MODERATE"
},
"details": "Improper input validation in the apps and endpoints configuration in PowerShell Universal before 2026.1.4 allows an authenticated user with permissions to create or modify Apps or Endpoints to override existing application or system routes, resulting in unintended request routing and denial of service via a conflicting URL path.",
"id": "GHSA-gx25-v2f3-ppxq",
"modified": "2026-03-17T21:31:45Z",
"published": "2026-03-17T21:31:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3563"
},
{
"type": "WEB",
"url": "https://devolutions.net/security/advisories/DEVO-2026-0008"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-H6C8-CWW8-35HF
Vulnerability from github – Published: 2026-03-26 17:21 – Updated: 2026-03-27 21:30Description
In OpenFGA, under specific conditions, models using conditions with caching enabled can result in two different check requests producing the same cache key. This can result in OpenFGA reusing an earlier cached result for a different request.
Am I Affected?
Users are affected if the following preconditions are met: 1. The model has relations which rely on condition evaluation. 1. Caching is enabled.
Fix
Upgrade to OpenFGA v1.13.1.
Acknowledgement
OpenFGA would like to thank @Amemoyoi for the discovery and responsible disclosure.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/openfga/openfga"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.13.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-33729"
],
"database_specific": {
"cwe_ids": [
"CWE-1289",
"CWE-20",
"CWE-345"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-26T17:21:50Z",
"nvd_published_at": "2026-03-27T01:16:20Z",
"severity": "MODERATE"
},
"details": "### Description\nIn OpenFGA, under specific conditions, models using conditions with caching enabled can result in two different check requests producing the same cache key. This can result in OpenFGA reusing an earlier cached result for a different request.\n\n### Am I Affected?\nUsers are affected if the following preconditions are met:\n1. The model has relations which rely on condition evaluation.\n1. Caching is enabled.\n\n### Fix\nUpgrade to OpenFGA v1.13.1.\n\n### Acknowledgement\nOpenFGA would like to thank @Amemoyoi for the discovery and responsible disclosure.",
"id": "GHSA-h6c8-cww8-35hf",
"modified": "2026-03-27T21:30:41Z",
"published": "2026-03-26T17:21:50Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openfga/openfga/security/advisories/GHSA-h6c8-cww8-35hf"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33729"
},
{
"type": "WEB",
"url": "https://github.com/openfga/openfga/commit/049b50ccd2cc7e163bd897f3d17a7b859ad146f8"
},
{
"type": "PACKAGE",
"url": "https://github.com/openfga/openfga"
},
{
"type": "WEB",
"url": "https://github.com/openfga/openfga/releases/tag/v1.13.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H",
"type": "CVSS_V4"
}
],
"summary": "OpenFGA has an Authorization Bypass through cached keys"
}
GHSA-H97M-WW89-6JMQ
Vulnerability from github – Published: 2024-12-09 20:41 – Updated: 2025-05-30 15:01idna 0.5.0 and earlier accepts Punycode labels that do not produce any non-ASCII output, which means that either ASCII labels or the empty root label can be masked such that they appear unequal without IDNA processing or when processed with a different implementation and equal when processed with idna 0.5.0 or earlier.
Concretely, example.org and xn--example-.org become equal after processing by idna 0.5.0 or earlier. Also, example.org.xn-- and example.org. become equal after processing by idna 0.5.0 or earlier.
In applications using idna (but not in idna itself) this may be able to lead to privilege escalation when host name comparison is part of a privilege check and the behavior is combined with a client that resolves domains with such labels instead of treating them as errors that preclude DNS resolution / URL fetching and with the attacker managing to introduce a DNS entry (and TLS certificate) for an xn---masked name that turns into the name of the target when processed by idna 0.5.0 or earlier.
Remedy
Upgrade to idna 1.0.3 or later, if depending on idna directly, or to url 2.5.4 or later, if depending on idna via url. (This issue was fixed in idna 1.0.0, but versions earlier than 1.0.3 are not recommended for other reasons.)
When upgrading, please take a moment to read about alternative Unicode back ends for idna.
If you are using Rust earlier than 1.81 in combination with SQLx 0.8.2 or earlier, please also read an issue about combining them with url 2.5.4 and idna 1.0.3.
Additional information
This issue resulted from idna 0.5.0 and earlier implementing the UTS 46 specification literally on this point and the specification having this bug. The specification bug has been fixed in revision 33 of UTS 46.
Acknowledgements
Thanks to kageshiron for recognizing the security implications of this behavior.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "idna"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-12224"
],
"database_specific": {
"cwe_ids": [
"CWE-1289",
"CWE-697"
],
"github_reviewed": true,
"github_reviewed_at": "2024-12-09T20:41:10Z",
"nvd_published_at": "2025-05-30T02:15:19Z",
"severity": "MODERATE"
},
"details": "`idna` 0.5.0 and earlier accepts Punycode labels that do not produce any non-ASCII output, which means that either ASCII labels or the empty root label can be masked such that they appear unequal without IDNA processing or when processed with a different implementation and equal when processed with `idna` 0.5.0 or earlier.\n\nConcretely, `example.org` and `xn--example-.org` become equal after processing by `idna` 0.5.0 or earlier. Also, `example.org.xn--` and `example.org.` become equal after processing by `idna` 0.5.0 or earlier.\n\nIn applications using `idna` (but not in `idna` itself) this may be able to lead to privilege escalation when host name comparison is part of a privilege check and the behavior is combined with a client that resolves domains with such labels instead of treating them as errors that preclude DNS resolution / URL fetching and with the attacker managing to introduce a DNS entry (and TLS certificate) for an `xn--`-masked name that turns into the name of the target when processed by `idna` 0.5.0 or earlier.\n\n## Remedy\n\nUpgrade to `idna` 1.0.3 or later, if depending on `idna` directly, or to `url` 2.5.4 or later, if depending on `idna` via `url`. (This issue was fixed in `idna` 1.0.0, but versions earlier than 1.0.3 are not recommended for other reasons.)\n\nWhen upgrading, please take a moment to read about [alternative Unicode back ends for `idna`](https://docs.rs/crate/idna_adapter/latest).\n\nIf you are using Rust earlier than 1.81 in combination with SQLx 0.8.2 or earlier, please also read an [issue](https://github.com/servo/rust-url/issues/992) about combining them with `url` 2.5.4 and `idna` 1.0.3.\n\n## Additional information\n\nThis issue resulted from `idna` 0.5.0 and earlier implementing the UTS 46 specification literally on this point and the specification having this bug. The specification bug has been fixed in [revision 33 of UTS 46](https://www.unicode.org/reports/tr46/tr46-33.html#Modifications).\n\n## Acknowledgements\n\nThanks to kageshiron for recognizing the security implications of this behavior.",
"id": "GHSA-h97m-ww89-6jmq",
"modified": "2025-05-30T15:01:30Z",
"published": "2024-12-09T20:41:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-12224"
},
{
"type": "WEB",
"url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1887898"
},
{
"type": "PACKAGE",
"url": "https://github.com/servo/rust-url"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2024-0421.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "`idna` accepts Punycode labels that do not produce any non-ASCII when decoded"
}
GHSA-HFQP-M279-7MJ7
Vulnerability from github – Published: 2026-07-30 15:31 – Updated: 2026-08-21 09:32Date::Manip versions through 6.99 for Perl return corrupted dates via non-ASCII decimal digits that pass the numeric range tests in check.
The parse regexes capture year, month and day with the \d shorthand, which on a character string matches the whole Unicode decimal digit property \p{Nd} and not just [0-9]. Date::Manip::Base::check then validates the captured fields with numeric comparisons alone ($y<1 || $y>9999, $m<1 || $m>12, $d<1 || $d>$days), and _parse_check stores the numified fields ($y+0). Perl truncates a string at the first character that is not an ASCII digit, so a field whose leading characters are ASCII digits numifies to an in-range prefix and satisfies every test: a year field of three ASCII digits followed by U+0664 ARABIC-INDIC DIGIT FOUR numifies to 202, giving the year 0202, and one non-ASCII digit in the month or day field shifts those fields the same way. The hour, minute and second fields match explicit ASCII character classes (0?[0-9], [0-5][0-9]) and do not shift, though a non-ASCII digit in a fractional hour or minute field truncates the fraction.
Any caller that passes an untrusted character string to ParseDate() or Date::Manip::Date->parse() can get back a date that differs from the string it parsed, with no parse error. Where the parsed date gates logic such as an expiry check or a retention window, the shift goes unnoticed.
{
"affected": [],
"aliases": [
"CVE-2026-60074"
],
"database_specific": {
"cwe_ids": [
"CWE-1289"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-30T14:17:02Z",
"severity": "HIGH"
},
"details": "Date::Manip versions through 6.99 for Perl return corrupted dates via non-ASCII decimal digits that pass the numeric range tests in check.\n\nThe parse regexes capture year, month and day with the `\\d` shorthand, which on a character string matches the whole Unicode decimal digit property `\\p{Nd}` and not just `[0-9]`. Date::Manip::Base::check then validates the captured fields with numeric comparisons alone (`$y\u003c1 || $y\u003e9999`, `$m\u003c1 || $m\u003e12`, `$d\u003c1 || $d\u003e$days`), and _parse_check stores the numified fields (`$y+0`). Perl truncates a string at the first character that is not an ASCII digit, so a field whose leading characters are ASCII digits numifies to an in-range prefix and satisfies every test: a year field of three ASCII digits followed by U+0664 ARABIC-INDIC DIGIT FOUR numifies to 202, giving the year 0202, and one non-ASCII digit in the month or day field shifts those fields the same way. The hour, minute and second fields match explicit ASCII character classes (`0?[0-9]`, `[0-5][0-9]`) and do not shift, though a non-ASCII digit in a fractional hour or minute field truncates the fraction.\n\nAny caller that passes an untrusted character string to ParseDate() or Date::Manip::Date-\u003eparse() can get back a date that differs from the string it parsed, with no parse error. Where the parsed date gates logic such as an expiry check or a retention window, the shift goes unnoticed.",
"id": "GHSA-hfqp-m279-7mj7",
"modified": "2026-08-21T09:32:02Z",
"published": "2026-07-30T15:31:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-60074"
},
{
"type": "WEB",
"url": "https://github.com/SBECK-github/Date-Manip/pull/54"
},
{
"type": "WEB",
"url": "https://metacpan.org/release/SBECK/Date-Manip-6.99/source/lib/Date/Manip/Base.pm#L602-614"
},
{
"type": "WEB",
"url": "https://metacpan.org/release/SBECK/Date-Manip-6.99/source/lib/Date/Manip/Date.pm#L1536-1539"
},
{
"type": "WEB",
"url": "https://security.metacpan.org/patches/D/Date-Manip/6.99/CVE-2026-60074-r1.patch"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/07/30/19"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HPV8-77XM-27WX
Vulnerability from github – Published: 2026-06-04 18:30 – Updated: 2026-06-04 18:30Net::CIDR::Set versions through 0.20 for Perl accept non-ASCII IP addresses and netmasks.
Unicode digits such as the Arabic-Indic One (U+0661) were accepted but not properly parsed as numbers. This could allow network masks to accept larger networks.
{
"affected": [],
"aliases": [
"CVE-2026-49940"
],
"database_specific": {
"cwe_ids": [
"CWE-1289"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-04T17:16:33Z",
"severity": "MODERATE"
},
"details": "Net::CIDR::Set versions through 0.20 for Perl accept non-ASCII IP addresses and netmasks.\n\nUnicode digits such as the Arabic-Indic One (U+0661) were accepted but not properly parsed as numbers. This could allow network masks to accept larger networks.",
"id": "GHSA-hpv8-77xm-27wx",
"modified": "2026-06-04T18:30:32Z",
"published": "2026-06-04T18:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40911"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-49940"
},
{
"type": "WEB",
"url": "https://metacpan.org/release/RRWO/Net-CIDR-Set-0.21/changes"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation MIT-5
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
No CAPEC attack patterns related to this CWE.