CWE-184
AllowedIncomplete List of Disallowed Inputs
Abstraction: Base · Status: Draft
The product implements a protection mechanism that relies on a list of inputs (or properties of inputs) that are not allowed by policy or otherwise require other action to neutralize before additional processing takes place, but the list is incomplete.
366 vulnerabilities reference this CWE, most recent first.
GHSA-2J5Q-PH68-3HP6
Vulnerability from github – Published: 2022-05-17 02:13 – Updated: 2022-05-17 02:13Incomplete blacklist vulnerability in SuiteCRM 7.2.2 allows remote authenticated users to execute arbitrary code by uploading a file with an executable extension.
{
"affected": [],
"aliases": [
"CVE-2015-5946"
],
"database_specific": {
"cwe_ids": [
"CWE-184"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-08-07T20:29:00Z",
"severity": "HIGH"
},
"details": "Incomplete blacklist vulnerability in SuiteCRM 7.2.2 allows remote authenticated users to execute arbitrary code by uploading a file with an executable extension.",
"id": "GHSA-2j5q-ph68-3hp6",
"modified": "2022-05-17T02:13:52Z",
"published": "2022-05-17T02:13:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2015-5946"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2015/08/06/6"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2016/03/02/5"
},
{
"type": "WEB",
"url": "http://xiphosresearch.com/2016/03/01/Vulnerability-Inheritance-across-Forks.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-2MFX-8QW9-7HFH
Vulnerability from github – Published: 2026-08-25 21:31 – Updated: 2026-08-25 21:31NVIDIA OpenShell for Linux contains a vulnerability in its sandbox provisioning API, where an attacker could cause an incomplete list of disallowed inputs. A successful exploit of this vulnerability might lead to code execution, escalation of privileges, information disclosure, data tampering, and denial of service.
{
"affected": [],
"aliases": [
"CVE-2026-65083"
],
"database_specific": {
"cwe_ids": [
"CWE-184"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-25T21:17:28Z",
"severity": "CRITICAL"
},
"details": "NVIDIA OpenShell for Linux contains a vulnerability in its sandbox provisioning API, where an attacker could cause an incomplete list of disallowed inputs. A successful exploit of this vulnerability might lead to code execution, escalation of privileges, information disclosure, data tampering, and denial of service.",
"id": "GHSA-2mfx-8qw9-7hfh",
"modified": "2026-08-25T21:31:30Z",
"published": "2026-08-25T21:31:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-65083"
},
{
"type": "WEB",
"url": "https://github.com/NVIDIA/product-security/tree/main/2026/5872"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65083"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-2P2V-3MJG-GFPF
Vulnerability from github – Published: 2026-08-11 15:32 – Updated: 2026-09-01 21:03Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-957r-qf9p-67xw. This link is maintained to preserve external references.
Original Description
Craft CMS 5.0.0-RC1 before 5.10.6 and 4.0.0-RC1 before 4.18.2 contain an arbitrary file read vulnerability. The create() Twig function restricts class instantiation using a 5-entry blocklist that does not include SplFileObject, allowing an authenticated administrator (with allowAdminChanges=true) to configure a malicious entry type title or URI format that instantiates SplFileObject in a non-sandboxed template context. When a user subsequently creates an entry in the affected section, arbitrary files on the server (such as .env containing the security key and database credentials) are read and rendered as entry titles.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c 4.18.2"
},
"package": {
"ecosystem": "Packagist",
"name": "craftcms/cms"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0-RC1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-184"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-01T21:03:28Z",
"nvd_published_at": "2026-08-11T13:19:08Z",
"severity": "HIGH"
},
"details": "## Duplicate Advisory\n\nThis advisory has been withdrawn because it is a duplicate of\u00a0GHSA-957r-qf9p-67xw. This link is maintained to preserve external references.\n\n## Original Description\nCraft CMS 5.0.0-RC1 before 5.10.6 and 4.0.0-RC1 before 4.18.2 contain an arbitrary file read vulnerability. The create() Twig function restricts class instantiation using a 5-entry blocklist that does not include SplFileObject, allowing an authenticated administrator (with allowAdminChanges=true) to configure a malicious entry type title or URI format that instantiates SplFileObject in a non-sandboxed template context. When a user subsequently creates an entry in the affected section, arbitrary files on the server (such as .env containing the security key and database credentials) are read and rendered as entry titles.",
"id": "GHSA-2p2v-3mjg-gfpf",
"modified": "2026-09-01T21:03:28Z",
"published": "2026-08-11T15:32:38Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/craftcms/cms/security/advisories/GHSA-957r-qf9p-67xw"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72779"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/craft-cms-rc1-before-arbitrary-file-read-via-splfileobject"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/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"
}
],
"summary": "Duplicate Advisory: Craft CMS: Arbitrary file read via SplFileObject in non-sandboxed template contexts",
"withdrawn": "2026-09-01T21:03:28Z"
}
GHSA-2P49-HGCM-8545
Vulnerability from github – Published: 2026-07-21 19:42 – Updated: 2026-08-13 18:08Summary
SVGO's removeScripts plugin (disabled by default) removes scripts from the SVG, however executable scripts were left intact in some cases. If a consumer relied on this plugin for sanitization and served them to users, these SVGs could open up doors to XSS.
Details
SVGO has a plugin for removing scripts from an SVG, which removes:
<script>elements- JavaScript URIs (v4 and v3 only)
on…event handlers (v4 and v3 only)
While SVGO is not a sanitization library, SVGO continues to maintain the plugin for those already using it for this purpose.
However, there were two problems:
- SVGO did not check namespaced/prefixed
scriptelements, for example if one declared an explicit prefix for the SVG namespace (<svg:script>) instead of using the default namespace (<script>), the<svg:script>tag would be left intact. - SVGO case sensitively matched JavaScript URIs, but it should've been case-insensitive.
Proof of Concept
import { optimize } from 'svgo';
/** Presume that this string was obtained in some other way, such as network. */
const original = `
<svg xmlns="http://www.w3.org/2000/svg" xmlns:svg="http://www.w3.org/2000/svg" xmlns:uwu="http://www.w3.org/1999/xlink" viewBox="0 0 100 100" version="1.1">
<a uwu:href="JavaScript:(() => { alert(document.cookie) })();"><text y="30">uwu</text></a>
<svg:script>
alert(document.cookie);
</svg:script>
</svg>
`;
optimize(original, {
plugins: ['removeScripts']
});
// Did not remove <svg:script> or uwu:href="JavaScript:…—still executed by browsers.
Impact
If you run SVGO on untrusted input (e.g., user uploads to a web application) and you depended on removeScripts, then some scripts may still be present. If that SVG was then opened directly by another user on the same domain, it could invoke scripts that could read local storage or cookies.
This may affect you if you have enabled one of the following:
| SVGO Version | Plugin Name |
|---|---|
| v4 | removeScripts |
| v3 | removeScriptElement |
| v2 | removeScriptElement |
| v1 | removeScriptElement |
It's unlikely to impact users who just use SVGO locally on their own SVGs or in build pipelines.
Patches
>= 3.0.0, <= 4.0.1
SVGO patched v4.0.2 and v3.3.4. Just upgrade the dependency using your preferred package manager! For example:
yarn up svgo
# or if SVGO is a nested dependency
yarn up -R svgo
The proposed fix is to improve our namespace-aware handling to explicitly act on the default namespace, SVG namespace, and XHTML namespace only. This handles all scripts that are executed by browsers, but will leave intact custom prefixes that happen to have an element called <*:script> which clients shouldn't treat as executable.
>= 2.0.0, <= 2.8.2
SVGO patched v2.8.3, however SVGO v2 explicitly only implements and documents that it will remove <script> elements and nothing more. It has the namespace aware handling for tags like <svg:script> or <xhtml:script>, but has not been updated to remove JavaScript URIs or event handlers like >= v3. If this is something you need, please upgrade to v4 or v3, or reach for one of the documented workarounds at the end.
>= 1.0.0, <= 1.3.2
SVGO v1 has been deprecated for a while now and won't be patched. Please upgrade to a more recent version! If something is preventing you from doing so, please reach out! We're happy to expand our migration guides or support you if you're having trouble.
Workarounds
If your motivation for enabling the plugin is SVG sanitization, consider reaching for a dedicated SVG sanitization tool and invoke it before passing the SVG to SVGO.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "svgo"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0"
},
{
"fixed": "2.8.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "svgo"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.3.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "svgo"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "4.0.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-73650"
],
"database_specific": {
"cwe_ids": [
"CWE-184",
"CWE-79"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-21T19:42:04Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\nSVGO\u0027s removeScripts plugin (disabled by default) removes scripts from the SVG, however executable scripts were left intact in some cases. If a consumer relied on this plugin for sanitization and served them to users, these SVGs could open up doors to XSS.\n\n### Details\n\nSVGO has a plugin for removing scripts from an SVG, which removes:\n\n- `\u003cscript\u003e` elements\n- JavaScript URIs (v4 and v3 only)\n- `on\u2026` event handlers (v4 and v3 only)\n\nWhile SVGO is not a sanitization library, SVGO continues to maintain the plugin for those already using it for this purpose.\n\nHowever, there were two problems:\n\n- SVGO did not check namespaced/prefixed `script` elements, for example if one declared an explicit prefix for the SVG namespace ( `\u003csvg:script\u003e`) instead of using the default namespace ( `\u003cscript\u003e`), the `\u003csvg:script\u003e` tag would be left intact.\n- SVGO case sensitively matched JavaScript URIs, but it should\u0027ve been case-insensitive.\n\n#### Proof of Concept\n\n```js\nimport { optimize } from \u0027svgo\u0027;\n\n/** Presume that this string was obtained in some other way, such as network. */\nconst original = `\n \u003csvg xmlns=\"http://www.w3.org/2000/svg\" xmlns:svg=\"http://www.w3.org/2000/svg\" xmlns:uwu=\"http://www.w3.org/1999/xlink\" viewBox=\"0 0 100 100\" version=\"1.1\"\u003e\n \u003ca uwu:href=\"JavaScript:(() =\u0026gt; { alert(document.cookie) })();\"\u003e\u003ctext y=\"30\"\u003euwu\u003c/text\u003e\u003c/a\u003e\n \u003csvg:script\u003e\n alert(document.cookie);\n \u003c/svg:script\u003e\n \u003c/svg\u003e\n`;\n\noptimize(original, {\n plugins: [\u0027removeScripts\u0027]\n});\n// Did not remove \u003csvg:script\u003e or uwu:href=\"JavaScript:\u2026\u2014still executed by browsers.\n```\n\n### Impact\n\nIf you run SVGO on untrusted input (e.g., user uploads to a web application) and you depended on removeScripts, then some scripts may still be present. If that SVG was then opened directly by another user on the same domain, it could invoke scripts that could read local storage or cookies.\n\nThis may affect you if you have enabled one of the following:\n\n| SVGO Version | Plugin Name |\n|---|---|\n| v4 | removeScripts |\n| v3 | removeScriptElement |\n| v2 | removeScriptElement |\n| v1 | removeScriptElement |\n\nIt\u0027s unlikely to impact users who just use SVGO locally on their own SVGs or in build pipelines.\n\n### Patches\n\n#### \u003e= 3.0.0, \u003c= 4.0.1\n\nSVGO patched v4.0.2 and v3.3.4. Just upgrade the dependency using your preferred package manager! For example:\n\n```sh\nyarn up svgo\n\n# or if SVGO is a nested dependency\nyarn up -R svgo\n```\n\nThe proposed fix is to improve our namespace-aware handling to explicitly act on the default namespace, SVG namespace, and XHTML namespace only. This handles all scripts that are executed by browsers, but will leave intact custom prefixes that happen to have an element called `\u003c*:script\u003e` which clients shouldn\u0027t treat as executable. \n\n#### \u003e= 2.0.0, \u003c= 2.8.2\n\nSVGO patched v2.8.3, however SVGO v2 explicitly only implements and documents that it will remove `\u003cscript\u003e` elements and nothing more. It has the namespace aware handling for tags like `\u003csvg:script\u003e` or `\u003cxhtml:script\u003e`, but has **_not_** been updated to remove JavaScript URIs or event handlers like \u003e= v3. If this is something you need, please upgrade to v4 or v3, or reach for one of the documented workarounds at the end.\n\n#### \u003e= 1.0.0, \u003c= 1.3.2\n\nSVGO v1 has been deprecated for a while now and won\u0027t be patched. Please upgrade to a more recent version! If something is preventing you from doing so, please reach out! We\u0027re happy to expand our migration guides or support you if you\u0027re having trouble.\n\n### Workarounds\n\nIf your motivation for enabling the plugin is SVG sanitization, consider reaching for a dedicated SVG sanitization tool and invoke it before passing the SVG to SVGO.",
"id": "GHSA-2p49-hgcm-8545",
"modified": "2026-08-13T18:08:43Z",
"published": "2026-07-21T19:42:04Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/svg/svgo/security/advisories/GHSA-2p49-hgcm-8545"
},
{
"type": "WEB",
"url": "https://github.com/svg/svgo/commit/628e3bc7336625a30365d0a9b60185307d852466"
},
{
"type": "WEB",
"url": "https://github.com/svg/svgo/commit/72a23886b4698b27624b936f3a15a80afd36d75f"
},
{
"type": "WEB",
"url": "https://github.com/svg/svgo/commit/f529cfccc6c154d6f6eabe276ec637a8c5db6763"
},
{
"type": "PACKAGE",
"url": "https://github.com/svg/svgo"
},
{
"type": "WEB",
"url": "https://github.com/svg/svgo/releases/tag/v2.8.3"
},
{
"type": "WEB",
"url": "https://github.com/svg/svgo/releases/tag/v3.3.4"
},
{
"type": "WEB",
"url": "https://github.com/svg/svgo/releases/tag/v4.0.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "SVGO removeScripts plugin leaves some executable scripts intact"
}
GHSA-354W-HCPX-6WVW
Vulnerability from github – Published: 2026-08-13 12:31 – Updated: 2026-08-13 12:31Flowise before 3.1.3 contains a sandbox escape vulnerability in pythonCodeValidator.ts that fails to block native Pandas DataFrame methods like to_csv, to_json, pipe, and query. Authenticated attackers can exploit this to exfiltrate uploaded CSV data or write arbitrary files to the server filesystem.
{
"affected": [],
"aliases": [
"CVE-2026-73484"
],
"database_specific": {
"cwe_ids": [
"CWE-184"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-13T12:17:23Z",
"severity": "HIGH"
},
"details": "Flowise before 3.1.3 contains a sandbox escape vulnerability in pythonCodeValidator.ts that fails to block native Pandas DataFrame methods like to_csv, to_json, pipe, and query. Authenticated attackers can exploit this to exfiltrate uploaded CSV data or write arbitrary files to the server filesystem.",
"id": "GHSA-354w-hcpx-6wvw",
"modified": "2026-08-13T12:31:09Z",
"published": "2026-08-13T12:31:09Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-x58f-9m57-qc4m"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-73484"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/flowise-before-sandbox-escape-via-pandas-methods"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/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"
}
]
}
GHSA-36QX-4GHF-XQ84
Vulnerability from github – Published: 2026-04-24 00:31 – Updated: 2026-04-24 00:31OpenClaw before 2026.3.28 contains an SSRF guard bypass vulnerability that fails to block four IPv6 special-use ranges. Attackers can exploit this by crafting URLs targeting internal or non-routable IPv6 addresses to bypass SSRF protections.
{
"affected": [],
"aliases": [
"CVE-2026-41361"
],
"database_specific": {
"cwe_ids": [
"CWE-184",
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-23T22:16:43Z",
"severity": "MODERATE"
},
"details": "OpenClaw before 2026.3.28 contains an SSRF guard bypass vulnerability that fails to block four IPv6 special-use ranges. Attackers can exploit this by crafting URLs targeting internal or non-routable IPv6 addresses to bypass SSRF protections.",
"id": "GHSA-36qx-4ghf-xq84",
"modified": "2026-04-24T00:31:52Z",
"published": "2026-04-24T00:31:52Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-g86v-f9qv-rh6m"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41361"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-ssrf-guard-bypass-via-ipv6-special-use-ranges"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:H/SI:L/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"
}
]
}
GHSA-3888-Q23F-X7QH
Vulnerability from github – Published: 2026-04-21 16:43 – Updated: 2026-04-24 21:06A server-side information disclosure vulnerability was identified in the handling of CSS preprocessor files. Backend users with Editor permissions could craft .less, .sass, or .scss files that leverage the compiler's import functionality to read arbitrary files from the server. This worked even with cms.safe_mode enabled.
Impact
- Potential exposure of sensitive server-side files
- Requires authenticated backend access with Editor permissions
- Only relevant when
cms.safe_modeis enabled (otherwise direct PHP injection is already possible)
Patches
The vulnerability has been patched in v3.7.14 and v4.1.10. When cms.safe_mode is enabled, .less, .sass, and .scss files can no longer be created, uploaded, or edited across the CMS editor, media manager, and file upload interfaces. All users are encouraged to upgrade to the latest patched version.
Workarounds
If upgrading immediately is not possible:
- Set cms.editable_asset_types config to ['css', 'js'] to remove preprocessor file types from the editor
- Restrict Editor tool access to fully trusted administrators only
- Reported by Chris Alupului
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "october/system"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.7.14"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "october/system"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "4.1.10"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-26067"
],
"database_specific": {
"cwe_ids": [
"CWE-184",
"CWE-200",
"CWE-22"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-21T16:43:49Z",
"nvd_published_at": "2026-04-21T17:16:24Z",
"severity": "MODERATE"
},
"details": "A server-side information disclosure vulnerability was identified in the handling of CSS preprocessor files. Backend users with Editor permissions could craft `.less`, `.sass`, or `.scss` files that leverage the compiler\u0027s import functionality to read arbitrary files from the server. This worked even with `cms.safe_mode` enabled.\n\n### Impact\n- Potential exposure of sensitive server-side files\n- Requires authenticated backend access with Editor permissions\n- Only relevant when `cms.safe_mode` is enabled (otherwise direct PHP injection is already possible)\n\n### Patches\nThe vulnerability has been patched in v3.7.14 and v4.1.10. When `cms.safe_mode` is enabled, `.less`, `.sass`, and `.scss` files can no longer be created, uploaded, or edited across the CMS editor, media manager, and file upload interfaces. All users are encouraged to upgrade to the latest patched version.\n\n### Workarounds\nIf upgrading immediately is not possible:\n- Set `cms.editable_asset_types` config to `[\u0027css\u0027, \u0027js\u0027]` to remove preprocessor file types from the editor\n- Restrict Editor tool access to fully trusted administrators only\n\n- Reported by [Chris Alupului](https://github.com/neosprings)",
"id": "GHSA-3888-q23f-x7qh",
"modified": "2026-04-24T21:06:45Z",
"published": "2026-04-21T16:43:49Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/octobercms/october/security/advisories/GHSA-3888-q23f-x7qh"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-26067"
},
{
"type": "PACKAGE",
"url": "https://github.com/octobercms/october"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "October CMS has Safe Mode Bypass via CSS Preprocessor Compilers"
}
GHSA-38CX-CQ6F-5755
Vulnerability from github – Published: 2026-06-15 17:31 – Updated: 2026-06-15 17:31Description
Symfony\Component\HttpClient\NoPrivateNetworkHttpClient is documented as a decorator that blocks requests to private networks by default. The list of blocked subnets (Symfony\Component\HttpFoundation\IpUtils::PRIVATE_SUBNETS on 6.4+, a private constant in NoPrivateNetworkHttpClient on 5.4) enumerates RFC1918, loopback, link-local and IPv4-mapped IPv6 (::ffff:0:0/96) prefixes, but omits the remaining IPv6 transition forms that can embed a private IPv4 destination: 6to4 (2002::/16, RFC 3056), Teredo (2001::/32, RFC 4380), NAT64 (64:ff9b::/96, RFC 6052 and 64:ff9b:1::/48, RFC 8215) and IPv4-compatible IPv6 (::/96, RFC 4291 §2.5.5.1).
IpUtils::checkIp6() is a pure bitwise CIDR comparison against the constants list and never extracts the embedded IPv4, so an attacker who can supply a URL writes the loopback / RFC1918 IPv4 target as e.g. http://[2002:7f00:1::]/ (6to4 → 127.0.0.1), http://[64:ff9b::7f00:1]/ (NAT64 → 127.0.0.1), http://[::7f00:1]/ (IPv4-compatible → 127.0.0.1) or http://[2001::1]/ (Teredo). IpUtils::isPrivateIp() returns false and NoPrivateNetworkHttpClient dispatches the request.
Real-world reachability of the embedded IPv4 depends on the deploy's IPv6 routing (6to4 tunnel interface, upstream NAT64 gateway, kernel handling of IPv4-compatible addresses), but the security boundary the decorator promises — the dispatch decision — is crossed regardless of whether the packet ultimately lands on the embedded IPv4.
Resolution
The private-subnet list now includes ::/96, 2002::/16, 2001::/32, 64:ff9b::/96 and 64:ff9b:1::/48. Blanket blocking of these prefixes matches the policy applied by Chromium and Mozilla's Private Network Access; server-side HTTPS APIs are not legitimately published on these prefixes.
The patches for this issue are available here for branch 5.4 and here for branch 6.4 (and forward-ported to 7.4, 8.0 and 8.1).
Credits
Symfony would like to thank tonghuaroot for reporting the issue and Nicolas Grekas for providing the fix.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/http-client"
},
"ranges": [
{
"events": [
{
"introduced": "5.4.0"
},
{
"fixed": "5.4.53"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/http-foundation"
},
"ranges": [
{
"events": [
{
"introduced": "6.4.0"
},
{
"fixed": "6.4.41"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/http-foundation"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0"
},
{
"fixed": "7.4.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/http-foundation"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/symfony"
},
"ranges": [
{
"events": [
{
"introduced": "5.4.0"
},
{
"fixed": "5.4.53"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/symfony"
},
"ranges": [
{
"events": [
{
"introduced": "6.4.0"
},
{
"fixed": "6.4.41"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/symfony"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0"
},
{
"fixed": "7.4.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/symfony"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.13"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-48736"
],
"database_specific": {
"cwe_ids": [
"CWE-184",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-15T17:31:28Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Description\n\n`Symfony\\Component\\HttpClient\\NoPrivateNetworkHttpClient` is documented as a decorator that blocks requests to private networks by default. The list of blocked subnets (`Symfony\\Component\\HttpFoundation\\IpUtils::PRIVATE_SUBNETS` on 6.4+, a private constant in `NoPrivateNetworkHttpClient` on 5.4) enumerates RFC1918, loopback, link-local and IPv4-mapped IPv6 (`::ffff:0:0/96`) prefixes, but omits the remaining IPv6 transition forms that can embed a private IPv4 destination: 6to4 (`2002::/16`, RFC 3056), Teredo (`2001::/32`, RFC 4380), NAT64 (`64:ff9b::/96`, RFC 6052 and `64:ff9b:1::/48`, RFC 8215) and IPv4-compatible IPv6 (`::/96`, RFC 4291 \u00a72.5.5.1).\n\n`IpUtils::checkIp6()` is a pure bitwise CIDR comparison against the constants list and never extracts the embedded IPv4, so an attacker who can supply a URL writes the loopback / RFC1918 IPv4 target as e.g. `http://[2002:7f00:1::]/` (6to4 \u2192 127.0.0.1), `http://[64:ff9b::7f00:1]/` (NAT64 \u2192 127.0.0.1), `http://[::7f00:1]/` (IPv4-compatible \u2192 127.0.0.1) or `http://[2001::1]/` (Teredo). `IpUtils::isPrivateIp()` returns `false` and `NoPrivateNetworkHttpClient` dispatches the request.\n\nReal-world reachability of the embedded IPv4 depends on the deploy\u0027s IPv6 routing (6to4 tunnel interface, upstream NAT64 gateway, kernel handling of IPv4-compatible addresses), but the security boundary the decorator promises \u2014 the dispatch decision \u2014 is crossed regardless of whether the packet ultimately lands on the embedded IPv4.\n\n### Resolution\n\nThe private-subnet list now includes `::/96`, `2002::/16`, `2001::/32`, `64:ff9b::/96` and `64:ff9b:1::/48`. Blanket blocking of these prefixes matches the policy applied by Chromium and Mozilla\u0027s Private Network Access; server-side HTTPS APIs are not legitimately published on these prefixes.\n\nThe patches for this issue are available [here](https://github.com/symfony/symfony/commit/82765368cf74177c36613575182f168a2eb765b2) for branch 5.4 and [here](https://github.com/symfony/symfony/commit/85b831555be8ea1f43bf01078afe87bc4c92f65e) for branch 6.4 (and forward-ported to 7.4, 8.0 and 8.1).\n\n### Credits\n\nSymfony would like to thank tonghuaroot for reporting the issue and Nicolas Grekas for providing the fix.",
"id": "GHSA-38cx-cq6f-5755",
"modified": "2026-06-15T17:31:28Z",
"published": "2026-06-15T17:31:28Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/symfony/symfony/security/advisories/GHSA-38cx-cq6f-5755"
},
{
"type": "WEB",
"url": "https://github.com/symfony/symfony/commit/82765368cf74177c36613575182f168a2eb765b2"
},
{
"type": "WEB",
"url": "https://github.com/symfony/symfony/commit/85b831555be8ea1f43bf01078afe87bc4c92f65e"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/http-client/CVE-2026-48736.yaml"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/http-foundation/CVE-2026-48736.yaml"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/symfony/CVE-2026-48736.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/symfony/symfony"
},
{
"type": "WEB",
"url": "https://symfony.com/cve-2026-48736"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Symfony: IpUtils::PRIVATE_SUBNETS Omits IPv6 Transition Forms (6to4, NAT64, Teredo, IPv4-compatible): SSRF Bypass in NoPrivateNetworkHttpClient"
}
GHSA-3C6H-G97W-FG78
Vulnerability from github – Published: 2026-03-03 21:41 – Updated: 2026-03-11 20:38Summary
In OpenClaw, tools.exec.safeBins validation for sort could be bypassed via GNU long-option abbreviations in allowlist mode, allowing approval-free execution paths that should require approval.
Affected Packages / Versions
- Ecosystem: npm
- Package:
openclaw - Latest published version checked:
2026.2.22-2 - Affected range:
<= 2026.2.22-2 - Fixed version:
2026.2.23
Impact
When all of the following are true:
- tools.exec.security=allowlist
- tools.exec.ask=on-miss
- tools.exec.safeBins includes sort
abbreviated GNU long options (for example --compress-prog) could bypass denied-flag checks and be treated as allowlist-satisfied safe-bin usage, skipping approval.
Root Cause
Long-option handling matched denied flags by exact string and accepted unknown long options with inline values instead of failing closed.
Fix Commit(s)
3b8e33037ae2e12af7beb56fcf0346f1f8cbde6f
Release Process Note
patched_versions is pre-set to the released version (2026.2.23). This advisory now reflects released fix version 2026.2.23.
OpenClaw thanks @tdjackey for reporting.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.2.23"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-32059"
],
"database_specific": {
"cwe_ids": [
"CWE-184",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-03T21:41:59Z",
"nvd_published_at": "2026-03-11T14:16:27Z",
"severity": "HIGH"
},
"details": "### Summary\nIn OpenClaw, `tools.exec.safeBins` validation for `sort` could be bypassed via GNU long-option abbreviations in allowlist mode, allowing approval-free execution paths that should require approval.\n\n### Affected Packages / Versions\n- Ecosystem: npm\n- Package: `openclaw`\n- Latest published version checked: `2026.2.22-2`\n- Affected range: `\u003c= 2026.2.22-2`\n- Fixed version: `2026.2.23`\n\n### Impact\nWhen all of the following are true:\n- `tools.exec.security=allowlist`\n- `tools.exec.ask=on-miss`\n- `tools.exec.safeBins` includes `sort`\n\nabbreviated GNU long options (for example `--compress-prog`) could bypass denied-flag checks and be treated as allowlist-satisfied safe-bin usage, skipping approval.\n\n### Root Cause\nLong-option handling matched denied flags by exact string and accepted unknown long options with inline values instead of failing closed.\n\n### Fix Commit(s)\n- `3b8e33037ae2e12af7beb56fcf0346f1f8cbde6f`\n\n### Release Process Note\n`patched_versions` is pre-set to the released version (`2026.2.23`). This advisory now reflects released fix version `2026.2.23`.\n\nOpenClaw thanks @tdjackey for reporting.",
"id": "GHSA-3c6h-g97w-fg78",
"modified": "2026-03-11T20:38:42Z",
"published": "2026-03-03T21:41:59Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-3c6h-g97w-fg78"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32059"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/3b8e33037ae2e12af7beb56fcf0346f1f8cbde6f"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-allowlist-bypass-via-sort-long-option-abbreviation-in-toolsexecsafebins"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/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"
}
],
"summary": "OpenClaw\u0027s tools.exec.safeBins sort long-option abbreviation bypass can skip exec approval in allowlist mode"
}
GHSA-3GGM-C5M7-HFV5
Vulnerability from github – Published: 2026-05-29 21:31 – Updated: 2026-07-02 21:02Spatie Laravel Media Library before version 11.23.0 contains a file upload restriction bypass in FileAdder::defaultSanitizer(). The sanitizer checks only the final filename suffix, allowing double-extension filenames such as shell.php.jpg to bypass the blocklist, with pathinfo() preserving inner .php stems in saved filenames. The blocklist also omits executable extensions including .php6, .shtml, and .htaccess. The double-extension bypass requires a legacy Apache AddHandler configuration to achieve PHP execution; the incomplete blocklist bypass does not.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "spatie/laravel-medialibrary"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "11.23.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-48557"
],
"database_specific": {
"cwe_ids": [
"CWE-184"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-02T21:02:07Z",
"nvd_published_at": "2026-05-29T20:16:28Z",
"severity": "HIGH"
},
"details": "Spatie Laravel Media Library before version 11.23.0 contains a file upload restriction bypass in FileAdder::defaultSanitizer(). The sanitizer checks only the final filename suffix, allowing double-extension filenames such as shell.php.jpg to bypass the blocklist, with pathinfo() preserving inner .php stems in saved filenames. The blocklist also omits executable extensions including .php6, .shtml, and .htaccess. The double-extension bypass requires a legacy Apache AddHandler configuration to achieve PHP execution; the incomplete blocklist bypass does not.",
"id": "GHSA-3ggm-c5m7-hfv5",
"modified": "2026-07-02T21:02:07Z",
"published": "2026-05-29T21:31:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48557"
},
{
"type": "WEB",
"url": "https://github.com/spatie/laravel-medialibrary/pull/3939"
},
{
"type": "WEB",
"url": "https://github.com/spatie/laravel-medialibrary/commit/608ea03703d3887c46434f5dda6af56de6346aba"
},
{
"type": "PACKAGE",
"url": "https://github.com/spatie/laravel-medialibrary"
},
{
"type": "WEB",
"url": "https://github.com/spatie/laravel-medialibrary/releases/tag/11.23.0"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/spatie-laravel-media-library-file-upload-restriction-bypass-via-fileadder-php"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Spatie Laravel Media Library contains a file upload restriction bypass"
}
Mitigation
Strategy: Input Validation
Do not rely exclusively on detecting disallowed inputs. There are too many variants to encode a character, especially when different environments are used, so there is a high likelihood of missing some variants. Only use detection of disallowed inputs as a mechanism for detecting suspicious activity. Ensure that you are using other protection mechanisms that only identify "good" input - such as lists of allowed inputs - and ensure that you are properly encoding your outputs.
CAPEC-120: Double Encoding
The adversary utilizes a repeating of the encoding process for a set of characters (that is, character encoding a character encoding of a character) to obfuscate the payload of a particular request. This may allow the adversary to bypass filters that attempt to detect illegal characters or strings, such as those that might be used in traversal or injection attacks. Filters may be able to catch illegal encoded strings, but may not catch doubly encoded strings. For example, a dot (.), often used in path traversal attacks and therefore often blocked by filters, could be URL encoded as %2E. However, many filters recognize this encoding and would still block the request. In a double encoding, the % in the above URL encoding would be encoded again as %25, resulting in %252E which some filters might not catch, but which could still be interpreted as a dot (.) by interpreters on the target.
CAPEC-15: Command Delimiters
An attack of this type exploits a programs' vulnerabilities that allows an attacker's commands to be concatenated onto a legitimate command with the intent of targeting other resources such as the file system or database. The system that uses a filter or denylist input validation, as opposed to allowlist validation is vulnerable to an attacker who predicts delimiters (or combinations of delimiters) not present in the filter or denylist. As with other injection attacks, the attacker uses the command delimiter payload as an entry point to tunnel through the application and activate additional attacks through SQL queries, shell commands, network scanning, and so on.
CAPEC-182: Flash Injection
An attacker tricks a victim to execute malicious flash content that executes commands or makes flash calls specified by the attacker. One example of this attack is cross-site flashing, an attacker controlled parameter to a reference call loads from content specified by the attacker.
CAPEC-3: Using Leading 'Ghost' Character Sequences to Bypass Input Filters
Some APIs will strip certain leading characters from a string of parameters. An adversary can intentionally introduce leading "ghost" characters (extra characters that don't affect the validity of the request at the API layer) that enable the input to pass the filters and therefore process the adversary's input. This occurs when the targeted API will accept input data in several syntactic forms and interpret it in the equivalent semantic way, while the filter does not take into account the full spectrum of the syntactic forms acceptable to the targeted API.
CAPEC-43: Exploiting Multiple Input Interpretation Layers
An attacker supplies the target software with input data that contains sequences of special characters designed to bypass input validation logic. This exploit relies on the target making multiples passes over the input data and processing a "layer" of special characters with each pass. In this manner, the attacker can disguise input that would otherwise be rejected as invalid by concealing it with layers of special/escape characters that are stripped off by subsequent processing steps. The goal is to first discover cases where the input validation layer executes before one or more parsing layers. That is, user input may go through the following logic in an application: <parser1> --> <input validator> --> <parser2>. In such cases, the attacker will need to provide input that will pass through the input validator, but after passing through parser2, will be converted into something that the input validator was supposed to stop.
CAPEC-6: Argument Injection
An attacker changes the behavior or state of a targeted application through injecting data or command syntax through the targets use of non-validated and non-filtered arguments of exposed services or methods.
CAPEC-71: Using Unicode Encoding to Bypass Validation Logic
An attacker may provide a Unicode string to a system component that is not Unicode aware and use that to circumvent the filter or cause the classifying mechanism to fail to properly understanding the request. That may allow the attacker to slip malicious data past the content filter and/or possibly cause the application to route the request incorrectly.
CAPEC-73: User-Controlled Filename
An attack of this type involves an adversary inserting malicious characters (such as a XSS redirection) into a filename, directly or indirectly that is then used by the target software to generate HTML text or other potentially executable content. Many websites rely on user-generated content and dynamically build resources like files, filenames, and URL links directly from user supplied data. In this attack pattern, the attacker uploads code that can execute in the client browser and/or redirect the client browser to a site that the attacker owns. All XSS attack payload variants can be used to pass and exploit these vulnerabilities.
CAPEC-85: AJAX Footprinting
This attack utilizes the frequent client-server roundtrips in Ajax conversation to scan a system. While Ajax does not open up new vulnerabilities per se, it does optimize them from an attacker point of view. A common first step for an attacker is to footprint the target environment to understand what attacks will work. Since footprinting relies on enumeration, the conversational pattern of rapid, multiple requests and responses that are typical in Ajax applications enable an attacker to look for many vulnerabilities, well-known ports, network locations and so on. The knowledge gained through Ajax fingerprinting can be used to support other attacks, such as XSS.