CWE-755
DiscouragedImproper Handling of Exceptional Conditions
Abstraction: Class · Status: Incomplete
The product does not handle or incorrectly handles an exceptional condition.
736 vulnerabilities reference this CWE, most recent first.
GHSA-R3MR-JGH6-PHPP
Vulnerability from github – Published: 2024-02-06 09:31 – Updated: 2024-02-06 09:31Dell Power Manager, versions prior to 3.14, contain an Improper Authorization vulnerability in DPM service. A low privileged malicious user could potentially exploit this vulnerability in order to elevate privileges on the system.
{
"affected": [],
"aliases": [
"CVE-2023-25543"
],
"database_specific": {
"cwe_ids": [
"CWE-280",
"CWE-755"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-06T07:15:08Z",
"severity": "HIGH"
},
"details": "\nDell Power Manager, versions prior to 3.14, contain an Improper Authorization vulnerability in DPM service. A low privileged malicious user could potentially exploit this vulnerability in order to elevate privileges on the system. \n\n",
"id": "GHSA-r3mr-jgh6-phpp",
"modified": "2024-02-06T09:31:37Z",
"published": "2024-02-06T09:31:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-25543"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/kbdoc/en-us/000209464/dsa-2023-075"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-R3R2-RV2R-78WF
Vulnerability from github – Published: 2022-05-24 17:25 – Updated: 2023-01-24 03:30An unhandled exception in check_ignored() in apport/report.py can be exploited by a local attacker to cause a denial of service. If the mtime attribute is a string value in apport-ignore.xml, it will trigger an unhandled exception, resulting in a crash. Fixed in 2.20.1-0ubuntu2.24, 2.20.9-0ubuntu7.16, 2.20.11-0ubuntu27.6.
{
"affected": [],
"aliases": [
"CVE-2020-15701"
],
"database_specific": {
"cwe_ids": [
"CWE-755"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-08-06T23:15:00Z",
"severity": "LOW"
},
"details": "An unhandled exception in check_ignored() in apport/report.py can be exploited by a local attacker to cause a denial of service. If the mtime attribute is a string value in apport-ignore.xml, it will trigger an unhandled exception, resulting in a crash. Fixed in 2.20.1-0ubuntu2.24, 2.20.9-0ubuntu7.16, 2.20.11-0ubuntu27.6.",
"id": "GHSA-r3r2-rv2r-78wf",
"modified": "2023-01-24T03:30:17Z",
"published": "2022-05-24T17:25:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15701"
},
{
"type": "WEB",
"url": "https://launchpad.net/bugs/1877023"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4449-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4449-2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-R3RM-QPHW-HH76
Vulnerability from github – Published: 2026-10-06 20:37 – Updated: 2026-10-06 20:37Root Cause
File: internal/bodyprocessors/multipart.go (since commit 3347961b, PR #1453 "feat: ignore unexpected EOF in MIME multipart request body processor", merged 2026-03-06, first shipped in v3.4.0).
The multipart body processor treats io.ErrUnexpectedEOF as a benign condition. Three sites are affected; all mishandle the error the same way.
File branch, filesystem-backed (lines 71–77)
sz, err := io.Copy(temp, p)
if err != nil {
if !errors.Is(err, io.ErrUnexpectedEOF) {
v.MultipartStrictError().(*collections.Single).Set("1")
return err
}
seenUnexpectedEOF = true // <-- flag never set for UnexpectedEOF
}
File branch, TinyGo path (lines 82–88)
sz, err := io.Copy(io.Discard, p)
if err != nil {
if !errors.Is(err, io.ErrUnexpectedEOF) {
v.MultipartStrictError().(*collections.Single).Set("1")
return err
}
seenUnexpectedEOF = true // <-- same gap
}
Field branch (lines 102–113)
data, err := io.ReadAll(p)
if err != nil {
if !errors.Is(err, io.ErrUnexpectedEOF) {
v.MultipartStrictError().(*collections.Single).Set("1")
return err
}
}
...
if errors.Is(err, io.ErrUnexpectedEOF) {
break // <-- exits loop with no flag set
}
The function then returns nil at line 116 for any body that ended prematurely. Consequences:
MULTIPART_STRICT_ERRORstays at its initial value0.REQBODY_ERRORis not propagated either (sinceProcessRequestreturnsnil).- Neither of the two canonical defensive rules shipped in
coraza.conf-recommendedfires:conf SecRule REQBODY_ERROR "!@eq 0" "id:200002,phase:2,deny,status:400,..." SecRule MULTIPART_STRICT_ERROR "!@eq 0" "id:200003,phase:2,deny,status:400,..."
All other error branches in the same function (lines 27, 48, 66, 84, 104) correctly set MULTIPART_STRICT_ERROR before returning; this is an inconsistency introduced in #1453, not a systemic issue.
Context — why the error is swallowed
PR #1453 was introduced to support SecRequestBodyLimitAction ProcessPartial: when a body is cut off because it hit the configured request-body limit, the parser should still surface the parts it did receive. The PR legitimately needs to avoid return err on ErrUnexpectedEOF. But it also silenced the strict-error flag, which is the wrong compromise — the flag is exactly how operators observe that something was incomplete. The fix should keep the non-fatal break and still set MULTIPART_STRICT_ERROR, letting the operator decide (via rule 200003 or their own policy) whether partial processing is acceptable.
Impact
Rule 200003 is Coraza's blanket defense against multipart parser-inconsistency evasions — attack classes where the body is crafted so Coraza's Go mime/multipart reader and the backend's multipart parser (PHP, Node, Java, legacy libmodsecurity, etc.) disagree about where fields start or end. The rule fails-closed on any malformed body, so the operator does not need to enumerate every parser-disagreement trick. That defense is now void for any evasion that also truncates the body.
Examples of what becomes reachable:
- Smuggling a second field past the truncation boundary that the backend's more permissive parser still extracts.
- Hiding payload bytes after a deliberately malformed
Content-Dispositionheader that the Go parser refuses but the backend accepts. - Generic CRS evasion chains that depend on rule 200003 as a catch-all.
The fix is tiny and low-risk. The impact is disproportionately large because rule 200003 is the only defense-in-depth rule for multipart in the recommended config — there is no secondary signal.
Proof of Concept
Start a Coraza-wrapped HTTP server shipping the canonical defensive rules from coraza.conf-recommended:
SecRuleEngine On
SecRequestBodyAccess On
SecRule REQBODY_ERROR "!@eq 0" \
"id:200002,phase:2,t:none,log,deny,status:400,msg:'Failed to parse request body.'"
SecRule MULTIPART_STRICT_ERROR "!@eq 0" \
"id:200003,phase:2,t:none,log,deny,status:400,msg:'Multipart strict validation failed.'"
Three real-curl requests against the listener:
| # | Body | Expected (with rule 200003) | Observed |
|---|---|---|---|
| 1 | Well-formed field1=benign + closing boundary |
HTTP 200 | HTTP 200 (baseline) |
| 2 | Two parts, no closing boundary (...MALFORMED_NO_TRAILING_BOUNDARY) |
HTTP 400 | HTTP 200 |
| 3 | Mid-part cutoff: name="x"\r\n\r\nabc (no \r\n, no boundary) |
HTTP 400 | HTTP 200 |
Server-side match log is empty for cases 2 and 3: neither rule 200002 nor rule 200003 fires. Example (case 2):
--PoCBoundary12345\r\n
Content-Disposition: form-data; name="field1"\r\n\r\n
benign\r\n
--PoCBoundary12345\r\n
Content-Disposition: form-data; name="truncated"\r\n\r\n
MALFORMED_NO_TRAILING_BOUNDARY
→ HTTP 200, no audit record, transaction.variables.multipartStrictError == 0.
Mitigation
A two-line change per site in internal/bodyprocessors/multipart.go:
if errors.Is(err, io.ErrUnexpectedEOF) {
v.MultipartStrictError().(*collections.Single).Set("1")
seenUnexpectedEOF = true // keep existing break semantics
}
Apply at the three sites (lines 71–77, 82–88, 102–113 in the current code). No change to the return err control flow is needed — the fix only adds the flag-setter alongside the existing seenUnexpectedEOF = true / break path. PR #1453's ProcessPartial goal is preserved.
Operators running in ProcessPartial mode who intentionally allow truncated bodies should pair this with a config-level change (downgrade rule 200003 to detection-only, or scope it with a secondary check on whether SecRequestBodyLimit was actually hit). The engine change above is safe by default — it restores the invariant that malformed multipart always raises MULTIPART_STRICT_ERROR.
Affected versions
Introduced in PR #1453 (commit 3347961b, merged 2026-03-06). First released in v3.4.0 and still present on main at 599ae64a.
Affected: >= 3.4.0, <= 3.7.0.
Releases prior to v3.4.0 returned err on io.ErrUnexpectedEOF and so REQBODY_ERROR would propagate via rule 200002 even if MULTIPART_STRICT_ERROR was not set — a different (arguably stricter) behavior that did not exhibit this bypass.
References
internal/bodyprocessors/multipart.golines 70–113coraza.conf-recommendedruleid:200003(MULTIPART_STRICT_ERROR)- PR #1453 — introduction of
ErrUnexpectedEOFswallowing coraza.conf-recommendedruleid:200002(REQBODY_ERROR) — also not raised becauseProcessRequestreturnsnil
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.7.0"
},
"package": {
"ecosystem": "Go",
"name": "github.com/corazawaf/coraza/v3"
},
"ranges": [
{
"events": [
{
"introduced": "3.4.0"
},
{
"fixed": "3.8.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-41508"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-693",
"CWE-755"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-06T20:37:54Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Root Cause\n\nFile: `internal/bodyprocessors/multipart.go` (since commit `3347961b`, PR #1453 *\"feat: ignore unexpected EOF in MIME multipart request body processor\"*, merged 2026-03-06, first shipped in `v3.4.0`).\n\nThe multipart body processor treats `io.ErrUnexpectedEOF` as a benign condition. Three sites are affected; all mishandle the error the same way.\n\n### File branch, filesystem-backed (lines 71\u201377)\n\n```go\nsz, err := io.Copy(temp, p)\nif err != nil {\n if !errors.Is(err, io.ErrUnexpectedEOF) {\n v.MultipartStrictError().(*collections.Single).Set(\"1\")\n return err\n }\n seenUnexpectedEOF = true // \u003c-- flag never set for UnexpectedEOF\n}\n```\n\n### File branch, TinyGo path (lines 82\u201388)\n\n```go\nsz, err := io.Copy(io.Discard, p)\nif err != nil {\n if !errors.Is(err, io.ErrUnexpectedEOF) {\n v.MultipartStrictError().(*collections.Single).Set(\"1\")\n return err\n }\n seenUnexpectedEOF = true // \u003c-- same gap\n}\n```\n\n### Field branch (lines 102\u2013113)\n\n```go\ndata, err := io.ReadAll(p)\nif err != nil {\n if !errors.Is(err, io.ErrUnexpectedEOF) {\n v.MultipartStrictError().(*collections.Single).Set(\"1\")\n return err\n }\n}\n...\nif errors.Is(err, io.ErrUnexpectedEOF) {\n break // \u003c-- exits loop with no flag set\n}\n```\n\nThe function then returns `nil` at line 116 for any body that ended prematurely. Consequences:\n\n1. `MULTIPART_STRICT_ERROR` stays at its initial value `0`.\n2. `REQBODY_ERROR` is not propagated either (since `ProcessRequest` returns `nil`).\n3. Neither of the two canonical defensive rules shipped in `coraza.conf-recommended` fires:\n ```conf\n SecRule REQBODY_ERROR \"!@eq 0\" \"id:200002,phase:2,deny,status:400,...\"\n SecRule MULTIPART_STRICT_ERROR \"!@eq 0\" \"id:200003,phase:2,deny,status:400,...\"\n ```\n\nAll other error branches in the same function (lines 27, 48, 66, 84, 104) correctly set `MULTIPART_STRICT_ERROR` before returning; this is an inconsistency introduced in #1453, not a systemic issue.\n\n## Context \u2014 why the error is swallowed\n\nPR #1453 was introduced to support `SecRequestBodyLimitAction ProcessPartial`: when a body is cut off because it hit the configured request-body limit, the parser should still surface the parts it did receive. The PR legitimately needs to avoid `return err` on `ErrUnexpectedEOF`. But it also silenced the strict-error flag, which is the wrong compromise \u2014 the flag is exactly how operators observe that something was incomplete. The fix should keep the non-fatal `break` and still set `MULTIPART_STRICT_ERROR`, letting the operator decide (via rule 200003 or their own policy) whether partial processing is acceptable.\n\n## Impact\n\nRule 200003 is Coraza\u0027s blanket defense against **multipart parser-inconsistency evasions** \u2014 attack classes where the body is crafted so Coraza\u0027s Go `mime/multipart` reader and the backend\u0027s multipart parser (PHP, Node, Java, legacy libmodsecurity, etc.) disagree about where fields start or end. The rule fails-closed on *any* malformed body, so the operator does not need to enumerate every parser-disagreement trick. That defense is now void for any evasion that also truncates the body.\n\nExamples of what becomes reachable:\n\n- Smuggling a second field past the truncation boundary that the backend\u0027s more permissive parser still extracts.\n- Hiding payload bytes after a deliberately malformed `Content-Disposition` header that the Go parser refuses but the backend accepts.\n- Generic CRS evasion chains that depend on rule 200003 as a catch-all.\n\nThe fix is tiny and low-risk. The impact is disproportionately large because rule 200003 is the *only* defense-in-depth rule for multipart in the recommended config \u2014 there is no secondary signal.\n\n## Proof of Concept\n\nStart a Coraza-wrapped HTTP server shipping the canonical defensive rules from `coraza.conf-recommended`:\n\n```conf\nSecRuleEngine On\nSecRequestBodyAccess On\nSecRule REQBODY_ERROR \"!@eq 0\" \\\n \"id:200002,phase:2,t:none,log,deny,status:400,msg:\u0027Failed to parse request body.\u0027\"\nSecRule MULTIPART_STRICT_ERROR \"!@eq 0\" \\\n \"id:200003,phase:2,t:none,log,deny,status:400,msg:\u0027Multipart strict validation failed.\u0027\"\n```\n\nThree real-curl requests against the listener:\n\n| # | Body | Expected (with rule 200003) | Observed |\n|---|---|---|---|\n| 1 | Well-formed `field1=benign` + closing boundary | HTTP 200 | HTTP 200 (baseline) |\n| 2 | Two parts, **no closing boundary** (`...MALFORMED_NO_TRAILING_BOUNDARY`) | HTTP 400 | **HTTP 200** |\n| 3 | Mid-part cutoff: `name=\"x\"\\r\\n\\r\\nabc` (no `\\r\\n`, no boundary) | HTTP 400 | **HTTP 200** |\n\nServer-side match log is empty for cases 2 and 3: neither rule 200002 nor rule 200003 fires. Example (case 2):\n\n```\n--PoCBoundary12345\\r\\n\nContent-Disposition: form-data; name=\"field1\"\\r\\n\\r\\n\nbenign\\r\\n\n--PoCBoundary12345\\r\\n\nContent-Disposition: form-data; name=\"truncated\"\\r\\n\\r\\n\nMALFORMED_NO_TRAILING_BOUNDARY\n```\n\u2192 `HTTP 200`, no audit record, transaction.variables.multipartStrictError == 0.\n\n## Mitigation\n\nA two-line change per site in `internal/bodyprocessors/multipart.go`:\n\n```go\nif errors.Is(err, io.ErrUnexpectedEOF) {\n v.MultipartStrictError().(*collections.Single).Set(\"1\")\n seenUnexpectedEOF = true // keep existing break semantics\n}\n```\n\nApply at the three sites (lines 71\u201377, 82\u201388, 102\u2013113 in the current code). No change to the `return err` control flow is needed \u2014 the fix only adds the flag-setter alongside the existing `seenUnexpectedEOF = true` / `break` path. PR #1453\u0027s ProcessPartial goal is preserved.\n\nOperators running in `ProcessPartial` mode who intentionally allow truncated bodies should pair this with a config-level change (downgrade rule 200003 to detection-only, or scope it with a secondary check on whether `SecRequestBodyLimit` was actually hit). The engine change above is safe by default \u2014 it restores the invariant that malformed multipart always raises `MULTIPART_STRICT_ERROR`.\n\n## Affected versions\n\nIntroduced in PR #1453 (commit `3347961b`, merged 2026-03-06). First released in `v3.4.0` and still present on `main` at `599ae64a`.\n\nAffected: `\u003e= 3.4.0, \u003c= 3.7.0`.\n\nReleases prior to `v3.4.0` returned `err` on `io.ErrUnexpectedEOF` and so `REQBODY_ERROR` would propagate via rule 200002 even if `MULTIPART_STRICT_ERROR` was not set \u2014 a different (arguably stricter) behavior that did not exhibit this bypass.\n\n## References\n\n- `internal/bodyprocessors/multipart.go` lines 70\u2013113\n- `coraza.conf-recommended` rule `id:200003` (`MULTIPART_STRICT_ERROR`)\n- PR #1453 \u2014 introduction of `ErrUnexpectedEOF` swallowing\n- `coraza.conf-recommended` rule `id:200002` (`REQBODY_ERROR`) \u2014 also not raised because `ProcessRequest` returns `nil`",
"id": "GHSA-r3rm-qphw-hh76",
"modified": "2026-10-06T20:37:55Z",
"published": "2026-10-06T20:37:54Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/corazawaf/coraza/security/advisories/GHSA-r3rm-qphw-hh76"
},
{
"type": "WEB",
"url": "https://github.com/corazawaf/coraza/commit/f94c81bec209f658120c418448d0590a549b71df"
},
{
"type": "PACKAGE",
"url": "https://github.com/corazawaf/coraza"
},
{
"type": "WEB",
"url": "https://github.com/corazawaf/coraza/releases/tag/v3.8.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Coraza: Truncated multipart body bypasses MULTIPART_STRICT_ERROR (rule 200003) via silent io.ErrUnexpectedEOF handling"
}
GHSA-R546-3C3C-RC3G
Vulnerability from github – Published: 2023-08-03 09:30 – Updated: 2024-04-04 06:30Due to insufficient file permissions, unprivileged users could gain access to unencrypted user credentials that are used in the integration interface towards 3rd party systems.
{
"affected": [],
"aliases": [
"CVE-2023-21408"
],
"database_specific": {
"cwe_ids": [
"CWE-755"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-08-03T07:15:12Z",
"severity": "CRITICAL"
},
"details": "\nDue to insufficient file permissions, unprivileged users could gain access to unencrypted user credentials\nthat are used in the integration interface towards 3rd party systems.\n\n",
"id": "GHSA-r546-3c3c-rc3g",
"modified": "2024-04-04T06:30:39Z",
"published": "2023-08-03T09:30:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-21408"
},
{
"type": "WEB",
"url": "https://www.axis.com/dam/public/0b/1c/96/cve-2023-2140712-en-US-409778.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-R5X6-W42P-JHPP
Vulnerability from github – Published: 2023-03-17 18:22 – Updated: 2023-03-20 13:59Impact
When Cilium is started, there is a short period when Cilium eBPF programs are not attached to the host. During this period, the host does not implement any of Cilium's featureset. This can cause disruption to newly established connections during this period due to the lack of Load Balancing, or can cause Network Policy bypass due to the lack of Network Policy enforcement during the window. This vulnerability impacts any Cilium-managed endpoints on the node (such as Kubernetes Pods), as well as the host network namespace (including Host Firewall).
Patches
This vulnerability is fixed by https://github.com/cilium/cilium/pull/24336, included in Cilium 1.13.1 or later. Cilium releases 1.12.x, 1.11.x and earlier are not affected.
Workarounds
There are no known workarounds.
Acknowledgements
The Cilium community has worked together with members of Isovalent to prepare these mitigations. Special thanks to Louis DeLosSantos and Timo Beckers for investigating and fixing the issue.
For more information
If you have any questions or comments about this advisory, please reach out on Slack.
As usual, if you think you found a related vulnerability, we strongly encourage you to report security vulnerabilities to our private security mailing list: security@cilium.io - first, before disclosing them in any public forums. This is a private mailing list where only members of the Cilium internal security team are subscribed to, and is treated as top priority.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/cilium/cilium"
},
"ranges": [
{
"events": [
{
"introduced": "1.13.0"
},
{
"fixed": "1.13.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-27595"
],
"database_specific": {
"cwe_ids": [
"CWE-755"
],
"github_reviewed": true,
"github_reviewed_at": "2023-03-17T18:22:57Z",
"nvd_published_at": "2023-03-17T22:15:00Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nWhen Cilium is started, there is a short period when Cilium eBPF programs are not attached to the host. During this period, the host does not implement any of Cilium\u0027s featureset. This can cause disruption to newly established connections during this period due to the lack of Load Balancing, or can cause Network Policy bypass due to the lack of Network Policy enforcement during the window. This vulnerability impacts any Cilium-managed endpoints on the node (such as Kubernetes Pods), as well as the host network namespace (including Host Firewall).\n\n### Patches\n\nThis vulnerability is fixed by https://github.com/cilium/cilium/pull/24336, included in Cilium 1.13.1 or later. Cilium releases 1.12.x, 1.11.x and earlier are not affected.\n\n### Workarounds\n\nThere are no known workarounds.\n\n### Acknowledgements\n\nThe Cilium community has worked together with members of Isovalent to prepare these mitigations. Special thanks to Louis DeLosSantos and Timo Beckers for investigating and fixing the issue.\n\n### For more information\n\nIf you have any questions or comments about this advisory, please reach out on [Slack](https://docs.cilium.io/en/latest/community/community/#slack).\n\nAs usual, if you think you found a related vulnerability, we strongly encourage you to report security vulnerabilities to our private security mailing list: security@cilium.io - first, before disclosing them in any public forums. This is a private mailing list where only members of the Cilium internal security team are subscribed to, and is treated as top priority.\n",
"id": "GHSA-r5x6-w42p-jhpp",
"modified": "2023-03-20T13:59:25Z",
"published": "2023-03-17T18:22:57Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/cilium/cilium/security/advisories/GHSA-r5x6-w42p-jhpp"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-27595"
},
{
"type": "WEB",
"url": "https://github.com/cilium/cilium/pull/24336"
},
{
"type": "PACKAGE",
"url": "https://github.com/cilium/cilium"
},
{
"type": "WEB",
"url": "https://github.com/cilium/cilium/releases/tag/v1.13.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "Cilium eBPF filters may be temporarily removed during agent restart"
}
GHSA-R668-8P4P-W5JH
Vulnerability from github – Published: 2022-05-24 17:48 – Updated: 2022-05-24 17:48On Juniper Networks Junos OS platforms configured as DHCPv6 local server or DHCPv6 Relay Agent, Juniper Networks Dynamic Host Configuration Protocol Daemon (JDHCPD) process might crash with a core dump if a specific DHCPv6 packet is received, resulting in a restart of the daemon. The daemon automatically restarts without intervention, but continued receipt and processing of these specific packets will repeatedly crash the JDHCPD process and sustain the Denial of Service (DoS) condition. This issue only affects DHCPv6. DHCPv4 is not affected by this issue. This issue affects: Juniper Networks Junos OS 17.3 versions prior to 17.3R3-S11; 17.4 versions prior to 17.4R3-S4; 18.1 versions prior to 18.1R3-S12; 18.2 versions prior to 18.2R3-S7; 18.3 versions prior to 18.3R3-S4; 18.4 versions prior to 18.4R3-S7; 19.1 versions prior to 19.1R3-S4; 19.2 versions prior to 19.2R3-S1; 19.3 versions prior to 19.3R3-S1, 19.3R3-S2; 19.4 versions prior to 19.4R3-S1; 20.1 versions prior to 20.1R2, 20.1R3; 20.2 versions prior to 20.2R2, 20.2R3; 20.3 versions prior to 20.3R1-S2, 20.3R2.
{
"affected": [],
"aliases": [
"CVE-2021-0241"
],
"database_specific": {
"cwe_ids": [
"CWE-755"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-04-22T20:15:00Z",
"severity": "HIGH"
},
"details": "On Juniper Networks Junos OS platforms configured as DHCPv6 local server or DHCPv6 Relay Agent, Juniper Networks Dynamic Host Configuration Protocol Daemon (JDHCPD) process might crash with a core dump if a specific DHCPv6 packet is received, resulting in a restart of the daemon. The daemon automatically restarts without intervention, but continued receipt and processing of these specific packets will repeatedly crash the JDHCPD process and sustain the Denial of Service (DoS) condition. This issue only affects DHCPv6. DHCPv4 is not affected by this issue. This issue affects: Juniper Networks Junos OS 17.3 versions prior to 17.3R3-S11; 17.4 versions prior to 17.4R3-S4; 18.1 versions prior to 18.1R3-S12; 18.2 versions prior to 18.2R3-S7; 18.3 versions prior to 18.3R3-S4; 18.4 versions prior to 18.4R3-S7; 19.1 versions prior to 19.1R3-S4; 19.2 versions prior to 19.2R3-S1; 19.3 versions prior to 19.3R3-S1, 19.3R3-S2; 19.4 versions prior to 19.4R3-S1; 20.1 versions prior to 20.1R2, 20.1R3; 20.2 versions prior to 20.2R2, 20.2R3; 20.3 versions prior to 20.3R1-S2, 20.3R2.",
"id": "GHSA-r668-8p4p-w5jh",
"modified": "2022-05-24T17:48:12Z",
"published": "2022-05-24T17:48:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0241"
},
{
"type": "WEB",
"url": "https://kb.juniper.net/JSA11168"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-R886-MF8R-26C7
Vulnerability from github – Published: 2026-10-06 21:31 – Updated: 2026-10-07 09:32Improper Handling of Exceptional Conditions vulnerability in the aspnet-request pattern converter of Apache log4net.
Reading request parameters triggers ASP.NET request validation, so a request carrying content such as markup made the layout throw and the appender discarded the whole event. A sender could suppress the log record of their own request. Only applications on ASP.NET for .NET Framework whose layout uses %aspnet-request are affected.
This issue affects Apache log4net: from 1.2.11 before 3.5.0.
Users are recommended to upgrade to version 3.5.0, which fixes the issue.
{
"affected": [],
"aliases": [
"CVE-2026-105242"
],
"database_specific": {
"cwe_ids": [
"CWE-755"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-06T20:17:16Z",
"severity": "MODERATE"
},
"details": "Improper Handling of Exceptional Conditions vulnerability in the aspnet-request pattern converter of Apache log4net.\n\nReading request parameters triggers ASP.NET request validation, so a request carrying content such as markup made the layout throw and the appender discarded the whole event. A sender could suppress the log record of their own request. Only applications on ASP.NET for .NET Framework whose layout uses %aspnet-request are affected.\n\nThis issue affects Apache log4net: from 1.2.11 before 3.5.0.\n\nUsers are recommended to upgrade to version 3.5.0, which fixes the issue.",
"id": "GHSA-r886-mf8r-26c7",
"modified": "2026-10-07T09:32:18Z",
"published": "2026-10-06T21:31:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-105242"
},
{
"type": "WEB",
"url": "https://github.com/apache/logging-log4net/pull/316"
},
{
"type": "WEB",
"url": "https://github.com/apache/logging-log4net/commit/145203420c579a703008b4b723b6a080757f4964"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/zg6dbqm4ztm7j3c21nfsqj0yxm5yrpdx"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/10/07/16"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
GHSA-R9XW-PV6R-FXR3
Vulnerability from github – Published: 2022-05-24 17:36 – Updated: 2022-05-24 17:36Improper check or handling of exceptional conditions in MELSEC iQ-F series FX5U(C) CPU unit firmware version 1.060 and earlier allows an attacker to cause a denial-of-service (DoS) condition on program execution and communication by sending a specially crafted ARP packet.
{
"affected": [],
"aliases": [
"CVE-2020-5665"
],
"database_specific": {
"cwe_ids": [
"CWE-755"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-12-14T03:15:00Z",
"severity": "HIGH"
},
"details": "Improper check or handling of exceptional conditions in MELSEC iQ-F series FX5U(C) CPU unit firmware version 1.060 and earlier allows an attacker to cause a denial-of-service (DoS) condition on program execution and communication by sending a specially crafted ARP packet.",
"id": "GHSA-r9xw-pv6r-fxr3",
"modified": "2022-05-24T17:36:21Z",
"published": "2022-05-24T17:36:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-5665"
},
{
"type": "WEB",
"url": "https://jvn.jp/vu/JVNVU95638588/index.html"
},
{
"type": "WEB",
"url": "https://us-cert.cisa.gov/ics/advisories/icsa-20-345-01"
},
{
"type": "WEB",
"url": "https://www.mitsubishielectric.co.jp/psirt/vulnerability/pdf/2020-018.pdf"
},
{
"type": "WEB",
"url": "https://www.mitsubishielectric.com/en/psirt/vulnerability/pdf/2020-018_en.pdf"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-RCM3-8WQ2-RCC2
Vulnerability from github – Published: 2024-06-06 18:30 – Updated: 2024-06-06 18:30mintplex-labs/anything-llm is vulnerable to multiple security issues due to improper input validation in several endpoints. An attacker can exploit these vulnerabilities to escalate privileges from a default user role to an admin role, read and delete arbitrary files on the system, and perform Server-Side Request Forgery (SSRF) attacks. The vulnerabilities are present in the /request-token, /workspace/:slug/thread/:threadSlug/update, /system/remove-logo, /system/logo, and collector's /process endpoints. These issues are due to the application's failure to properly validate user input before passing it to prisma functions and other critical operations. Affected versions include the latest version prior to 1.0.0.
{
"affected": [],
"aliases": [
"CVE-2024-3152"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-755",
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-06T18:15:17Z",
"severity": "HIGH"
},
"details": "mintplex-labs/anything-llm is vulnerable to multiple security issues due to improper input validation in several endpoints. An attacker can exploit these vulnerabilities to escalate privileges from a default user role to an admin role, read and delete arbitrary files on the system, and perform Server-Side Request Forgery (SSRF) attacks. The vulnerabilities are present in the `/request-token`, `/workspace/:slug/thread/:threadSlug/update`, `/system/remove-logo`, `/system/logo`, and collector\u0027s `/process` endpoints. These issues are due to the application\u0027s failure to properly validate user input before passing it to `prisma` functions and other critical operations. Affected versions include the latest version prior to 1.0.0.",
"id": "GHSA-rcm3-8wq2-rcc2",
"modified": "2024-06-06T18:30:57Z",
"published": "2024-06-06T18:30:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-3152"
},
{
"type": "WEB",
"url": "https://github.com/mintplex-labs/anything-llm/commit/200bd7f0615347ed2efc07903d510e5a208b0afc"
},
{
"type": "WEB",
"url": "https://huntr.com/bounties/46034fa0-d623-49f8-8ee8-390390181373"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-RCW6-69H3-89FH
Vulnerability from github – Published: 2022-05-24 17:07 – Updated: 2025-10-22 00:31smtp_mailaddr in smtp_session.c in OpenSMTPD 6.6, as used in OpenBSD 6.6 and other products, allows remote attackers to execute arbitrary commands as root via a crafted SMTP session, as demonstrated by shell metacharacters in a MAIL FROM field. This affects the "uncommented" default configuration. The issue exists because of an incorrect return value upon failure of input validation.
{
"affected": [],
"aliases": [
"CVE-2020-7247"
],
"database_specific": {
"cwe_ids": [
"CWE-252",
"CWE-755",
"CWE-78"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-01-29T16:15:00Z",
"severity": "HIGH"
},
"details": "smtp_mailaddr in smtp_session.c in OpenSMTPD 6.6, as used in OpenBSD 6.6 and other products, allows remote attackers to execute arbitrary commands as root via a crafted SMTP session, as demonstrated by shell metacharacters in a MAIL FROM field. This affects the \"uncommented\" default configuration. The issue exists because of an incorrect return value upon failure of input validation.",
"id": "GHSA-rcw6-69h3-89fh",
"modified": "2025-10-22T00:31:50Z",
"published": "2022-05-24T17:07:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-7247"
},
{
"type": "WEB",
"url": "https://github.com/openbsd/src/commit/9dcfda045474d8903224d175907bfc29761dcb45"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/OPH4QU4DNVHA7ACFXMYFCEP5PSXXPN4E"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OPH4QU4DNVHA7ACFXMYFCEP5PSXXPN4E"
},
{
"type": "WEB",
"url": "https://seclists.org/bugtraq/2020/Jan/51"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4268-1"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2020-7247"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2020/dsa-4611"
},
{
"type": "WEB",
"url": "https://www.kb.cert.org/vuls/id/390745"
},
{
"type": "WEB",
"url": "https://www.openbsd.org/security.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/156137/OpenBSD-OpenSMTPD-Privilege-Escalation-Code-Execution.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/156145/OpenSMTPD-6.6.2-Remote-Code-Execution.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/156249/OpenSMTPD-MAIL-FROM-Remote-Code-Execution.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/156295/OpenSMTPD-6.6.1-Local-Privilege-Escalation.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/162093/OpenBSD-OpenSMTPD-6.6-Remote-Code-Execution.html"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2020/Jan/49"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2020/01/28/3"
}
],
"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"
}
]
}
No mitigation information available for this CWE.
No CAPEC attack patterns related to this CWE.