CVE-2026-27111: 
NixOS vulnerability analysis and mitigation

CVE-2026-27111 is a Missing Authorization vulnerability in Akuity Kargo, a Kubernetes-native software artifact promotion management tool. Three REST API endpoints introduced in v1.9.0 fail to enforce Kargo's custom promote verb, allowing authenticated users with only standard Kubernetes RBAC permissions to bypass the intended authorization boundary and trigger freight promotions. Affected versions are v1.9.0 through v1.9.2; the issue is fixed in v1.9.3. It carries a CVSS v3.1 score of 5.0 (Medium) and a CVSS v4.0 score of 5.3 (Medium) (GitHub Advisory, Feedly).

The root cause is CWE-862 (Missing Authorization): Kargo's legacy gRPC API correctly enforces a non-standard Kubernetes "dolphin verb" called promote before allowing freight advancement, but three newer REST API handlers omit this check entirely. The affected endpoints — POST /v1beta1/projects/{project}/freight/{freight}/approve, POST /v1beta1/projects/{project}/stages/{stage}/promotions, and POST /v1beta1/projects/{project}/stages/{stage}/promotions/downstream — rely solely on standard Kubernetes RBAC (patch on freights/status or create on promotions) without additionally verifying the promote verb on the target Stage. The fix (commit 833314c) adds explicit authorizeFn calls for the promote verb in each of the three REST handlers before proceeding with the operation (GitHub Commit, GitHub Advisory).

Successful exploitation allows a low-privileged user — one deliberately denied the promote verb — to bypass separation-of-duties controls and advance Freight through promotion pipelines without authorization. Within the Kargo control plane, this results in bounded state corruption (a Stage being coerced into a state it should not reach), while downstream systems such as Argo CD may deploy incorrect artifact revisions as a result. Impact is scoped to a single Kargo Project; cross-project escalation is not possible, and no confidentiality or availability impact has been identified (GitHub Advisory).

No public proof-of-concept exploit code is known, and there is no evidence of in-the-wild exploitation as of the time of disclosure (GitHub Advisory). Exploitation requires authentication to the Kargo API server and possession of specific operational permissions (patch on freights/status or create on promotions), limiting the attacker pool to existing, partially-privileged users. The EPSS score is approximately 0.031% (very low probability of exploitation in the near term) (Feedly). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog.

1. Identify a target Kargo instance: Confirm the Kargo API server is running a version between v1.9.0 and v1.9.2 and that the REST API (/v1beta1/) is accessible over the network.
2. Obtain low-privileged credentials: Acquire credentials for a Kargo/Kubernetes account that holds patch on freights/status or create on promotions within a target Project, but that has NOT been granted the promote verb on Stages.
3. Identify target freight and stage: Enumerate available Freight and Stage resources within the accessible Project using standard Kubernetes API calls or the Kargo REST API.
4. Trigger unauthorized promotion via REST API: Send a crafted HTTP POST request to one of the vulnerable endpoints, e.g.:
   • POST /v1beta1/projects/{project}/stages/{stage}/promotions with a JSON body specifying the desired Freight name.
   • POST /v1beta1/projects/{project}/freight/{freight}/approve to approve Freight for a specific Stage.
   • POST /v1beta1/projects/{project}/stages/{stage}/promotions/downstream to promote to all downstream Stages.
5. Observe unauthorized promotion: The Kargo controller processes the Promotion resource as if it were legitimately authorized, advancing the Freight through the pipeline and potentially triggering downstream deployments (e.g., in Argo CD) (GitHub Advisory, GitHub Commit).

• Network: Unexpected HTTP POST requests to /v1beta1/projects/{project}/freight/{freight}/approve, /v1beta1/projects/{project}/stages/{stage}/promotions, or /v1beta1/projects/{project}/stages/{stage}/promotions/downstream from users or service accounts not normally expected to trigger promotions.
• Logs: Kargo API server access logs showing successful 201 Created or 200 OK responses to the above REST endpoints for accounts that lack the promote verb; audit logs recording create on promotions or patch on freights/status by accounts not in the expected promoter role.
• Kubernetes Audit: Kubernetes audit log entries showing Promotion resource creation by a subject that does not hold the promote verb on the relevant Stage, particularly via the REST API path rather than the gRPC API.
• Application State: Unexpected Stage transitions or Promotion objects appearing in a Project that do not correspond to authorized promotion activity; downstream Argo CD applications deploying artifact revisions that were not expected to be promoted (GitHub Advisory).

Upgrade Kargo to v1.9.3 or later, which adds the missing promote verb authorization check to all three affected REST API endpoints (GitHub Commit, GitHub Advisory). As a temporary workaround for organizations unable to upgrade immediately, restrict network access to the Kargo REST API (/v1beta1/) to only trusted users, or tighten Kubernetes RBAC to remove patch on freights/status and create on promotions from any accounts that should not be able to promote. After patching, audit promotion activity that occurred while running v1.9.0–v1.9.2 to identify any unauthorized promotions performed by users lacking the promote verb.

The advisory was published by Kargo maintainer krancour on February 17, 2026, with reporters credited as b0b0haha and spingARbor (GitHub Advisory). The vulnerability received coverage from automated vulnerability tracking services including Vulners, CIRCL, and CVEFeed shortly after disclosure, and was noted by INCIBE-CERT and LinuxSecurity. No significant independent researcher commentary or social media discussion has been identified beyond standard vulnerability database aggregation.