CVE-2026-54673: builder-util-runtime Leaks Auth Headers on Redirect

Introduction

electron-updater doesn't talk to update servers directly — it delegates the actual HTTP work to builder-util-runtime, a shared module also used by electron-builder's app-builder-lib. That module's HTTP request executor is responsible for fetching update manifests (latest.yml, latest-mac.yml, etc.) and downloading installer artifacts, often from feeds that require an Authorization header or token to access private releases.

The problem fixed by CVE-2026-54673 sits in how that executor handled HTTP redirects. When an update server responds with a 301/302/307 and a Location header pointing somewhere else, a correctly behaving client should decide whether to keep sending credentials based on whether the redirect target is the same origin. builder-util-runtime's executor didn't make that distinction before 9.7.0: it followed the redirect and resent the same request headers — including any credential header set for the original request — to whatever host the Location pointed to.

For any application using electron-updater against a feed that requires authentication (private GitHub releases, a self-hosted update server behind a token, S3 buckets fronted by signed URLs that redirect, etc.), this meant the credential could leak to a third party if the update host ever redirected cross-origin — whether due to misconfiguration, a CDN migration, or a malicious actor positioned to influence the redirect chain.

Affected Versions

This finding was flagged against the project's own dependency manifest rather than a published first-party API. In practice, the fix is a dependency bump: builder-util-runtime moves from the vulnerable line (seen in the lockfile as 9.5.1 and a duplicate 9.3.1) to the patched 9.7.0 release.

The Vulnerability Explained

The core issue is a classic redirect-handling mistake: the HTTP executor inside builder-util-runtime treated "follow the redirect" and "resend the same headers" as the same decision. In concrete terms, before 9.7.0 the lockfile pinned two separate copies of the module:

"node_modules/builder-util-runtime": {
  "version": "9.5.1",

"node_modules/electron-updater/node_modules/builder-util-runtime": {
  "version": "9.3.1",

Both of those pre-9.7.0 releases carried the vulnerable redirect behavior in the shared executor that electron-updater calls to fetch update feeds and binaries. Because the executor is reused for both the manifest request and the artifact download, any credential header configured for a private feed — set once by the application when it configures its update URL — rode along on every retry and every redirect hop until the response finally resolved.

Attack scenario: an application configures electron-updater against a private feed, e.g. a GitHub Releases URL that requires a bearer token for a private repository, or an internal update server protected by a static API key sent as Authorization. If that server's response is ever redirected to a different host — a CDN endpoint, a storage bucket, or a host under an attacker's control via DNS/BGP interference or a compromised intermediate proxy — the client faithfully re-sends the Authorization header to the new destination. The operator of that destination (or anyone able to observe traffic to it) now has the application's update credential, which can often be reused to pull private release artifacts or probe other parts of the update infrastructure.

The real-world impact is proportional to how much trust is placed in that token: for apps gating pre-release builds behind a private feed, this is a straightforward credential-theft path triggered simply by the update check that already runs on every app launch.

The Fix

The fix is a dependency version bump plus a dependency-tree cleanup — no application source code changes:

-      "version": "9.5.1",
+      "version": "9.7.0",

and the removal of the stale duplicate electron-updater had vendored on its own:

-    "node_modules/electron-updater/node_modules/builder-util-runtime": {
-      "version": "9.3.1",

To make sure no other package in the tree could silently pull back in an older, vulnerable copy, package.json now pins the fix with explicit overrides:

"overrides": {
  "app-builder-lib": {
    "builder-util-runtime": "9.7.0"
  },
  "builder-util": {
    "builder-util-runtime": "9.7.0"
  },
  "builder-util-runtime": {
    "builder-util-runtime": "9.7.0"
  }
}

Each override entry matters for a different reason: app-builder-lib and builder-util both depend on builder-util-runtime independently and could otherwise resolve to their own historical pin; the builder-util-runtime self-override guarantees even nested resolutions converge on 9.7.0. Combined with deleting the duplicate 9.3.1 entry that electron-updater carried in its own subtree, this closes every path by which the vulnerable redirect-handling code could still end up in node_modules.

Key Takeaways

• A single shared HTTP executor (builder-util-runtime) is used by both electron-updater and electron-builder's app-builder-lib — a flaw there affects every consumer, not just the update-check path you're actively testing.
• Credential headers configured for an update feed are not automatically scoped to the original origin; redirect-following HTTP clients must explicitly decide to drop or keep them per-hop.
• Dependency duplication (electron-updater silently vendoring its own builder-util-runtime@9.3.1 alongside the top-level 9.5.1) can let a vulnerable version survive a top-level upgrade — check nested node_modules entries, not just the root dependency.
• npm overrides is the right tool to force convergence on a patched transitive dependency across multiple direct dependents at once.

How Orbis AppSec Detected This

• Source: the Authorization/credential header attached by the application when configuring electron-updater's update feed request
• Sink: builder-util-runtime's HTTP request executor re-issuing the request to the Location of a redirect response
• Missing control: no origin comparison between the original request host and the redirect target before resending credential headers
• CWE: unknown (not classified in this advisory)
• Fix: upgrade builder-util-runtime to 9.7.0 and enforce that version across the dependency tree via overrides

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 is a reminder that an update mechanism's HTTP plumbing deserves the same scrutiny as any other code path that handles credentials. electron-updater's reliance on builder-util-run