GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
Common Weakness Enumeration

CWE-1289

Allowed

Improper 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:32
VLAI
Summary
DOMPurify has a SAFE_FOR_TEMPLATES bypass in RETURN_DOM mode
Details

Summary

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:

  1. 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;
}
  1. 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:

  1. Parser creates: TEXT("{")<foo>TEXT("{payload}")<foo>TEXT("}") — no single node contains {{, so pass #1 misses it
  2. <foo> is not allowed, so DOMPurify removes it but keeps surrounding text
  3. The three text nodes are now adjacent — .outerHTML reads 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);
Show details on source website

{
  "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:31
VLAI
Details

Net::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.

Show details on source website

{
  "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:31
VLAI
Details

1Password 8 before 8.10.38 for macOS allows local attackers to exfiltrate vault items by bypassing macOS-specific security mechanisms.

Show details on source website

{
  "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:32
VLAI
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.

Show details on source website

{
  "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:31
VLAI
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.

Mask forms like "/00" and "/01" pass validation and parse to the same prefix as their unpadded value.

See also CVE-2026-45190.

Show details on source website

{
  "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:31
VLAI
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.

Show details on source website

{
  "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:30
VLAI
Summary
OpenFGA has an Authorization Bypass through cached keys
Details

Description

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.

Show details on source website

{
  "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:01
VLAI
Summary
`idna` accepts Punycode labels that do not produce any non-ASCII when decoded
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.

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.

Show details on source website

{
  "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:32
VLAI
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.

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.

Show details on source website

{
  "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:30
VLAI
Details

Net::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.

Show details on source website

{
  "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
Implementation

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.