# electron-updater: Cross-origin redirect leaks `PRIVATE-TOKEN` and mixed-case `Authorization` credentials in `builder-util-runtime`

builder-util-runtime stripped only lowercase 'authorization' on cross-origin redirects, forwarding GitLab PRIVATE-TOKEN and mixed-case Authorization headers to attacker-controlled hosts.

- Payout: Research
- Severity: high
- Program: electron-builder
- Found by: Str1ckl4nd
- Disclosed: 2026-07-24
- CVE: CVE-2026-54673
- Write-up quality: 7/10
- Original: https://github.com/advisories/GHSA-p2f4-r6v6-j797
- Library page: https://bugbountylibrary.com/r/ghsa%3AGHSA-p2f4-r6v6-j797
- Tags: area:os domain:desktop domain:oss impact:data-leak kind:research platform:ghsa sev:high tech:nodejs technique:incomplete-fix technique:source-review vuln:info-disclosure vuln:secrets-leak

**Target:** HttpExecutor.prepareRedirectUrlOptions in builder-util-runtime (npm), used by electron-updater GitLabProvider
**Root cause:** The cross-origin redirect credential strip used a case-sensitive property check `headers?.authorization`, so any credential header not named exactly lowercase 'authorization' (e.g. PRIVATE-TOKEN, Authorization) was never deleted and got forwarded to the redirect destination.
**Steps:**
1. Configure electron-updater with an authenticated GitLab provider using a personal access token (non-Bearer), so `PRIVATE-TOKEN: <token>` is set on requests.
2. Trigger an update check; the updater fetches release metadata then requests a release asset URL.
3. The trusted GitLab origin returns a 3xx cross-origin redirect (e.g. to S3 object storage).
4. `HttpExecutor.prepareRedirectUrlOptions` runs; guard `headers?.authorization` is falsy for key `PRIVATE-TOKEN`, so no header is deleted.
5. The redirected request is issued with `PRIVATE-TOKEN: <token>` intact to the redirect destination.
**How found:** Code review of the redirect handler: noticed the strip guard used a single case-sensitive property access `headers?.authorization`, then cross-referenced GitLabProvider.setAuthHeaderForToken which sets `PRIVATE-TOKEN` for PATs and lowercase `authorization` only for Bearer tokens — revealing headers that bypass the guard.
**Exploitation:** An attacker who controls or can observe the cross-origin redirect destination (e.g. a malicious/compromised object-storage origin, or a redirect they can influence) receives the forwarded GitLab PAT or mixed-case Bearer token during a routine automatic update check, then uses it with whatever repo/API permissions it carries.
**Insight:** When auditing credential-stripping on redirects, enumerate every header name the codebase actually sets (grep for header assignment sites) rather than trusting the strip list; JS object property checks are case-sensitive, so any non-lowercase or differently-named credential header silently survives.