gray-matter EUVD-2026-84241

Exploitation requires that the application parses attacker-controlled input with gray-matter AND that the JavaScript/js engine is reachable - which it is by default, because gray-matter ships a js/javascript engine (lib/engines.js) using eval() and honors an inline language declaration in the front-matter fence (e.g. '---js' or '---javascript'). The concrete prerequisite is therefore: untrusted markdown/front-matter content flows into gray-matter's parse call. Limiting factors: the attacker must be able to supply the document content; applications that only parse trusted/first-party content, or that override the engines option to remove the JavaScript engine, are not exploitable. No authentication or user interaction is required by the library itself (per PR:N/UI:N), but the effective attack surface is gated by whether the host application exposes gray-matter parsing to untrusted input.

This is a genuine high-severity code-execution flaw whose real-world priority hinges entirely on integration context. The vendor CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N, C:H/I:H/A:H = 9.8) is defensible ONLY for applications that pass attacker-controlled documents to gray-matter, because the library's default engine set includes a JavaScript engine (lib/engines.js) that calls eval(), and gray-matter lets the document itself declare its front-matter language inline (e.g. a '---js'/'---javascript' fence). An attacker who controls the parsed content therefore needs no configuration change and no authentication, matching PR:N/UI:N. However, the signals conflict on urgency: EPSS is very low (0.17%, 7th percentile), there is no CISA KEV listing, and no formal POC=YES flag is present - so despite the 9.8 score this is NOT evidence of widespread active exploitation. Note the CWE-95 (eval injection) is well-documented in the referenced GitHub issues (#182, #131, #112) and a security blog, meaning the technique is public and trivially reproducible even if no packaged exploit is tracked. The dominant caveat: 'All versions' with no fix and a CPE of 'n/a:n/a' means affected-product metadata is effectively absent - the flaw is a long-standing by-design behavior of the library, so risk is a function of how each downstream app uses it rather than a discrete patchable version boundary. Bottom line: treat as high priority ONLY where untrusted markdown/front-matter is parsed; otherwise it is a latent high-CVSS issue with low observed exploitation.

An application (e.g. a CMS, static-site builder, or markdown-processing API) uses gray-matter to parse user-submitted markdown. The attacker submits a document whose front-matter fence declares the JavaScript language (e.g. '---js') with a payload; gray-matter routes it to the eval()-based engine and runs the attacker's code in the Node.js process. The technique is publicly documented in the referenced GitHub issues and blog, but no packaged/weaponized exploit is tracked in the provided data.