Intermittent 403 Forbidden Errors during Electron App Auto-Updates from GitHub Releases

[myunghoNA]

Select Topic Area

Question

Body

I am experiencing an intermittent 403 Forbidden error when my Electron application attempts to auto-update by downloading assets from GitHub Releases. This issue has become noticeable specifically since approximately July 8th, 2025, and mostly occurs during the morning hours (KST), although it can be intermittent at other times too. Previously, the auto-update process worked reliably.

Details of the Issue:

Error Code: 403 Forbidden (AuthenticationFailed)
Affected URL: Downloads from release-assets.githubusercontent.com are failing. The error message explicitly mentions "Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature."

Error Heders:
Headers:{
"server": "Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0",
"x-ms-request-id": "14f0e3ba-301e-000e-2d31-f6c8e5000000",
"accept-ranges": "bytes",
"via": "1.1 varnish, 1.1 varnish",
"date": "Wed, 16 Jul 2025 09:07:53 GMT",
"x-served-by": "cache-iad-kiad7000170-IAD, cache-icn1450066-ICN",
"x-cache": "MISS, MISS",
"x-cache-hits": "0, 0",
"x-timer": "S1752656874.698756,VS0,VE181",
"content-disposition": "attachment; filename=latest.yml",
"content-type": "application/octet-stream",
"content-length": "321"
}

1.electron-updater Version: Confirmed using the latest version of electron-updater.
2.Authentication: Verified GH_TOKEN environment variable is correctly set and has repo scope for private repositories (if applicable).
3.Network: Tested across different network environments; issue persists intermittently. We've considered firewalls/proxies but logs indicate the 403 comes from GitHub's CDN.
4.Retry Logic: Implemented an exponential backoff retry mechanism, but the error still occasionally manifests.
5.Logging: Enabled debug level logging for electron-updater and can provide detailed logs showing the 403 error, timestamps, and the specific download URLs.
Given that the issue began around July 8th, 2025, and consistently involves AuthenticationFailed for release-assets.githubusercontent.com URLs, it appears to be related to the temporary access tokens (JWT/SAS) generated by GitHub/Azure Blob Storage, rather than an issue with my application's code.

Could you please investigate if there were any recent changes (around July 8th, 2025) to the GitHub Releases infrastructure, CDN, or token generation/validation policies that might explain this intermittent behavior? Any guidance or insight would be greatly appreciated.

Thank you for your time and assistance.

Best regards,

[ebndev]

Hi @Piyushh10, thanks for participating in GitHub Discussions!

Please note: we’ve clarified our stance on using generative AI tools like ChatGPT within our Community via this announcement. Please review the guidelines to ensure your post meets them as failure to adhere to those rules can result in action taken by our moderator team.

You can read our updated Code of Conduct and the announcement for more details.

Please feel encouraged to continue engaging in Discussions as your authentic self though. We appreciate you being a part of the Community 🌟

[amanmah0778]

@Piyushh10 Would you be having any link to any doc/article that talks about this change? It would be greatly helpful. How did you get to know about this? Thanks!

[IdrisMMG]

I recently started experiencing this same issue. Can't seem to figure out what is the cause. My app was always working fine, until recently.

Has anyone came up with a fix / solution?

[eldanet]

The same happened to me, trying to check for new releases with electron-update. The last succesfull request was done on 10th of July.

Headers:{
"accept-ranges": "bytes",
"content-disposition": "attachment; filename=latest.yml",
"content-length": "321",
"content-type": "application/octet-stream",
"date": "Wed, 16 Jul 2025 17:36:56 GMT",
"server": "Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0",
"via": "1.1 varnish, 1.1 varnish",
"x-cache": "MISS, MISS",
"x-cache-hits": "0, 0",
"x-ms-request-id": "6f184009-001e-0067-7a78-f6f1a9000000",
"x-served-by": "cache-iad-kjyo7100148-IAD, cache-mxp6922-MXP",
"x-timer": "S1752687417.659531,VS0,VE94"
}

Thanks for support.

[yonizabari]

I’m seeing the same issue when trying to download release assets using curl. Out of nowhere, I started getting this error:
Connecting to release-assets.githubusercontent.com (release-assets.githubusercontent.com)|185.199.110.133|:443... connected. HTTP request sent, awaiting response... 403 Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.
No changes on my side (scripts, tokens, or environment).

[hggutvik]

Same here, downloading assets from GitHub Releases results in 403s more and more frequently.

In our case we have an Azure Release Pipeline setup with Azure/kubelogin as one of the artifacts. The Download GitHub Release v0 task sends requests to https://api.github.com/repos/azure/kubelogin/releases/.../assets attempting to download all the files.
July 10th we started seeing intermittent retries on some of the file downloads, presumably because of 403s. The problem seems to have worsened, with retries getting more and more frequent. Since July 14th we haven't been able to run the pipeline successfully, as the pipeline task consistently fails with ##[error]Error: Failed request: (statusCode) 403 after 4 retries on one or more file downloads.

[hggutvik]

Working as normal here now

[nogitting]

I’m seeing the same issue when trying to download release assets using curl.

You should not run into it using cURL, unless you are using 6.0 <= v <= 7.57.0 or explicitly giving it the permission to pass that header.

[developer-gulam]

We're also experiencing this issue in our Electron app during auto-updates.

Here's the relevant error we're seeing:

 HttpError: 403 method: GET url: https://release-assets.githubusercontent.com/github-production-release-asset/... Data: <?xml version="1.0" encoding="utf-8"?> <Error> <Code>AuthenticationFailed</Code> <Message> Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature. RequestId: c76df6fe-601e-004e-3a09-f7cfdd000000 Time: 2025-07-17T10:59:10.3443684Z </Message> </Error> Headers:{"server": "Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0", "x-ms-request-id": "c76df6fe-601e-004e-3a09-f7cfdd000000", "accept-ranges": "bytes", "via": "1.1 varnish, 1.1 varnish", "date": "Thu, 17 Jul 2025 10:59:10 GMT", "x-served-by": "cache-iad-kjyo7100108-IAD, cache-bom4751-BOM", "x-cache": "MISS, MISS", "x-cache-hits": "0, 0", "x-timer": "S1752749950.204785,VS0,VE335", "content-disposition": "attachment; filename=latest-mac.yml", "content-type": "application/octet-stream", "content-length": "321" } 

[Ahmedmeshref280]

أواجه نفس المشكلة عند محاولة تنزيل أصول الإصدار باستخدام curl. فجأةً، بدأت أتلقى هذا الخطأ

[karpikpl]

I was able to reproduce the issue. 403 happens consistently until I use the browser_url, which works and possibly caches the file. Following requests are successful. Waiting for GH support to address the issue

[burnedikt]

Whether the client is responsible or not is a different question but the fact is that this appears to be a breaking change as we've been downloading assets while providing the access token (also on the redirected request) for years and it just suddenly stopped working. It's also worth noting that the behavior is flaky, we're seeing some downloads (10-20%) still succeed even with the auth header present while the rest is failing.

Thanks for the hint though, removing the auth header on redirected requests solves the issue for us.

[karpikpl]

My guess is that sometimes the asset is cached and not every request causes the redirect.
I'm trying to convince GitHub support that this is a product bug.

[nogitting]

Whether the client is responsible or not is a different question but the fact is that this appears to be a breaking change

That is exactly what I said: It is obviously and technically a breaking change for a number of users, but it should be on the client to strip that header out, as per the HTTP spec (mainly to avoid leaking credentials). For the record though, to be fair, Github's REST API documentation already states that clients should handle both 200 or 302 responses.

we're seeing some downloads (10-20%) still succeed even with the auth header present while the rest is failing

That is also what I mentioned: As long as the resource is cached, it will pass. (Note that a cached asset does not mean there will be no redirect. You can check the network logs.)
In fact, in case the user has little to no control on the client and/or corresponding code, a clean-and-simple-enough workaround would be to programmatically precede the related step with a cURL -L command, to enable the cache, so to speak, so that the header will not matter.

[nogitting]

For what it is worth, here are my investigation results from Jul-18/19 that relate to the redirect part:
(Note that a Bearer token was used.)

• Sending a get request to the redirect URL as is,
  • Without the authorization header,
    • 200 — Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
  • With the authorization header,
    • 403 [...] — Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
• Sending a get request to the redirect URL without the JWT (jwt parameter),
  • Without the authorization header,
    • 618 jwt-not-provided — Varnish (the cache server)
  • With the authorization header,
    • ditto
• Sending a get request to the redirect URL without the signature (sig parameter),
  • Without the authorization header,
    • 409 Public access is not permitted on this storage account. — Blob Service Version 1.0 Microsoft-HTTPAPI/2.0
  • With the authorization header,
    • 403 [...] Authentication scheme Bearer is not supported in this version. — Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
• Sending a get request to the redirect URL with a tampered signature (sig parameter),
  • Without the authorization header,
    • 403 [...] Signature did not match. String to sign used was... — Microsoft-HTTPAPI/2.0
  • With the authorization header,
    • 403 [...] Authentication scheme Bearer is not supported in this version. — Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0

So, you could tell the change led to the header superseding the query parameters until the resource has been accessed and cached.

[nogitting]

And, now (post-fix), it is safe to say that the header is being ignored, because if you omit the signature, even with the header being present, you will get "409 Public access is not permitted...". (cf. 3.2 from the above list)

[Compartilly]

Hey guys, any news about it? still getting this issue

[jungsikjeong]

ing..😭

[bodslink]

I'm still working on changing to AWS S3 because it's not resolved yet. But I still want to know the cause of the problem. ㅜㅜ

[rmatt01]

HHHM
Same problem here. worked since friday 18/07/2025.

[FringeNet]

Critical Security Issue: GitHub PATs Exposed to Microsoft Azure Infrastructure

Security Impact

The 403 errors reveal a critical security vulnerability affecting developers downloading GitHub Release assets. When Authorization headers are included in redirect requests, GitHub Personal Access Tokens are being sent to Microsoft Azure Blob Storage servers.

Technical Analysis

Network investigation confirms that release-assets.githubusercontent.com routes to Azure infrastructure:

• Backend confirmed: server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
• JWT tokens contain Azure path: "path": "releaseassetproduction.blob.core.windows.net"
• Cross-domain token exposure: GitHub PATs sent to releaseassetproduction.blob.core.windows.net

Security Implications

When developers include Authorization headers in redirects:

1. Token Exposure: GitHub PATs with potentially broad scopes (repo access, organization data, user information) are transmitted to Microsoft Azure servers
2. Logging Risk: These tokens may be logged in Azure access logs, creating persistent security exposure
3. Third-party Access: Violates principle of least privilege by exposing authentication to unintended infrastructure
4. Scope Escalation: If PATs have admin or write permissions, Azure infrastructure receives unnecessary elevated access

Immediate Mitigation

// SECURITY RISK - Exposes GitHub PAT to Azure headers: {'Authorization': `Bearer ${token}`}// SECURE - Remove auth header on redirect headers: {/* 'Authorization': `Bearer ${token}`, */}

Root Cause of Recent 403s

The timing suggests Microsoft Azure made infrastructure changes around July 8th to reject invalid authentication headers. Previously, GitHub PATs may have been silently accepted or ignored by Azure, creating an unnoticed security exposure.

Recommendation

This is not just a technical fix but a security best practice. HTTP clients should never forward authentication credentials to third-party domains during redirects. The SAS tokens in the redirect URLs provide sufficient authorization for Azure access.

All developers downloading GitHub Release assets should audit their code immediately to ensure Authorization headers are not forwarded to release-assets.githubusercontent.com.

[rmatt01]

okay @FringeNet , but how can you solve with autoUpdater (electron-updater using typescript)?

autoUpdater.setFeedURL({provider: 'github', owner: 'rmatt01', repo: 'ZPE_tuninig', private: true, token: 'ghp_xxx', }); 

(this is an example)

[FringeNet]

I am still working on this myself, looking at switching to AWS S3

[karl-emilbp]

I found a hotfix to be to modify prepareRedirectUrlOptions in node_modules/electron-updater/node_modules/builder-util-runtime/out/httpExecutor.js to the following:

staticprepareRedirectUrlOptions(redirectUrl,options){constnewOptions=configureRequestOptionsFromUrl(redirectUrl,{ ...options});constheaders=newOptions.headers;if(headers===null||headers===void0 ? void0 : headers.authorization){constparsedNewUrl=newurl_1.URL(redirectUrl);if(parsedNewUrl.hostname.endsWith(".amazonaws.com")||parsedNewUrl.searchParams.has("X-Amz-Credential")||parsedNewUrl.hostname.includes("release-assets.githubusercontent.com")){deleteheaders.authorization;}}returnnewOptions;}

[FringeNet]

It happened to me intermittently last week, a few clients failed to update rather randomly. I thought nothing of it until today.
Either way, that fix is still necessary in Electron.

Daddy Microsoft must now have the code they want, so they thought it would be nice to nod to us that we must fix the vulnerability

[nogitting]

It looks like objects.githubusercontent.com is "friendlier", but I will have to investigate more.
Anyway, the bug/fix is a blessing in disguise indeed.
Cheers.

[FringeNet]

It looks like objects.githubusercontent.com is "friendlier", but I will have to investigate more. Anyway, the bug/fix is a blessing in disguise indeed. Cheers.

objects.githubusercontent.com is pointing me to S3.

I am unable to reproduce the 403 when pointing to release-assets.githubusercontent.com anymore (which I confirmed earlier was pointing to Azure.)

[karpikpl]

shouldn't the default behavior match what curl is doing with --location-trusted ?
https://curl.se/docs/CVE-2018-1000007.html

not sure why you think cherry picking domains or parameters is better when deciding when to pass Authorization with a redirect.

[FringeNet]

shouldn't the default behavior match what curl is doing with --location-trusted ? https://curl.se/docs/CVE-2018-1000007.html

not sure why you think cherry picking domains or parameters is better when deciding when to pass Authorization with a redirect.

That's what Electron is doing, cherry picking domains to strip the header from.
The hotfix above works, but isn't ideal.

[FringeNet]

Safer HotFix

static prepareRedirectUrlOptions(redirectUrl: string, options: RequestOptions): RequestOptions{const newOptions = configureRequestOptionsFromUrl(redirectUrl,{...options }) const headers = newOptions.headers if (headers?.authorization){// Parse original and redirect URLs to compare origins const originalUrl = HttpExecutor.reconstructOriginalUrl(options) const parsedRedirectUrl = parseUrl(redirectUrl, options) // Strip authorization header on cross-origin redirects (different protocol, hostname, or port) if (HttpExecutor.isCrossOriginRedirect(originalUrl, parsedRedirectUrl)){delete headers.authorization } } return newOptions } private static reconstructOriginalUrl(options: RequestOptions): URL{const protocol = options.protocol || "https:" const hostname = options.hostname || "localhost" const port = options.port ? `:${options.port}` : "" const path = options.path || "/" return new URL(`${protocol}//${hostname}${port}${path}`) } private static isCrossOriginRedirect(originalUrl: URL, redirectUrl: URL): boolean{// Case-insensitive hostname comparison if (originalUrl.hostname.toLowerCase() !== redirectUrl.hostname.toLowerCase()){return true } // Special case: allow http -> https redirect on same host with standard ports // This matches the behavior of Python requests library for backward compatibility if ( originalUrl.protocol === "http:" && HttpExecutor.getEffectivePort(originalUrl) === 80 && redirectUrl.protocol === "https:" && HttpExecutor.getEffectivePort(redirectUrl) === 443 ){return false } // Strip auth on any other protocol change if (originalUrl.protocol !== redirectUrl.protocol){return true } // Strip auth on port change (accounting for default ports) const originalPort = HttpExecutor.getEffectivePort(originalUrl) const redirectPort = HttpExecutor.getEffectivePort(redirectUrl) return originalPort !== redirectPort } private static getEffectivePort(url: URL): number{if (url.port){return parseInt(url.port, 10) } // Return default port for scheme return url.protocol === "https:" ? 443 : 80 } 

[karpikpl]

GH might be implementing a fix today 5 PM EST.
My understanding is that single http call (without special handling of authorization headers) should work.
You can continue stripping it on different host/port/protocol though - this seems reasonable.

(this is not an official GH/MS statement though)

[nogitting]

What do you mean by "single http call (without special handling of authorization headers) should work"? Like once their fix is shipped?

[karpikpl]

that's my understanding, that they will remove the Authorization header themselves, so no more 403

[nogitting]

They will not, because it is a client thing. So, I guess they will revert to the old state, which seemingly consists in ignoring that header for duly-signed URLs.

[karpikpl]

I'm not sure why not, it's a fairly standard thing on any application gateway to strip headers.
Anyway, the fix is in, and I can no longer reproduce the issue.

[abhay288]

🔍 What’s Going On?

A Github Community discussion confirms that many Electron apps using GitHub Releases are experiencing 403s from the CDN (backed by Azure Blob Storage) when fetching signed asset URLs
GitHub+2GitHub+2GitHub+2
.

More importantly, a security-focused comment reveals a recent change: Azure Blob Storage has begun blocking requests that include an unnecessary Authorization header when accessing release assets via redirects
GitHub+1Rclone+1
. Prior to early July, sending such headers may have been silently ignored, but now triggers a 403 error as Azure enforces stricter authentication rules.

Key excerpt: HTTP clients shouldn’t forward authentication credentials to third-party domains… SAS tokens in redirect URLs provide sufficient authorization. [GitHub](https://github.com/orgs/community/discussions/166304?utm_source=chatgpt.com) 

✅ What This Means for Your App

Your Electron updater setup is likely still attaching the Authorization header (with GH_TOKEN or PAT) to HTTP(S) requests—even after being redirected to release-assets.githubusercontent.com. That header is now being rejected by Azure, resulting in intermittent 403s.
🛠 Recommended Fixes

Stop forwarding Authorization headers after redirects: Ensure your HTTP client strips or disables forwarding any Authorization header when following the redirect to download assets. Rely instead on the signed SAS token included in the redirect URL—it's fully sufficient for access. Verify redirect handling: In electron-updater or your custom download logic, double-check that followRedirect is enabled and Authorization headers aren't preserved. Update your dependencies: Make sure you're using the very latest versions of electron-updater and any HTTP libraries, as maintainers may have surfaced patches that address this issue. 

🧪 Pro Tip

Create a test script that:

Requests a release asset with Authorization header. Follows redirect to release-assets.githubusercontent.com. Logs the final HTTP request (headers, URL). Confirms whether the SAS token is used (good) and Authorization is omitted (good). 

✅ Summary

Root cause: A stricter Azure security change rolled out in early July 2025. Effect: Requests with Authorization headers now fail with 403. Solution: Remove Authorization headers after redirect, rely exclusively on SAS tokens. 

[therealstarkX]

Oh yeah, those random 403 errors during updates are super annoying! Here's what usually fixes it: First, make sure you're not hitting GitHub's rate limits by adding a personal access token to your electron-builder config. Also, set a proper User-Agent header - GitHub sometimes blocks requests that look like bots. If it still happens, we can add some retry logic to handle temporary network issues. Wanna try these steps and see if it helps?

[mstfymstfa49-collab]

ايلغعغ

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬

[cristian-ist]

Between late April and mid-July 2025 GitHub changed how some release assets are served (increasingly via release-assets.githubusercontent.com, which fronts Azure Blob). Since roughly July 8, 2025, requests that arrive at the redirected Azure Blob URL with an Authorization header intermittently return 403 AuthenticationFailed. When the asset is already cached at an edge, the same request may succeed—hence the flakiness and the time-of-day/region pattern you’re seeing. Multiple users (including Electron auto-update flows) reported the same symptoms, and removing the Authorization header on the redirected request fixes it.

Evidence we found

GitHub Community thread with identical headers, dates, regions (IAD/ICN), and error text; several confirmations that stripping Authorization after the 302 redirect resolves the 403.
GitHub

electron-builder/electron-updater issue opened July 17, 2025 showing the same AuthenticationFailed from Azure with release-assets.githubusercontent.com and SAS/JWT query params.
GitHub

StepSecurity noticed a platform shift to release-assets.githubusercontent.com across many customers in late April/May 2025, consistent with infra changes preceding these July regressions.
StepSecurity

What changed (most probable)

GitHub’s release download pipeline now more often redirects to Azure Blob URLs signed with SAS/JWT.

Best practice (and apparently now enforced): do not forward repository credentials (PAT/GH_TOKEN) to third-party domains on redirect. Azure will reject such requests with AuthenticationFailed. Some edges still serve cached objects, which is why it works sometimes.
GitHub

What to do right now

Ensure your HTTP client strips Authorization on redirects.

In your updater stack (electron-updater → builder-util-runtime), confirm that when the first request to api.github.com/objects.githubusercontent.com redirects to release-assets.githubusercontent.com, the follow-up request is sent without Authorization. Users have reported this alone fixes the issue.
GitHub

If you can’t change the client immediately, quick mitigations:

Pre-fetch via the GitHub API (with token) to get the asset’s browser URL, then download that URL without any auth header.
GitHub

Put a tiny proxy in front of updater downloads that removes Authorization on outbound requests to *.githubusercontent.com.

Add retry with one forced “no-auth” attempt after a 403 from release-assets.githubusercontent.com. Community reports indicate a subsequent request without the header succeeds.

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬

[abhay288]

Thank you for the reminder! This discussion is still relevant, and I’m continuing to work on the topic. I will provide additional updates soon so the conversation remains active. Please keep the discussion open for now.

Thanks again for the notification! 🙌