Key points
- Vanus versions 0.8.0 through 0.9.0 are affected by this missing authentication vulnerability.
- Attackers can send forged CloudEvents without tokens to specific gateway paths.
- The flaw allows unauthenticated remote attackers to store and deliver events to sinks.
Vanus versions 0.8.0 through 0.9.0 contain a security gap that allows remote attackers to inject events without proving their identity. The National Vulnerability Database records this flaw as CVE-2026-111999 with a CVSS score of 8.7, classifying it as high severity. This issue affects the gateway CloudEvents HTTP receiver component within the Vanus platform developed by vanus-labs.
In plain English
Authentication is the process that verifies who is trying to access a system. In this case, the verification step is missing for a specific function. An attacker does not need a password, token, or any credential to interact with the eventbus. They can simply send a request to the server, and the server will accept it as valid. This bypasses the security checks that are supposed to stop unauthorized users from publishing data.
The background
The vulnerability stems from how the gateway handles incoming requests on two specific paths. According to the source material, attackers can target the /namespaces/{ns}/eventbus/{name}/events endpoint or the legacy /gateway/{name} path. When a request hits these locations, the system fails to perform token authentication or authPublish checks. As a result, the forged CloudEvents are stored in the system and subsequently delivered to any subscription sinks that are listening for those events.
What changes now
Organizations running Vanus up to version 0.9.0 are exposed to this risk. The weakness is categorized under CWE-306, which relates to missing authentication for critical functions. Because the flaw allows unauthenticated remote access, any system with this version exposed to the internet or an untrusted network is vulnerable. There is no mention of a patch or updated version in the provided source material, meaning the vulnerability remains active in the affected versions.
Who needs to act first
Teams should prioritize identifying all instances of Vanus version 0.9.0 and earlier in their environment. Since no fix is confirmed yet, focus on reducing exposure by restricting network access to the gateway endpoints. Isolate these systems from untrusted networks where possible. Verify that internal monitoring tools are capturing traffic to the affected paths. Prepare a rollback plan in case a future update introduces instability. Ensure backups of current configurations are safe and tested.
What to do and how to stay safe: Vanus
- Inventory all servers and containers running Vanus to identify those on version 0.8.0 through 0.9.0.
- Restrict network access to the CloudEvents HTTP receiver endpoints to trusted IP addresses only.
- Monitor logs for unusual traffic volumes to the /namespaces and /gateway paths.
- Contact the vendor to confirm if a patched version has been released since the source material was compiled.
Step-by-step guide: Out-of-Band Patches: Meaning, Risks, and Deployment Reality
General security guidance from the Patch Herald newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Which versions of Vanus are affected by CVE-2026-111999?
Vanus versions 0.8.0 through 0.9.0 are affected by this missing authentication vulnerability.
How can an attacker exploit this flaw?
Attackers can send forged CloudEvents to specific gateway paths without authentication tokens.
Is there a patch available for this vulnerability?
The source material does not mention a patch or fix, so no update is confirmed yet.
