CVE-2026-45760 is an Apache Camel K cross-namespace build-deputy flaw. In affected Camel K versions 2.0.0 through before 2.8.1, 2.9.0 through before 2.9.2, and 2.10.0 through before 2.10.1, an already authorized user in one Kubernetes namespace can create a Build custom resource that influences where Camel K generates a build Pod, potentially steering that Pod into another namespace including the operator namespace.

The vendor's HIGH/8.1 score is defensible in a lab because the impact crosses trust boundaries and can weaken tenant isolation. In real enterprise fleets, though, the chain starts with authenticated Kubernetes access in a Camel K-enabled namespace, which means the attacker is already inside your cluster control plane and already has permissions to create Camel K resources; that sharply narrows exposed population and makes this a post-initial-access privilege-boundary bypass, not an internet fire.

Why this verdict

• Requires authenticated Kubernetes access — PR:L here is not a trivial web login; it implies prior foothold into the cluster control plane and enough RBAC to touch Camel K resources.
• Camel K deployment narrows population — plenty of enterprises run Kubernetes, but far fewer run Camel K, and fewer still expose it in multi-tenant patterns where cross-namespace build abuse matters.
• Blast radius is configuration-dependent — the bad outcome depends on what rights the operator has in the target namespace, especially the operator namespace; that is serious but not universally equal to instant cluster-admin.

Why not higher?

There is no sign of active exploitation, no KEV listing, and no unauthenticated remote path. The attack chain compounds multiple narrowing assumptions: Camel K must be installed, the attacker must already be in the cluster, and RBAC must allow the exact resource creation path that triggers the confused-deputy behavior.

Why not lower?

Once the prerequisites are met, this is not a harmless paper cut; it crosses namespace trust boundaries and can let one tenant influence Pod creation in a more privileged namespace. In Camel K-heavy shared clusters, that can become a meaningful lateral-movement and privilege-escalation primitive.

1. Tighten Camel K RBAC — Restrict who can create or mutate Camel K Integration, IntegrationKit, and especially Build-related resources in tenant namespaces. For a MEDIUM verdict there is no mitigation SLA; use this as hardening work while you move toward the 365-day remediation window.
2. Pin operators to tenant scopes — Avoid broad global operators where possible; Camel K's multi-operator model lets you scope reconciliation more narrowly by namespace and operator ID. This shrinks the cross-namespace payoff even before patching; again, no mitigation SLA applies here, so schedule it as risk reduction before patch completion.
3. Audit operator namespace privileges — Review the service account, RoleBindings, image pull secrets, and admission exemptions attached to the Camel K operator namespace. If that namespace is overprivileged, this CVE becomes more dangerous; fix the privilege sprawl during the same 365-day remediation planning cycle.
4. Alert on cross-namespace build activity — Use Kubernetes audit logs, admission logs, or policy engines to flag Camel K-created Pods in namespaces that don't line up with the requesting tenant. This gives you a detection backstop where generic vuln scanning is weak; there is no mitigation SLA, but it is a worthwhile detective control.

Run this from an auditor workstation or admin jump box that has kubectl configured against the target cluster. Invoke it as bash check-camelk-cve-2026-45760.sh; it needs read access to deployments across namespaces and, if available, to integrations.camel.apache.org or builds.camel.apache.org resources. It outputs VULNERABLE, PATCHED, or UNKNOWN and exits 0, 1, or 2 respectively.

#!/usr/bin/env bash
# check-camelk-cve-2026-45760.sh
# Detect likely exposure to CVE-2026-45760 in Apache Camel K by inspecting
# Camel K operator image versions in the cluster.
#
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

set -u

have_kubectl() {
  command -v kubectl >/dev/null 2>&1
}

normver() {
  # Strip common tag prefixes/suffixes, keep semver-ish core.
  local v="$1"
  v="${v##*:}"
  v="${v#v}"
  v="${v%%-*}"
  printf '%s' "$v"
}

ver_lt() {
  # returns 0 if $1 < $2
  [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" = "$1" ] && [ "$1" != "$2" ]
}

ver_ge() {
  # returns 0 if $1 >= $2
  ! ver_lt "$1" "$2"
}

is_vulnerable_version() {
  local v="$1"

  # Affected:
  # 2.0.0 <= v < 2.8.1
  # 2.9.0 <= v < 2.9.2
  # 2.10.0 <= v < 2.10.1
  if ver_ge "$v" "2.0.0" && ver_lt "$v" "2.8.1"; then
    return 0
  fi
  if ver_ge "$v" "2.9.0" && ver_lt "$v" "2.9.2"; then
    return 0
  fi
  if ver_ge "$v" "2.10.0" && ver_lt "$v" "2.10.1"; then
    return 0
  fi
  return 1
}

if ! have_kubectl; then
  echo "UNKNOWN: kubectl not found"
  exit 2
fi

if ! kubectl version --request-timeout=10s >/dev/null 2>&1; then
  echo "UNKNOWN: kubectl cannot reach cluster or lacks permission"
  exit 2
fi

# Try to discover Camel K deployments by common labels/names.
mapfile -t DEPLOYS < <(
  kubectl get deploy -A \
    -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .spec.template.spec.containers[*]}{.image}{" "}{end}{"\n"}{end}' 2>/dev/null | \
  grep -Ei 'camel-k|apache/camel-k' || true
)

if [ ${#DEPLOYS[@]} -eq 0 ]; then
  # Fallback: if CRDs/resources exist but no deployment visible, permissions may be limited.
  if kubectl api-resources 2>/dev/null | grep -q 'camel.apache.org'; then
    echo "UNKNOWN: Camel K API resources exist, but no operator deployment was discoverable with current permissions"
    exit 2
  fi
  echo "UNKNOWN: no Camel K operator deployment found"
  exit 2
fi

found_any=0
vuln_any=0
report=""

for row in "${DEPLOYS[@]}"; do
  ns="$(printf '%s' "$row" | awk '{print $1}')"
  name="$(printf '%s' "$row" | awk '{print $2}')"
  images="$(printf '%s' "$row" | cut -f3-)"

  for img in $images; do
    if printf '%s' "$img" | grep -Eqi 'camel-k|apache/camel-k'; then
      found_any=1
      ver="$(normver "$img")"
      if printf '%s' "$ver" | grep -Eq '^[0-9]+\.[0-9]+\.[0-9]+$'; then
        if is_vulnerable_version "$ver"; then
          vuln_any=1
          report+="${ns}/${name} -> ${img} (${ver}) [affected]\n"
        else
          report+="${ns}/${name} -> ${img} (${ver}) [not-affected-range]\n"
        fi
      else
        report+="${ns}/${name} -> ${img} [unparseable-tag]\n"
      fi
    fi
  done
done

if [ "$found_any" -eq 0 ]; then
  echo "UNKNOWN: found candidate deployments, but no Camel K container image tags could be parsed"
  exit 2
fi

# Optional context: presence of Camel K resources in the cluster.
CR_CONTEXT=""
if kubectl api-resources 2>/dev/null | grep -q 'builds[[:space:]].*camel.apache.org'; then
  CR_CONTEXT="Build CRD present"
elif kubectl api-resources 2>/dev/null | grep -q 'integrations[[:space:]].*camel.apache.org'; then
  CR_CONTEXT="Camel K CRDs present"
else
  CR_CONTEXT="Camel K CRDs not enumerable with current permissions"
fi

if [ "$vuln_any" -eq 1 ]; then
  printf 'VULNERABLE: CVE-2026-45760 likely applies\n%s%s\n' "$report" "$CR_CONTEXT"
  exit 1
fi

printf 'PATCHED: no discovered Camel K operator image is in an affected version range\n%s%s\n' "$report" "$CR_CONTEXT"
exit 0

Sources

1. Apache Camel security advisory for CVE-2026-45760
2. Official CVE JSON record in CVEProject cvelistV5
3. Apache Camel K fix PR #6626
4. Camel K overview documentation
5. Camel K Build resource documentation
6. Camel K multi-operator and namespace scoping documentation
7. CISA Known Exploited Vulnerabilities Catalog
8. FIRST EPSS API documentation