CVE-2026-48615

What it actually does

This flaw can cause Node.js to include proxy authentication material in ERR_PROXY_TUNNEL error messages when an application uses a proxy URL containing embedded credentials, such as a username and password in the URL authority component. If a proxy tunnel connection fails, those credentials may be propagated through exceptions, application logs, crash reports, telemetry pipelines, diagnostics, or other error handlers. The primary impact is confidentiality loss of proxy credentials; integrity and availability are not directly affected by the flaw itself.

Why it matters to the business

Organizations that run Node.js applications through authenticated proxies could unintentionally leak proxy usernames, passwords, or tokens into logs and monitoring systems, increasing the risk of unauthorized proxy use, traffic interception, lateral movement, or broader credential reuse if those secrets are shared across systems. The issue affects supported Node.js 22, 24, and 26 release lines, so exposure may be widespread across applications, build systems, server-side services, and automation that rely on Node.js HTTP(S) proxy tunneling. It is not listed in CISA KEV, is not known to be used in ransomware campaigns, and currently has low EPSS, but the operational risk is meaningful because leaked credentials can persist in logs long after the original error occurred.

How an attack unfolds

An attacker does not need to exploit memory corruption or execute code against Node.js. The attacker’s goal is to cause or observe a failed proxy tunnel request in an application that uses proxy credentials embedded in a proxy URL. If the proxy connection fails, Node.js may generate an ERR_PROXY_TUNNEL error that includes the credential-bearing proxy URL. The application or surrounding platform may then record the error in logs, monitoring traces, crash dumps, CI/CD output, support bundles, or diagnostic exports. An attacker with access to any of those downstream error consumers can retrieve the exposed proxy credentials and use them to authenticate to the proxy or pivot to other systems if the credentials are reused.

How to fix it

Upgrade Node.js 22, 24, and 26 installations to a vendor-provided patched release as soon as fixed versions are available. No exact fixed versions were provided in the input, so teams should follow the official Node.js security release advisory for CVE-2026-48615 and standardize on patched builds across runtime images, developer workstations, CI/CD runners, containers, and server hosts. As an immediate mitigation, avoid embedding credentials directly in proxy URLs. Use safer secret handling mechanisms where supported, such as separate credential fields, secure secret stores, short-lived tokens, or runtime configuration that does not place secrets in URL strings. Configure application logging, exception handling, APM, tracing, and crash-reporting tools to redact proxy URLs, Authorization-like values, and URL authority components containing userinfo. Rotate any proxy credentials that may have appeared in logs or diagnostics, and purge or restrict access to historical log data containing exposed secrets where feasible.

How to confirm the fix worked

Confirm the deployed Node.js versions are within patched release levels once the Node.js project publishes fixed versions for the affected 22, 24, and 26 lines. Inventory applications and runtime images using Node.js and determine whether they configure proxies with credentials embedded in URLs. Review representative application error paths by triggering controlled proxy tunnel failures in a non-production environment and verifying that ERR_PROXY_TUNNEL errors do not expose usernames, passwords, tokens, or full credential-bearing proxy URLs. Validate that centralized logging, APM, crash-reporting, and CI/CD systems redact URL userinfo patterns such as scheme://user:password@host. Confirm that any previously exposed proxy credentials have been rotated and that retained logs are access-controlled or remediated according to retention and incident-response policy.

Typical attack path

1. Identify a Node.js application, service, job, or development tool that uses an authenticated HTTP or HTTPS proxy.
2. Cause or wait for a proxy tunnel failure, such as by inducing unreachable proxy behavior, malformed upstream connectivity, blocked destinations, or transient network errors.
3. Rely on Node.js error handling to emit an ERR_PROXY_TUNNEL message containing the proxy URL with embedded credentials.
4. Obtain access to application logs, CI/CD logs, observability traces, crash reports, diagnostics, support bundles, or centralized logging systems that captured the error.
5. Extract the proxy username, password, token, or other secret from the logged proxy URL.
6. Use the exposed credentials to authenticate to the proxy, monitor or route traffic, bypass network controls, or attempt credential reuse elsewhere.

How to detect it

Detection should focus on evidence that proxy credentials were exposed through error messages and whether those exposed secrets were later accessed or used. Review application logs, centralized SIEM data, APM traces, exception aggregators, crash reports, container logs, CI/CD job logs, support bundles, and diagnostic archives for ERR_PROXY_TUNNEL messages near proxy connection failures. Search for proxy URLs containing embedded user information, especially patterns like http://user:password@proxy or https://token@proxy. Correlate any findings with access logs for the logging platform to identify who or what read, exported, forwarded, or downloaded the affected log events. Review proxy authentication logs for unusual use of exposed accounts after the first observed leak, including new source IPs, unexpected destinations, atypical volumes, or access outside normal service schedules. Because there are no public exploit artifacts or malware-specific indicators provided, detection is primarily log-content and credential-use analysis rather than file or process-based compromise detection.

• ERR_PROXY_TUNNEL
• http://*@*
• https://*@*
• HTTP_PROXY=http://
• HTTPS_PROXY=http://
• HTTP_PROXY=https://
• HTTPS_PROXY=https://
• proxy tunnel
• Proxy-Authorization
• @proxy
• ERR_PROXY_TUNNEL

What your security team should do

• Inventory Node.js 22, 24, and 26 usage across services, containers, build pipelines, developer tooling, and automation.
• Prioritize applications that use authenticated HTTP or HTTPS proxies, especially those embedding credentials in proxy URLs.
• Upgrade to patched Node.js releases as soon as official fixed versions are available; until then, apply configuration and logging mitigations.
• Remove proxy credentials from URL strings where possible and migrate them to safer secret-management mechanisms.
• Search historical logs, traces, crash reports, CI/CD output, and diagnostic archives for ERR_PROXY_TUNNEL messages and credential-bearing proxy URLs.
• Rotate proxy credentials found in logs or used by applications that may have generated proxy tunnel errors.
• Add log redaction rules for URL userinfo, proxy URLs, and common proxy environment variables before data reaches centralized observability platforms.
• Restrict access to logging and diagnostic systems that may contain proxy secrets, and review whether exposed credentials were accessed after capture.
• Monitor Node.js security advisories for exact fixed versions and update base images and dependency-management policies accordingly.