CVE-2026-80354 in Camel K
Summary
by MITRE • 09/10/2026
Authorization bypass through User-Controlled key vulnerability in Apache Camel K.
An authorization vulnerability in custom resource resolution allows a tenant to reference secrets by name in the operator namespace, potentially exposing secrets belonging to other tenants or operator components.
This issue affects Apache Camel K: from 2.0.0 before 2.9.3, from 2.10.1 before 2.10.2.
Users are recommended to upgrade to version 2.9.3, 2.10.2 or 2.11.0, which fixes the issue.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/10/2026
The vulnerability identified in Apache Camel K represents a critical authorization bypass flaw rooted in how custom resources resolve references to Kubernetes secrets. In containerized environments utilizing operator patterns like those found in Apache Camel K, it is standard practice for tenants or applications running within specific namespaces to reference external configuration data stored as secrets. The core technical deficiency lies in the validation logic governing these secret references. Specifically, when a tenant attempts to configure an integration by pointing to a secret name, the system fails to adequately verify that the referenced secret resides within the same namespace as the requesting resource or is explicitly permitted for cross-namespace access under strict security policies. This oversight allows a malicious actor operating with limited privileges in one namespace to construct requests that target secrets located in other namespaces, including those belonging to different tenants or critical operator components responsible for managing the integration lifecycle.
From an operational perspective, this flaw enables unauthorized data exfiltration and potential privilege escalation within the Kubernetes cluster. By referencing secrets by name without proper scope validation, a compromised tenant account can retrieve sensitive credentials such as database passwords, API keys, or TLS certificates intended for other services. This exposure violates fundamental principles of multi-tenancy isolation, where strict boundaries must be maintained between different logical tenants sharing the same infrastructure. The ability to read arbitrary secrets in the operator namespace is particularly severe because these secrets often contain high-level permissions required for managing Camel K integrations, thereby allowing an attacker to potentially manipulate or disrupt integration deployments across the entire cluster.
This vulnerability aligns with CWE-284 Improper Access Control and CVE classification standards related to authorization bypasses where user-controlled input influences security-critical decisions without adequate validation. In terms of MITRE ATT&CK mapping, this behavior corresponds to techniques involving unauthorized access to sensitive information through API endpoints or resource references, specifically falling under the category of Discovery and Collection phases where an adversary gathers credentials for lateral movement or persistence. The lack of namespace-scoped checks on secret references creates a direct path for attackers to violate confidentiality guarantees established by Kubernetes RBAC policies.
To mitigate this risk, organizations must immediately upgrade Apache Camel K to version 2.9.3, 2.10.2, or the latest stable release such as 2.11.0, which implements rigorous validation checks ensuring that secret references are strictly scoped to the requesting namespace unless explicitly allowed by secure configuration patterns. In addition to upgrading, administrators should audit existing Camel K configurations for any custom resources that reference secrets across namespaces and restrict these permissions using Network Policies or RBAC rules where possible. Implementing admission controllers like OPA Gatekeeper can further enforce policies that prevent cross-namespace secret references at the API server level, providing a defense-in-depth strategy against this class of authorization bypass vulnerabilities until all instances are patched.