CircleCI Response to CVE-2026-43499 ("GhostLock" Linux kernel vulnerability)

Announcements Security
1

On July 7, 2026, the High Severity Linux kernel vulnerability CVE-2026-43499 (aka “GhostLock”) was disclosed, which could allow a user already running code on a system to gain elevated access and potentially escape container isolation. In response, our engineering team began an Emergency Maintenance on July 9 at 21:00 UTC to roll out patched kernel images across the potentially vulnerable parts of our fleet.

In order to exploit CVE-2026-43499, an attacker must already have the ability to run code on the affected system. By carefully choreographing threads to trigger a race in the remove_waiter() function, an unprivileged user can reclaim freed kernel stack memory and redirect kernel execution to gain root access on the machine. This can allow an attacker to escape container isolation and gain access to the host. The CVSS severity score for this vulnerability is 7.8 out of 10 (High). As of this writing, we have no evidence that this vulnerability has been exploited in any part of the CircleCI infrastructure.

Docker jobs: No Action Required

Docker jobs run on a shared Linux fleet where kernel-level isolation forms the security boundary between customers. The Emergency Maintenance rollout of patched kernel images is in progress and this post will be updated when complete. No action is required on your part.

Machine executor jobs: No Action Required

Machine executor jobs already run with root access by design, so this vulnerability does not expose data or credentials beyond the access that your build already has. Each VM is yours alone for the duration of a job and is destroyed when the job ends, so this vulnerability cannot carry over between jobs or customers.

Even so, the Emergency Maintenance rollout of patched kernel images is in progress and this post will be updated when complete. No action is required on your part.

‘Self-hosted’ Runners: Patch Your Host Machines

If you use CircleCI Runners on a vulnerable Linux version, you will need to immediately patch your host machines according to your Linux distribution provider’s guidance. CircleCI does not distribute any images for Runners, so there are no CircleCI updates to Runner binaries.

A note on vulnerability scanners

If you’re running a vulnerability scanner inside your job, it may temporarily flag the current kernel version as unpatched. That’s accurate and expected, and will clear once updated kernel images are fully deployed across the CircleCI infrastructure. In the meantime, you can reference this post to document the exception in your security tooling.

Updates

July 9, 2026, 21:00 UTC - Patched kernel rollout in progress across Docker executor and Machine executor fleets. This post will be updated when the rollout is complete.

July 10, 2026, 5:04 UTC - We have completed the kernel upgrades across all the infrastructure used to run Docker jobs. Our monitoring shows Docker job execution is working as normal.

During the maintenance, a small number of jobs were forcibly canceled as machines were upgraded. These jobs will have an “Infrastructure Fail” status in the CircleCI UI. You can rerun Infrastructure Fail jobs from the UI or pushing to your VCS brach.

Thank you for your patience during this maintenance.

2

@kami We think this might be related to CI failures we’re now seeing across all our tests. We use Mongo container for DB, and it is now segfaulting on every CI run, causing tests to spin for hours on end until killed manually, chewing through usage :frowning: So far, we have not been able to find a fix that we can make on our end. This has rendered CircleCI completely unusable for us. Please treat with high priority and provide remediation steps ASAP.

3

Further info. Seems that the latest linux kernels removed an internal function that jemalloc relied on, which mongodb in turn relies on. So MongoDB is completely broken on latest kernel versions - https://jira.mongodb.org/browse/SERVER-121912 - And there is not currently a fixed version of MongoDB released that works around this breakage. So CircleCI is now completely unusable until either 1) CircleCI reverts the kernel updates, 2) MongoDB releases a fixed version, 3) Linux kernel restores the removed internal function jemalloc relied on. So we’re completely stuck :frowning:

4

We’ve been locked for 3 days and any we don’t see any path beyond waiting with no clear timeline. @kami can’t you provide means to select the kernel version?

5

I also have issues since this change. I have some jobs that used to work that are now getting killed, presumably going out of memory. (I reran on the same commit hash that used to work.)

6

To everyone affected by this issue:

We’re very sorry that this emergency security maintenance unexpectedly disrupted builds for users using MongoDB 8.x. We understand how serious this is when tests remain waiting for a database that never becomes ready and usage continues to accumulate. Thank you to everyone who reported the issue and shared diagnostic details; those reports helped us confirm the compatibility path.

CircleCI engineering has validated the following workaround for MongoDB 8.x on the updated Docker executor hosts. Add GLIBC_TUNABLES=glibc.pthread.rseq=1 to the MongoDB service container:

Depending on the MongoDB image version, the service may fail with a startup message like:

MongoDB cannot start: Linux kernel versions 6.19 and newer has a known incompatibility with this version of MongoDB. See https://jira.mongodb.org/browse/SERVER-121912 for more information.

Older image versions may instead terminate with:

exited with error (exited with 139)

The test process may then report that no MongoDB server is available, for example Mongo::Error::NoServerAvailable.

docker:
  - image: cimg/base:current
  - image: mongo:8.0
    environment:
      GLIBC_TUNABLES: glibc.pthread.rseq=1

This allows MongoDB to start by avoiding the incompatible TCMalloc RSEQ path. It does have a performance tradeoff: MongoDB uses per-thread caching instead of per-CPU caching. Please test it against your workload and continue using a readiness check with a finite timeout so a failed database startup cannot leave a job running indefinitely.

If an application supports MongoDB 7.x, pinning the service to a fixed 7.x image, such as mongo:7.0, is another option. MongoDB identifies this specific incompatibility as affecting MongoDB 8.0 and newer in its production notes. Please test the version against the application and avoid floating tags such as mongo or mongo:latest.

The CircleCI kernel update cannot be rolled back because it remediates a high-severity container-isolation vulnerability on the shared Docker fleet. The maintenance rollout is complete, and the current issue affects jobs that run MongoDB 8.x inside the Docker executor and not any other CircleCI jobs.

We’re sorry again for the disruption and for the time customers have lost investigating this. We appreciate everyone’s patience while the upstream and platform compatibility work progresses.

7

Hi everyone, thanks for the detailed reports.

CircleCI patched the Docker executor fleet to address CVE-2026-43499 (GhostLock), a high-severity container isolation vulnerability. This update applies to the shared fleet and cannot be rolled back, per-job or per-org kernel selection is not available on the Docker executor.

For MongoDB 8.x: The new kernel breaks MongoDB 8.x, which exits with error code 139. The confirmed workaround is to set the following environment variable in your MongoDB container:

GLIBC_TUNABLES=glibc.pthread.rseq=1

Example for docker-compose.yaml:
yaml

mongodb:
  image: mongo:8.2.7
  environment:
    - GLIBC_TUNABLES=glibc.pthread.rseq=1

This prevents the crash by disabling TCMalloc’s RSEQ usage. MongoDB will run on per-thread cache instead of per-CPU cache, there is a minor performance tradeoff, but builds will pass. If MongoDB 8.x is not a hard requirement, pinning to mongo:7.x is a stable alternative in the meantime.

The MongoDB team is tracking a fix at SERVER-121912. Monitoring that ticket directly is the best way to stay informed on a permanent resolution.