ZeroHour
oss-securitypublished ()ingested 1
Part of a story covered by 3 sources: “Apache Camel K: three tenant-isolation flaws (CVE-2026-80351, CVE-2026-80352, CVE-2026-80354) fixed in 2.9.3/2.10.2” — merged summary and timeline →

CVE-2026-80354: Apache Camel K: Camel K Builder trait mavenProfiles ValueSources resolve tenant-named secrets in operator namespace

mediumVulnerabilityimportance 28CVE-2026-80354
AI summary · glm-5.3-flash

Apache Camel K CVE-2026-80354 lets tenants reference secrets by name in the operator namespace, exposing other tenants' secrets.

Apache disclosed a moderate authorization bypass (CVE-2026-80354) in Apache Camel K's Builder trait, where mavenProfiles ValueSources resolve tenant-named secrets in the operator namespace. A tenant can reference secrets by name, potentially exposing secrets belonging to other tenants or the operator. Affected versions are 2.0.0 before 2.9.3 and 2.10.1 before 2.10.2; fixes are available in 2.9.3 and 2.10.2.

  • Authorization bypass via user-controlled key in custom resource resolution.
  • Tenants can resolve secrets in the operator namespace across tenant boundaries.
  • Fixed in Apache Camel K 2.9.3 and 2.10.2; rated moderate severity.

Vulnerabilities mentionedAll →

CVEVulnerabilityCVSSEPSSFlagsAffectedExposurePublished
CVE-2026-80354
Cross-Tenant Secret Exposure via Authorization Bypass in Apache Camel K

Apache Camel K, the Kubernetes-native integration runtime for Apache Camel, has an authorization flaw (CWE-639, user-controlled key) in its custom resource resolution: tenant-supplied values, such as the Builder trait's mavenProfiles ValueSources, cause the operator to resolve secrets by name from the operator's namespace instead of the tenant's own namespace. A tenant that can set a secret name on an Integration build resource can therefore have the operator pull in a secret belonging to another tenant or to operator components. An attacker with tenant-level access gains access to those secrets, potentially obtaining credentials shared across the multi-tenant cluster. Users running Apache Camel K 2.0.0 through 2.9.2 or version 2.10.1 are affected; fixes are available in 2.9.3, 2.10.2, and 2.11.0. No public proof of concept exists, the issue is not in CISA KEV, and no in-the-wild exploitation is known.

Do: Upgrade to Apache Camel K 2.9.3, 2.10.2, or 2.11.0. As interim mitigation, review tenant-authored Integrations for secret references that resolve in the operator namespace (particularly Builder trait mavenProfiles ValueSources), restrict tenants from naming operator-namespace secrets, and rotate any sensitive secrets in the operator namespace that tenants could have referenced.

8.1
  • Apache Camel K >= 2.0.0 and < 2.9.3 (fixed in 2.9.3)
  • Apache Camel K 2.10.1 (fixed in 2.10.2); 2.11.0 is unaffected
nicheunknown; plausibly on the order of hundreds to a few thousand Kubernetes clusters, likely far fewer in strictly multi-tenant configurations where the flaw…
Full article

Posted by Pasquale Congiusti on Sep 10 Severity: moderate Affected versions: - Apache Camel K (apache/camel-k) 2.0.0 before 2.9.3 - Apache Camel K (apache/camel-k) 2.10.1 before 2.10.2 Description: 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...

This source does not provide full text. Read it at seclists.org.