Disclosure: this page contains affiliate links. East Bay Cyber may earn a commission if you buy through them, at no extra cost to you. That never changes how we rank products. Editorial policy.
CVE-2026-111998: Vanus Token Vulnerability
TL;DR - CVE-2026-111998 is a CVSS 9.8 critical vulnerability in Vanus 0.8.0 through 0.9.0. - An unauthenticated remote attacker may obtain cluster-admin access through the gateway gRPC proxy. - No fixed version was verified; restrict exposure, rotate tokens, and investigate activity immediately.
CVE-2026-111998 is a critical Vanus vulnerability involving a hardcoded administrator bearer token. Vanus deployments running versions 0.8.0 through 0.9.0 may allow unauthenticated remote attackers to obtain cluster-admin access when the gateway gRPC proxy is reachable.
Are You Affected?
Vanus deployments running versions 0.8.0 through 0.9.0 are affected according to the available NVD record. The issue is a default-credentials vulnerability involving a hardcoded administrator bearer token. Any deployment that exposes the gateway gRPC proxy to an untrusted network should be treated as potentially reachable by an attacker.
| Field | Assessment |
|---|---|
| CVE | CVE-2026-111998 |
| CVSS | 9.8 Critical |
| CVSS vector | Not included in the retrieved NVD response; verify the canonical record before publishing the vector |
| Affected product | Vanus |
| Affected versions | 0.8.0 through 0.9.0 |
| Attack vector | Network |
| Authentication required | None |
| Privileges required | None |
| User interaction | Not required, based on the described attack |
| Patch available | No verified fixed version identified |
| CISA KEV | Not listed; on_kev: false |
The affected project is identified as Vanus Labs’ vanus-labs/vanus repository. The available material does not identify a separate affected edition or operating-system limitation. Assess every Vanus 0.8.0, 0.8.x, or 0.9.0 deployment, including installations behind reverse proxies, load balancers, or service meshes.
A deployment is not necessarily safe just because the gRPC port is not exposed directly to the Internet. An attacker who can reach the gateway through an internal network, compromised workstation, cloud security-group path, VPN, container network, or adjacent service may still be able to present the token. Treat the gateway as sensitive administrative infrastructure.
For background on attackers using legitimate tools and credentials after gaining access, see our guide to living-off-the-land techniques.
The Fix, If You’re in a Hurry
No specific fixed version was confirmed in the retrieved authoritative material. The available record identifies 0.8.0 through 0.9.0 as affected but does not name a release that resolves CVE-2026-111998. Do not assume that upgrading to the latest available Vanus release fixes the issue unless the Vanus project explicitly documents the correction. The required upgrade target is therefore unknown pending vendor or project confirmation.
Until a verified fix is available, restrict access to the gateway gRPC proxy to trusted management networks. Remove Internet exposure, apply firewall or security-group rules, and use an authenticated administrative jump host or private network path. Rotate or invalidate administrator and service tokens that may have been exposed. Then review namespaces, event buses, users, tokens, role bindings, and event activity for unauthorized changes.
If administrators must access Vanus remotely, use a controlled private access path rather than exposing the gateway publicly. Organizations evaluating remote-access controls can also compare VPN and ZTNA approaches. For individual administrators who need a reputable commercial VPN for general remote connectivity, Check NordVPN pricing → is one option; it does not replace network segmentation, authentication, or Vanus-specific remediation.
Technical Notes
A generic network control should deny inbound access to the gateway gRPC port from untrusted sources. The exact port depends on the deployment configuration, so identify the listener before applying the rule:
# Identify Vanus listeners and owning processes
ss -lntp
sudo lsof -nP -iTCP -sTCP:LISTEN | grep -i vanus
# Example nftables policy; replace 3000 and the trusted CIDR with
# values from the actual deployment configuration.
sudo nft add rule inet filter input tcp dport 3000 ip saddr != 10.20.0.0/16 drop
The commands above are containment examples, not a product-specific patch. Before changing production firewall policy, confirm the gateway port and trusted management CIDRs. If Vanus runs in Kubernetes, restrict the service with network policy or remove public ingress exposure. After the project publishes a confirmed fixed version, upgrade using the project’s documented release procedure rather than relying on an unverified version number.
Analyst’s Take: The first move is network containment, not an assumed upgrade: no fixed version has been verified, while the gateway can expose administrator-level operations. Token rotation and review of control-plane activity should follow, because restricting reachability does not establish whether a reachable deployment was already accessed.
How This Vulnerability Works
CVE-2026-111998 is caused by a hardcoded administrator token or default credential in Vanus application logic. The token can reportedly be submitted as a bearer credential to the gateway’s gRPC proxy. Because the token is embedded in the application rather than provisioned uniquely and securely for each deployment, an attacker who obtains or derives the value can authenticate as an administrator without first stealing a customer password.
The affected authorization level is significant. The described administrative operations include managing namespaces, event buses, users, tokens, and role bindings. The attacker may also read events and publish events. This makes the issue a control-plane compromise with possible confidentiality, integrity, and availability consequences, rather than a narrowly scoped authentication bypass.
The NVD-referenced source paths are internal/controller/tenant/controller.go, around lines 449–500, and internal/primitive/constants.go, around line 37, in the v0.9.0 source tree. A related project issue is GitHub issue #647. The retrieved source material supports the hardcoded-token description, but the exact code behavior should be independently reviewed against the project’s current source before using it to build a product-specific detection or exploit test.
Technical Notes
The relevant protocol is the gateway’s gRPC proxy, not necessarily a conventional HTTP login endpoint. Security teams should inventory gRPC listeners and proxy routes rather than limiting their review to HTTP access logs. A successful attack may appear as a normal authenticated administrative request if the gateway accepts the hardcoded bearer token.
Because the available record does not provide the token value, a safe validation approach is to inspect configuration, compiled-image provenance, and project source under controlled conditions. Do not paste a suspected administrator token into production systems or public scanning tools. Preserve the original image or binary for forensic analysis before replacing it.
Severity, Explained
The assigned CVSS score is 9.8 Critical. The described characteristics indicate a remotely reachable attack with no authentication, no required privileges, and no user interaction. The resulting impact can span confidentiality, integrity, and availability because administrative access enables control over users, credentials, authorization bindings, event buses, and event data.
The exact CVSS vector string was not included in the retrieved NVD response. The likely characteristics are network attack vector, low complexity, no privileges required, no user interaction, and high impact across the three primary impact metrics, but those details should not be published as a definitive vector until confirmed from the authoritative CVE record. The 9.8 score alone is sufficient to prioritize containment and investigation.
Operational severity may be higher in deployments that expose event data containing credentials, customer records, financial messages, or internal commands. It is also higher where Vanus has permission to publish into downstream systems or where role bindings can be used to expand access. Network isolation can reduce practical exposure, but it does not remove the vulnerability from the software.
Is It Being Exploited?
Confirmed exploitation in the wild was not established in the available research. CVE-2026-111998 is not listed in the CISA Known Exploited Vulnerabilities catalog; the lookup returned on_kev: false. There is consequently no CISA date added, due date, required action, or ransomware-campaign designation for this CVE at the time of assessment.
No dedicated public exploit repository or verified public proof-of-concept was identified in the retrieved material. The vulnerability appears straightforward to exploit if the gateway gRPC proxy is reachable because the attack reportedly relies on a fixed bearer token rather than a complex multi-step chain. Public source references and GitHub issue material may lower the barrier to independent reproduction even though a dedicated PoC was not found.
The absence of a KEV listing or public PoC is not evidence that exploitation cannot occur. Organizations should assume that exposed administrative interfaces may be tested after technical details become available. Review telemetry for the period beginning before public disclosure or internal awareness, especially where the gateway was Internet-accessible.
Detecting It in Your Environment
Start by identifying all Vanus instances and their versions. Inventory container images, package manifests, Helm values, systemd units, and deployment pipelines rather than relying only on running-process names. Focus on versions 0.8.0 through 0.9.0, and identify whether the gateway gRPC listener was reachable from the Internet, partner networks, user VLANs, Kubernetes namespaces, or cloud peering connections.
Investigate administrative changes that do not match approved maintenance. Look for new or modified users, tokens, role bindings, namespaces, and event buses, along with unexpected event reads or publications. A single suspicious operation is not proof of exploitation, but a cluster of administrative actions from an unusual source should trigger token rotation and incident response.
Technical Notes
Vanus-specific log field names and audit-event schemas were not provided in the available record. Use the following as a starting point, adapting field names to the deployment’s actual structured logs:
# Search common log locations for administrative operations and auth indicators
grep -RniE \
'grpc|bearer|authorize|authentication|admin|namespace|event.?bus|role.?binding|token|publish|read' \
/var/log/vanus /var/log 2>/dev/null
For centralized logs, an equivalent SIEM query can identify administrative activity from unexpected sources:
service.name:"vanus"
AND (
event.action:(create OR update OR delete OR publish OR read)
OR url.path:(*namespace* OR *eventbus* OR *role* OR *token* OR *user*)
)
AND NOT source.ip:(10.20.0.0/16)
The query is intentionally generic because the exact Vanus audit format and gateway paths were not verified. Network defenders should also alert on new external connections to the gateway’s gRPC listener, especially TCP sessions using HTTP/2 or gRPC characteristics. Review load-balancer, ingress, firewall, and service-mesh logs for source IPs reaching that listener, then correlate them with Vanus administrative changes.
Response and Recovery
If you identify suspicious access, preserve relevant logs, container images, binaries, and configuration before making destructive changes. Restrict the gateway first, then rotate administrator and service tokens through a trusted management path. Review role bindings, users, namespaces, event buses, and event contents for unauthorized modifications or disclosure.
Where the Vanus deployment can publish to downstream systems, assess whether an attacker could have inserted, altered, or replayed events. Coordinate with owners of connected applications and preserve message-level evidence where available. If credentials or sensitive data were present in event payloads, follow the organization’s breach-assessment and notification procedures.
After containment, rebuild from a trusted image or package source once a verified remediation path is available. Do not treat token rotation alone as proof that the hardcoded credential has been removed.
References and Further Reading
The NVD-referenced source locations are the primary technical references for understanding the reported root cause:
- Vanus tenant controller source,
v0.9.0 - Vanus primitive constants,
v0.9.0 - Vanus GitHub issue #647
- VulnCheck advisory for Vanus 0.8.0 through 0.9.0
Check the authoritative CVE record again before publication or remediation sign-off for the exact CVSS vector and any newly documented fixed release. The available material confirms the affected range and critical rating but does not confirm a remediation version. Until the project publishes that information, first limit gateway reachability, then rotate potentially exposed credentials and investigate control-plane activity.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.