All EAS Update assets return 403 Forbidden from assets.eascdn.net — devices never apply updates

[Khashayarbayati1]

Summary

Every asset of every update we publish — the launch asset (JS bundle) and all 61 static assets — returns HTTP 403 Forbidden from assets.eascdn.net. The manifest endpoint at u.expo.dev serves correctly and eas update publishes succeed, so devices fetch the manifest, fail to download the files, and silently keep the embedded bundle. As far as we can tell, no OTA update has ever applied for this project.

Similar past report: #1688 (Cloudflare-level denial on eascdn).

Project

• Project ID: c4988614-4950-482a-b174-dc2ba141f2fa (account kaivest, Free plan)
• SDK 57 · expo-updates ~57.0.8 · eas-cli 21.2.0 · runtimeVersion policy appVersion (1.0.0) · channel/branch production
• Example affected update group: 842fcd11-36e5-425d-9fbe-3563c8430128 (also all earlier groups on the branch)

Reproduction

Manifest is served fine:

curl -s "https://u.expo.dev/c4988614-4950-482a-b174-dc2ba141f2fa" \
  -H "expo-platform: ios" -H "expo-runtime-version: 1.0.0" \
  -H "expo-channel-name: production" -H "expo-protocol-version: 1" \
  -H "Accept: multipart/mixed"
# → 200, correct latest update manifest

Every asset URL from that manifest 403s:

curl -s -o /dev/null -w "%{http_code}\n" "https://assets.eascdn.net/dwddHDrldp2nFKHZdWqQqnPOcNLDzFtS1_sbXdDf-0w?project=c4988614-4950-482a-b174-dc2ba141f2fa"
# → 403 (same for all 61 assets of the update, and for older update groups)

Tested with multiple user agents (curl default, empty, CFNetwork-style) — always 403.

Ruled out

• Client config: extracted Expo.plist from the actual production IPA — EXUpdatesEnabled true, correct EXUpdatesURL, expo-channel-name: production request header, runtime 1.0.0, CheckOnLaunch: ALWAYS.
• Publish failures: eas update completes successfully; eas update:list shows the groups with both platforms.
• Runtime/channel mismatch: manifest endpoint returns the expected latest update for the exact headers the binary sends.
• Real devices (TestFlight builds 12 and 13, multiple networks: home wifi + cellular) never apply any update, consistent with the asset 403s.

Ask

Could you check whether this project's assets or account are being blocked at the CDN (Cloudflare) level? Happy to provide anything else useful.

🤖 Filed with Claude Code on behalf of the account owner.

[gwdp]

Hey @Khashayarbayati1, thanks for the report! I took a quick look at c4988614-4950-482a-b174-dc2ba141f2fa

Your assets aren’t blocked from what I see. The curl 403s are expected as assets.eascdn.net requires a timed HMAC Authorization header. Those come back in the multipart manifest under assetRequestHeaders, and expo-updates attaches them when it downloads. A bare curl of the URL will always hit our unauthorized page.

With the headers from your manifest, the launch asset, and the other assets I checked, all return 200. Manifest for production / 1.0.0 looks fine too. So this isn’t a CDN/account block (and it’s a different issue from #1688).

If TestFlight builds still aren’t applying updates, it’s likely on the client side — if you can share expo-updates logs from check → download → apply (and whether you’re expecting apply on download vs next launch), we’re happy to keep digging.