CVE-2026-25555: Authentication Bypass in OpenBullet2
| Field | Value |
|---|---|
| CVE ID | CVE-2026-25555 |
| CVSS score | 9.8 (Critical) |
| Attack vector | Not provided in the retrieved NVD response |
| Authentication required | None |
| Patch status | A newer release line exists (0.3.3.3093), but an official vendor advisory explicitly mapping this CVE to that fixed version was not confirmed in the provided sources |
TL;DR - OpenBullet2 through
0.3.2can treat an emptyX-Api-Keyheader as valid admin authentication. - Internet-exposed instances are the priority risk; no credentials are required. - Public exploit details exist, so defenders should treat this as urgent even without confirmed in-the-wild exploitation.
Vulnerability at a Glance
CVE-2026-25555 is an authentication bypass in OpenBullet2 caused by flawed API-key validation logic. According to the NVD description, OpenBullet2 through version 0.3.2 compares the inbound X-Api-Key header against an AdminApiKey value that is empty by default. If an attacker sends an empty header value, that comparison can succeed and the request is treated as authenticated administrative traffic.
The practical consequence is much worse than a narrow API issue. The vulnerable middleware can expose the admin console and all API endpoints protected by that check. In plain terms, this is an unauthenticated path to administrator-level access on reachable OpenBullet2 instances. Because no valid credentials are needed, any internet-exposed deployment should be considered high risk until verified otherwise.
What Is This Vulnerability?
This is a logic flaw, not a memory corruption bug or a complex race condition. OpenBullet2 supports API-key-based authentication, but the implementation reportedly allows the configured admin API key to remain empty while still performing an equality check against user-supplied input. If the server receives X-Api-Key: with no value, the empty input can match the empty configured value, resulting in a successful authentication decision.
That distinction matters for defenders. Many teams assume “empty means disabled” when reading settings or deployment defaults. The available reporting around this issue indicates that OpenBullet2 behaved differently: the empty key did not reliably disable the control, but instead created a bypass condition. This kind of bug is especially dangerous because it survives ordinary deployment habits. Admins may not think they have enabled API-key auth at all, while attackers only need to know the header name and send an empty value.
Technical Notes
A minimal proof-of-concept request looks like this:
GET / HTTP/1.1
Host: target.example
X-Api-Key:
A quick curl example for validation in a controlled environment:
curl -i http://TARGET:8069/ -H 'X-Api-Key:'
If the target is vulnerable and exposed, defenders should assume that any endpoint behind the same middleware may also be reachable without credentials.
Who Is Affected?
Based on the retrieved NVD description, OpenBullet2 through version 0.3.2 is affected. Public reporting also specifically references OpenBullet2 0.3.2 as vulnerable, and the official project release stream shows that a later 0.3.3.3093 release exists. However, the important caveat is that the provided sources did not include an official vendor security advisory explicitly stating, “CVE-2026-25555 is fixed in version 0.3.3.3093.”
That means defenders should be precise in their internal guidance. You can say with confidence that versions up to and including 0.3.2 are affected. You can also say that a newer release line exists and should be evaluated immediately. But if your change management process requires a vendor-confirmed fix statement, you do not have that from the source set here. In the absence of that confirmation, the safest operational assumption is that any deployment running 0.3.2 or earlier is vulnerable and should either be upgraded to the latest available release after testing or isolated until validated.
| Product | Affected versions | Fixed version |
|---|---|---|
| OpenBullet2 | Through 0.3.2 |
Not explicitly confirmed in a fetched vendor advisory; later release 0.3.3.3093 exists |
If you do not know what version is running, treat the instance as exposed until you verify the deployed image tag, binary version, or container manifest. This is particularly important for self-hosted Docker deployments where older tags may persist long after newer releases become available.
Technical Notes
A deployment example cited in public reporting uses Docker:
docker run --name openbullet2 --rm -p 8069:5000 -it openbullet/openbullet2:0.3.2
To enumerate running containers and identify potentially affected tags:
docker ps --format 'table {{.Names}} {{.Image}} {{.Ports}}'
docker images | grep -i openbullet
For Kubernetes environments, look for image references in manifests:
```bash kubectl get pods -A -o jsonpath=’{range .items[*]}{.metadata.namespace}{‘