Bitrise Takes Its Mobile Build Service Offline After a Breach, Tells Customers to Rotate Every Secret

What Bitrise Has Said So Far

The account has shifted a little from one update to the next.

The first notice, at 20:44 UTC on 13 November, described a security incident “affecting some of Bitrise’s internal secrets, detected within the last hour”. Out of caution, it asked customers to rotate any Git and source-code access credentials connected to Bitrise.

The next detailed update came at 01:26 UTC on 14 November. It put the detection at 16:32 UTC, about four hours before the first notice, and said the system the intruder reached “does not store or process customer data”. It also widened the advice. Once the service is back, customers should rotate “all secrets, access tokens, and certificates stored in Bitrise”. Bitrise hasn’t explained why the first notice said “within the last hour”.

At 02:29 UTC it began restoring services in phases. An hour later it expected logins to work again by 06:00 UTC. That didn’t happen, and every update since has said logins will be back “soon”. In incident updates, soon is a flexible unit of time.

An internal system without customer data, and advice to replace every customer secret, don’t sit comfortably side by side. The most likely reading is caution: if Bitrise can’t yet rule out that its own keys open a path to customer secrets, rotating everything is the safe default. Bitrise hasn’t said which internal secrets were affected.

Why a Build Service Is a Sensitive Place

A build service like Bitrise takes an app’s source code, compiles it, signs it and sends it to the App Store or Google Play. To do that, it has to hold the developer’s keys.

For iOS apps, Bitrise asks customers to upload their signing certificates as .p12 files, which contain the private key, and to connect an Apple account or an App Store Connect API key. Android builds need the app’s keystore and its passwords, and publishing to Google Play needs a Google service-account key. Add access to the source code on GitHub, GitLab or Bitbucket, and the “secrets” teams store for their builds: API keys for their own servers, analytics, crash reporting and payment providers.

Then there is Bitrise’s hosted CodePush. It lets React Native apps download new JavaScript code directly from Bitrise’s servers, with no App Store or Google Play review in between.

A build service is, by design, the place where a company keeps the keys to its own apps. This is convenient, right up to the day someone else gets into the building.

Bitrise says it has no evidence that any of this was reached. Its advice to rotate everything is a precaution, not a confirmation.

Should You Worry About the Apps on Your Phone?

For now, you don’t need to do anything. Bitrise has found no sign that customer secrets were exposed, and most routes from a stolen key to your phone have a check on them.

Updates from the App Store and Google Play still pass through Apple and Google. With Play App Signing, Google holds the key that signs the final app delivered to your device, and a developer’s upload key can be reset if it leaks. Apple says that revoking an App Store distribution certificate doesn’t affect apps already in the store.

Over-the-air updates are the weaker spot, because they skip store review. In August 2026 Bitrise added code signing for CodePush: the app checks each update’s signature and discards any that doesn’t match. That protects users only if the developer turned it on and kept the private signing key outside Bitrise. Nobody outside Bitrise knows how many apps do.

You can’t easily tell which of your apps are built on Bitrise, so the usual rule is the whole rule here: install apps and updates only from the official stores. What you may notice is delay. While Bitrise is down, companies that depend on it can’t ship new builds or bug fixes through it.

What Developers Should Do Now

Bitrise advises rotating everything once you can log in again. Part of it you can do now, at the source. Your builds aren’t running anyway, so breaking them today costs little.

• Git access: revoke the SSH keys, deploy keys and access tokens Bitrise uses for your repositories, and check your Git host’s audit log for clones or pushes you don’t recognise since 13 November.
• Build secrets: replace every API key and password stored as a Bitrise secret at the service that issued it, not only in Bitrise.
• Apple: revoke App Store Connect API keys connected to Bitrise, and revoke and reissue the distribution certificates you uploaded. App Store apps keep working, but Apple warns that in-house apps signed with a revoked certificate stop running, and that builds uploaded but not yet submitted for review may be marked invalid.
• Google Play: if your upload key was on Bitrise, request an upload key reset in Play Console, and replace the service-account key used for publishing. If you manage your own app signing key and it was stored on Bitrise, your position is harder: Google says that key can’t be reset.
• CodePush: replace your deployment keys, and if you sign updates, check where the private key is kept.
• Bitrise itself: once logins work, replace personal access tokens and review who has access to your workspace.

What Bitrise Hasn't Said Yet

Bitrise hasn’t said which of its internal secrets were affected or how the intruder got in. It also hasn’t said whether those secrets could lead to customer data, or why its first notice came about four hours after the detection time it later gave. There is no date for a full restore.

If its investigation finds that personal data was involved, the GDPR gives Bitrise, as a company headquartered in Budapest, 72 hours to report the breach to the data protection authority, unless the breach is unlikely to put people at risk. For now it says the system involved holds no customer data.

We will update this article when Bitrise publishes its findings.