Cpe:2.3:a:openchoreo:openchoreo_api:*:*:*:*:*:*:*:* - CraftedSignal Threat Feedhttps://feed.craftedsignal.io/cpes/cpe2.3aopenchoreoopenchoreo_api/Trending threats, MITRE ATT&CK coverage, and detection metadata. Fed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioThu, 03 Sep 2026 00:03:08 +0000https://feed.craftedsignal.io/favicon-32x32.pngCraftedSignal Threat Feedhttps://feed.craftedsignal.io/3232https://feed.craftedsignal.io/favicon.svgAuthorization Bypass in OpenChoreo API Endpointshttps://feed.craftedsignal.io/briefs/2026-09-openchoreo-auth-bypass/Thu, 03 Sep 2026 00:03:08 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-09-openchoreo-auth-bypass/An authorization flaw in the OpenChoreo API server allows authenticated users with project-scoped grants to execute commands and access logs across different projects within the same namespace.OpenChoreo versions prior to 1.2.3 and 1.1.6 contain an authorization bypass vulnerability (CVE-2026-73841) within the openchoreo-api component's exec and wirelogs endpoints. The API server incorrectly trusts user-supplied project identifiers to authorize requests instead of validating the target component against its actual owning project recorded in the internal resource hierarchy. Because the authorization engine only verifies if the caller holds a project-scoped grant (such as component:exec or wirelogs:view), a malicious actor with legitimate access to a single project can perform unauthorized operations on components belonging to other projects within the same Kubernetes namespace. This flaw enables cross-project command execution and unauthorized access to sensitive workload logs, potentially exposing environment variables, credentials, and secrets.

Attack Chain

  1. Attacker gains access to a low-privileged account with a valid component:exec or wirelogs:view grant for a single project within an OpenChoreo-managed namespace.
  2. Attacker identifies a high-value target component in a different project within the same namespace.
  3. Attacker crafts an HTTP request to the openchoreo-api exec or wirelogs endpoint.
  4. Attacker substitutes the project parameter in the request with the identifier of the victim's component project.
  5. The API server processes the request, resolving the target component by name without verifying the ownership relationship.
  6. The authorization engine validates the attacker's grant against the caller-supplied (spoofed) project ID.
  7. The server grants the attacker access, permitting command execution or log retrieval from the target component pod.

Impact

The vulnerability allows unauthorized users to achieve remote command execution or sensitive data exfiltration from workloads they do not own, provided the target is within the same namespace. Successful exploitation allows for the compromise of environment variables and Kubernetes Secrets associated with the targeted component, lateral movement within the cluster, and potential disruption of service integrity across different organizational teams sharing a namespace.

Recommendation

Prioritized actions for security and infrastructure teams:

  • Upgrade openchoreo-api to version 1.2.3 or 1.1.6 immediately to enforce correct project-based authorization (CVE-2026-73841).
  • Audit existing component:exec and wirelogs:view grants to ensure they are restricted to trusted operators only.
  • Segregate highly sensitive components into distinct Kubernetes namespaces to prevent cross-project access while the patch is being deployed.
  • Review cluster-gateway configuration to ensure internal proxies enforce caller authorization, addressing the related security gaps noted in GHSA-rh53-xvx2-j327.
]]>highadvisoryvulnerabilitycloud-securityauthorization-bypass