How credential header disclosure happens in electron-updater and how to fix it

Introduction

The package-lock.json file in this Electron application specified electron-updater version 6.3.0, a dependency used to handle automatic application updates. However, this version contained a critical flaw in how it processed HTTP redirects during update checks and downloads.

When the auto-updater made requests to fetch update manifests or binaries, it included authorization headers for authentication. The vulnerability (CVE-2026-54673) meant that if the update server responded with a redirect—whether intentional or through a man-in-the-middle attack—those credential headers would follow the redirect to the new destination without being stripped.

This matters significantly because Electron applications often handle sensitive operations, and in this codebase, OAuth tokens and API keys are already stored in the local filesystem. Having those same credentials potentially leak during routine update checks compounds the risk dramatically.

The Vulnerability Explained

What Happens During a Normal Update Check

When an Electron app using electron-updater checks for updates, it typically:

1. Sends an HTTP request to the configured update server
2. Includes authentication headers if the update feed requires authorization
3. Receives a response with update metadata or a redirect to the actual download location

The Redirect Problem

The vulnerable versions of builder-util-runtime (used internally by electron-updater) didn't distinguish between same-origin and cross-origin redirects when preserving HTTP headers. Here's the problematic flow:

Application → Update Server (with Authorization: Bearer <token>)
                    ↓
              302 Redirect to attacker.com
                    ↓
Application → attacker.com (with Authorization: Bearer <token>)  ← LEAKED!

Real Attack Scenario

Consider this attack against the affected application:

1. An attacker compromises the DNS or performs a MITM attack on the update check request
2. They respond with a 302 redirect to https://attacker-controlled-server.com/fake-update
3. The electron-updater follows the redirect, sending the original Authorization header
4. The attacker captures OAuth tokens or API keys from the Authorization header
5. These credentials can now be used to impersonate the user or access protected resources

The vulnerable dependency chain in package-lock.json was:

"electron-updater": "^6.3.0"

This version pulled in a vulnerable builder-util-runtime that didn't implement header stripping on redirects.

The Fix

The fix upgrades electron-updater to version 6.8.9, which includes a patched builder-util-runtime (9.7.0) that properly sanitizes headers during redirect handling.

Before (Vulnerable)

{
  "electron-updater": "^6.3.0"
}

After (Fixed)

{
  "electron-updater": "^6.8.9"
}

What Changed Internally

The updated builder-util-runtime 9.7.0 implements redirect handling that:

1. Detects cross-origin redirects: Compares the original request URL with the redirect target
2. Strips sensitive headers: Removes Authorization, Cookie, and other credential-bearing headers before following cross-origin redirects
3. Preserves functionality: Same-origin redirects continue to work normally with headers intact

The diff also shows cleanup of nested debug dependencies that were previously duplicated:

-    "node_modules/@electron/get/node_modules/debug": {
-      "version": "4.4.3",
-      ...
-    },
-    "node_modules/@electron/notarize/node_modules/debug": {
-      "version": "4.4.3",
-      ...
-    },

This consolidation is a side effect of the dependency resolution with the newer electron-updater version, resulting in a cleaner and more maintainable dependency tree.

Key Takeaways

• electron-updater versions before 6.8.9 leak credentials on HTTP redirects — any Electron app using auto-updates with authentication is potentially affected
• Dependency upgrades aren't just about features — this single version bump from 6.3.0 to 6.8.9 closes a critical credential disclosure vector
• Defense in depth matters — even with this fix, the plaintext credential storage in plugins/auth-oauth2/src/store.ts should be addressed using the available PBKDF2 encryption
• Trivy correctly identified this CVE in package-lock.json — automated scanning caught what manual review might miss
• The fix is minimal but impactful — only package.json and package-lock.json changed, demonstrating that security fixes don't always require code rewrites

How Orbis AppSec Detected This

• Source: HTTP requests made by electron-updater during update checks, containing Authorization headers with OAuth tokens
• Sink: builder-util-runtime's HTTP redirect handling, which forwarded headers to redirect destinations without sanitization
• Missing control: No header stripping logic for cross-origin redirects in builder-util-runtime versions prior to 9.7.0
• CWE: CWE-522 (Insufficiently Protected Credentials)
• Fix: Upgraded electron-updater from 6.3.0 to 6.8.9, which includes builder-util-runtime 9.7.0 with proper credential header handling

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 subtle flaw in HTTP redirect handling can expose sensitive credentials. The electron-updater library is widely used in Electron applications, making this vulnerability particularly impactful across the desktop application ecosystem.

The fix was straightforward—a dependency version bump—but the implications of leaving it unpatched could have been severe. OAuth tokens leaked during routine update checks could grant attackers persistent access to user accounts and protected resources.

For developers maintaining Electron applications: audit your electron-updater version today, enable automated dependency scanning, and consider implementing additional layers of protection like code signing and certificate pinning. Security is built through multiple overlapping defenses, not single points of protection.