CVE-2026-111998 in Vanus
Summary
by MITRE • 10/18/2026
Vanus 0.8.0 through 0.9.0 contains a default credentials vulnerability that allows unauthenticated remote attackers to gain cluster-admin access by using the hardcoded admin token. Attackers can send the fixed Bearer token to the gateway gRPC proxy port to manage namespaces, eventbuses, users, tokens, and role bindings, and read or publish events.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/18/2026
The vulnerability identified in Vanus versions 0.8.0 through 0.9.0 represents a critical failure in authentication configuration, specifically categorized under CWE-798: Use of Hard-coded Credentials. This flaw stems from the deployment of default administrative credentials that remain active and unmodified out-of-the-box within the software distribution. The specific technical mechanism involves a hardcoded Bearer token designated for cluster-admin access, which is embedded directly into the application logic or configuration files without any requirement for initial user intervention to change these defaults. Consequently, any entity capable of network connectivity to the Vanus gateway gRPC proxy port can exploit this static credential set to bypass all authentication mechanisms entirely.
From an operational perspective, the impact of this vulnerability is severe due to the elevated privileges associated with the compromised account. By presenting the fixed Bearer token during communication with the gRPC interface, unauthenticated remote attackers achieve full cluster-admin status. This level of access grants comprehensive control over the entire Vanus event streaming infrastructure. Attackers can manipulate core system components including namespaces and eventbuses, effectively altering the routing and storage architecture for data streams. Furthermore, they possess the authority to manage users and tokens, allowing them to create persistent backdoors or revoke legitimate administrative access, thereby ensuring long-term unauthorized presence within the environment.
The ability to read and publish events introduces significant risks related to confidentiality, integrity, and availability of data flowing through the system. Attackers can intercept sensitive information transmitted between microservices by reading published events, leading to potential data breaches compliant with regulations such as GDPR or HIPAA depending on the data type. Simultaneously, the capability to inject malicious payloads into event streams allows for supply chain attacks where compromised data is propagated downstream to other services that trust these inputs. This can lead to further exploitation of dependent applications, escalating the scope of compromise beyond the Vanus cluster itself.
In terms of threat modeling and adversary behavior, this vulnerability aligns with MITRE ATT&CK techniques related to Initial Access via Valid Accounts or Default Credentials, specifically T1078: Valid Accounts. The attacker leverages pre-existing credentials that were not rotated during deployment, a common misconfiguration in containerized environments where default settings are often left unchanged for convenience. This allows the adversary to establish a foothold and move laterally within the cluster without triggering typical intrusion detection systems that monitor for brute-force or credential stuffing attacks, as no such activity occurs; instead, the attacker simply presents the known static token.
Mitigation strategies must prioritize immediate remediation of this configuration error. The primary action is to upgrade Vanus to a version beyond 0.9.0 if available, where default credentials have been removed or require explicit user initialization. For environments still running affected versions, administrators must immediately rotate all administrative tokens and enforce strict access control policies that prohibit the use of hardcoded secrets in production deployments. It is also recommended to implement network-level restrictions on the gRPC proxy port using firewalls or service mesh configurations to limit exposure only to trusted internal services rather than exposing it broadly across the network segment. Regular auditing of configuration files for hard-coded strings and enforcing policy-as-code tools can prevent such misconfigurations in future deployments, ensuring that no default administrative access remains active by design.