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

CWE-178

Allowed

Improper Handling of Case Sensitivity

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

The product does not properly account for differences in case sensitivity when accessing or determining the properties of a resource, leading to inconsistent results.

179 vulnerabilities reference this CWE, most recent first.

GHSA-6MJ3-QW4J-HGRW

Vulnerability from github – Published: 2026-09-08 20:59 – Updated: 2026-09-08 20:59
VLAI
Summary
xmldom: HTML raw-text closing-tag case mismatch causes output amplification
Details

Summary

In HTML mode (text/html), a raw-text element (script, style, textarea, title) whose closing tag differs in case from its opening tag (e.g. </ScRiPt> for <script>) is mishandled by the parser, producing quadratic (O(n²)) output growth — a small crafted document parses and serializes into output orders of magnitude larger, exhausting CPU and memory. A modest input of tens of KB can therefore cause a denial of service in any service that parses untrusted HTML with xmldom. Only HTML mode is affected.

Details

The parser calls parseHtmlSpecialContent for each raw-text element in HTML mode, matched via isHTMLRawTextElement / isHTMLEscapableRawTextElement (so all four types — script, style, textarea, title — are in scope). It searches for the element's closing tag with source.indexOf('</' + tagName + '>', elStartEnd), a byte-for-byte case-sensitive match. A mixed-case closing tag never matches, so the search returns -1, and the following source.substring(elStartEnd + 1, -1) extracts text backwards from the start of the document instead of the element's content. The function then returns -1 to the parse loop, which cannot advance normally and falls back to character-by-character reprocessing. Every raw-text element re-captures all source text preceding it, so output grows as O(n²) in the number of such elements.

Root Cause

  1. Case-sensitive close-tag search (lib/sax.js:549): source.indexOf('</' + tagName + '>', elStartEnd) does not fold case, contrary to the WHATWG HTML RAWTEXT end-tag-name rule.
  2. Unguarded -1 (lib/sax.js:550): source.substring(elStartEnd + 1, elEndStart) runs even when elEndStart === -1, extracting text backwards from position 0.
  3. Unstable progression (lib/sax.js:556): the function returns elEndStart (-1), driving repeated character-by-character fallback in the parse loop.

Affected Versions

Only the 0.9.x line is affected — the amplification was introduced in 0.9.0-beta.1 when parseHtmlSpecialContent was refactored, and remains through 0.9.11. The 0.8.x line is not affected: its older parseHtmlSpecialContent does not amplify, despite sharing the same case-sensitive indexOf.

Proof of Concept

const { DOMParser, XMLSerializer } = require('@xmldom/xmldom');

const n = 1000;
const payload = '<html><body>' + '<script>x</ScRiPt>'.repeat(n) + '</body></html>';
const doc = new DOMParser().parseFromString(payload, 'text/html');
const out = new XMLSerializer().serializeToString(doc);
console.log(payload.length, out.length, (out.length / payload.length).toFixed(1) + 'x');
// 18026 9037063 501.3x  — an 18 KB input yields ~9 MB of output

Output size grows quadratically with the number of case-mismatched raw-text elements:

Repeats | Input len | Output len | Ratio
1       | 44        | 109        | 2.5x
100     | 1826      | 93763      | 51.3x
500     | 9026      | 2268563    | 251.3x
1000    | 18026     | 9037063    | 501.3x
2000    | 36026     | 36074063   | 1001.3x

Proof of Concept from @KarimTantawey (tested with script); the same amplification occurs for style, textarea, and title.

Impact

Small attacker payloads can force disproportionate CPU and memory usage in services that parse and serialize untrusted HTML via xmldom. The quadratic growth means a modest-sized input (tens of kilobytes) can produce output in the tens or hundreds of megabytes, potentially exhausting memory or causing timeouts.

The attack only requires HTML mode (text/html MIME type) and mixed-case closing tags for any of the four raw-text element types. No special configuration or error handler setup is needed.

Severity note

The CVSS 4.0 vector scores availability only (VA:H, with VC:N/VI:N): the flaw neither discloses nor corrupts data, but a small untrusted HTML input (tens of KB) can force output and memory in the tens to hundreds of MB, enough to exhaust a service's heap or stall its event loop. It is reachable with no authentication, configuration, or error-handler setup — only that the application parses untrusted text/html and serializes the result.

Fix Applied

The raw-text closing tag is now matched case-insensitively in HTML raw-text mode (per the WHATWG HTML RAWTEXT end-tag rule), and a missing closing tag is handled explicitly, removing the quadratic output amplification. Output for well-formed input is unchanged. Non-breaking; 0.9.x-only.

Severity
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.9.11"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@xmldom/xmldom"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.9.0-beta.1"
            },
            {
              "fixed": "0.9.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-83612"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-178",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-08T20:59:54Z",
    "nvd_published_at": "2026-09-01T15:17:39Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nIn HTML mode (`text/html`), a raw-text element (`script`, `style`, `textarea`, `title`) whose closing\ntag differs in case from its opening tag (e.g. `\u003c/ScRiPt\u003e` for `\u003cscript\u003e`) is mishandled by the\nparser, producing quadratic (O(n\u00b2)) output growth \u2014 a small crafted document parses and serializes\ninto output orders of magnitude larger, exhausting CPU and memory. A modest input of tens of KB can\ntherefore cause a denial of service in any service that parses untrusted HTML with xmldom. Only HTML\nmode is affected.\n\n## Details\n\nThe parser calls `parseHtmlSpecialContent` for each raw-text element in HTML mode, matched via\n`isHTMLRawTextElement` / `isHTMLEscapableRawTextElement` (so all four types \u2014 `script`, `style`,\n`textarea`, `title` \u2014 are in scope). It searches for the element\u0027s closing tag with\n`source.indexOf(\u0027\u003c/\u0027 + tagName + \u0027\u003e\u0027, elStartEnd)`, a byte-for-byte case-sensitive match. A\nmixed-case closing tag never matches, so the search returns `-1`, and the following\n`source.substring(elStartEnd + 1, -1)` extracts text backwards from the start of the document\ninstead of the element\u0027s content. The function then returns `-1` to the parse loop, which cannot\nadvance normally and falls back to character-by-character reprocessing. Every raw-text element\nre-captures all source text preceding it, so output grows as O(n\u00b2) in the number of such elements.\n\n### Root Cause\n\n1. **Case-sensitive close-tag search** (`lib/sax.js:549`): `source.indexOf(\u0027\u003c/\u0027 + tagName + \u0027\u003e\u0027,\n   elStartEnd)` does not fold case, contrary to the WHATWG HTML RAWTEXT end-tag-name rule.\n2. **Unguarded `-1`** (`lib/sax.js:550`): `source.substring(elStartEnd + 1, elEndStart)` runs even\n   when `elEndStart === -1`, extracting text backwards from position 0.\n3. **Unstable progression** (`lib/sax.js:556`): the function returns `elEndStart` (`-1`), driving\n   repeated character-by-character fallback in the parse loop.\n\n## Affected Versions\n\nOnly the `0.9.x` line is affected \u2014 the amplification was introduced in `0.9.0-beta.1` when\n`parseHtmlSpecialContent` was refactored, and remains through `0.9.11`. The `0.8.x` line is **not**\naffected: its older `parseHtmlSpecialContent` does not amplify, despite sharing the same\ncase-sensitive `indexOf`.\n\n## Proof of Concept\n\n```js\nconst { DOMParser, XMLSerializer } = require(\u0027@xmldom/xmldom\u0027);\n\nconst n = 1000;\nconst payload = \u0027\u003chtml\u003e\u003cbody\u003e\u0027 + \u0027\u003cscript\u003ex\u003c/ScRiPt\u003e\u0027.repeat(n) + \u0027\u003c/body\u003e\u003c/html\u003e\u0027;\nconst doc = new DOMParser().parseFromString(payload, \u0027text/html\u0027);\nconst out = new XMLSerializer().serializeToString(doc);\nconsole.log(payload.length, out.length, (out.length / payload.length).toFixed(1) + \u0027x\u0027);\n// 18026 9037063 501.3x  \u2014 an 18 KB input yields ~9 MB of output\n```\n\nOutput size grows quadratically with the number of case-mismatched raw-text elements:\n\n```\nRepeats | Input len | Output len | Ratio\n1       | 44        | 109        | 2.5x\n100     | 1826      | 93763      | 51.3x\n500     | 9026      | 2268563    | 251.3x\n1000    | 18026     | 9037063    | 501.3x\n2000    | 36026     | 36074063   | 1001.3x\n```\n\nProof of Concept from @KarimTantawey (tested with `script`); the same amplification occurs for `style`,\n`textarea`, and `title`.\n\n## Impact\n\nSmall attacker payloads can force disproportionate CPU and memory usage in services that\nparse and serialize untrusted HTML via xmldom. The quadratic growth means a modest-sized input\n(tens of kilobytes) can produce output in the tens or hundreds of megabytes, potentially\nexhausting memory or causing timeouts.\n\nThe attack only requires HTML mode (`text/html` MIME type) and mixed-case closing tags for\nany of the four raw-text element types. No special configuration or error handler setup is needed.\n\n## Severity note\n\nThe CVSS 4.0 vector scores availability only (`VA:H`, with `VC:N/VI:N`): the flaw neither discloses\nnor corrupts data, but a small untrusted HTML input (tens of KB) can force output and memory in the\ntens to hundreds of MB, enough to exhaust a service\u0027s heap or stall its event loop. It is reachable\nwith no authentication, configuration, or error-handler setup \u2014 only that the application parses\nuntrusted `text/html` and serializes the result.\n\n## Fix Applied\n\nThe raw-text closing tag is now matched case-insensitively in HTML raw-text mode (per the WHATWG HTML\n[RAWTEXT end-tag rule](https://html.spec.whatwg.org/multipage/parsing.html#rawtext-end-tag-name-state)),\nand a missing closing tag is handled explicitly, removing the quadratic output amplification. Output\nfor well-formed input is unchanged. Non-breaking; 0.9.x-only.",
  "id": "GHSA-6mj3-qw4j-hgrw",
  "modified": "2026-09-08T20:59:54Z",
  "published": "2026-09-08T20:59:54Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/xmldom/xmldom/security/advisories/GHSA-6mj3-qw4j-hgrw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-83612"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xmldom/xmldom/pull/1071"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xmldom/xmldom/commit/7ced40c06c28d151e996a97045018c3559ae4707"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/xmldom/xmldom"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xmldom/xmldom/releases/tag/0.9.12"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "xmldom: HTML raw-text closing-tag case mismatch causes output amplification"
}

GHSA-6RGH-57XM-37V8

Vulnerability from github – Published: 2026-04-30 18:30 – Updated: 2026-09-14 15:32
VLAI
Details

A flaw was found in gnutls. This vulnerability occurs because gnutls performs case-sensitive comparisons of nameConstraints labels, specifically for dNSName (DNS) or rfc822Name (email) constraints within excludedSubtrees or permittedSubtrees. A remote attacker can exploit this by crafting a leaf certificate with casing differences in the Subject Alternative Name (SAN), leading to a policy bypass where a certificate that should be rejected is instead accepted. This could result in unauthorized access or information disclosure.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-3833"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-178"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-30T18:16:30Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in gnutls. This vulnerability occurs because gnutls performs case-sensitive comparisons of `nameConstraints` labels, specifically for `dNSName` (DNS) or `rfc822Name` (email) constraints within `excludedSubtrees` or `permittedSubtrees`. A remote attacker can exploit this by crafting a leaf certificate with casing differences in the Subject Alternative Name (SAN), leading to a policy bypass where a certificate that should be rejected is instead accepted. This could result in unauthorized access or information disclosure.",
  "id": "GHSA-6rgh-57xm-37v8",
  "modified": "2026-09-14T15:32:02Z",
  "published": "2026-04-30T18:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3833"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gnutls/gnutls/-/issues/1803"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2445763"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-3833"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:62549"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:62409"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:60019"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:59831"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:58981"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:57402"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:43575"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:41921"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:33125"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:32962"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:30850"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:30849"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:30004"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:29197"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:26409"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:26319"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:20613"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:20612"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:20611"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:13274"
    }
  ],
  "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"
    }
  ]
}

GHSA-72H4-MXFC-JX37

Vulnerability from github – Published: 2026-04-25 23:30 – Updated: 2026-05-12 13:28
VLAI
Summary
Heimdall: Case-sensitive host matching may lead to policy bypass
Details

Summary

Heimdall performs host matching in a case-sensitive manner, while HTTP hostnames are case-insensitive. This discrepancy can result in heimdall failing to match a rule for a request host that differs only in letter casing, potentially causing the request to be classified differently than intended.

Note: The issue can only lead to unintended access if heimdall is configured with an "allow all" default rule. Since v0.16.0, heimdall enforces secure defaults and refuses to start with such a configuration unless this enforcement is explicitly disabled, e.g. via --insecure-skip-secure-default-rule-enforcement or the broader --insecure flag.

Details

This vulnerability can potentially be exploited by an adversary if rule matching relies on the request host.

For example, consider the following rule:

id: rule-1
match:
  hosts:
    - type: exact
      value: admin.example.com
execute: # configured to require authentication and authorization
  # ...

If an adversary now sends a request with the Host header set to Admin.Example.Com, rule-1 will not be matched, and the following will happen instead:

  • If no default rule is configured, the request will result in an error (404 Not Found)
  • If a default rule is configured, it will be executed. If the default rule is configured in an overly permissive way (e.g. allowing anonymous access), this results in a policy bypass.

Impact

Bypass of access control policies enforced by heimdall may lead to the following consequences:

  • Access to or modification of data that should be restricted
  • Invocation of functionality that is expected to require authentication or authorization
  • In certain configurations, escalation of privileges depending on the exposed functionality

Workarounds

  • Normalize request hosts to lowercase in the layers in front of heimdall.
  • Do not configure a permissive default rule. Respectively, do not make use of the --insecure or the --insecure-skip-secure-default-rule-enforcement flags.
  • When using regex type for host matching, expressions shall be defined in a case-insensitive manner (e.g. (?i)^admin\.example\.com$)
  • Include the ID of the rule expected to be executed in the JWT issued by heimdall and check that value in the consuming project's service.
Severity
7.8 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/dadrus/heimdall"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.17.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42273"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-178",
      "CWE-436"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-25T23:30:18Z",
    "nvd_published_at": "2026-05-08T04:16:22Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nHeimdall performs host matching in a case-sensitive manner, while HTTP hostnames are case-insensitive. This discrepancy can result in heimdall failing to match a rule for a request host that differs only in letter casing, potentially causing the request to be classified differently than intended.\n\n**Note:** The issue can only lead to unintended access if heimdall is configured with an \"allow all\" default rule. Since v0.16.0, heimdall enforces secure defaults and refuses to start with such a configuration unless this enforcement is explicitly disabled, e.g. via `--insecure-skip-secure-default-rule-enforcement` or the broader `--insecure` flag.\n\n### Details\n\nThis vulnerability can potentially be exploited by an adversary if rule matching relies on the request host.\n\nFor example, consider the following rule:\n\n```yaml\nid: rule-1\nmatch:\n  hosts:\n    - type: exact\n      value: admin.example.com\nexecute: # configured to require authentication and authorization\n  # ...\n```\n\nIf an adversary now sends a request with the `Host` header set to `Admin.Example.Com`, rule-1 will not be matched, and the following will happen instead:\n\n* If no default rule is configured, the request will result in an error (`404 Not Found`)\n* If a default rule is configured, it will be executed. If the default rule is configured in an overly permissive way (e.g. allowing anonymous access), this results in a policy bypass.\n\n### Impact\n\nBypass of access control policies enforced by heimdall may lead to the following consequences:\n\n* Access to or modification of data that should be restricted\n* Invocation of functionality that is expected to require authentication or authorization\n* In certain configurations, escalation of privileges depending on the exposed functionality\n\n### Workarounds\n\n* Normalize request hosts to lowercase in the layers in front of heimdall.\n* Do not configure a permissive default rule. Respectively, do not make use of the `--insecure` or the `--insecure-skip-secure-default-rule-enforcement` flags.\n* When using `regex` type for host matching, expressions shall be defined in a case-insensitive manner (e.g. `(?i)^admin\\.example\\.com$`)\n* Include the ID of the rule expected to be executed in the JWT issued by heimdall and check that value in the consuming project\u0027s service.",
  "id": "GHSA-72h4-mxfc-jx37",
  "modified": "2026-05-12T13:28:54Z",
  "published": "2026-04-25T23:30:18Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/dadrus/heimdall/security/advisories/GHSA-72h4-mxfc-jx37"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42273"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dadrus/heimdall/pull/3208"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dadrus/heimdall/commit/3d05e56a9e7ef0355f17482b4322054af4e85943"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/dadrus/heimdall"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dadrus/heimdall/releases/tag/v0.17.14"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Heimdall: Case-sensitive host matching may lead to policy bypass"
}

GHSA-7774-7VR3-CC8J

Vulnerability from github – Published: 2021-08-30 16:15 – Updated: 2021-12-13 13:09
VLAI
Summary
Authorization Policy Bypass Due to Case Insensitive Host Comparison
Details

Impact

According to RFC 4343, Istio authorization policy should compare the hostname in the HTTP Host header in a case insensitive way, but currently the comparison is case sensitive. The Envoy proxy will route the request hostname in a case-insensitive way which means the authorization policy could be bypassed.

As an example, the user may have an authorization policy that rejects request with hostname "httpbin.foo" for some source IPs, but the attacker can bypass this by sending the request with hostname "Httpbin.Foo".

Patches

  • Istio 1.11.1 and above
  • Istio 1.10.4 and above
  • Istio 1.9.8 and above

Workarounds

A Lua filter may be written to normalize Host header before the authorization check. This is similar to the Path normalization presented in the Security Best Practices guide.

References

More details can be found in the Istio Security Bulletin.

For more information

If you have any questions or comments about this advisory, please email us at istio-security-vulnerability-reports@googlegroups.com

Severity
8.3 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "istio.io/istio"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.9.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "istio.io/istio"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.10.0"
            },
            {
              "fixed": "1.10.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "istio.io/istio"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.11.0"
            },
            {
              "fixed": "1.11.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.11.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2021-39155"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-178"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-08-25T22:29:16Z",
    "nvd_published_at": "2021-08-24T23:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nAccording to [RFC 4343](https://datatracker.ietf.org/doc/html/rfc4343), Istio authorization policy should compare the hostname in the HTTP Host header in a case insensitive way, but currently the comparison is case sensitive.  The Envoy proxy will route the request hostname in a case-insensitive way which means the authorization policy could be bypassed.\n \nAs an example, the user may have an authorization policy that rejects request with hostname \"httpbin.foo\" for some source IPs, but the attacker can bypass this by sending the request with hostname \"Httpbin.Foo\".\n\n### Patches\n* Istio 1.11.1 and above\n* Istio 1.10.4 and above\n* Istio 1.9.8 and above\n\n### Workarounds\nA Lua filter may be written to normalize Host header before the authorization check.  This is similar to the Path normalization presented in the [Security Best Practices](https://istio.io/latest/docs/ops/best-practices/security/#case-normalization) guide.\n\n### References\nMore details can be found in the [Istio Security Bulletin](https://istio.io/latest/news/security/istio-security-2021-008).\n\n### For more information\nIf you have any questions or comments about this advisory, please email us at istio-security-vulnerability-reports@googlegroups.com\n",
  "id": "GHSA-7774-7vr3-cc8j",
  "modified": "2021-12-13T13:09:54Z",
  "published": "2021-08-30T16:15:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/istio/istio/security/advisories/GHSA-7774-7vr3-cc8j"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39155"
    },
    {
      "type": "WEB",
      "url": "https://github.com/istio/istio/commit/084b417a486dbe9b9024d4812877016a484572b1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/istio/istio/commit/76ed51413ddd2a7fa253a368ab20a9cec5fb1cbe"
    },
    {
      "type": "WEB",
      "url": "https://github.com/istio/istio/commit/90b00bdf891e6c770cb3235c14a9b1fda96cc7c5"
    },
    {
      "type": "WEB",
      "url": "https://datatracker.ietf.org/doc/html/rfc4343"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/istio/istio"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Authorization Policy Bypass Due to Case Insensitive Host Comparison"
}

GHSA-7CWC-FJQM-8VH8

Vulnerability from github – Published: 2024-12-10 00:31 – Updated: 2024-12-10 19:09
VLAI
Summary
Drupal core Access bypass
Details

Drupal's uniqueness checking for certain user fields is inconsistent depending on the database engine and its collation. As a result, a user may be able to register with the same email address as another user. This may lead to data integrity issues. This issue affects Drupal Core: from 8.0.0 before 10.2.11, from 10.3.0 before 10.3.9, from 11.0.0 before 11.0.8.

Severity
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "drupal/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.0.0"
            },
            {
              "fixed": "10.2.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "drupal/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.3.0"
            },
            {
              "fixed": "10.3.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "drupal/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.0.0"
            },
            {
              "fixed": "11.0.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "drupal/core-recommended"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.0.0"
            },
            {
              "fixed": "10.2.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "drupal/core-recommended"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.3.0"
            },
            {
              "fixed": "10.3.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "drupal/core-recommended"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.0.0"
            },
            {
              "fixed": "11.0.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "drupal/drupal"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.0.0"
            },
            {
              "fixed": "10.2.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "drupal/drupal"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.3.0"
            },
            {
              "fixed": "10.3.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "drupal/drupal"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.0.0"
            },
            {
              "fixed": "11.0.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-55634"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-178"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-12-10T19:09:24Z",
    "nvd_published_at": "2024-12-10T00:15:22Z",
    "severity": "MODERATE"
  },
  "details": "Drupal\u0027s uniqueness checking for certain user fields is inconsistent depending on the database engine and its collation. As a result, a user may be able to register with the same email address as another user. This may lead to data integrity issues. This issue affects Drupal Core: from 8.0.0 before 10.2.11, from 10.3.0 before 10.3.9, from 11.0.0 before 11.0.8.",
  "id": "GHSA-7cwc-fjqm-8vh8",
  "modified": "2024-12-10T19:09:24Z",
  "published": "2024-12-10T00:31:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-55634"
    },
    {
      "type": "WEB",
      "url": "https://github.com/drupal/core/commit/7ae0e8f1824e15f8b2b06e4da09836250e85e934"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/drupal/core"
    },
    {
      "type": "WEB",
      "url": "https://www.drupal.org/sa-core-2024-004"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Drupal core Access bypass"
}

GHSA-7FGQ-GPH8-29Q5

Vulnerability from github – Published: 2026-08-05 18:31 – Updated: 2026-08-06 18:30
VLAI
Details

Jenkins 2.575 and earlier, LTS 2.568.1 and earlier handles case-insensitivity in user names and group names inconsistently, allowing attackers able to create new users or groups with names that case-insensitively match other characters to impersonate other users or be granted their permissions in some circumstances.

Severity
8.1 (High)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-70429"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-178"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-05T18:17:12Z",
    "severity": "HIGH"
  },
  "details": "Jenkins 2.575 and earlier, LTS 2.568.1 and earlier handles case-insensitivity in user names and group names inconsistently, allowing attackers able to create new users or groups with names that case-insensitively match other characters to impersonate other users or be granted their permissions in some circumstances.",
  "id": "GHSA-7fgq-gph8-29q5",
  "modified": "2026-08-06T18:30:42Z",
  "published": "2026-08-05T18:31:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-70429"
    },
    {
      "type": "WEB",
      "url": "https://www.jenkins.io/security/advisory/2026-08-05/#SECURITY-3924"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8364-HFQJ-PWM6

Vulnerability from github – Published: 2026-05-19 15:31 – Updated: 2026-06-04 18:49
VLAI
Summary
Camel-CXF and Camel-Knative Message Header are Vulnerable to Injection via Missing Inbound Filtering
Details

Camel-CXF and Camel-Knative Message Header Injection via Missing Inbound Filtering

The CXF and Knative HeaderFilterStrategy implementations (CxfRsHeaderFilterStrategy in camel-cxf-rest, CxfHeaderFilterStrategy in camel-cxf-transport, and KnativeHttpHeaderFilterStrategy in camel-knative-http) only filter outbound Camel-internal headers via setOutFilterStartsWith, while not configuring inbound filtering via setInFilterStartsWith. As a result, an unauthenticated attacker can inject Camel-internal headers (e.g. CamelExecCommandExecutable, CamelFileName) via HTTP requests to CXF-RS or CXF-SOAP endpoints. When a route forwards messages from these endpoints to header-driven components such as camel-exec or camel-file, the injected headers override configured values, enabling remote code execution or arbitrary file writes. This is the same pattern that was previously addressed in camel-undertow (CVE-2025-30177), the broader incoming-header filter (CVE-2025-27636 and CVE-2025-29891), and non-HTTP strategies (CVE-2026-40453).

This issue affects Apache Camel: from 3.18.0 before 4.14.6, from 4.15.0 before 4.18.2.

Users are recommended to upgrade to version 4.19.0, which fixes the issue. If users are on the 4.18.x LTS releases stream, then they are suggested to upgrade to 4.18.2. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.6.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.camel:camel-cxf-rest"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.18.0"
            },
            {
              "fixed": "4.14.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.camel:camel-cxf-rest"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.15.0"
            },
            {
              "fixed": "4.18.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-47323"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-178"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-04T18:49:44Z",
    "nvd_published_at": "2026-05-19T14:16:48Z",
    "severity": "CRITICAL"
  },
  "details": "Camel-CXF and Camel-Knative Message Header Injection via Missing Inbound Filtering\n\nThe CXF and Knative HeaderFilterStrategy implementations (CxfRsHeaderFilterStrategy in camel-cxf-rest, CxfHeaderFilterStrategy in camel-cxf-transport, and KnativeHttpHeaderFilterStrategy in camel-knative-http) only filter outbound Camel-internal headers via setOutFilterStartsWith, while not configuring inbound filtering via setInFilterStartsWith. As a result, an unauthenticated attacker can inject Camel-internal headers (e.g. CamelExecCommandExecutable, CamelFileName) via HTTP requests to CXF-RS or CXF-SOAP endpoints. When a route forwards messages from these endpoints to header-driven components such as camel-exec or camel-file, the injected headers override configured values, enabling remote code execution or arbitrary file writes. This is the same pattern that was previously addressed in camel-undertow (CVE-2025-30177), the broader incoming-header filter (CVE-2025-27636 and CVE-2025-29891), and non-HTTP strategies (CVE-2026-40453).\n\n\nThis issue affects Apache Camel: from 3.18.0 before 4.14.6, from 4.15.0 before 4.18.2.\n\nUsers are recommended to upgrade to version 4.19.0, which fixes the issue. If users are on the 4.18.x LTS releases stream, then they are suggested to upgrade to 4.18.2. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.6.",
  "id": "GHSA-8364-hfqj-pwm6",
  "modified": "2026-06-04T18:49:44Z",
  "published": "2026-05-19T15:31:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47323"
    },
    {
      "type": "WEB",
      "url": "https://camel.apache.org/security/CVE-2026-47323.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/camel"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Camel-CXF and Camel-Knative Message Header are Vulnerable to Injection via Missing Inbound Filtering"
}

GHSA-85HQ-Q7C6-7J82

Vulnerability from github – Published: 2026-09-02 15:34 – Updated: 2026-09-02 21:32
VLAI
Details

Improper Handling of Case Sensitivity vulnerability in Drupal External Authentication allows Privilege Escalation. This issue affects External Authentication versions: from 0.0.0 to 2.0.13.

Severity
5.4 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-73476"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-178"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-02T13:18:08Z",
    "severity": "MODERATE"
  },
  "details": "Improper Handling of Case Sensitivity vulnerability in Drupal External Authentication allows Privilege Escalation. This issue affects External Authentication versions: from 0.0.0 to 2.0.13.",
  "id": "GHSA-85hq-q7c6-7j82",
  "modified": "2026-09-02T21:32:02Z",
  "published": "2026-09-02T15:34:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-73476"
    },
    {
      "type": "WEB",
      "url": "https://www.drupal.org/sa-contrib-2026-098"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8678-W3JW-XFC2

Vulnerability from github – Published: 2026-06-19 16:36 – Updated: 2026-06-19 16:36
VLAI
Summary
Nokogiri: XML::Schema on JRuby allows network requests when NONET is set, bypassing CVE-2020-26247
Details

Summary

The NONET parse option, which Nokogiri turns on by default for Nokogiri::XML::Schema (see CVE-2020-26247), was not correctly enforced on the JRuby implementation. As a result, a schema parsed with default options could still cause external resources to be fetched over the network, potentially enabling SSRF or XXE attacks.

Nokogiri 1.19.4 replaces the scheme denylist with an allowlist. When NONET is enabled, only local resources (a file: scheme, or a relative or absolute path with no scheme) are resolved, and every network scheme is blocked, case-insensitively. This brings the JRuby behavior in line with CRuby.

Only the JRuby implementation is affected. CRuby is not affected, because libxml2's xmlNoNetExternalEntityLoader blocks all network schemes at the I/O layer regardless of scheme or case.

Severity

The Nokogiri maintainers have evaluated this as low severity (CVSS 2.6, CVSS:3.0/AV:N/AC:H/PR:L/UI:R/S:U/C:L/I:N/A:N). It is a bypass of CVE-2020-26247, which was scored the same way.

Mitigation

Upgrade to Nokogiri 1.19.4 or later.

There are no known workarounds for affected versions.

This change properly enforces NONET on JRuby, which is a breaking change for any code that (perhaps unknowingly) relied on the previous behavior to load network resources with default parse options. If you trust your input and want to allow external resources to be accessed over the network, you can explicitly disable NONET, exactly as documented for CVE-2020-26247:

  1. Ensure the input is trusted. Do not enable this option for untrusted input.
  2. Pass a Nokogiri::XML::ParseOptions with the NONET flag turned off:
# allows resources to be accessed over the network for trusted input
schema = Nokogiri::XML::Schema.new(trusted_schema, Nokogiri::XML::ParseOptions.new.nononet)

References

  • Bypass of: https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-vr8q-g5c7-m54m

Credit

This issue was responsibly reported by @bilerden.

Severity
2.6 (Low)
CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "nokogiri"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.19.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-178",
      "CWE-184",
      "CWE-611"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-19T16:36:11Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "### Summary\n\nThe `NONET` parse option, which Nokogiri turns on by default for `Nokogiri::XML::Schema` (see [CVE-2020-26247](https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-vr8q-g5c7-m54m)), was not correctly enforced on the JRuby implementation. As a result, a schema parsed with default options could still cause external resources to be fetched over the network, potentially enabling SSRF or XXE attacks.\n\nNokogiri 1.19.4 replaces the scheme denylist with an allowlist. When `NONET` is enabled, only local resources (a `file:` scheme, or a relative or absolute path with no scheme) are resolved, and every network scheme is blocked, case-insensitively. This brings the JRuby behavior in line with CRuby.\n\nOnly the JRuby implementation is affected. CRuby is not affected, because libxml2\u0027s `xmlNoNetExternalEntityLoader` blocks all network schemes at the I/O layer regardless of scheme or case.\n\n### Severity\n\nThe Nokogiri maintainers have evaluated this as low severity (CVSS 2.6, `CVSS:3.0/AV:N/AC:H/PR:L/UI:R/S:U/C:L/I:N/A:N`). It is a bypass of CVE-2020-26247, which was scored the same way.\n\n### Mitigation\n\nUpgrade to Nokogiri 1.19.4 or later.\n\nThere are no known workarounds for affected versions.\n\nThis change properly enforces `NONET` on JRuby, which is a breaking change for any code that (perhaps unknowingly) relied on the previous behavior to load network resources with default parse options. If you trust your input and want to allow external resources to be accessed over the network, you can explicitly disable `NONET`, exactly as documented for CVE-2020-26247:\n\n1. Ensure the input is trusted. Do not enable this option for untrusted input.\n2. Pass a `Nokogiri::XML::ParseOptions` with the `NONET` flag turned off:\n\n``` ruby\n# allows resources to be accessed over the network for trusted input\nschema = Nokogiri::XML::Schema.new(trusted_schema, Nokogiri::XML::ParseOptions.new.nononet)\n```\n\n### References\n\n- Bypass of: https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-vr8q-g5c7-m54m\n\n### Credit\n\nThis issue was responsibly reported by @bilerden.",
  "id": "GHSA-8678-w3jw-xfc2",
  "modified": "2026-06-19T16:36:11Z",
  "published": "2026-06-19T16:36:11Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-8678-w3jw-xfc2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sparklemotion/nokogiri"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Nokogiri: XML::Schema on JRuby allows network requests when NONET is set, bypassing CVE-2020-26247"
}

GHSA-893R-MPWJ-QHHG

Vulnerability from github – Published: 2024-06-11 15:31 – Updated: 2024-08-12 18:30
VLAI
Details

In violation of spec, cookie prefixes such as __Secure were being ignored if they were not correctly capitalized - by spec they should be checked with a case-insensitive comparison. This could have resulted in the browser not correctly honoring the behaviors specified by the prefix. This vulnerability affects Firefox < 127.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-5699"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-178"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-11T13:15:51Z",
    "severity": "CRITICAL"
  },
  "details": "In violation of spec, cookie prefixes such as `__Secure` were being ignored if they were not correctly capitalized - by spec they should be checked with a case-insensitive comparison. This could have resulted in the browser not correctly honoring the behaviors specified by the prefix. This vulnerability affects Firefox \u003c 127.",
  "id": "GHSA-893r-mpwj-qhhg",
  "modified": "2024-08-12T18:30:44Z",
  "published": "2024-06-11T15:31:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-5699"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1891349"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2024-25"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation MIT-44
Architecture and Design

Strategy: Input Validation

Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names.

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.
Mitigation MIT-20
Implementation

Strategy: Input Validation

Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list