CWE-178
AllowedImproper Handling of Case Sensitivity
Abstraction: Base · Status: Incomplete
The product does not properly account for differences in case sensitivity when accessing or determining the properties of a resource, leading to inconsistent results.
136 vulnerabilities reference this CWE, most recent first.
GHSA-5VX9-J5CW-47VQ
Vulnerability from github – Published: 2023-02-17 18:30 – Updated: 2023-03-01 01:35Authentication vulnerability in MOSN before v.0.23.0 allows attacker to escalate privileges via case-sensitive JWT authorization.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "mosn.io/mosn"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.23.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-32163"
],
"database_specific": {
"cwe_ids": [
"CWE-178",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2023-02-17T20:47:37Z",
"nvd_published_at": "2023-02-17T18:15:00Z",
"severity": "CRITICAL"
},
"details": "Authentication vulnerability in MOSN before v.0.23.0 allows attacker to escalate privileges via case-sensitive JWT authorization.",
"id": "GHSA-5vx9-j5cw-47vq",
"modified": "2023-03-01T01:35:47Z",
"published": "2023-02-17T18:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32163"
},
{
"type": "WEB",
"url": "https://github.com/mosn/mosn/issues/1633"
},
{
"type": "WEB",
"url": "https://github.com/mosn/mosn/pull/1637"
},
{
"type": "PACKAGE",
"url": "https://github.com/mosn/mosn"
}
],
"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": "Privilege escalation in MOSN"
}
GHSA-6C7R-27GF-58JJ
Vulnerability from github – Published: 2022-04-30 18:21 – Updated: 2024-02-15 21:31register.php in Ultimate PHP Board (UPB) 1.0 and 1.0b uses an administrative account Admin with a capital "A," but allows a remote attacker to impersonate the administrator by registering an account name of admin with a lower case "a."
{
"affected": [],
"aliases": [
"CVE-2002-1820"
],
"database_specific": {
"cwe_ids": [
"CWE-178"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2002-12-31T05:00:00Z",
"severity": "HIGH"
},
"details": "register.php in Ultimate PHP Board (UPB) 1.0 and 1.0b uses an administrative account Admin with a capital \"A,\" but allows a remote attacker to impersonate the administrator by registering an account name of admin with a lower case \"a.\"",
"id": "GHSA-6c7r-27gf-58jj",
"modified": "2024-02-15T21:31:22Z",
"published": "2022-04-30T18:21:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2002-1820"
},
{
"type": "WEB",
"url": "http://www.iss.net/security_center/static/9972.php"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/289417"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/5580"
}
],
"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"
}
]
}
GHSA-6RGH-57XM-37V8
Vulnerability from github – Published: 2026-04-30 18:30 – Updated: 2026-06-30 03:36A 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.
{
"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-06-30T03:36:28Z",
"published": "2026-04-30T18:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3833"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:13274"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:20611"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:20612"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:20613"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:26319"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:26409"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:29197"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:30004"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:30849"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:30850"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:32962"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:33125"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-3833"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2445763"
},
{
"type": "WEB",
"url": "https://gitlab.com/gnutls/gnutls/-/issues/1803"
}
],
"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:28Summary
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
--insecureor the--insecure-skip-secure-default-rule-enforcementflags. - When using
regextype 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.
{
"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:09Impact
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
{
"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:09Drupal'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.
{
"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-8364-HFQJ-PWM6
Vulnerability from github – Published: 2026-05-19 15:31 – Updated: 2026-06-04 18:49Camel-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.
{
"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-8678-W3JW-XFC2
Vulnerability from github – Published: 2026-06-19 16:36 – Updated: 2026-06-19 16:36Summary
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:
- Ensure the input is trusted. Do not enable this option for untrusted input.
- Pass a
Nokogiri::XML::ParseOptionswith theNONETflag 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.
{
"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:30In 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.
{
"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"
}
]
}
GHSA-8CJM-8MP7-R2XF
Vulnerability from github – Published: 2026-06-03 15:30 – Updated: 2026-06-03 15:30An issue was discovered in Django 5.2 before 5.2.15 and 6.0 before 6.0.6.
django.middleware.cache.UpdateCacheMiddleware in Django does not match Cache-Control response directives case-insensitively, which allows remote attackers to read responses that were incorrectly cached because their Cache-Control directives used uppercase or mixed-case values.
Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected.
Django would like to thank Ahmed Badawe for reporting this issue.
{
"affected": [],
"aliases": [
"CVE-2026-8404"
],
"database_specific": {
"cwe_ids": [
"CWE-178"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-03T14:16:47Z",
"severity": "LOW"
},
"details": "An issue was discovered in Django 5.2 before 5.2.15 and 6.0 before 6.0.6.\n`django.middleware.cache.UpdateCacheMiddleware` in Django does not match `Cache-Control` response directives case-insensitively, which allows remote attackers to read responses that were incorrectly cached because their `Cache-Control` directives used uppercase or mixed-case values.\nEarlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected.\nDjango would like to thank Ahmed Badawe for reporting this issue.",
"id": "GHSA-8cjm-8mp7-r2xf",
"modified": "2026-06-03T15:30:43Z",
"published": "2026-06-03T15:30:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-8404"
},
{
"type": "WEB",
"url": "https://docs.djangoproject.com/en/dev/releases/security"
},
{
"type": "WEB",
"url": "https://groups.google.com/g/django-announce"
},
{
"type": "WEB",
"url": "https://www.djangoproject.com/weblog/2026/jun/03/security-releases"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
Mitigation MIT-44
Strategy: Input Validation
Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names.
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.
Mitigation MIT-20
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.