All the vulnerabilities related to the version 2.5.10 of the package
Hostname spoofing via backslashes in URL
If using affected versions to determine a URL's hostname, the hostname can be spoofed by using a backslash (\
) character followed by an at (@
) character. If the hostname is used in security decisions, the decision may be incorrect.
Depending on library usage and attacker intent, impacts may include allow/block list bypasses, SSRF attacks, open redirects, or other undesired behavior.
Example URL: https://expected-example.com\@observed-example.com
Escaped string: https://expected-example.com\\@observed-example.com
(JavaScript strings must escape backslash)
Affected versions incorrectly return observed-example.com
. Patched versions correctly return expected-example.com
. Patched versions match the behavior of other parsers which implement the WHATWG URL specification, including web browsers and Node's built-in URL class.
Version 1.19.4 is patched against all known payload variants. Version 1.19.3 has a partial patch but is still vulnerable to a payload variant.
https://github.com/medialize/URI.js/releases/tag/v1.19.4 (complete fix for this bypass) https://github.com/medialize/URI.js/releases/tag/v1.19.3 (partial fix for this bypass) PR #233 (initial fix for backslash handling)
If you have any questions or comments about this advisory, open an issue in https://github.com/medialize/URI.js
URIjs Hostname spoofing via backslashes in URL
If using affected versions to determine a URL's hostname, the hostname can be spoofed by using a backslash (\
) character as part of the scheme delimiter, e.g. scheme:/\hostname
. If the hostname is used in security decisions, the decision may be incorrect.
Depending on library usage and attacker intent, impacts may include allow/block list bypasses, SSRF attacks, open redirects, or other undesired behavior.
Example URL: https:/\expected-example.com/path
Escaped string: https:/\\expected-example.com/path
(JavaScript strings must escape backslash)
Affected versions incorrectly return no hostname. Patched versions correctly return expected-example.com
. Patched versions match the behavior of other parsers which implement the WHATWG URL specification, including web browsers and Node's built-in URL class.
Version 1.19.6 is patched against all known payload variants.
https://github.com/medialize/URI.js/releases/tag/v1.19.6 (fix for this particular bypass) https://github.com/medialize/URI.js/releases/tag/v1.19.4 (fix for related bypass) https://github.com/medialize/URI.js/releases/tag/v1.19.3 (fix for related bypass) PR #233 (initial fix for backslash handling)
If you have any questions or comments about this advisory, open an issue in https://github.com/medialize/URI.js
Yaniv Nizry from the CxSCA AppSec team at Checkmarx
URIjs Vulnerable to Hostname spoofing via backslashes in URL
If using affected versions to determine a URL's hostname, the hostname can be spoofed by using a combination of backslash (\
) and slash (/
) characters as part of the scheme delimiter, e.g. scheme:/\/\/\hostname
. If the hostname is used in security decisions, the decision may be incorrect.
Depending on library usage and attacker intent, impacts may include allow/block list bypasses, SSRF attacks, open redirects, or other undesired behavior.
Example URL: https:/\/\/\expected-example.com/path
Escaped string: https:/\\/\\/\\expected-example.com/path
(JavaScript strings must escape backslash)
Affected versions incorrectly return no hostname. Patched versions correctly return expected-example.com
. Patched versions match the behavior of other parsers which implement the WHATWG URL specification, including web browsers and Node's built-in URL class.
Version 1.19.7 is patched against all known payload variants.
https://github.com/medialize/URI.js/releases/tag/v1.19.7 (fix for this particular bypass) https://github.com/medialize/URI.js/releases/tag/v1.19.6 (fix for related bypass) https://github.com/medialize/URI.js/releases/tag/v1.19.4 (fix for related bypass) https://github.com/medialize/URI.js/releases/tag/v1.19.3 (fix for related bypass) PR #233 (initial fix for backslash handling)
If you have any questions or comments about this advisory, open an issue in https://github.com/medialize/URI.js
ready-research via https://huntr.dev/
Authorization Bypass Through User-Controlled Key in urijs
Attacker can use case-insensitive protocol schemes like HTTP, htTP, HTtp etc. in order to bypass the patch for CVE-2021-3647.
Leading white space bypasses protocol validation
Whitespace characters are not removed from the beginning of the protocol, so URLs are not parsed properly and protocol validation mechanisms may fail.
Patched in 1.19.9
Remove leading whitespace from values before passing them to URI.parse (e.g. via .href(value)
or new URI(value)
), e.g. by using
function remove_whitespace(url){
const whitespace = /^[\x00-\x20\u00a0\u1680\u2000-\u200a\u2028\u2029\u202f\u205f\u3000\ufeff]+/;
url = url.replace(whitespace, '')
return url
}
If you have any questions or comments about this advisory:
Open Redirect in urijs
urijs prior to version 1.19.10 is vulnerable to open redirect. This is the result of a bypass for the fix to CVE-2022-0613.
Incorrect protocol extraction via \r, \n and \t characters
\r, \n and \t characters in user-input URLs can potentially lead to incorrect protocol extraction when using npm package urijs prior to version 1.19.11.
This can lead to XSS when the module is used to prevent passing in malicious javascript: links into HTML or Javascript (see following example):
const parse = require('urijs')
const express = require('express')
const app = express()
const port = 3000
input = "ja\r\nvascript:alert(1)"
url = parse(input)
console.log(url)
app.get('/', (req, res) => {
if (url.protocol !== "javascript:") {res.send("<iframe src=\'" + input + "\'>CLICK ME!</iframe>")}
})
app.listen(port, () => {
console.log(`Example app listening on port ${port}`)
})
URL Confusion When Scheme Not Supplied in medialize/uri.js
Medialize is a Javascript URL mutation library. When parsing a URL without a scheme and with excessive slashes, like ///www.example.com, URI.js will parse the hostname as null and the path as /www.example.com. Such behaviour is different from that exhibited by browsers, which will parse ///www.example.com as http://www.example.com instead. For example, the following will cause a redirect to http://www.example.com: A fix was released in version 1.19.11.
tmp allows arbitrary temporary file / directory write via symbolic link dir
parameter
tmp@0.2.3
is vulnerable to an Arbitrary temporary file / directory write via symbolic link dir
parameter.
According to the documentation there are some conditions that must be held:
// https://github.com/raszi/node-tmp/blob/v0.2.3/README.md?plain=1#L41-L50
Other breaking changes, i.e.
- template must be relative to tmpdir
- name must be relative to tmpdir
- dir option must be relative to tmpdir //<-- this assumption can be bypassed using symlinks
are still in place.
In order to override the system's tmpdir, you will have to use the newly
introduced tmpdir option.
// https://github.com/raszi/node-tmp/blob/v0.2.3/README.md?plain=1#L375
* `dir`: the optional temporary directory that must be relative to the system's default temporary directory.
absolute paths are fine as long as they point to a location under the system's default temporary directory.
Any directories along the so specified path must exist, otherwise a ENOENT error will be thrown upon access,
as tmp will not check the availability of the path, nor will it establish the requested path for you.
Related issue: https://github.com/raszi/node-tmp/issues/207.
The issue occurs because _resolvePath
does not properly handle symbolic link when resolving paths:
// https://github.com/raszi/node-tmp/blob/v0.2.3/lib/tmp.js#L573-L579
function _resolvePath(name, tmpDir) {
if (name.startsWith(tmpDir)) {
return path.resolve(name);
} else {
return path.resolve(path.join(tmpDir, name));
}
}
If the dir
parameter points to a symlink that resolves to a folder outside the tmpDir
, it's possible to bypass the _assertIsRelative
check used in _assertAndSanitizeOptions
:
// https://github.com/raszi/node-tmp/blob/v0.2.3/lib/tmp.js#L590-L609
function _assertIsRelative(name, option, tmpDir) {
if (option === 'name') {
// assert that name is not absolute and does not contain a path
if (path.isAbsolute(name))
throw new Error(`${option} option must not contain an absolute path, found "${name}".`);
// must not fail on valid .<name> or ..<name> or similar such constructs
let basename = path.basename(name);
if (basename === '..' || basename === '.' || basename !== name)
throw new Error(`${option} option must not contain a path, found "${name}".`);
}
else { // if (option === 'dir' || option === 'template') {
// assert that dir or template are relative to tmpDir
if (path.isAbsolute(name) && !name.startsWith(tmpDir)) {
throw new Error(`${option} option must be relative to "${tmpDir}", found "${name}".`);
}
let resolvedPath = _resolvePath(name, tmpDir); //<---
if (!resolvedPath.startsWith(tmpDir))
throw new Error(`${option} option must be relative to "${tmpDir}", found "${resolvedPath}".`);
}
}
The following PoC demonstrates how writing a tmp file on a folder outside the tmpDir
is possible.
Tested on a Linux machine.
tmpDir
that points to a directory outside of itmkdir $HOME/mydir1
ln -s $HOME/mydir1 ${TMPDIR:-/tmp}/evil-dir
ls -lha $HOME/mydir1 | grep "tmp-"
node main.js
File: /tmp/evil-dir/tmp-26821-Vw87SLRaBIlf
test 1: ENOENT: no such file or directory, open '/tmp/mydir1/tmp-[random-id]'
test 2: dir option must be relative to "/tmp", found "/foo".
test 3: dir option must be relative to "/tmp", found "/home/user/mydir1".
$HOME/mydir1
(outside the tmpDir
):ls -lha $HOME/mydir1 | grep "tmp-"
-rw------- 1 user user 0 Apr X XX:XX tmp-[random-id]
main.js
// npm i tmp@0.2.3
const tmp = require('tmp');
const tmpobj = tmp.fileSync({ 'dir': 'evil-dir'});
console.log('File: ', tmpobj.name);
try {
tmp.fileSync({ 'dir': 'mydir1'});
} catch (err) {
console.log('test 1:', err.message)
}
try {
tmp.fileSync({ 'dir': '/foo'});
} catch (err) {
console.log('test 2:', err.message)
}
try {
const fs = require('node:fs');
const resolved = fs.realpathSync('/tmp/evil-dir');
tmp.fileSync({ 'dir': resolved});
} catch (err) {
console.log('test 3:', err.message)
}
A Potential fix could be to call fs.realpathSync
(or similar) that resolves also symbolic links.
function _resolvePath(name, tmpDir) {
let resolvedPath;
if (name.startsWith(tmpDir)) {
resolvedPath = path.resolve(name);
} else {
resolvedPath = path.resolve(path.join(tmpDir, name));
}
return fs.realpathSync(resolvedPath);
}
Arbitrary temporary file / directory write via symlink
Prototype pollution in Plist before 3.0.5 can cause denial of service
Prototype pollution vulnerability via .parse()
in Plist allows attackers to cause a Denial of Service (DoS) and may lead to remote code execution.
Misinterpretation of malicious XML input
xmldom versions 0.4.0 and older do not correctly preserve system identifiers, FPIs or namespaces when repeatedly parsing and serializing maliciously crafted documents.
This may lead to unexpected syntactic changes during XML processing in some downstream applications.
Update to 0.5.0 (once it is released)
Downstream applications can validate the input and reject the maliciously crafted documents.
Similar to this one reported on the Go standard library:
If you have any questions or comments about this advisory:
xmldom/xmldom
npm owner ls xmldom
Misinterpretation of malicious XML input
xmldom versions 0.6.0 and older do not correctly escape special characters when serializing elements removed from their ancestor. This may lead to unexpected syntactic changes during XML processing in some downstream applications.
Update to one of the fixed versions of @xmldom/xmldom
(>=0.7.0
)
See issue #271 for the status of publishing xmldom
to npm or join #270 for Q&A/discussion until it's resolved.
Downstream applications can validate the input and reject the maliciously crafted documents.
Similar to this one reported on the Go standard library:
If you have any questions or comments about this advisory:
xmldom/xmldom
npm owner ls @xmldom/xmldom
xmldom allows multiple root nodes in a DOM
xmldom parses XML that is not well-formed because it contains multiple top level elements, and adds all root nodes to the childNodes
collection of the Document
, without reporting any error or throwing.
This breaks the assumption that there is only a single root node in the tree, which led to https://nvd.nist.gov/vuln/detail/CVE-2022-39299 and is a potential issue for dependents.
Update to @xmldom/xmldom@~0.7.7
, @xmldom/xmldom@~0.8.4
(dist-tag latest
) or @xmldom/xmldom@>=0.9.0-beta.4
(dist-tag next
).
One of the following approaches might help, depending on your use case:
documentElement
.childNode
.If you have any questions or comments about this advisory:
Got allows a redirect to a UNIX socket
The got package before 11.8.5 and 12.1.0 for Node.js allows a redirect to a UNIX socket.
http-cache-semantics vulnerable to Regular Expression Denial of Service
http-cache semantics contains an Inefficient Regular Expression Complexity , leading to Denial of Service. This affects versions of the package http-cache-semantics before 4.1.1. The issue can be exploited via malicious request header values sent to a server, when that server reads the cache policy from the request using this library.