The eMudhra certificate compromise: how it affects Bitrise users

On October 17, 2026, the developer world learned that the private keys of eight intermediate certificate authority (CA) certificates from eMudhra had been compromised. In this article, I’ll explain how that affects the Bitrise environment powering your Bitrise CI jobs, Build Hub runners, and Remote Developer Environments.

How certificates, certificate authorities, and keys work

Websites and services prove their identity by presenting a certificate attesting to their identity. These certificates are signed by intermediate certificate authorities (CAs), which are signed by root CAs. CAs are a small set of trusted authorities that guarantee the identity of downstream certificates.

Certificates are signed with a CA’s private key, which should be a very large, secret, unguessable number. When an attacker knows the number, then they can sign any certificate and impersonate websites and services to anyone who trusts the CA.

What went wrong with eMudhra

eMudhra is a certificate authority (although after this failure they have decided to get out of the global SSL/TLS cert business). A key-generation flaw reduced the effective entropy of the P-384 keys to an estimated 3 to 8 bits, and one key was literally the number 4, and security researchers were able to identify the numbers.

With the certificate compromised, the only fix is to stop trusting certificates issued under eMudhra. This is achieved by revoking eMudhra’s certificates from trust stores.

Is your Bitrise environment at risk?

Attackers can only exploit the compromised certificate by inserting themselves in the network path of the service or website you are connecting to (man in the middle). For example, at a coffee shop, the attacker sets up a fake hotspot with a similar name to the coffee shop wifi and directs requests through their own machine.

The Bitrise VMs run in our data centers on private networks, which narrows the scope of attacks to incredibly high-profile avenues like BGP hijack or compromised upstream network providers. Regardless, to further minimize risk, we have begun rolling out updates to our hosted environments (Bitrise CI runners, Build Hub runners, and Remote Developer Environments). Most updates are already published, and the remainder will be completed in the next week.

How trust stores work on macOS

Trust stores are lists of root CA certificates that tools trust. macOS and applications running on macOS have several. Different tools read different stores:

• /etc/ssl/cert.pem - this is a static file used by system curl (system meaning the version at /usr/bin), system git, pythons (via its certifi package), and other system tools. Apple has stated they will update this file as part of a future macOS release. More on our response below.
• SecTrust - a part of macOS Security framework used by applications like Safari and Xcode.
• Homebrew ca-certificates - a Homebrew package that provides a trust store to many other Homebrew packages (like the Homebrew installed curl which is the curl on the PATH of our stacks). openssl uses ca-certificates.
• tools that bundle their own trust store - various tools ranging from Java to awscli package up their own trust store in the tool

SecTrust deserves more explanation. This is powered by a local database with certificate revocation information, managed by a background service, trustd. trustd runs on a schedule to occasionally sync the latest revocation information from its server. This means that when a session or job begins, the database contains information from when the image was built. It won’t be updated until the sync is run. More on how we address that below.

Homebrew curl is also a special case. It uses Homebrew ca-certificates, but if a cert is rejected there, it falls back to SecTrust. So for Homebrew curl, both fixes are needed.

How trust stores work  on Ubuntu

Ubuntu is a much simpler story because there is no SecTrust style service. Almost every tool uses the system trust store. For Ubuntu, we have:

• /etc/ssl/certs is the system level store managed by the ca-certificates apt package.
• tools that bundle their own trust store

Relevant to Android developers, the Java trust store is rebuilt by updates to ca-certificates.

What we’ve changed on Bitrise stacks

Even though an attack through Bitrise environments is unlikely, we are updating our stacks to remove the compromised certificates from trust stores on stable and edge stacks (if you are unfamiliar with stable vs edge vs frozen stacks, the stack update policy explains them):

For macOS:

• Updating Homebrew’s ca-certificates package on stable and edge macOS stacks so that most brew tools reject compromised certificates.
• Making Homebrew’s version of curl the default (instead of the system curl) on all stable and edge stacks.
• Updating installed tools on edge stacks (ex. Node.js, Go)
• Faster revocation at boot: running a script to tell trustd to sync right at the beginning of each workflow/session. Earlier I mentioned that the sync normally happens on a schedule. That means a session could start with an outdated database, only getting updated once the scheduled sync happens, potentially late in a session. To avoid this, we developed a tool to proactively trigger the sync at the beginning of every session.
• running an Apple recommended workaround script to remove compromised certificates from /etc/ssl/cert.pem so that we do not have to wait for a macOS update.

For Linux:

• updating apt’s ca-certificate package on stable and edge Linux stacks.
• updating installed tools on edge stacks (ex. Node.js, pip)

What we haven’t changed on stable stacks

To keep stable stacks predictable, we followed our stack update policy and limited tool upgrades to edge stacks, barring a couple of surgical updates that we deemed necessary (ca-certificates update and defaulting to Homebrew curl across all stacks). That leaves some tools that bundle their own trust store with compromised certificates on the stable stacks. (Ubuntu: pip, Node.js, macOS: Node.js, Java, uv).

Frozen stacks (Xcode 16.x and Ubuntu 22) don’t receive updates and are scheduled for removal. Their changelogs (available at Bitrise Stack Updates) now include a warning and steps for patching yourself.

What you can do

None of these steps are emergencies, but they're worth doing soon, especially on stable or frozen stacks. Therefore, the following suggestions need not be pursued with p0 urgency.

Check the changelogs at Bitrise Stack Updates  to see what was updated on the stacks you depend on. If you see a tool that vendors its own trust store and was not updated, consider updating that at the beginning of your workflow or RDE session. Bitrise CI users have a convenient, declarative mechanism to install custom tools versions, the tools: block of bitrise.yml, that avoids writing custom scripts. More on that in Configuring tool versions. This especially applies to users of stable stacks.

We encourage users of the frozen stacks to target the stable or edge channels, which receive updates. But if your project requires a frozen stack, the changelog pages of every frozen stack Bitrise Stack Updates include information on what to include in scripts to update the environments.

eMudhra Intermediate CA Compromise provides excellent additional information on this situation along with example checks that you can use to confirm updated trust stores are used.

Looking ahead

Surprisingly, in this specific scenario, the researcher who identified the problem with conventional tools (not AI)! But that does not change the fact that we are in a new era of AI-assisted security research (and AI-assisted attackers). Vulnerabilities will be identified and announced (or not announced) with increasing frequency. Bitrise will continue to take proactive measures to secure the Bitrise CI, Build Hub, and Remote Developer Environments. You can follow our security notices on the Bitrise Trust Center.