Came across something in pnpm-lock.yaml around line 1 that looked worth flagging.
HIGH severity — CVE-2025-27152 in axios 0.24.0 (detected in pnpm-lock.yaml). Axios fails to reject absolute URLs when a baseURL is configured: if code calls axios.get('https://host/path') instead of a protocol-relative or relative path, axios ignores baseURL and sends the request directly to the absolute URL. Any credentials tied to the intended target (Authorization headers, cookies, API keys attached via interceptors) may then be delivered to an attacker-controlled host, and servers can be tricked into making arbitrary outbound requests (SSRF) to internal services (cloud metadata endpoints, internal APIs). This affects both Node.js server-side and browser client-side usage. Risk is HIGH, especially wherever URL strings are built from user input or external data. Remediation: upgrade axios to >= 1.8.2 (or >= 0.30.0 to stay on the 0.x line), which enforces baseURL handling for absolute URLs. Because the finding is in pnpm-lock.yaml, the lockfile must be regenerated after updating the dependency manifest. As defense-in-depth, also validate/allowlist any externally influenced URLs and prefer relative paths so baseURL is always honored.
Something like this might fix it:
--- a/package.json
+++ b/package.json
@@
"dependencies": {
- "axios": "^0.24.0"
+ "axios": "^1.8.2"
}
# Regenerate the lockfile so pnpm-lock.yaml reflects the patched version:
$ pnpm install
# --- Alternative: if axios is only a transitive dependency and cannot be bumped
# --- directly, force it via a pnpm override in package.json:
@@
}
+ ,"pnpm": {
+ "overrides": {
+ "axios": "^1.8.2"
+ }
+ }
}
# --- If you must remain on the 0.x release line, use the backported fix instead:
- "axios": "^0.24.0"
+ "axios": "^0.30.0"
# --- Defense-in-depth: never pass fully attacker-controlled absolute URLs to axios.
# --- Use relative paths so baseURL is applied:
- const res = await axios.get(userSuppliedUrl);
+ if (!userSuppliedUrl.startsWith('/')) {
+ throw new Error('Only relative paths against the configured baseURL are allowed');
+ }
+ const res = await axios.get(userSuppliedUrl);
For reference: rule CVE-2025-27152. Rated high.
I may be wrong about this one — closing it costs you nothing if so.
Found with automated scanning (RedGem) and reviewed before opening. If it is not useful, closing it is completely fine.
Came across something in
pnpm-lock.yamlaround line 1 that looked worth flagging.HIGH severity — CVE-2025-27152 in axios 0.24.0 (detected in pnpm-lock.yaml). Axios fails to reject absolute URLs when a baseURL is configured: if code calls axios.get('https://host/path') instead of a protocol-relative or relative path, axios ignores baseURL and sends the request directly to the absolute URL. Any credentials tied to the intended target (Authorization headers, cookies, API keys attached via interceptors) may then be delivered to an attacker-controlled host, and servers can be tricked into making arbitrary outbound requests (SSRF) to internal services (cloud metadata endpoints, internal APIs). This affects both Node.js server-side and browser client-side usage. Risk is HIGH, especially wherever URL strings are built from user input or external data. Remediation: upgrade axios to >= 1.8.2 (or >= 0.30.0 to stay on the 0.x line), which enforces baseURL handling for absolute URLs. Because the finding is in pnpm-lock.yaml, the lockfile must be regenerated after updating the dependency manifest. As defense-in-depth, also validate/allowlist any externally influenced URLs and prefer relative paths so baseURL is always honored.
Something like this might fix it:
For reference: rule
CVE-2025-27152. Rated high.I may be wrong about this one — closing it costs you nothing if so.
Found with automated scanning (RedGem) and reviewed before opening. If it is not useful, closing it is completely fine.