CWE-940
AllowedImproper Verification of Source of a Communication Channel
Abstraction: Base · Status: Incomplete
The product establishes a communication channel to handle an incoming request that has been initiated by an actor, but it does not properly verify that the request is coming from the expected origin.
94 vulnerabilities reference this CWE, most recent first.
GHSA-W6V7-W58J-PG5R
Vulnerability from github – Published: 2021-11-15 17:40 – Updated: 2021-11-15 14:59In versions of the @theia/plugin-ext component of Eclipse Theia prior to 1.18.0, Webview contents can be hijacked via postMessage().
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@theia/plugin-ext"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.18.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-41038"
],
"database_specific": {
"cwe_ids": [
"CWE-940"
],
"github_reviewed": true,
"github_reviewed_at": "2021-11-12T19:46:56Z",
"nvd_published_at": "2021-11-10T17:15:00Z",
"severity": "MODERATE"
},
"details": "In versions of the @theia/plugin-ext component of Eclipse Theia prior to 1.18.0, Webview contents can be hijacked via postMessage().",
"id": "GHSA-w6v7-w58j-pg5r",
"modified": "2021-11-15T14:59:59Z",
"published": "2021-11-15T17:40:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41038"
},
{
"type": "WEB",
"url": "https://github.com/eclipse-theia/theia/pull/10125"
},
{
"type": "WEB",
"url": "https://bugs.eclipse.org/bugs/show_bug.cgi?id=575924"
},
{
"type": "PACKAGE",
"url": "https://github.com/eclipse-theia/theia"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Improper Verification of Communication Channel in @theia/plugin-ext"
}
GHSA-X426-X7CC-3FPC
Vulnerability from github – Published: 2026-06-11 13:27 – Updated: 2026-06-11 13:27Impact
Wreck strips credential headers (Authorization, Cookie, Proxy-Authorization) before following a cross-origin redirect, but the origin check compares hostnames only and ignores scheme and port. As a result, credentials are forwarded intact across same-host port changes and HTTPS-to-HTTP downgrades, allowing a co-tenant on an adjacent port or a network-position attacker capable of forging a redirect to capture bearer tokens, session cookies, and proxy credentials and impersonate the victim against the upstream service. The fix replaces the hostname comparison with a full-origin comparison (scheme, host, and port), aligning the behavior with the WHATWG Fetch same-origin definition used by browsers.
Patches
Upgrade to >= 18.1.2.
Workarounds
- Set
redirects: 0(default) and handle redirects manually with a strict origin check. - Use the
beforeRedirecthook to inspect the redirect target and abort or strip sensitive headers before the follow-on request.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@hapi/wreck"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "18.1.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-48022"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-319",
"CWE-346",
"CWE-522",
"CWE-940"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-11T13:27:05Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Impact\nWreck strips credential headers (Authorization, Cookie, Proxy-Authorization) before following a cross-origin redirect, but the origin check compares hostnames only and ignores scheme and port. As a result, credentials are forwarded intact across same-host port changes and HTTPS-to-HTTP downgrades, allowing a co-tenant on an adjacent port or a network-position attacker capable of forging a redirect to capture bearer tokens, session cookies, and proxy credentials and impersonate the victim against the upstream service. The fix replaces the hostname comparison with a full-origin comparison (scheme, host, and port), aligning the behavior with the WHATWG Fetch same-origin definition used by browsers.\n\n### Patches\nUpgrade to \u003e= 18.1.2.\n\n### Workarounds\n- Set `redirects: 0` (default) and handle redirects manually with a strict origin check.\n- Use the `beforeRedirect` hook to inspect the redirect target and abort or strip sensitive headers before the follow-on request.",
"id": "GHSA-x426-x7cc-3fpc",
"modified": "2026-06-11T13:27:05Z",
"published": "2026-06-11T13:27:05Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/hapijs/wreck/security/advisories/GHSA-x426-x7cc-3fpc"
},
{
"type": "WEB",
"url": "https://github.com/hapijs/wreck/commit/b93323b63ad3adb14d2b4019d77219182211641e"
},
{
"type": "PACKAGE",
"url": "https://github.com/hapijs/wreck"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "@hapi/wreck: Sensitive credential headers leak across cross-port and cross-scheme redirects"
}
GHSA-X445-F3H2-J279
Vulnerability from github – Published: 2026-07-23 14:31 – Updated: 2026-08-13 19:05Summary
Auth.js stores the OAuth/OIDC anti-CSRF checks (state, nonce, and the PKCE verifier) in global cookies that are not bound to the provider that created them. On callback, a check value minted during a sign-in started with one provider can satisfy the callback for a different provider, because the stored cookie is not verified against the callback provider's identity (provider id, issuer, client id, or redirect URI). In a multi-provider app that allows account linking while logged in, this provider-confusion / mix-up condition can let an attacker link their account at a second provider to a victim's user.
Am I affected?
You may be affected if all of the following hold:
- You use
next-auth<= 4.24.14or>= 5.0.0-beta.1, <= 5.0.0-beta.31, or@auth/core<= 0.41.2. - You configure multiple OAuth/OIDC providers.
- You allow users to link additional providers while logged in.
- At least one configured provider's authorization request is observable by an attacker, and at least one target provider's callback can be satisfied without a PKCE verifier (i.e. it relies only on
stateor only onnonce).
You are not affected if you use a single OAuth provider, do not allow logged-in account linking, or all providers enforce PKCE.
Impact
- Account-linking confusion: an attacker can get their account at a target provider linked to the victim's Auth.js user, granting the attacker persistent sign-in to the victim's account through that linked provider.
- Exploitation requires luring the victim into starting a legitimate same-origin flow; it cannot be performed by cross-site request forgery alone, which reduces practical likelihood.
Patched version
The fix binds the OAuth check cookies to the provider/authorization flow that created them, so a callback cannot consume a check value minted for a different provider. Upgrade to the first releases containing this fix (pending; this advisory will be updated with exact patched versions before publication).
Workarounds
If you cannot upgrade immediately:
- Enable PKCE (
checks: ["pkce"], in addition tostate/nonce) on every provider that supports it; PKCE blocks the practical code-swap variant because the attacker cannot observe the relying party's verifier. - Avoid offering logged-in account linking across multiple providers where one provider is lower-trust or attacker-observable.
- Treat
events.linkAccountas sensitive: add audit logging, user notification, or out-of-band confirmation so that any unexpected link is visible (defense-in-depth, not a root-cause fix).
Credit
Reported by @Nadav0077. Thank you for the responsible disclosure.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.41.2"
},
"package": {
"ecosystem": "npm",
"name": "@auth/core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.41.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.0.0-beta.31"
},
"package": {
"ecosystem": "npm",
"name": "next-auth"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0-beta.1"
},
{
"fixed": "5.0.0-beta.32"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.24.14"
},
"package": {
"ecosystem": "npm",
"name": "next-auth"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.24.15"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-73419"
],
"database_specific": {
"cwe_ids": [
"CWE-345",
"CWE-346",
"CWE-940"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-23T14:31:51Z",
"nvd_published_at": "2026-08-12T21:17:41Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nAuth.js stores the OAuth/OIDC anti-CSRF checks (`state`, `nonce`, and the PKCE verifier) in global cookies that are not bound to the provider that created them. On callback, a check value minted during a sign-in started with one provider can satisfy the callback for a different provider, because the stored cookie is not verified against the callback provider\u0027s identity (provider id, issuer, client id, or redirect URI). In a multi-provider app that allows account linking while logged in, this provider-confusion / mix-up condition can let an attacker link their account at a second provider to a victim\u0027s user.\n\n## Am I affected?\n\nYou may be affected if **all** of the following hold:\n\n- You use `next-auth` `\u003c= 4.24.14` or `\u003e= 5.0.0-beta.1, \u003c= 5.0.0-beta.31`, or `@auth/core` `\u003c= 0.41.2`.\n- You configure multiple OAuth/OIDC providers.\n- You allow users to link additional providers while logged in.\n- At least one configured provider\u0027s authorization request is observable by an attacker, and at least one target provider\u0027s callback can be satisfied without a PKCE verifier (i.e. it relies only on `state` or only on `nonce`).\n\nYou are **not** affected if you use a single OAuth provider, do not allow logged-in account linking, or all providers enforce PKCE.\n\n## Impact\n\n- Account-linking confusion: an attacker can get their account at a target provider linked to the victim\u0027s Auth.js user, granting the attacker persistent sign-in to the victim\u0027s account through that linked provider.\n- Exploitation requires luring the victim into starting a legitimate same-origin flow; it cannot be performed by cross-site request forgery alone, which reduces practical likelihood.\n\n## Patched version\n\nThe fix binds the OAuth check cookies to the provider/authorization flow that created them, so a callback cannot consume a check value minted for a different provider. Upgrade to the first releases containing this fix (pending; this advisory will be updated with exact patched versions before publication).\n\n## Workarounds\n\nIf you cannot upgrade immediately:\n\n- Enable PKCE (`checks: [\"pkce\"]`, in addition to `state`/`nonce`) on every provider that supports it; PKCE blocks the practical code-swap variant because the attacker cannot observe the relying party\u0027s verifier.\n- Avoid offering logged-in account linking across multiple providers where one provider is lower-trust or attacker-observable.\n- Treat `events.linkAccount` as sensitive: add audit logging, user notification, or out-of-band confirmation so that any unexpected link is visible (defense-in-depth, not a root-cause fix).\n\n## Credit\n\nReported by @Nadav0077. Thank you for the responsible disclosure.",
"id": "GHSA-x445-f3h2-j279",
"modified": "2026-08-13T19:05:32Z",
"published": "2026-07-23T14:31:51Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nextauthjs/next-auth/security/advisories/GHSA-x445-f3h2-j279"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-73419"
},
{
"type": "WEB",
"url": "https://github.com/nextauthjs/next-auth/pull/13469"
},
{
"type": "WEB",
"url": "https://github.com/nextauthjs/next-auth/commit/5bca2399a79ba8d116ca5179b4b1ebcd152e7f05"
},
{
"type": "WEB",
"url": "https://github.com/nextauthjs/next-auth/commit/9f7a97fade9b1319bb9ac19fc9828d62e0a2a852"
},
{
"type": "PACKAGE",
"url": "https://github.com/nextauthjs/next-auth"
},
{
"type": "WEB",
"url": "https://github.com/nextauthjs/next-auth/releases/tag/@auth/core@0.41.3"
},
{
"type": "WEB",
"url": "https://github.com/nextauthjs/next-auth/releases/tag/next-auth@4.24.15"
},
{
"type": "WEB",
"url": "https://github.com/nextauthjs/next-auth/releases/tag/next-auth@5.0.0-beta.32"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Auth.js: OAuth state, nonce, and PKCE check cookies are not bound to the provider that created them"
}
GHSA-XV5W-Q5WQ-R3C3
Vulnerability from github – Published: 2025-12-03 21:31 – Updated: 2026-01-30 21:30Improper validation of source IP addresses in OpenVPN version 2.6.0 through 2.7_rc1 allows an attacker to open a session from a different IP address which did not initiate the connection resulting in a denial of service for the originating client
{
"affected": [],
"aliases": [
"CVE-2025-13086"
],
"database_specific": {
"cwe_ids": [
"CWE-940"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-03T20:16:24Z",
"severity": "MODERATE"
},
"details": "Improper validation of source IP addresses in OpenVPN version 2.6.0 through 2.7_rc1 allows an attacker to open a session from a different IP address which did not initiate the connection resulting in a denial of service for the originating client",
"id": "GHSA-xv5w-q5wq-r3c3",
"modified": "2026-01-30T21:30:19Z",
"published": "2025-12-03T21:31:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-13086"
},
{
"type": "WEB",
"url": "https://community.openvpn.net/Security%20Announcements/CVE-2025-13086"
},
{
"type": "WEB",
"url": "https://www.mail-archive.com/openvpn-announce@lists.sourceforge.net/msg00151.html"
},
{
"type": "WEB",
"url": "https://www.mail-archive.com/openvpn-announce@lists.sourceforge.net/msg00152.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:U/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
Mitigation
- Use a mechanism that can validate the identity of the source, such as a certificate, and validate the integrity of data to ensure that it cannot be modified in transit using an Adversary-in-the-Middle (AITM) attack.
- When designing functionality of actions in the URL scheme, consider whether the action should be accessible to all mobile applications, or if an allowlist of applications to interface with is appropriate.
CAPEC-500: WebView Injection
An adversary, through a previously installed malicious application, injects code into the context of a web page displayed by a WebView component. Through the injected code, an adversary is able to manipulate the DOM tree and cookies of the page, expose sensitive information, and can launch attacks against the web application from within the web page.
CAPEC-594: Traffic Injection
An adversary injects traffic into the target's network connection. The adversary is therefore able to degrade or disrupt the connection, and potentially modify the content. This is not a flooding attack, as the adversary is not focusing on exhausting resources. Instead, the adversary is crafting a specific input to affect the system in a particular way.
CAPEC-595: Connection Reset
In this attack pattern, an adversary injects a connection reset packet to one or both ends of a target's connection. The attacker is therefore able to have the target and/or the destination server sever the connection without having to directly filter the traffic between them.
CAPEC-596: TCP RST Injection
An adversary injects one or more TCP RST packets to a target after the target has made a HTTP GET request. The goal of this attack is to have the target and/or destination web server terminate the TCP connection.