CWE-345
DiscouragedInsufficient Verification of Data Authenticity
Abstraction: Class · Status: Draft
The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.
948 vulnerabilities reference this CWE, most recent first.
GHSA-4XW9-CX39-R355
Vulnerability from github – Published: 2023-11-17 22:48 – Updated: 2026-06-08 23:38Summary
The json-web-token library is vulnerable to a JWT algorithm confusion attack.
Details
On line 86 of the 'index.js' file, the algorithm to use for verifying the signature of the JWT token is taken from the JWT token, which at that point is still unverified and thus shouldn't be trusted. To exploit this vulnerability, an attacker needs to craft a malicious JWT token containing the HS256 algorithm, signed with the public RSA key of the victim application. This attack will only work against this library is the RS256 algorithm is in use, however it is a best practice to use that algorithm.
PoC
Take a server running the following code:
const express = require('express');
const jwt = require('json-web-token');
const fs = require('fs');
const path = require('path');
const app = express();
const port = 3000;
// Load the keys from the file
const publicKeyPath = path.join(__dirname, 'public-key.pem');
const publicKey = fs.readFileSync(publicKeyPath, 'utf8');
const privateKeyPath = path.join(__dirname, 'private-key.pem');
const privateKey = fs.readFileSync(privateKeyPath, 'utf8');
app.use(express.json());
// Endpoint to generate a JWT token with admin: False
app.get('/generateToken', async (req, res) => {
const payload = { admin: false, name: req.query.name };
const token = await jwt.encode(privateKey, payload, 'RS256', function (err, token) {
res.json({ token });
});
});
// Middleware to verify the JWT token
function verifyToken(req, res, next) {
const token = req.query.token;
jwt.decode(publicKey, token, (err, decoded) => {
if (err) {
console.log(err)
return res.status(401).json({ message: 'Token authentication failed' });
}
req.decoded = decoded;
next();
});
}
// Endpoint to check if you are the admin or not
app.get('/checkAdmin', verifyToken, (req, res) => {
res.json(req.decoded);
});
app.listen(port, () => {
console.log(`Server is running on port ${port}`);
});
Public key recovery
First, an attacker needs to recover the public key from the server in any way possible. It is possible to extract this from just two JWT tokens as shown below.
Grab two different JWT tokens and utilize the following tool: https://github.com/silentsignal/rsa_sign2n/blob/release/standalone/jwt_forgery.py
python3 jwt_forgery.py token1 token2
The tool will generate 4 different public keys, all in different formats. Try the following for all 4 formats.
Algorithm confusion
Change the JWT to the HS256 algorithm and modify any of the contents to your liking at https://jwt.io/.
Copy the resulting JWT token and use with the following tool: https://github.com/ticarpi/jwt_tool.
python /opt/jwt_tool/jwt_tool.py --exploit k -pk public_key token
You will now get a resulting JWT token that is validly signed.
Impact
Applications using the RS256 algorithm, are vulnerable to this algorithm confusion attack which allows attackers to sign arbitrary payloads that the verifier will accept.
Solution
Either one of the following solutions will work.
1. Change the signature of the decode function to ensure that the algorithm is set in that call
2. Check whether or not the secret could be a public key in the decode function and in that case, set the key to be a public key.
Fixed in 4.0.0. Both encode and decode now reject combinations where the key type (PEM vs plain secret) doesn't match the algorithm family. Upgrade with npm install json-web-token@^4.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.1.1"
},
"package": {
"ecosystem": "npm",
"name": "json-web-token"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-48238"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-345"
],
"github_reviewed": true,
"github_reviewed_at": "2023-11-17T22:48:15Z",
"nvd_published_at": "2023-11-17T22:15:07Z",
"severity": "HIGH"
},
"details": "### Summary\nThe json-web-token library is vulnerable to a JWT algorithm confusion attack.\n\n### Details\nOn line 86 of the \u0027index.js\u0027 file, the algorithm to use for verifying the signature of the JWT token is taken from the JWT token, which at that point is still unverified and thus shouldn\u0027t be trusted. To exploit this vulnerability, an attacker needs to craft a malicious JWT token containing the HS256 algorithm, signed with the public RSA key of the victim application. This attack will only work against this library is the RS256 algorithm is in use, however it is a best practice to use that algorithm.\n\n### PoC\nTake a server running the following code:\n```javascript\nconst express = require(\u0027express\u0027);\nconst jwt = require(\u0027json-web-token\u0027);\nconst fs = require(\u0027fs\u0027);\nconst path = require(\u0027path\u0027);\n\nconst app = express();\nconst port = 3000;\n\n// Load the keys from the file\nconst publicKeyPath = path.join(__dirname, \u0027public-key.pem\u0027);\nconst publicKey = fs.readFileSync(publicKeyPath, \u0027utf8\u0027);\nconst privateKeyPath = path.join(__dirname, \u0027private-key.pem\u0027);\nconst privateKey = fs.readFileSync(privateKeyPath, \u0027utf8\u0027);\n\napp.use(express.json());\n\n// Endpoint to generate a JWT token with admin: False\napp.get(\u0027/generateToken\u0027, async (req, res) =\u003e {\n const payload = { admin: false, name: req.query.name };\n const token = await jwt.encode(privateKey, payload, \u0027RS256\u0027, function (err, token) {\n res.json({ token });\n });\n});\n\n// Middleware to verify the JWT token\nfunction verifyToken(req, res, next) {\n const token = req.query.token;\n\n jwt.decode(publicKey, token, (err, decoded) =\u003e {\n if (err) {\n console.log(err)\n return res.status(401).json({ message: \u0027Token authentication failed\u0027 });\n }\n\n req.decoded = decoded;\n next();\n });\n}\n\n// Endpoint to check if you are the admin or not\napp.get(\u0027/checkAdmin\u0027, verifyToken, (req, res) =\u003e {\n res.json(req.decoded);\n});\n\napp.listen(port, () =\u003e {\n console.log(`Server is running on port ${port}`);\n});\n```\n\n**Public key recovery**\nFirst, an attacker needs to recover the public key from the server in any way possible. It is possible to extract this from just two JWT tokens as shown below.\nGrab two different JWT tokens and utilize the following tool: `https://github.com/silentsignal/rsa_sign2n/blob/release/standalone/jwt_forgery.py`\n```\npython3 jwt_forgery.py token1 token2\n```\nThe tool will generate 4 different public keys, all in different formats. Try the following for all 4 formats.\n\n**Algorithm confusion**\nChange the JWT to the HS256 algorithm and modify any of the contents to your liking at `https://jwt.io/`.\nCopy the resulting JWT token and use with the following tool: `https://github.com/ticarpi/jwt_tool`.\n```\npython /opt/jwt_tool/jwt_tool.py --exploit k -pk public_key token\n```\nYou will now get a resulting JWT token that is validly signed.\n\n### Impact\nApplications using the RS256 algorithm, are vulnerable to this algorithm confusion attack which allows attackers to sign arbitrary payloads that the verifier will accept.\n\n### Solution\nEither one of the following solutions will work.\n1. Change the signature of the `decode` function to ensure that the algorithm is set in that call\n2. Check whether or not the secret could be a public key in the decode function and in that case, set the key to be a public key.\n\n\n\u003e Fixed in 4.0.0. Both encode and decode now reject combinations where the key type (PEM vs plain secret) doesn\u0027t match the algorithm family. Upgrade with npm install json-web-token@^4.",
"id": "GHSA-4xw9-cx39-r355",
"modified": "2026-06-08T23:38:28Z",
"published": "2023-11-17T22:48:15Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/joaquimserafim/json-web-token/security/advisories/GHSA-4xw9-cx39-r355"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-48238"
},
{
"type": "WEB",
"url": "https://github.com/joaquimserafim/json-web-token/commit/b6e56b1346f48432d29133c76b65222ad93956b7"
},
{
"type": "PACKAGE",
"url": "https://github.com/joaquimserafim/json-web-token"
},
{
"type": "WEB",
"url": "https://github.com/joaquimserafim/json-web-token/blob/acf6a462471e1b14187eb77414e9161b8b7bff7e/index.js#L86"
}
],
"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"
}
],
"summary": "json-web-token library is vulnerable to a JWT algorithm confusion attack"
}
GHSA-524X-476P-JQF4
Vulnerability from github – Published: 2023-06-13 18:30 – Updated: 2024-04-04 04:47Insufficient verification of data authenticity in Zoom for Windows clients before 5.14.0 may allow an authenticated user to potentially enable an escalation of privilege via network access.
{
"affected": [],
"aliases": [
"CVE-2023-34113"
],
"database_specific": {
"cwe_ids": [
"CWE-345"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-13T18:15:21Z",
"severity": "HIGH"
},
"details": "Insufficient verification of data authenticity in Zoom for Windows clients before 5.14.0 may allow an authenticated user to potentially enable an escalation of privilege via network access.\n\n",
"id": "GHSA-524x-476p-jqf4",
"modified": "2024-04-04T04:47:43Z",
"published": "2023-06-13T18:30:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-34113"
},
{
"type": "WEB",
"url": "https://explore.zoom.us/en/trust/security/security-bulletin"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-52MQ-6JCV-J79X
Vulnerability from github – Published: 2021-03-03 02:23 – Updated: 2021-04-14 19:07Impact
The user content sandbox can be abused to trick users into opening unexpected documents after several user interactions. The content can be opened with a blob origin from the Matrix client, so it is possible for a malicious document to access user messages and secrets.
Patches
This has been fixed by https://github.com/matrix-org/matrix-react-sdk/pull/5657, which is included in 3.15.0.
Workarounds
There are no known workarounds.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "matrix-react-sdk"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.15.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-21320"
],
"database_specific": {
"cwe_ids": [
"CWE-345"
],
"github_reviewed": true,
"github_reviewed_at": "2021-03-02T02:47:04Z",
"nvd_published_at": "2021-03-02T03:15:00Z",
"severity": "LOW"
},
"details": "### Impact\n\nThe user content sandbox can be abused to trick users into opening unexpected documents after several user interactions. The content can be opened with a `blob` origin from the Matrix client, so it is possible for a malicious document to access user messages and secrets.\n\n### Patches\n\nThis has been fixed by https://github.com/matrix-org/matrix-react-sdk/pull/5657, which is included in 3.15.0.\n\n### Workarounds\n\nThere are no known workarounds.",
"id": "GHSA-52mq-6jcv-j79x",
"modified": "2021-04-14T19:07:25Z",
"published": "2021-03-03T02:23:56Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/matrix-org/matrix-react-sdk/security/advisories/GHSA-52mq-6jcv-j79x"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21320"
},
{
"type": "WEB",
"url": "https://github.com/matrix-org/matrix-react-sdk/pull/5657"
},
{
"type": "WEB",
"url": "https://github.com/matrix-org/matrix-react-sdk/commit/b386f0c73b95ecbb6ea7f8f79c6ff5171a8dedd1"
},
{
"type": "WEB",
"url": "https://www.npmjs.com/package/matrix-react-sdk"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "User content sandbox can be confused into opening arbitrary documents"
}
GHSA-53J2-QXV2-HFQJ
Vulnerability from github – Published: 2026-03-10 18:31 – Updated: 2026-03-10 18:31Insufficient verification of data authenticity in Windows App Installer allows an unauthorized attacker to perform spoofing over a network.
{
"affected": [],
"aliases": [
"CVE-2026-23656"
],
"database_specific": {
"cwe_ids": [
"CWE-345"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-10T18:18:13Z",
"severity": "MODERATE"
},
"details": "Insufficient verification of data authenticity in Windows App Installer allows an unauthorized attacker to perform spoofing over a network.",
"id": "GHSA-53j2-qxv2-hfqj",
"modified": "2026-03-10T18:31:19Z",
"published": "2026-03-10T18:31:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23656"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-23656"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-53JQ-549V-3FJG
Vulnerability from github – Published: 2024-05-15 21:31 – Updated: 2024-05-15 21:31Insufficient verification of data authenticity in the installer for Zoom Workplace VDI App for Windows may allow an authenticated user to conduct an escalation of privilege via local access.
{
"affected": [],
"aliases": [
"CVE-2024-27244"
],
"database_specific": {
"cwe_ids": [
"CWE-345",
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-15T21:15:08Z",
"severity": "MODERATE"
},
"details": "Insufficient verification of data authenticity in the installer for Zoom Workplace VDI App for Windows may allow an authenticated user to conduct an escalation of privilege via local access.",
"id": "GHSA-53jq-549v-3fjg",
"modified": "2024-05-15T21:31:26Z",
"published": "2024-05-15T21:31:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27244"
},
{
"type": "WEB",
"url": "https://www.zoom.com/en/trust/security-bulletin/zsb-24015"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-54HH-G5MX-JQCP
Vulnerability from github – Published: 2026-06-26 22:52 – Updated: 2026-06-26 22:52While it is unclear whether this should be classified as a vulnerability, it is being reported through this channel because the current behavior may represent an unsafe default.
Summary
pnpm install in non-frozen mode can accept new remote package content after detecting that the downloaded tarball does not match the integrity recorded in pnpm-lock.yaml.
When a package is already locked with an integrity value, and the registry later serves different metadata and tarball content for the same package name and version, pnpm initially reports an integrity mismatch. However, plain pnpm install then performs a resolution repair, accepts the registry's new integrity, updates the lockfile, installs the new content, and exits successfully.
This means the lockfile integrity check does not act as a hard stop by default.
Reproduction Scenario
- Run a local npm-compatible registry.
- Publish or serve
example-package@1.0.0with tarball contentv1. - Install it with pnpm:
pnpm add example-package@1.0.0 --registry=http://127.0.0.1:48741
- Confirm
pnpm-lock.yamlcontains thev1integrity:
packages:
example-package@1.0.0:
resolution:
integrity: sha512-...v1...
- Change the registry metadata and tarball for the same
example-package@1.0.0to contentv2. - On a clean store/cache, run:
pnpm install --registry=http://127.0.0.1:48741
Observed Behavior
pnpm detects the checksum mismatch:
WARN Got unexpected checksum for "http://127.0.0.1:48741/example-package/-/example-package-1.0.0.tgz".
Wanted "sha512-...v1..."
Got "sha512-...v2...".
ERR_PNPM_TARBALL_INTEGRITY The lockfile is broken! Resolution step will be performed to fix it.
However, the install still succeeds:
INSTALL_RC=0
INSTALLED=v2-replaced
The lockfile is then rewritten to trust the new remote integrity:
packages:
example-package@1.0.0:
resolution:
integrity: sha512-...v2...
Expected Behavior
If a downloaded tarball does not match the integrity recorded in pnpm-lock.yaml, the install should fail by default.
The lockfile integrity should be treated as authoritative unless the user explicitly requests lockfile repair or dependency update behavior.
Security Impact
This behavior weakens the protection normally expected from a committed lockfile.
If a registry is compromised and an attacker overwrites the metadata and tarball for an existing package version, a new environment without the old pnpm store/cache may install the attacker's replacement package even though the project already has a lockfile with the original integrity.
Examples of affected new or clean environments include:
- an engineer setting up the project on a new machine
- a new team member onboarding to the project
In this situation, pnpm first detects that the downloaded tarball does not match the integrity stored in pnpm-lock.yaml. However, instead of failing by default, plain pnpm install performs a resolution repair, trusts the current remote registry metadata, updates the lockfile to the new integrity, and installs the new registry content.
In other words, when the lockfile and registry disagree, the default non-frozen behavior can end up trusting the remote registry over the content previously recorded in the lockfile.
This is especially relevant for:
- private registries that allow overwriting or republishing the same version
- registry mirrors or proxies that can serve changed metadata and tarballs
- compromised public or private registries
- compromised registry proxy infrastructure
The behavior is also surprising because the command reports an integrity error but still exits successfully after resolution repair.
This issue does not occur when --frozen-lockfile is enabled. In frozen mode, the same integrity mismatch fails the install and does not install the changed package content.
However, since the lockfile already records an integrity value, the integrity for the same package version should normally not change. If it does change, one likely explanation is that the server or registry has been compromised or is serving mutated package content. Under normal package publishing workflows, changed package content should be published as a new version instead of replacing an existing version.
For that reason, it may be safer for pnpm's default behavior to be closer to frozen mode for this specific case. At minimum, pnpm should not automatically repair the lockfile and trust the registry after an integrity mismatch. It should fail and let the user explicitly decide whether to discard the locked integrity, re-resolve the package from the remote registry, and update the lockfile.
Comparison
In the same scenario, npm install with an existing package-lock.json fails with EINTEGRITY and does not install the changed tarball.
pnpm install --frozen-lockfile also fails as expected:
ERR_PNPM_TARBALL_INTEGRITY
The issue is specific to the default non-frozen behavior of plain pnpm install in non-CI environment.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "pnpm"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "10.34.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "pnpm"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0"
},
{
"fixed": "11.4.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-50573"
],
"database_specific": {
"cwe_ids": [
"CWE-345"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-26T22:52:33Z",
"nvd_published_at": "2026-06-25T18:16:39Z",
"severity": "MODERATE"
},
"details": "While it is unclear whether this should be classified as a vulnerability, it is being reported through this channel because the current behavior may represent an unsafe default.\n\n## Summary\n\n`pnpm install` in non-frozen mode can accept new remote package content after detecting that the downloaded tarball does not match the integrity recorded in `pnpm-lock.yaml`.\n\nWhen a package is already locked with an `integrity` value, and the registry later serves different metadata and tarball content for the same package name and version, pnpm initially reports an integrity mismatch. However, plain `pnpm install` then performs a resolution repair, accepts the registry\u0027s new integrity, updates the lockfile, installs the new content, and exits successfully.\n\nThis means the lockfile integrity check does not act as a hard stop by default.\n\n## Reproduction Scenario\n\n1. Run a local npm-compatible registry.\n2. Publish or serve `example-package@1.0.0` with tarball content `v1`.\n3. Install it with pnpm:\n\n```bash\npnpm add example-package@1.0.0 --registry=http://127.0.0.1:48741\n```\n\n4. Confirm `pnpm-lock.yaml` contains the `v1` integrity:\n\n```yaml\npackages:\n example-package@1.0.0:\n resolution:\n integrity: sha512-...v1...\n```\n\n5. Change the registry metadata and tarball for the same `example-package@1.0.0` to content `v2`.\n6. On a clean store/cache, run:\n\n```bash\npnpm install --registry=http://127.0.0.1:48741\n```\n\n## Observed Behavior\n\npnpm detects the checksum mismatch:\n\n```text\nWARN Got unexpected checksum for \"http://127.0.0.1:48741/example-package/-/example-package-1.0.0.tgz\".\nWanted \"sha512-...v1...\"\nGot \"sha512-...v2...\".\n\nERR_PNPM_TARBALL_INTEGRITY The lockfile is broken! Resolution step will be performed to fix it.\n```\n\nHowever, the install still succeeds:\n\n```text\nINSTALL_RC=0\nINSTALLED=v2-replaced\n```\n\nThe lockfile is then rewritten to trust the new remote integrity:\n\n```yaml\npackages:\n example-package@1.0.0:\n resolution:\n integrity: sha512-...v2...\n```\n\n## Expected Behavior\n\nIf a downloaded tarball does not match the integrity recorded in `pnpm-lock.yaml`, the install should fail by default.\n\nThe lockfile integrity should be treated as authoritative unless the user explicitly requests lockfile repair or dependency update behavior.\n\n## Security Impact\n\nThis behavior weakens the protection normally expected from a committed lockfile.\n\nIf a registry is compromised and an attacker overwrites the metadata and tarball for an existing package version, a new environment without the old pnpm store/cache may install the attacker\u0027s replacement package even though the project already has a lockfile with the original integrity.\n\nExamples of affected new or clean environments include:\n\n- an engineer setting up the project on a new machine\n- a new team member onboarding to the project\n\nIn this situation, pnpm first detects that the downloaded tarball does not match the integrity stored in `pnpm-lock.yaml`. However, instead of failing by default, plain `pnpm install` performs a resolution repair, trusts the current remote registry metadata, updates the lockfile to the new integrity, and installs the new registry content.\n\nIn other words, when the lockfile and registry disagree, the default non-frozen behavior can end up trusting the remote registry over the content previously recorded in the lockfile.\n\nThis is especially relevant for:\n\n- private registries that allow overwriting or republishing the same version\n- registry mirrors or proxies that can serve changed metadata and tarballs\n- compromised public or private registries\n- compromised registry proxy infrastructure\n\nThe behavior is also surprising because the command reports an integrity error but still exits successfully after resolution repair.\n\nThis issue does not occur when `--frozen-lockfile` is enabled. In frozen mode, the same integrity mismatch fails the install and does not install the changed package content.\n\nHowever, since the lockfile already records an integrity value, the integrity for the same package version should normally not change. If it does change, one likely explanation is that the server or registry has been compromised or is serving mutated package content. Under normal package publishing workflows, changed package content should be published as a new version instead of replacing an existing version.\n\nFor that reason, it may be safer for pnpm\u0027s default behavior to be closer to frozen mode for this specific case. At minimum, pnpm should not automatically repair the lockfile and trust the registry after an integrity mismatch. It should fail and let the user explicitly decide whether to discard the locked integrity, re-resolve the package from the remote registry, and update the lockfile.\n\n## Comparison\n\nIn the same scenario, `npm install` with an existing `package-lock.json` fails with `EINTEGRITY` and does not install the changed tarball.\n\n`pnpm install --frozen-lockfile` also fails as expected:\n\n```text\nERR_PNPM_TARBALL_INTEGRITY\n```\n\nThe issue is specific to the default non-frozen behavior of plain `pnpm install` in non-CI environment.",
"id": "GHSA-54hh-g5mx-jqcp",
"modified": "2026-06-26T22:52:33Z",
"published": "2026-06-26T22:52:33Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pnpm/pnpm/security/advisories/GHSA-54hh-g5mx-jqcp"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50573"
},
{
"type": "PACKAGE",
"url": "https://github.com/pnpm/pnpm"
}
],
"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": "pnpm: Unsafe default behavior breaks integrity check"
}
GHSA-5554-V93Q-454G
Vulnerability from github – Published: 2023-06-09 09:30 – Updated: 2024-04-04 04:42The Brizy Page Builder plugin for WordPress is vulnerable to IP Address Spoofing in versions up to, and including, 2.4.18. This is due to an implicit trust of user-supplied IP addresses in an 'X-Forwarded-For' HTTP header for the purpose of validating allowed IP addresses against a Maintenance Mode whitelist. Supplying a whitelisted IP address within the 'X-Forwarded-For' header allows maintenance mode to be bypassed and may result in the disclosure of potentially sensitive information or allow access to restricted functionality.
{
"affected": [],
"aliases": [
"CVE-2023-2897"
],
"database_specific": {
"cwe_ids": [
"CWE-345",
"CWE-348"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-09T07:15:10Z",
"severity": "MODERATE"
},
"details": "The Brizy Page Builder plugin for WordPress is vulnerable to IP Address Spoofing in versions up to, and including, 2.4.18. This is due to an implicit trust of user-supplied IP addresses in an \u0027X-Forwarded-For\u0027 HTTP header for the purpose of validating allowed IP addresses against a Maintenance Mode whitelist. Supplying a whitelisted IP address within the \u0027X-Forwarded-For\u0027 header allows maintenance mode to be bypassed and may result in the disclosure of potentially sensitive information or allow access to restricted functionality.",
"id": "GHSA-5554-v93q-454g",
"modified": "2024-04-04T04:42:25Z",
"published": "2023-06-09T09:30:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2897"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/2919443/brizy"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/ae342dd9-2f5f-4356-8fb4-9a3e5f4f8316?source=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-5565-3C98-G6JC
Vulnerability from github – Published: 2025-03-25 21:49 – Updated: 2025-03-25 21:49Impact
A vulnerability was found in OIDC-Client. When using the elytron-oidc-client subsystem with WildFly, authorization code injection attacks can occur, allowing an attacker to inject a stolen authorization code into the attacker's own session with the client with a victim's identity. This is usually done with a Man-in-the-Middle (MitM) or phishing attack.
Patches
Workarounds
Currently, no mitigation is currently available for this vulnerability.
References
https://nvd.nist.gov/vuln/detail/CVE-2024-12369
https://access.redhat.com/security/cve/CVE-2024-12369
https://bugzilla.redhat.com/show_bug.cgi?id=2331178
https://issues.redhat.com/browse/ELY-2887
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.wildfly.security:wildfly-elytron"
},
"ranges": [
{
"events": [
{
"introduced": "1.17.0.Final"
},
{
"fixed": "2.2.9.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.wildfly.security:wildfly-elytron"
},
"ranges": [
{
"events": [
{
"introduced": "2.3.0.Final"
},
{
"fixed": "2.6.2.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.wildfly.security:wildfly-elytron-http-oidc"
},
"ranges": [
{
"events": [
{
"introduced": "1.17.0.Final"
},
{
"fixed": "2.2.9.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.wildfly.security:wildfly-elytron-http-oidc"
},
"ranges": [
{
"events": [
{
"introduced": "2.3.0.Final"
},
{
"fixed": "2.6.2.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-12369"
],
"database_specific": {
"cwe_ids": [
"CWE-345"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-25T21:49:11Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Impact\n\nA vulnerability was found in OIDC-Client. When using the elytron-oidc-client subsystem with WildFly, authorization code injection attacks can occur, allowing an attacker to inject a stolen authorization code into the attacker\u0027s own session with the client with a victim\u0027s identity. This is usually done with a Man-in-the-Middle (MitM) or phishing attack.\n\n### Patches\n\n[2.2.9.Final](https://github.com/wildfly-security/wildfly-elytron/releases/tag/2.2.9.Final)\n[2.6.2.Final](https://github.com/wildfly-security/wildfly-elytron/releases/tag/2.6.2.Final)\n\n### Workarounds\n\nCurrently, no mitigation is currently available for this vulnerability.\n\n### References\n\nhttps://nvd.nist.gov/vuln/detail/CVE-2024-12369\nhttps://access.redhat.com/security/cve/CVE-2024-12369\t\nhttps://bugzilla.redhat.com/show_bug.cgi?id=2331178\nhttps://issues.redhat.com/browse/ELY-2887",
"id": "GHSA-5565-3c98-g6jc",
"modified": "2025-03-25T21:49:11Z",
"published": "2025-03-25T21:49:11Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/wildfly-security/wildfly-elytron/security/advisories/GHSA-5565-3c98-g6jc"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-12369"
},
{
"type": "WEB",
"url": "https://github.com/wildfly-security/wildfly-elytron/pull/2253"
},
{
"type": "WEB",
"url": "https://github.com/wildfly-security/wildfly-elytron/pull/2261"
},
{
"type": "WEB",
"url": "https://github.com/wildfly-security/wildfly-elytron/commit/5ac5e6bbcba58883b3cebb2ddbcec4de140c5ceb"
},
{
"type": "WEB",
"url": "https://github.com/wildfly-security/wildfly-elytron/commit/d7754f5a6a91ceb0f4dbbbfe301991f6a55404cb"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2024-12369"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2331178"
},
{
"type": "PACKAGE",
"url": "https://github.com/wildfly-security/wildfly-elytron"
},
{
"type": "WEB",
"url": "https://issues.redhat.com/browse/ELY-2887"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "WildFly Elytron OpenID Connect Client ExtensionOIDC authorization code injection attack"
}
GHSA-573W-86FX-GF5P
Vulnerability from github – Published: 2022-05-24 17:11 – Updated: 2023-05-24 15:30An issue was discovered in OpenWrt 18.06.0 to 18.06.6 and 19.07.0, and LEDE 17.01.0 to 17.01.7. A bug in the fork of the opkg package manager before 2020-01-25 prevents correct parsing of embedded checksums in the signed repository index, allowing a man-in-the-middle attacker to inject arbitrary package payloads (which are installed without verification).
{
"affected": [],
"aliases": [
"CVE-2020-7982"
],
"database_specific": {
"cwe_ids": [
"CWE-345",
"CWE-74"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-03-16T22:15:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in OpenWrt 18.06.0 to 18.06.6 and 19.07.0, and LEDE 17.01.0 to 17.01.7. A bug in the fork of the opkg package manager before 2020-01-25 prevents correct parsing of embedded checksums in the signed repository index, allowing a man-in-the-middle attacker to inject arbitrary package payloads (which are installed without verification).",
"id": "GHSA-573w-86fx-gf5p",
"modified": "2023-05-24T15:30:26Z",
"published": "2022-05-24T17:11:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-7982"
},
{
"type": "WEB",
"url": "https://arstechnica.com/information-technology/2020/03/openwrt-is-vulnerable-to-attacks-that-execute-malicious-code"
},
{
"type": "WEB",
"url": "https://blog.forallsecure.com/uncovering-openwrt-remote-code-execution-cve-2020-7982"
},
{
"type": "WEB",
"url": "https://github.com/openwrt/openwrt/commits/master"
},
{
"type": "WEB",
"url": "https://openwrt.org/advisory/2020-01-31-1"
}
],
"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-57R2-H2WJ-G887
Vulnerability from github – Published: 2026-04-25 23:47 – Updated: 2026-05-19 15:56Affected Packages / Versions
- Package:
openclaw(npm) - Affected versions:
< 2026.4.20 - Patched version:
2026.4.20
Impact
Output from webhook-triggered isolated cron agent runs could be queued into the main session awareness stream without trusted: false. That made the event render as a trusted System: event instead of an untrusted system event.
This is a trust-labeling issue that can strengthen prompt-injection impact, but it does not directly bypass gateway auth, tool policy, or sandboxing. Severity is low.
Fix
OpenClaw now preserves untrusted labels for isolated cron awareness events and forwards the trust flag through cron delivery helpers.
Fix commit:
f61896b03cc7031f51106a04566831f4ac2a0bd7
Release
Fixed in OpenClaw 2026.4.20.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.4.20"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44999"
],
"database_specific": {
"cwe_ids": [
"CWE-345"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-25T23:47:31Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "## Affected Packages / Versions\n\n- Package: `openclaw` (npm)\n- Affected versions: `\u003c 2026.4.20`\n- Patched version: `2026.4.20`\n\n## Impact\n\nOutput from webhook-triggered isolated cron agent runs could be queued into the main session awareness stream without `trusted: false`. That made the event render as a trusted `System:` event instead of an untrusted system event.\n\nThis is a trust-labeling issue that can strengthen prompt-injection impact, but it does not directly bypass gateway auth, tool policy, or sandboxing. Severity is low.\n\n## Fix\n\nOpenClaw now preserves untrusted labels for isolated cron awareness events and forwards the trust flag through cron delivery helpers.\n\nFix commit:\n\n- `f61896b03cc7031f51106a04566831f4ac2a0bd7`\n\n## Release\n\nFixed in OpenClaw `2026.4.20`.",
"id": "GHSA-57r2-h2wj-g887",
"modified": "2026-05-19T15:56:28Z",
"published": "2026-04-25T23:47:31Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-57r2-h2wj-g887"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44999"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/f61896b03cc7031f51106a04566831f4ac2a0bd7"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-improper-trust-labeling-in-isolated-cron-awareness-events"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "OpenClaw: Isolated cron awareness events were recorded as trusted system events"
}
No mitigation information available for this CWE.
CAPEC-111: JSON Hijacking (aka JavaScript Hijacking)
An attacker targets a system that uses JavaScript Object Notation (JSON) as a transport mechanism between the client and the server (common in Web 2.0 systems using AJAX) to steal possibly confidential information transmitted from the server back to the client inside the JSON object by taking advantage of the loophole in the browser's Same Origin Policy that does not prohibit JavaScript from one website to be included and executed in the context of another website.
CAPEC-141: Cache Poisoning
An attacker exploits the functionality of cache technologies to cause specific data to be cached that aids the attackers' objectives. This describes any attack whereby an attacker places incorrect or harmful material in cache. The targeted cache can be an application's cache (e.g. a web browser cache) or a public cache (e.g. a DNS or ARP cache). Until the cache is refreshed, most applications or clients will treat the corrupted cache value as valid. This can lead to a wide range of exploits including redirecting web browsers towards sites that install malware and repeatedly incorrect calculations based on the incorrect value.
CAPEC-142: DNS Cache Poisoning
A domain name server translates a domain name (such as www.example.com) into an IP address that Internet hosts use to contact Internet resources. An adversary modifies a public DNS cache to cause certain names to resolve to incorrect addresses that the adversary specifies. The result is that client applications that rely upon the targeted cache for domain name resolution will be directed not to the actual address of the specified domain name but to some other address. Adversaries can use this to herd clients to sites that install malware on the victim's computer or to masquerade as part of a Pharming attack.
CAPEC-148: Content Spoofing
An adversary modifies content to make it contain something other than what the original content producer intended while keeping the apparent source of the content unchanged. The term content spoofing is most often used to describe modification of web pages hosted by a target to display the adversary's content instead of the owner's content. However, any content can be spoofed, including the content of email messages, file transfers, or the content of other network communication protocols. Content can be modified at the source (e.g. modifying the source file for a web page) or in transit (e.g. intercepting and modifying a message between the sender and recipient). Usually, the adversary will attempt to hide the fact that the content has been modified, but in some cases, such as with web site defacement, this is not necessary. Content Spoofing can lead to malware exposure, financial fraud (if the content governs financial transactions), privacy violations, and other unwanted outcomes.
CAPEC-218: Spoofing of UDDI/ebXML Messages
An attacker spoofs a UDDI, ebXML, or similar message in order to impersonate a service provider in an e-business transaction. UDDI, ebXML, and similar standards are used to identify businesses in e-business transactions. Among other things, they identify a particular participant, WSDL information for SOAP transactions, and supported communication protocols, including security protocols. By spoofing one of these messages an attacker could impersonate a legitimate business in a transaction or could manipulate the protocols used between a client and business. This could result in disclosure of sensitive information, loss of message integrity, or even financial fraud.
CAPEC-384: Application API Message Manipulation via Man-in-the-Middle
An attacker manipulates either egress or ingress data from a client within an application framework in order to change the content of messages. Performing this attack can allow the attacker to gain unauthorized privileges within the application, or conduct attacks such as phishing, deceptive strategies to spread malware, or traditional web-application attacks. The techniques require use of specialized software that allow the attacker to perform adversary-in-the-middle (CAPEC-94) communications between the web browser and the remote system. Despite the use of AiTH software, the attack is actually directed at the server, as the client is one node in a series of content brokers that pass information along to the application framework. Additionally, it is not true "Adversary-in-the-Middle" attack at the network layer, but an application-layer attack the root cause of which is the master applications trust in the integrity of code supplied by the client.
CAPEC-385: Transaction or Event Tampering via Application API Manipulation
An attacker hosts or joins an event or transaction within an application framework in order to change the content of messages or items that are being exchanged. Performing this attack allows the attacker to manipulate content in such a way as to produce messages or content that look authentic but may contain deceptive links, substitute one item or another, spoof an existing item and conduct a false exchange, or otherwise change the amounts or identity of what is being exchanged. The techniques require use of specialized software that allow the attacker to man-in-the-middle communications between the web browser and the remote system in order to change the content of various application elements. Often, items exchanged in game can be monetized via sales for coin, virtual dollars, etc. The purpose of the attack is for the attack to scam the victim by trapping the data packets involved the exchange and altering the integrity of the transfer process.
CAPEC-386: Application API Navigation Remapping
An attacker manipulates either egress or ingress data from a client within an application framework in order to change the destination and/or content of links/buttons displayed to a user within API messages. Performing this attack allows the attacker to manipulate content in such a way as to produce messages or content that looks authentic but contains links/buttons that point to an attacker controlled destination. Some applications make navigation remapping more difficult to detect because the actual HREF values of images, profile elements, and links/buttons are masked. One example would be to place an image in a user's photo gallery that when clicked upon redirected the user to an off-site location. Also, traditional web vulnerabilities (such as CSRF) can be constructed with remapped buttons or links. In some cases navigation remapping can be used for Phishing attacks or even means to artificially boost the page view, user site reputation, or click-fraud.
CAPEC-387: Navigation Remapping To Propagate Malicious Content
An adversary manipulates either egress or ingress data from a client within an application framework in order to change the content of messages and thereby circumvent the expected application logic.
CAPEC-388: Application API Button Hijacking
An attacker manipulates either egress or ingress data from a client within an application framework in order to change the destination and/or content of buttons displayed to a user within API messages. Performing this attack allows the attacker to manipulate content in such a way as to produce messages or content that looks authentic but contains buttons that point to an attacker controlled destination.
CAPEC-665: Exploitation of Thunderbolt Protection Flaws
An adversary leverages a firmware weakness within the Thunderbolt protocol, on a computing device to manipulate Thunderbolt controller firmware in order to exploit vulnerabilities in the implementation of authorization and verification schemes within Thunderbolt protection mechanisms. Upon gaining physical access to a target device, the adversary conducts high-level firmware manipulation of the victim Thunderbolt controller SPI (Serial Peripheral Interface) flash, through the use of a SPI Programing device and an external Thunderbolt device, typically as the target device is booting up. If successful, this allows the adversary to modify memory, subvert authentication mechanisms, spoof identities and content, and extract data and memory from the target device. Currently 7 major vulnerabilities exist within Thunderbolt protocol with 9 attack vectors as noted in the Execution Flow.
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.