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.
1008 vulnerabilities reference this CWE, most recent first.
GHSA-XG8H-H4CF-QVVX
Vulnerability from github – Published: 2022-05-24 17:48 – Updated: 2022-06-29 00:00HomeAutomation 3.3.2 suffers from an authentication bypass vulnerability when spoofing client IP address using the X-Forwarded-For header with the local (loopback) IP address value allowing remote control of the smart home solution.
{
"affected": [],
"aliases": [
"CVE-2020-22001"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-04-27T18:15:00Z",
"severity": "CRITICAL"
},
"details": "HomeAutomation 3.3.2 suffers from an authentication bypass vulnerability when spoofing client IP address using the X-Forwarded-For header with the local (loopback) IP address value allowing remote control of the smart home solution.",
"id": "GHSA-xg8h-h4cf-qvvx",
"modified": "2022-06-29T00:00:31Z",
"published": "2022-05-24T17:48:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-22001"
},
{
"type": "WEB",
"url": "https://cwe.mitre.org/data/definitions/290.html"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/47807"
},
{
"type": "WEB",
"url": "https://www.zeroscience.mk/en/vulnerabilities/ZSL-2019-5557.php"
}
],
"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-XGGH-GJH3-26R2
Vulnerability from github – Published: 2025-12-16 03:31 – Updated: 2025-12-17 15:34An authentication bypass by spoofing vulnerability has been reported to affect several QNAP operating system versions. The remote attackers can then exploit the vulnerability to access resources which are not otherwise accessible without proper authentication.
We have already fixed the vulnerability in the following versions: QTS 5.2.7.3297 build 20251024 and later QuTS hero h5.2.7.3297 build 20251024 and later QuTS hero h5.3.1.3292 build 20251024 and later
{
"affected": [],
"aliases": [
"CVE-2025-59385"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-16T03:15:58Z",
"severity": "HIGH"
},
"details": "An authentication bypass by spoofing vulnerability has been reported to affect several QNAP operating system versions. The remote attackers can then exploit the vulnerability to access resources which are not otherwise accessible without proper authentication.\n\nWe have already fixed the vulnerability in the following versions:\nQTS 5.2.7.3297 build 20251024 and later\nQuTS hero h5.2.7.3297 build 20251024 and later\nQuTS hero h5.3.1.3292 build 20251024 and later",
"id": "GHSA-xggh-gjh3-26r2",
"modified": "2025-12-17T15:34:52Z",
"published": "2025-12-16T03:31:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59385"
},
{
"type": "WEB",
"url": "https://www.qnap.com/en/security-advisory/qsa-25-45"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/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"
}
]
}
GHSA-XGHR-G5W9-XWR9
Vulnerability from github – Published: 2025-08-11 09:30 – Updated: 2025-08-11 09:30Official Document Management System developed by 2100 Technology has an Authentication Bypass vulnerability, allowing unauthenticated remote attackers to obtain any user's connection token and use it to log into the system as that user.
{
"affected": [],
"aliases": [
"CVE-2025-8853"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-11T09:15:30Z",
"severity": "CRITICAL"
},
"details": "Official Document Management System developed by 2100 Technology has an Authentication Bypass vulnerability, allowing unauthenticated remote attackers to obtain any user\u0027s connection token and use it to log into the system as that user.",
"id": "GHSA-xghr-g5w9-xwr9",
"modified": "2025-08-11T09:30:37Z",
"published": "2025-08-11T09:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-8853"
},
{
"type": "WEB",
"url": "https://www.chtsecurity.com/news/8618a2f0-390a-4506-9ff8-a9e74030d19e"
},
{
"type": "WEB",
"url": "https://www.chtsecurity.com/news/a9a90f0b-c2cb-4c66-b3d1-bc7f252fd108"
},
{
"type": "WEB",
"url": "https://www.twcert.org.tw/en/cp-139-10320-ad540-2.html"
},
{
"type": "WEB",
"url": "https://www.twcert.org.tw/tw/cp-132-10319-adc18-1.html"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/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"
}
]
}
GHSA-XH6M-2H5X-55MH
Vulnerability from github – Published: 2023-11-22 18:30 – Updated: 2023-12-04 15:31An issue was discovered in Network Optix NxCloud before 23.1.0.40440. It was possible to add a fake VMS server to NxCloud by using the exact identification of a legitimate VMS server. As result, it was possible to retrieve authorization headers from legitimate users when the legitimate client connects to the fake VMS server.
{
"affected": [],
"aliases": [
"CVE-2023-6263"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-11-22T18:15:09Z",
"severity": "HIGH"
},
"details": "An issue was discovered in Network Optix NxCloud before 23.1.0.40440.\u00a0It was possible to add a fake VMS server to NxCloud by using the exact\u00a0identification of a legitimate VMS server. As result, it was possible to\u00a0retrieve authorization headers from legitimate users when the\u00a0legitimate client connects to the fake VMS server.\n",
"id": "GHSA-xh6m-2h5x-55mh",
"modified": "2023-12-04T15:31:55Z",
"published": "2023-11-22T18:30:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6263"
},
{
"type": "WEB",
"url": "https://networkoptix.atlassian.net/wiki/spaces/CHS/blog/2023/09/22/3074195467/vulnerability+2023-09-21+-+Server+Spoofing"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-XH87-MX6M-69F3
Vulnerability from github – Published: 2026-02-25 18:02 – Updated: 2026-02-27 20:55Summary
When using the AWS Lambda adapter (hono/aws-lambda) behind an Application Load Balancer (ALB), the getConnInfo() function incorrectly selected the first value from the X-Forwarded-For header.
Because AWS ALB appends the real client IP address to the end of the X-Forwarded-For header, the first value can be attacker-controlled.
This could allow IP-based access control mechanisms (such as the ipRestriction middleware) to be bypassed.
Details
In ALB environments, AWS appends the actual client IP address to the end of any existing X-Forwarded-For header value. However, the previous implementation of getConnInfo() extracted the leftmost IP address:
address = xff.split(',')[0].trim()
If a client sent:
X-Forwarded-For: <spoofed-ip>
ALB would forward:
X-Forwarded-For: <spoofed-ip>, <real-client-ip>
Since the implementation selected the first value, the spoofed IP address was trusted. This affected applications using:
ipRestriction(getConnInfo, { allowList: [...] })
or any custom middleware relying on getConnInfo(c).remote.address for authorization decisions.
The issue only affects deployments using the AWS Lambda adapter behind an ALB. API Gateway (v1/v2) and Lambda Function URLs are not affected, as they use AWS-provided source IP values from requestContext.
Impact
An unauthenticated remote attacker could bypass IP-based access restrictions by supplying a crafted X-Forwarded-For header. This may allow access to resources that were intended to be restricted by IP address.
Only applications deployed behind an ALB and relying on getConnInfo() for IP-based authorization are affected.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "hono"
},
"ranges": [
{
"events": [
{
"introduced": "4.12.0"
},
{
"fixed": "4.12.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-27700"
],
"database_specific": {
"cwe_ids": [
"CWE-290",
"CWE-345"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-25T18:02:19Z",
"nvd_published_at": "2026-02-25T16:23:26Z",
"severity": "HIGH"
},
"details": "## Summary\n\nWhen using the AWS Lambda adapter (`hono/aws-lambda`) behind an Application Load Balancer (ALB), the `getConnInfo()` function incorrectly selected the first value from the `X-Forwarded-For` header.\n\nBecause AWS ALB appends the real client IP address to the end of the `X-Forwarded-For` header, the first value can be attacker-controlled.\n\nThis could allow IP-based access control mechanisms (such as the `ipRestriction` middleware) to be bypassed.\n\n## Details\n\nIn ALB environments, AWS appends the actual client IP address to the end of any existing `X-Forwarded-For` header value. However, the previous implementation of `getConnInfo()` extracted the leftmost IP address:\n\n```ts\naddress = xff.split(\u0027,\u0027)[0].trim()\n```\n\nIf a client sent:\n\n```\nX-Forwarded-For: \u003cspoofed-ip\u003e\n```\n\nALB would forward:\n\n```\nX-Forwarded-For: \u003cspoofed-ip\u003e, \u003creal-client-ip\u003e\n```\n\nSince the implementation selected the first value, the spoofed IP address was trusted. This affected applications using:\n\n```ts\nipRestriction(getConnInfo, { allowList: [...] })\n```\n\nor any custom middleware relying on `getConnInfo(c).remote.address` for authorization decisions.\n\nThe issue only affects deployments using the AWS Lambda adapter behind an ALB. API Gateway (v1/v2) and Lambda Function URLs are not affected, as they use AWS-provided source IP values from `requestContext`.\n\n## Impact\n\nAn unauthenticated remote attacker could bypass IP-based access restrictions by supplying a crafted `X-Forwarded-For` header. This may allow access to resources that were intended to be restricted by IP address.\n\nOnly applications deployed behind an ALB and relying on `getConnInfo()` for IP-based authorization are affected.",
"id": "GHSA-xh87-mx6m-69f3",
"modified": "2026-02-27T20:55:22Z",
"published": "2026-02-25T18:02:19Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/honojs/hono/security/advisories/GHSA-xh87-mx6m-69f3"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27700"
},
{
"type": "WEB",
"url": "https://github.com/honojs/hono/commit/41adbf56e252c04611f8972364ac0887ae07a4c7"
},
{
"type": "PACKAGE",
"url": "https://github.com/honojs/hono"
},
{
"type": "WEB",
"url": "https://github.com/honojs/hono/releases/tag/v4.12.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Hono is Vulnerable to Authentication Bypass by IP Spoofing in AWS Lambda ALB conninfo"
}
GHSA-XJ5X-M3F3-5X3H
Vulnerability from github – Published: 2026-04-03 02:44 – Updated: 2026-04-06 23:11Impact
A service worker running in a session could spoof reply messages on the internal IPC channel used by webContents.executeJavaScript() and related methods, causing the main-process promise to resolve with attacker-controlled data.
Apps are only affected if they have service workers registered and use the result of webContents.executeJavaScript() (or webFrameMain.executeJavaScript()) in security-sensitive decisions.
Workarounds
Do not trust the return value of webContents.executeJavaScript() for security decisions. Use dedicated, validated IPC channels for security-relevant communication with renderers.
Fixed Versions
41.0.040.8.139.8.138.8.6
For more information
If there are any questions or comments about this advisory, please email security@electronjs.org
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "electron"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "38.8.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "electron"
},
"ranges": [
{
"events": [
{
"introduced": "39.0.0-alpha.1"
},
{
"fixed": "39.8.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "electron"
},
"ranges": [
{
"events": [
{
"introduced": "40.0.0-alpha.1"
},
{
"fixed": "40.8.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "electron"
},
"ranges": [
{
"events": [
{
"introduced": "41.0.0-alpha.1"
},
{
"fixed": "41.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-34778"
],
"database_specific": {
"cwe_ids": [
"CWE-290",
"CWE-345"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-03T02:44:59Z",
"nvd_published_at": "2026-04-04T00:16:19Z",
"severity": "MODERATE"
},
"details": "### Impact\nA service worker running in a session could spoof reply messages on the internal IPC channel used by `webContents.executeJavaScript()` and related methods, causing the main-process promise to resolve with attacker-controlled data.\n\nApps are only affected if they have service workers registered and use the result of `webContents.executeJavaScript()` (or `webFrameMain.executeJavaScript()`) in security-sensitive decisions.\n\n### Workarounds\nDo not trust the return value of `webContents.executeJavaScript()` for security decisions. Use dedicated, validated IPC channels for security-relevant communication with renderers.\n\n### Fixed Versions\n* `41.0.0`\n* `40.8.1`\n* `39.8.1`\n* `38.8.6`\n\n### For more information\nIf there are any questions or comments about this advisory, please email [security@electronjs.org](mailto:security@electronjs.org)",
"id": "GHSA-xj5x-m3f3-5x3h",
"modified": "2026-04-06T23:11:12Z",
"published": "2026-04-03T02:44:59Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/electron/electron/security/advisories/GHSA-xj5x-m3f3-5x3h"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34778"
},
{
"type": "PACKAGE",
"url": "https://github.com/electron/electron"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Electron: Service worker can spoof executeJavaScript IPC replies"
}
GHSA-XJHX-X9FP-X5MX
Vulnerability from github – Published: 2024-05-17 09:31 – Updated: 2024-05-17 09:31Authentication Bypass by Spoofing vulnerability in Filipe Seabra WordPress Manutenção allows Functionality Bypass.This issue affects WordPress Manutenção: from n/a through 1.0.6.
{
"affected": [],
"aliases": [
"CVE-2024-22139"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-17T09:15:20Z",
"severity": "LOW"
},
"details": "Authentication Bypass by Spoofing vulnerability in Filipe Seabra WordPress Manuten\u00e7\u00e3o allows Functionality Bypass.This issue affects WordPress Manuten\u00e7\u00e3o: from n/a through 1.0.6.",
"id": "GHSA-xjhx-x9fp-x5mx",
"modified": "2024-05-17T09:31:02Z",
"published": "2024-05-17T09:31:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-22139"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/wp-manutencao/wordpress-wordpress-manutencao-plugin-1-0-6-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-XJR9-GG9Q-JX3V
Vulnerability from github – Published: 2026-06-19 20:47 – Updated: 2026-06-19 20:47Impact
Full impersonation of any principal the trusted STS could have issued an assertion for — including administrative principals when the relying party grants them via SAML claims. Affects both SAML 1.1 and SAML 2.0.
Preconditions
Relying-party service is hosted with WSFederationHttpBinding or WS2007FederationHttpBinding (or any binding that triggers FederatedSecurityTokenManager for issued-token validation), and IdentityConfiguration is wired (UseIdentityConfiguration = true). Attacker can reach the service over the network and knows the trusted STS’s public certificate (public certs are by design discoverable).
Patches
Fixed in CoreWCF v1.8.1 and v1.9.1
Workarounds
None
{
"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-54782"
],
"database_specific": {
"cwe_ids": [
"CWE-290",
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-19T20:47:11Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "### Impact\nFull impersonation of any principal the trusted STS could have issued an assertion for \u2014 including administrative principals when the relying party grants them via SAML claims. Affects both SAML 1.1 and SAML 2.0.\n\n#### Preconditions\nRelying-party service is hosted with WSFederationHttpBinding or WS2007FederationHttpBinding (or any binding that triggers FederatedSecurityTokenManager for issued-token validation), and IdentityConfiguration is wired (UseIdentityConfiguration = true).\nAttacker can reach the service over the network and knows the trusted STS\u2019s public certificate (public certs are by design discoverable).\n\n### Patches\nFixed in CoreWCF v1.8.1 and v1.9.1\n\n### Workarounds\nNone",
"id": "GHSA-xjr9-gg9q-jx3v",
"modified": "2026-06-19T20:47:11Z",
"published": "2026-06-19T20:47:11Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/CoreWCF/CoreWCF/security/advisories/GHSA-xjr9-gg9q-jx3v"
},
{
"type": "PACKAGE",
"url": "https://github.com/CoreWCF/CoreWCF"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "CoreWCF: Authentication bypass in CoreWCF SAML 1.1 / 2.0 token signature validation"
}
GHSA-XM9X-VJCF-6HVV
Vulnerability from github – Published: 2025-09-12 12:30 – Updated: 2025-09-12 12:30Wi-SUN unexpected 4- Way Handshake packet receptions may lead to predictable keys and potentially leading to Man in the middle (MitM) attack
{
"affected": [],
"aliases": [
"CVE-2025-7448"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-12T10:15:32Z",
"severity": "HIGH"
},
"details": "Wi-SUN unexpected 4- Way Handshake packet receptions may lead to predictable keys and potentially leading to Man in the middle (MitM) attack",
"id": "GHSA-xm9x-vjcf-6hvv",
"modified": "2025-09-12T12:30:23Z",
"published": "2025-09-12T12:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-7448"
},
{
"type": "WEB",
"url": "https://community.silabs.com/068Vm00000UtuIG"
},
{
"type": "WEB",
"url": "https://docs.silabs.com/sisdk-release-notes/latest/sisdk-wisun-release-notes"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/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"
}
]
}
GHSA-XMH9-RG6F-J3MR
Vulnerability from github – Published: 2021-03-12 22:39 – Updated: 2021-03-10 04:01Impact
Severity
Any Pod on a Solid server using a vulnerable version of the identity-token-verifier library is at risk of a spoofed Demonstration of Proof-of-Possession (DPoP) token binding. This vulnerability could give total and complete access to a targeted Pod.
Summary
A verification flaw in the implementation of the identity token verifier library (https://github.com/solid/identity-token-verifier) allows DPoP proofs to be spoofed.
DPoP proofs are used to bind access tokens to a private key meant to be in sole possession of a specific user. Instead of verifying against the hash of an embedded public key, the library instead verifies against a field that an attacker can modify to spoof another user’s DPoP.
A stolen DPoP proof, when used in the right context, therefore allows the rebinding of a DPoP-bound access token. Any attacker in possession of a targeted access token could build an attack environment to replay it on any Pod service with this vulnerability.
Patches
A new version 0.5.2 of identity-token-verifier fixes the verification: https://github.com/solid/identity-token-verifier/blob/7e18d86d65ee681e8ae912b6a032a1bae3cae570/src/lib/DPoP.ts#L25-L35
Workarounds
None
References
Are there any links users can visit to find out more?
For more information
If you have any questions or comments about this advisory: * Open an issue in the identity-token-verifier repository. * Email: info@solidproject.org
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@solid/identity-token-verifier"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.5.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": true,
"github_reviewed_at": "2021-03-10T04:01:48Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Impact\n#### Severity\nAny Pod on a Solid server using a vulnerable version of the identity-token-verifier library is at risk of a spoofed Demonstration of Proof-of-Possession (DPoP) token binding. This vulnerability could give total and complete access to a targeted Pod.\n\n#### Summary\nA verification flaw in the implementation of the identity token verifier library (https://github.com/solid/identity-token-verifier) allows DPoP proofs to be spoofed. \n\nDPoP proofs are used to bind access tokens to a private key meant to be in sole possession of a specific user. Instead of verifying against the hash of an embedded public key, the library instead verifies against a field that an attacker can modify to spoof another user\u2019s DPoP. \n\nA stolen DPoP proof, when used in the right context, therefore allows the rebinding of a DPoP-bound access token. Any attacker in possession of a targeted access token could build an attack environment to replay it on any Pod service with this vulnerability. \n\n\n### Patches\nA new version 0.5.2 of identity-token-verifier fixes the verification: https://github.com/solid/identity-token-verifier/blob/7e18d86d65ee681e8ae912b6a032a1bae3cae570/src/lib/DPoP.ts#L25-L35\n\n### Workarounds\nNone\n\n### References\n_Are there any links users can visit to find out more?_\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in the [identity-token-verifier](https://github.com/solid/identity-token-verifier/) repository.\n* Email: info@solidproject.org",
"id": "GHSA-xmh9-rg6f-j3mr",
"modified": "2021-03-10T04:01:48Z",
"published": "2021-03-12T22:39:01Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/solid/identity-token-verifier/security/advisories/GHSA-xmh9-rg6f-j3mr"
},
{
"type": "WEB",
"url": "https://github.com/solid/identity-token-verifier/commit/fbdeb4aa8c12694b3744cd0454acb826817d9e6c"
},
{
"type": "WEB",
"url": "https://github.com/solid/identity-token-verifier/releases/tag/0.5.2"
},
{
"type": "WEB",
"url": "https://www.npmjs.com/package/@solid/identity-token-verifier"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Verification flaw in Solid identity-token-verifier"
}
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.