Back to Blog
high SEVERITY5 min read

How Information Disclosure via Unstripped Credential Headers Happens in Electron Apps and How to Fix It

A high-severity vulnerability (CVE-2026-54673) in the builder-util-runtime package allowed sensitive credential headers to leak during HTTP redirects in Electron applications. The fix upgrades builder-util-runtime from version 9.5.1 to 9.7.0, which properly strips authentication headers before following redirects to prevent information disclosure.

O
By Orbis AppSec
Published August 22, 2026Reviewed August 22, 2026

Answer Summary

CVE-2026-54673 is an information disclosure vulnerability in electron-updater's builder-util-runtime package (JavaScript/Node.js) where credential headers are not stripped during HTTP redirects, potentially leaking authentication tokens to third-party servers. The fix involves upgrading builder-util-runtime to version 9.7.0, which properly sanitizes headers before following redirects. This is related to CWE-200 (Exposure of Sensitive Information).

Vulnerability at a Glance

cweCWE-200
fixUpgrade builder-util-runtime to version 9.7.0
riskSensitive authentication credentials leaked to unintended third-party servers
languageJavaScript/Node.js
root causeHTTP client fails to strip Authorization headers when following redirects
vulnerabilityInformation Disclosure via Credential Header Leakage

Introduction

In the dsa-desktop Electron application, a high-severity vulnerability was discovered in the dependency chain through builder-util-runtime. The apps/dsa-desktop/package-lock.json file pinned builder-util-runtime at version 9.5.1 (with a nested dependency at 9.2.4), which contained a critical flaw in how HTTP redirects were handled during the auto-update process.

This vulnerability, tracked as CVE-2026-54673, could have allowed attackers to intercept authentication credentials by manipulating update server redirects. For any Electron desktop application using electron-updater, this represents a significant risk—the very mechanism designed to keep your application secure could become the vector for credential theft.

The Vulnerability Explained

What Happens During an Electron Update?

When an Electron application checks for updates, it makes HTTP requests to update servers. These requests often include authentication headers—tokens that verify the application is authorized to download updates. The builder-util-runtime package handles these HTTP communications for electron-updater.

The Dangerous Redirect Behavior

The vulnerable versions of builder-util-runtime (prior to 9.7.0) failed to strip sensitive headers when following HTTP redirects. Here's what the vulnerable dependency chain looked like in package-lock.json:

"node_modules/electron-updater/node_modules/builder-util-runtime": {
  "version": "9.5.1",
  "resolved": "https://registry.npmjs.org/builder-util-runtime/-/builder-util-runtime-9.5.1.tgz",
  "integrity": "sha512-qt41tMfgHTllhResqM5DcnHyDIWNgzHvuY2jDcYP9iaGpkWxTUzV6GQjDeLnlR1/DtdlcsWQbA7sByMpmJFTLQ==",
  "license": "MIT",
  "dependencies": {
    "debug": "^4.3.4",
    "sax": "^1.2.4"
  }
}

Attack Scenario

Consider this attack flow specific to the dsa-desktop application:

  1. Initial Request: The Electron app sends an update check to https://updates.legitimate-server.com/check with an Authorization: Bearer <token> header
  2. Malicious Redirect: An attacker performs a man-in-the-middle attack or compromises the update server to return a 302 redirect to https://attacker-controlled-server.com/capture
  3. Credential Leak: The vulnerable builder-util-runtime follows the redirect with the Authorization header intact
  4. Token Theft: The attacker's server receives the valid authentication token

This is particularly dangerous because:
- Update mechanisms run with elevated privileges
- Users trust automatic updates
- The leaked tokens could provide access to private update channels or other authenticated resources

The Fix

Dependency Upgrade Strategy

The fix involves two key changes in the apps/dsa-desktop directory:

1. Removing the Nested Vulnerable Dependency

The entire vulnerable nested dependency block was removed from package-lock.json:

-    "node_modules/electron-updater/node_modules/builder-util-runtime": {
-      "version": "9.5.1",
-      "resolved": "https://registry.npmjs.org/builder-util-runtime/-/builder-util-runtime-9.5.1.tgz",
-      "integrity": "sha512-qt41tMfgHTllhResqM5DcnHyDIWNgzHvuY2jDcYP9iaGpkWxTUzV6GQjDeLnlR1/DtdlcsWQbA7sByMpmJFTLQ==",
-      "license": "MIT",
-      "dependencies": {
-        "debug": "^4.3.4",
-        "sax": "^1.2.4"
-      },
-      "engines": {
-        "node": ">=12.0.0"
-      }
-    },

2. Upgrading the Root Dependency

The root builder-util-runtime was upgraded from 9.2.4 to 9.7.0:

     "node_modules/builder-util-runtime": {
-      "version": "9.2.4",
-      "resolved": "https://registry.npmjs.org/builder-util-runtime/-/builder-util-runtime-9.2.4.tgz",
-      "integrity": "sha512-upp+biKpN/XZMLim7aguUyW8s0FUpDvOtK6sbanMFDAMBzpHDqdhgVYm6zc9HJ6nWo7u2Lxk60i2M6Jd3aiNrA==",
-      "dev": true,
+      "version": "9.7.0",
+      "resolved": "https://registry.npmjs.org/builder-util-runtime/-/builder-util-runtime-9.7.0.tgz",
+      "integrity": "sha512-g/kR520giAFYkSXTzcmF3kqQq7wi8F6N6SzeDgZrqTBN+VHdmgWOyTdD1yD7AATDId/yXLvuP34CxW46/BwCdw==",
       "license": "MIT",

3. Adding an Override in package.json

To ensure all nested dependencies use the patched version, an override was added:

+  "overrides": {
+    "builder-util-runtime": "9.7.0"
+  }

Why This Works

The overrides field in package.json is a powerful npm feature that forces all instances of a dependency—regardless of where they appear in the dependency tree—to use the specified version. This ensures that even if electron-updater requests version 9.5.1, npm will resolve it to 9.7.0 instead.

Version 9.7.0 of builder-util-runtime properly implements header stripping during redirects, removing sensitive headers like Authorization, Cookie, and Proxy-Authorization before following redirects to different origins.

Prevention & Best Practices

1. Regular Dependency Auditing

Run security audits regularly:

npm audit
# or
npx trivy fs --scanners vuln ./

2. Use Dependency Override Patterns

When a vulnerability exists in a transitive dependency, use overrides to force the patched version:

{
  "overrides": {
    "vulnerable-package": "^patched.version"
  }
}

3. Pin Critical Security Dependencies

For security-critical packages like those handling HTTP communications, consider pinning exact versions and reviewing changelogs before updates.

4. Implement Defense in Depth

Even with patched dependencies:
- Use short-lived tokens where possible
- Implement token rotation
- Monitor for unusual update server behavior
- Consider certificate pinning for update endpoints

5. Enable Dependabot or Similar Tools

Automated dependency update tools can catch these vulnerabilities early, often before they're widely exploited.

Key Takeaways

  • Nested dependencies can hide vulnerabilities: The vulnerable builder-util-runtime@9.5.1 was nested under electron-updater, making it easy to miss in manual reviews
  • npm overrides are essential for transitive dependency fixes: Without the "overrides" field in package.json, electron-updater would continue using the vulnerable version
  • Auto-update mechanisms are high-value targets: Attackers specifically target update systems because they run with elevated privileges and user trust
  • Header leakage during redirects is a common HTTP client flaw: Always verify that your HTTP client properly sanitizes headers when following cross-origin redirects
  • The dsa-desktop application's update process is now protected: Users receiving updates will no longer risk credential exposure through redirect attacks

How Orbis AppSec Detected This

  • Source: HTTP redirect response (3xx status code) from update server
  • Sink: HTTP client request to redirect target URL in builder-util-runtime network handling code
  • Missing control: Header sanitization logic to strip Authorization and other sensitive headers before following cross-origin redirects
  • CWE: CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor)
  • Fix: Upgraded builder-util-runtime from 9.5.1 to 9.7.0 via npm overrides, which implements proper header stripping during redirects

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-2026-54673 demonstrates how a seemingly minor implementation detail—failing to strip headers during HTTP redirects—can create a significant security vulnerability. For Electron applications relying on auto-update functionality, this flaw could have exposed authentication credentials to malicious actors.

The fix was straightforward: upgrade builder-util-runtime to version 9.7.0 and use npm's override mechanism to ensure consistent versioning across the dependency tree. This pattern of using overrides for transitive dependency fixes is a valuable technique for any Node.js project.

Remember: your application's security is only as strong as its weakest dependency. Regular auditing, automated scanning, and prompt patching are essential practices for maintaining secure software.

References

Frequently Asked Questions

What is credential header leakage during HTTP redirects?

When an HTTP client follows a redirect (3xx response) to a different domain while preserving sensitive headers like Authorization, those credentials get sent to the redirect target, potentially exposing them to untrusted servers.

How do you prevent credential header leakage in Node.js/Electron?

Use HTTP clients that automatically strip sensitive headers (Authorization, Cookie, etc.) when following cross-origin redirects, or upgrade to patched versions of libraries like builder-util-runtime 9.7.0 that implement this behavior.

What CWE is credential header leakage?

CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) covers this vulnerability, as credentials intended for one server are inadvertently disclosed to another.

Is using HTTPS enough to prevent credential header leakage?

No, HTTPS only encrypts data in transit. If your client follows a redirect to a malicious server while preserving Authorization headers, those credentials will be encrypted but still delivered to the attacker's server.

Can static analysis detect credential header leakage?

Yes, static analysis tools like Trivy can detect vulnerable dependency versions. Dynamic analysis and security scanners can also identify improper redirect handling behavior in HTTP clients.

View the Security Fix

Check out the pull request that fixed this vulnerability

View PR #2253

Related Articles

critical

How Command Injection via Unescaped Line Terminators Happens in Node.js and How to Fix It

A critical command injection vulnerability (CVE-2026-9277) was discovered in the shell-quote npm package version 1.8.3, where unescaped line terminators could allow attackers to execute arbitrary code. This fix upgrades shell-quote to version 1.9.0 using npm overrides to ensure all instances in the dependency tree are patched, eliminating the attack vector across the entire application.

critical

How Distributed Lock Takeover Happens in Node.js and How to Fix It

A critical vulnerability in `redis-lock/server.mjs` allowed any authenticated client to release another client's lock by guessing predictable holder identifiers like process IDs or hostnames. The fix implements cryptographically random `lockId` values that are minted on lock acquisition and validated on release, eliminating the exploit primitive entirely.

high

How Denial of Service via Infinite Loop happens in JavaScript (nanoid) and how to fix it

A high-severity denial of service vulnerability (CVE-2026-67213) was discovered in nanoid versions before 5.1.6 and 3.3.18, where the `customAlphabet` function could enter an infinite loop during random ID generation. The fix upgrades the transitive nanoid dependency from 3.3.16 to 3.3.18 using pnpm overrides, ensuring the vulnerable code path is eliminated from the entire dependency tree including PostCSS.

high

How Command Injection happens in PHP and how to fix it

A high-severity command injection vulnerability was discovered in `lib/Controller/Helper.php` where the `corruptline()` method used `exec()` to run sed and awk commands with user-controlled input. The fix replaced all shell command execution with native PHP file operations using `SplFileObject`, eliminating the command injection attack surface entirely.

high

How Missing CSRF Middleware happens in Express.js and how to fix it

A high-severity CSRF vulnerability was discovered in `libProxy.js` of an Express.js application — the app had no CSRF middleware protecting its state-changing routes, leaving them open to cross-site request forgery attacks. The fix introduces a `csrf` token library, a `/csrf-token` endpoint to issue tokens, and a middleware that validates `x-csrf-token` headers or `_csrf` body fields on all non-safe HTTP methods. This proactive hardening removes an exploit primitive that could be chained with ot

high

How Regular Expression Denial of Service happens in JavaScript and how to fix it

CVE-2026-33671 is a Regular Expression Denial of Service (ReDoS) vulnerability in the picomatch glob-matching library, triggered by specially crafted extglob patterns that cause catastrophic regex backtracking. The fix upgrades picomatch to version 4.0.4 (with overrides pinning all transitive copies) in the client's dependency tree, eliminating the vulnerable regex evaluation path. Left unpatched, any code path that passes user-influenced glob patterns to picomatch could be weaponized to stall a