CWE-290
AllowedAuthentication Bypass by Spoofing
Abstraction: Base · Status: Incomplete
This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks.
927 vulnerabilities reference this CWE, most recent first.
GHSA-JC5P-HFQ2-7MFM
Vulnerability from github – Published: 2023-01-26 21:30 – Updated: 2023-02-01 18:30An issue has been discovered in GitLab affecting all versions starting from 15.4 prior to 15.4.4, and 15.5 prior to 15.5.2. GitLab was not performing correct authentication with some Package Registries when IP address restrictions were configured, allowing an attacker already in possession of a valid Deploy Token to misuse it from any location.
{
"affected": [],
"aliases": [
"CVE-2022-3820"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-01-26T21:15:00Z",
"severity": "MODERATE"
},
"details": "An issue has been discovered in GitLab affecting all versions starting from 15.4 prior to 15.4.4, and 15.5 prior to 15.5.2. GitLab was not performing correct authentication with some Package Registries when IP address restrictions were configured, allowing an attacker already in possession of a valid Deploy Token to misuse it from any location.",
"id": "GHSA-jc5p-hfq2-7mfm",
"modified": "2023-02-01T18:30:24Z",
"published": "2023-01-26T21:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3820"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2022/CVE-2022-3820.json"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/378638"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-JF2C-V9V9-9R3W
Vulnerability from github – Published: 2021-11-25 00:00 – Updated: 2023-12-28 18:30{
"affected": [],
"aliases": [
"CVE-2021-43220"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-11-24T01:15:00Z",
"severity": "HIGH"
},
"details": "Microsoft Edge for iOS Spoofing Vulnerability",
"id": "GHSA-jf2c-v9v9-9r3w",
"modified": "2023-12-28T18:30:31Z",
"published": "2021-11-25T00:00:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43220"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2021-43220"
}
],
"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-JF52-3F2H-H9J5
Vulnerability from github – Published: 2026-01-07 19:22 – Updated: 2026-01-08 20:51Impact
An authentication bypass in the Stripe Trigger node allows unauthenticated parties to trigger workflows by sending forged Stripe webhook events.
The Stripe Trigger creates and stores a Stripe webhook signing secret when registering the webhook endpoint, but incoming webhook requests were not verified against this secret. As a result, any HTTP client that knows the webhook URL could send a POST request containing a matching event type, causing the workflow to execute as if a legitimate Stripe event had been received.
This issue affects n8n users who have active workflows using the Stripe Trigger node. An attacker could potentially fake payment or subscription events and influence downstream workflow behavior. The practical risk is reduced by the fact that the webhook URL contains a high-entropy UUID; however, authenticated n8n users with access to the workflow can view this webhook ID.
Patches
The issue has been fixed in n8n version 2.2.2. Users should upgrade to this version or later to ensure that Stripe webhook signatures are properly verified.
Workarounds
There is no complete workaround short of upgrading. As a temporary mitigation, users can deactivate affected workflows or restrict access to workflows containing Stripe Trigger nodes to trusted users only.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "n8n"
},
"ranges": [
{
"events": [
{
"introduced": "0.150.0"
},
{
"fixed": "2.2.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-21894"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-07T19:22:54Z",
"nvd_published_at": "2026-01-08T10:15:55Z",
"severity": "MODERATE"
},
"details": "### Impact\nAn authentication bypass in the Stripe Trigger node allows unauthenticated parties to trigger workflows by sending forged Stripe webhook events.\n\nThe Stripe Trigger creates and stores a Stripe webhook signing secret when registering the webhook endpoint, but incoming webhook requests were not verified against this secret. As a result, any HTTP client that knows the webhook URL could send a POST request containing a matching event `type`, causing the workflow to execute as if a legitimate Stripe event had been received.\n\nThis issue affects n8n users who have active workflows using the Stripe Trigger node. An attacker could potentially fake payment or subscription events and influence downstream workflow behavior. The practical risk is reduced by the fact that the webhook URL contains a high-entropy UUID; however, authenticated n8n users with access to the workflow can view this webhook ID.\n\n### Patches\nThe issue has been fixed in n8n version 2.2.2. Users should upgrade to this version or later to ensure that Stripe webhook signatures are properly verified.\n\n### Workarounds\nThere is no complete workaround short of upgrading. As a temporary mitigation, users can deactivate affected workflows or restrict access to workflows containing Stripe Trigger nodes to trusted users only.",
"id": "GHSA-jf52-3f2h-h9j5",
"modified": "2026-01-08T20:51:27Z",
"published": "2026-01-07T19:22:54Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/n8n-io/n8n/security/advisories/GHSA-jf52-3f2h-h9j5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-21894"
},
{
"type": "WEB",
"url": "https://github.com/n8n-io/n8n/pull/22764"
},
{
"type": "WEB",
"url": "https://github.com/n8n-io/n8n/commit/a61a5991093c41863506888336e808ac1eff8d59"
},
{
"type": "PACKAGE",
"url": "https://github.com/n8n-io/n8n"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "n8n\u0027s Missing Stripe-Signature Verification Allows Unauthenticated Forged Webhooks"
}
GHSA-JHPV-4Q4F-43G5
Vulnerability from github – Published: 2025-10-07 21:15 – Updated: 2025-10-07 21:15Impact
This is a critical network security vulnerability for Akka.Remote users who have SSL / TLS enabled on their Akka.Remote connections and were expecting certificate-based authentication to be enforced on all peers attempting to join the network.
In all versions of Akka.Remote from v1.2.0 to v1.5.51, TLS could be enabled via our akka.remote.dot-netty.tcp transport and this would correctly enforce private key validation on the server-side of inbound connections. Akka.Remote, however, never asked the outbound-connecting client to present ITS certificate - therefore it's possible for untrusted parties to connect to a private key'd Akka.NET cluster and begin communicating with it without any certificate.
The issue here is that for certificate-based authentication to work properly, ensuring that all members of the Akka.Remote network are secured with the same private key, Akka.Remote needed to implement mutual TLS. This was not the case before Akka.NET v1.5.52.
If you are running Akka.NET inside a private network you fully control or you were never using TLS in the first place, then this bug has no impact on you. However: if you are using TLS to secure your network YOU MUST upgrade to Akka.NET V1.5.52 or later.
Patches
https://github.com/akkadotnet/akka.net/pull/7847 - forces "fail fast" semantics if TLS is enabled but the private key is missing or invalid. Previous versions would only check that once connection attempts occurred. https://github.com/akkadotnet/akka.net/pull/7851 - critical fix: enforces mutual TLS (mTLS) by default, so both parties must be keyed using the same certificate. This fulfills the original security
These updates have been shipped into Akka.NET v1.5.52: https://github.com/akkadotnet/akka.net/releases/tag/1.5.52
Workarounds
If your application isn't exposed publicly, then CVE-2025-61778 has no practical impact on your application. That being said: upgrading to Akka.NET v1.5.52 or later is a good idea.
References
Please view our latest network security documentation here: https://getakka.net/articles/remoting/security.html
{
"affected": [
{
"package": {
"ecosystem": "NuGet",
"name": "Akka.Remote"
},
"ranges": [
{
"events": [
{
"introduced": "1.2.0"
},
{
"fixed": "1.5.52"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Akka.Cluster"
},
"ranges": [
{
"events": [
{
"introduced": "1.2.0"
},
{
"fixed": "1.5.52"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-61778"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": true,
"github_reviewed_at": "2025-10-07T21:15:44Z",
"nvd_published_at": "2025-10-06T17:16:08Z",
"severity": "CRITICAL"
},
"details": "### Impact\n\nThis is a critical network security vulnerability for Akka.Remote **users who have SSL / TLS enabled** on their Akka.Remote connections and were expecting certificate-based authentication to be enforced on all peers attempting to join the network.\n\nIn all versions of Akka.Remote from v1.2.0 to v1.5.51, TLS could be enabled via our `akka.remote.dot-netty.tcp` transport and this would correctly enforce private key validation on the server-side of inbound connections. Akka.Remote, however, never asked the outbound-connecting client to present ITS certificate - therefore it\u0027s possible for untrusted parties to connect to a private key\u0027d Akka.NET cluster and begin communicating with it **without any certificate**. \n\nThe issue here is that for certificate-based authentication to work properly, ensuring that all members of the Akka.Remote network are secured with the same private key, Akka.Remote needed to implement mutual TLS. This was not the case before Akka.NET v1.5.52.\n\nIf you are running Akka.NET inside a private network you fully control or you were never using TLS in the first place, then this bug has no impact on you. However: if you are using TLS to secure your network YOU MUST upgrade to Akka.NET V1.5.52 or later.\n\n### Patches\n\nhttps://github.com/akkadotnet/akka.net/pull/7847 - forces \"fail fast\" semantics if TLS is enabled but the private key is missing or invalid. Previous versions would only check that once connection attempts occurred.\nhttps://github.com/akkadotnet/akka.net/pull/7851 - **critical fix**: enforces mutual TLS (mTLS) by default, so both parties must be keyed using the same certificate. This fulfills the original security \n\nThese updates have been shipped into Akka.NET v1.5.52: https://github.com/akkadotnet/akka.net/releases/tag/1.5.52\n\n### Workarounds\n\nIf your application isn\u0027t exposed publicly, then CVE-2025-61778 has no practical impact on your application. That being said: upgrading to Akka.NET v1.5.52 or later is a good idea.\n\n### References\n\nPlease view our latest network security documentation here: https://getakka.net/articles/remoting/security.html",
"id": "GHSA-jhpv-4q4f-43g5",
"modified": "2025-10-07T21:15:45Z",
"published": "2025-10-07T21:15:44Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/akkadotnet/akka.net/security/advisories/GHSA-jhpv-4q4f-43g5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-61778"
},
{
"type": "WEB",
"url": "https://github.com/akkadotnet/akka.net/pull/7847"
},
{
"type": "WEB",
"url": "https://github.com/akkadotnet/akka.net/pull/7851"
},
{
"type": "WEB",
"url": "https://getakka.net/articles/remoting/security.html"
},
{
"type": "PACKAGE",
"url": "https://github.com/akkadotnet/akka.net"
},
{
"type": "WEB",
"url": "https://github.com/akkadotnet/akka.net/releases/tag/1.5.52"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Akka.Remote TLS did not properly implement certificate-based authentication"
}
GHSA-JJ26-78H6-475H
Vulnerability from github – Published: 2022-05-02 03:21 – Updated: 2024-02-13 18:38The web interface on the snom VoIP phones snom 300, snom 320, snom 360, snom 370, and snom 820 with firmware 6.5 before 6.5.20, 7.1 before 7.1.39, and 7.3 before 7.3.14 allows remote attackers to bypass authentication, and reconfigure the phone or make arbitrary use of the phone, via a (1) http or (2) https request with 127.0.0.1 in the Host header.
{
"affected": [],
"aliases": [
"CVE-2009-1048"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2009-08-14T15:16:00Z",
"severity": "HIGH"
},
"details": "The web interface on the snom VoIP phones snom 300, snom 320, snom 360, snom 370, and snom 820 with firmware 6.5 before 6.5.20, 7.1 before 7.1.39, and 7.3 before 7.3.14 allows remote attackers to bypass authentication, and reconfigure the phone or make arbitrary use of the phone, via a (1) http or (2) https request with 127.0.0.1 in the Host header.",
"id": "GHSA-jj26-78h6-475h",
"modified": "2024-02-13T18:38:21Z",
"published": "2022-05-02T03:21:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2009-1048"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/52424"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/36293"
},
{
"type": "WEB",
"url": "http://www.csnc.ch/misc/files/advisories/cve-2009-1048.txt"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/505723/100/0/threaded"
}
],
"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:H",
"type": "CVSS_V3"
}
]
}
GHSA-JJ58-2436-6MC6
Vulnerability from github – Published: 2024-05-17 12:30 – Updated: 2024-05-17 12:30Authentication Bypass by Spoofing vulnerability in helderk Maintenance Mode allows Functionality Bypass.This issue affects Maintenance Mode: from n/a through 3.0.1.
{
"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-JMG8-WCJF-QMF3
Vulnerability from github – Published: 2022-05-13 01:20 – Updated: 2022-05-13 01:20A spoofing vulnerability exists when Microsoft Edge improperly handles specific HTML content, aka "Microsoft Edge Spoofing Vulnerability." This affects Microsoft Edge.
{
"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-JQXM-W4MH-HQ99
Vulnerability from github – Published: 2023-10-16 21:30 – Updated: 2024-04-04 08:41This 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.
{
"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{
"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:32Azure Active Directory Pod Identity Spoofing Vulnerability
{
"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"
}
]
}
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.