Common Weakness Enumeration

CWE-290

Allowed

Authentication Bypass by Spoofing

Abstraction: Base · Status: Incomplete

This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks.

1242 vulnerabilities reference this CWE, most recent first.

GHSA-JJ58-2436-6MC6

Vulnerability from github – Published: 2024-05-17 12:30 – Updated: 2024-05-17 12:30
VLAI
Details

Authentication Bypass by Spoofing vulnerability in helderk Maintenance Mode allows Functionality Bypass.This issue affects Maintenance Mode: from n/a through 3.0.1.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-32708"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-17T10:15:09Z",
    "severity": "LOW"
  },
  "details": "Authentication Bypass by Spoofing vulnerability in helderk Maintenance Mode allows Functionality Bypass.This issue affects Maintenance Mode: from n/a through 3.0.1.",
  "id": "GHSA-jj58-2436-6mc6",
  "modified": "2024-05-17T12:30:59Z",
  "published": "2024-05-17T12:30:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-32708"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/hkdev-maintenance-mode/wordpress-maintenance-mode-plugin-3-0-1-ip-bypass-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JJG8-VHCX-8XM4

Vulnerability from github – Published: 2026-08-06 15:32 – Updated: 2026-08-06 15:32
VLAI
Details

Unauthenticated Bypass Vulnerability in CAPTCHA 4WP <= 7.6.0 versions.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-32469"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-06T15:16:54Z",
    "severity": "MODERATE"
  },
  "details": "Unauthenticated Bypass Vulnerability in CAPTCHA 4WP \u003c= 7.6.0 versions.",
  "id": "GHSA-jjg8-vhcx-8xm4",
  "modified": "2026-08-06T15:32:45Z",
  "published": "2026-08-06T15:32:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32469"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/advanced-nocaptcha-recaptcha/vulnerability/wordpress-captcha-4wp-plugin-7-6-0-captcha-bypass-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JMG8-WCJF-QMF3

Vulnerability from github – Published: 2022-05-13 01:20 – Updated: 2022-05-13 01:20
VLAI
Details

A spoofing vulnerability exists when Microsoft Edge improperly handles specific HTML content, aka "Microsoft Edge Spoofing Vulnerability." This affects Microsoft Edge.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-8278"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-07-11T00:29:00Z",
    "severity": "MODERATE"
  },
  "details": "A spoofing vulnerability exists when Microsoft Edge improperly handles specific HTML content, aka \"Microsoft Edge Spoofing Vulnerability.\" This affects Microsoft Edge.",
  "id": "GHSA-jmg8-wcjf-qmf3",
  "modified": "2022-05-13T01:20:44Z",
  "published": "2022-05-13T01:20:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-8278"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-8278"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/104627"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1041255"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JQCG-44MW-7W3H

Vulnerability from github – Published: 2026-10-05 23:30 – Updated: 2026-10-05 23:30
VLAI
Summary
proxy-addr vulnerable to IP spoofing via IPv4-mapped IPv6 trust subnet
Details

Impact

proxy-addr determines which network hops are trusted proxies so that X-Forwarded-For can be believed. When an application configures a trust subnet as an IPv4-mapped IPv6 address with a short prefix, such as ::ffff:10.0.0.0/8 (the correct spelling is ::ffff:10.0.0.0/104), the subnet compiles with all-zero leading bits and matches every IPv4 address instead of the block it names. The same happens for any IPv6 trust subnet with zero leading bits, such as ::/1.

Every unauthenticated client is then trusted as a proxy at hop 0, so proxyaddr(req, trust), and therefore req.ip and req.ips in Express, returns whatever the client sends in X-Forwarded-For. This defeats IP-based access control, rate limiting, geolocation, and audit logging. The misconfiguration compiles without any error, and the same block written correctly behaves correctly, so the difference is not visible from the configuration.

Patches

Upgrade to proxy-addr 2.0.8. An IPv4 address now matches an IPv6 trust subnet only when that subnet is a genuine IPv4-mapped subnet whose prefix covers the mapped marker.

Workarounds

Write IPv4 trust subnets in plain IPv4 notation (for example 10.0.0.0/8). If IPv4-mapped IPv6 notation is required, use the full form so the prefix covers the mapped marker (for example ::ffff:10.0.0.0/104 for the 10.0.0.0/8 block).

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "proxy-addr"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.1.0"
            },
            {
              "fixed": "2.0.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-90711"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290",
      "CWE-348",
      "CWE-697"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-05T23:30:26Z",
    "nvd_published_at": "2026-09-15T07:16:33Z",
    "severity": "CRITICAL"
  },
  "details": "### Impact\n\n`proxy-addr` determines which network hops are trusted proxies so that `X-Forwarded-For` can be believed. When an application configures a trust subnet as an IPv4-mapped IPv6 address with a short prefix, such as `::ffff:10.0.0.0/8` (the correct spelling is `::ffff:10.0.0.0/104`), the subnet compiles with all-zero leading bits and matches every IPv4 address instead of the block it names. The same happens for any IPv6 trust subnet with zero leading bits, such as `::/1`.\n\nEvery unauthenticated client is then trusted as a proxy at hop 0, so `proxyaddr(req, trust)`, and therefore `req.ip` and `req.ips` in Express, returns whatever the client sends in `X-Forwarded-For`. This defeats IP-based access control, rate limiting, geolocation, and audit logging. The misconfiguration compiles without any error, and the same block written correctly behaves correctly, so the difference is not visible from the configuration.\n\n### Patches\n\nUpgrade to `proxy-addr` 2.0.8. An IPv4 address now matches an IPv6 trust subnet only when that subnet is a genuine IPv4-mapped subnet whose prefix covers the mapped marker.\n\n### Workarounds\n\nWrite IPv4 trust subnets in plain IPv4 notation (for example `10.0.0.0/8`). If IPv4-mapped IPv6 notation is required, use the full form so the prefix covers the mapped marker (for example `::ffff:10.0.0.0/104` for the `10.0.0.0/8` block).",
  "id": "GHSA-jqcg-44mw-7w3h",
  "modified": "2026-10-05T23:30:27Z",
  "published": "2026-10-05T23:30:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jshttp/proxy-addr/security/advisories/GHSA-jqcg-44mw-7w3h"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-90711"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jshttp/proxy-addr/commit/780911d84d18e2c5fa008ed0c0d387631ec11965"
    },
    {
      "type": "WEB",
      "url": "https://cna.openjsf.org/security-advisories.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jshttp/proxy-addr"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jshttp/proxy-addr/releases/tag/v2.0.8"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "proxy-addr vulnerable to IP spoofing via IPv4-mapped IPv6 trust subnet"
}

GHSA-JQJG-6W6P-5MH7

Vulnerability from github – Published: 2026-08-01 09:30 – Updated: 2026-08-05 18:31
VLAI
Details

The YOP Poll WordPress plugin before 7.0.6 does not validate the connection's origin IP address and instead trusts client-controlled forwarding headers when enforcing its per-IP vote restriction, allowing unauthenticated attackers to bypass the vote limit and cast unlimited votes on a public poll.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-14840"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-01T07:16:31Z",
    "severity": "MODERATE"
  },
  "details": "The YOP Poll WordPress plugin before 7.0.6 does not validate the connection\u0027s origin IP address and instead trusts client-controlled forwarding headers when enforcing its per-IP vote restriction, allowing unauthenticated attackers to bypass the vote limit and cast unlimited votes on a public poll.",
  "id": "GHSA-jqjg-6w6p-5mh7",
  "modified": "2026-08-05T18:31:27Z",
  "published": "2026-08-01T09:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-14840"
    },
    {
      "type": "WEB",
      "url": "https://wpscan.com/vulnerability/fc810ca2-3f27-414d-b94a-68842925b7c6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JQXM-W4MH-HQ99

Vulnerability from github – Published: 2023-10-16 21:30 – Updated: 2024-04-04 08:41
VLAI
Details

This user-activity-log-pro WordPress plugin before 2.3.4 retrieves client IP addresses from potentially untrusted headers, allowing an attacker to manipulate its value. This may be used to hide the source of malicious traffic.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-5133"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-10-16T20:15:17Z",
    "severity": "HIGH"
  },
  "details": "This user-activity-log-pro WordPress plugin before 2.3.4 retrieves client IP addresses from potentially untrusted headers, allowing an attacker to manipulate its value. This may be used to hide the source of malicious traffic.",
  "id": "GHSA-jqxm-w4mh-hq99",
  "modified": "2024-04-04T08:41:59Z",
  "published": "2023-10-16T21:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5133"
    },
    {
      "type": "WEB",
      "url": "https://wpscan.com/vulnerability/36c30e54-75e4-4df1-b01a-60c51c0e76a3"
    }
  ],
  "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"
    }
  ]
}

GHSA-JR4H-HC9R-9RR3

Vulnerability from github – Published: 2022-05-11 00:00 – Updated: 2025-10-22 00:32
VLAI
Details

Windows LSA Spoofing Vulnerability.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-26925"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290",
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-05-10T21:15:00Z",
    "severity": "HIGH"
  },
  "details": "Windows LSA Spoofing Vulnerability.",
  "id": "GHSA-jr4h-hc9r-9rr3",
  "modified": "2025-10-22T00:32:32Z",
  "published": "2022-05-11T00:00:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-26925"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-26925"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2022-26925"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2022-26925"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JR8J-FH83-J7H4

Vulnerability from github – Published: 2022-05-24 17:38 – Updated: 2024-10-08 18:32
VLAI
Details

Azure Active Directory Pod Identity Spoofing Vulnerability

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-1677"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-01-12T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Azure Active Directory Pod Identity Spoofing Vulnerability",
  "id": "GHSA-jr8j-fh83-j7h4",
  "modified": "2024-10-08T18:32:59Z",
  "published": "2022-05-24T17:38:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-1677"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-1677"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2021-1677"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JV3F-F575-7XGV

Vulnerability from github – Published: 2025-04-07 06:30 – Updated: 2025-04-07 06:30
VLAI
Details

Access control vulnerability in the security verification module Impact: Successful exploitation of this vulnerability will affect integrity and confidentiality.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-58124"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-07T04:15:18Z",
    "severity": "HIGH"
  },
  "details": "Access control vulnerability in the security verification module\nImpact: Successful exploitation of this vulnerability will affect integrity and confidentiality.",
  "id": "GHSA-jv3f-f575-7xgv",
  "modified": "2025-04-07T06:30:27Z",
  "published": "2025-04-07T06:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58124"
    },
    {
      "type": "WEB",
      "url": "https://consumer.huawei.com/en/support/bulletin/2025/4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JVC7-762P-3743

Vulnerability from github – Published: 2026-06-16 19:00 – Updated: 2026-07-20 13:43
VLAI
Summary
n8n: Missing Token Validation on Microsoft Agent 365 Trigger and Stripe Nodes
Details

Impact

The MicrosoftAgent365Trigger and StripeTrigger node did not validate that inbound requests. As a result, an unauthenticated attacker who knows the webhook URL could submit a forged payload and cause the workflow to execute with attacker-controlled data.

Patches

The issue has been fixed in n8n versions 2.25.7, and 2.26.2. Users should upgrade to one of these versions or later to remediate the vulnerability.

Workarounds

If upgrading is not immediately possible, administrators should consider the following temporary mitigations: - Deactivate any workflows using the Microsoft Agent 365 Trigger node or Stripe Trigger node until the instance can be upgraded. - Restrict network access to the n8n webhook endpoint to trusted sources only.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "n8n"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.26.0"
            },
            {
              "fixed": "2.26.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "n8n"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.25.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54308"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-16T19:00:13Z",
    "nvd_published_at": "2026-06-23T17:17:07Z",
    "severity": "MODERATE"
  },
  "details": "## Impact\nThe `MicrosoftAgent365Trigger` and `StripeTrigger` node did not validate that inbound requests. As a result, an unauthenticated attacker who knows the webhook URL could submit a forged payload and cause the workflow to execute with attacker-controlled data.\n\n## Patches\nThe issue has been fixed in n8n versions 2.25.7, and 2.26.2. Users should upgrade to one of these versions or later to remediate the vulnerability.\n\n## Workarounds\nIf upgrading is not immediately possible, administrators should consider the following temporary mitigations:\n- Deactivate any workflows using the Microsoft Agent 365 Trigger node or Stripe Trigger node until the instance can be upgraded.\n- Restrict network access to the n8n webhook endpoint to trusted sources only.\n\nThese workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.",
  "id": "GHSA-jvc7-762p-3743",
  "modified": "2026-07-20T13:43:47Z",
  "published": "2026-06-16T19:00:13Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/security/advisories/GHSA-jvc7-762p-3743"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54308"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/n8n-io/n8n"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "n8n: Missing Token Validation on Microsoft Agent 365 Trigger and Stripe Nodes"
}

No mitigation information available for this CWE.

CAPEC-21: Exploitation of Trusted Identifiers

An adversary guesses, obtains, or "rides" a trusted identifier (e.g. session ID, resource ID, cookie, etc.) to perform authorized actions under the guise of an authenticated user or service.

CAPEC-22: Exploiting Trust in Client

An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.

CAPEC-459: Creating a Rogue Certification Authority Certificate

An adversary exploits a weakness resulting from using a hashing algorithm with weak collision resistance to generate certificate signing requests (CSR) that contain collision blocks in their "to be signed" parts. The adversary submits one CSR to be signed by a trusted certificate authority then uses the signed blob to make a second certificate appear signed by said certificate authority. Due to the hash collision, both certificates, though different, hash to the same value and so the signed blob works just as well in the second certificate. The net effect is that the adversary's second X.509 certificate, which the Certification Authority has never seen, is now signed and validated by that Certification Authority.

CAPEC-461: Web Services API Signature Forgery Leveraging Hash Function Extension Weakness

An adversary utilizes a hash function extension/padding weakness, to modify the parameters passed to the web service requesting authentication by generating their own call in order to generate a legitimate signature hash (as described in the notes), without knowledge of the secret token sometimes provided by the web service.

CAPEC-473: Signature Spoof

An attacker generates a message or datablock that causes the recipient to believe that the message or datablock was generated and cryptographically signed by an authoritative or reputable source, misleading a victim or victim operating system into performing malicious actions.

CAPEC-476: Signature Spoofing by Misrepresentation

An attacker exploits a weakness in the parsing or display code of the recipient software to generate a data blob containing a supposedly valid signature, but the signer's identity is falsely represented, which can lead to the attacker manipulating the recipient software or its victim user to perform compromising actions.

CAPEC-59: Session Credential Falsification through Prediction

This attack targets predictable session ID in order to gain privileges. The attacker can predict the session ID used during a transaction to perform spoofing and session hijacking.

CAPEC-60: Reusing Session IDs (aka Session Replay)

This attack targets the reuse of valid session ID to spoof the target system in order to gain privileges. The attacker tries to reuse a stolen session ID used previously during a transaction to perform spoofing and session hijacking. Another name for this type of attack is Session Replay.

CAPEC-667: Bluetooth Impersonation AttackS (BIAS)

An adversary disguises the MAC address of their Bluetooth enabled device to one for which there exists an active and trusted connection and authenticates successfully. The adversary can then perform malicious actions on the target Bluetooth device depending on the target’s capabilities.

CAPEC-94: Adversary in the Middle (AiTM)

An adversary targets the communication between two components (typically client and server), in order to alter or obtain data from transactions. A general approach entails the adversary placing themself within the communication channel between the two components.