CVE-2026-27112 — kargo
Fix: akuity/kargo@155c685CVE-2026-27112 is a CWE-863 vulnerability in github.com/akuity/kargo. A fix is available for github.com/akuity/kargo — see the affected versions and patch details below.
Kargo has an Authorization Bypass Vulnerability in Batch Resource Creation API Endpoints
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-27112.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Real-World Exposure
github.com/akuity/kargo🐹github.com/akuity/kargo🐹github.com/akuity/kargoReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Summary
The batch resource creation endpoints of both Kargo's legacy gRPC API and newer REST API accept multi-document YAML payloads. When either endpoint creates a Project resource, creation of subsequent resources from that same payload belonging in that Project's underlying Kubernetes namespace, by design, proceeds using the API server's own permissions. The creator of a new Project automatically becomes its administrator, but those permissions are granted asynchronously by the management controller. The design choice to create the affected resources using the API server's own permissions averts a race and is contextually appropriate.
Specially crafted payloads can manifest a bug present in the logic of both endpoints to inject arbitrary resources (of specific types only) into the underlying namespace of an existing Project using the API server's own permissions when that behavior was not intended. Critically, an attacker may exploit this as a vector for elevating their own permissions, which can then be leveraged to achieve remote code execution or secret exfiltration. Exfiltrated artifact repository credentials can be leveraged, in turn, to execute further attacks.
In some configurations of the Kargo control plane's underlying Kubernetes cluster, elevated permissions may additionally be leveraged to achieve remote code execution or secret exfiltration using kubectl. This can reduce the complexity of the attack, however, worst case scenarios remain entirely achievable even without this.
Base Metrics
The following sections provide the rationale for the values selected for each of CVSS v4's base metrics.
Attack Vector (AV): Network
The affected endpoints are served by the Kargo API server over HTTP/HTTPS. No local or physical access is required.
Attack Complexity (AC): Low
Exploitation requires only a specially crafted YAML payload sent to an affected API endpoint.
Attack Requirements (AT): None
No specific environmental conditions are required beyond those that are typical for any Kargo instance.
Privileges Required (PR): Low
The attack relies only on the ability to authenticate to the Kargo API server along with basic permissions that are typically granted to all Kargo users.
User Interaction (UI): None
The attack is fully automated via API calls. No other user needs to take any action.
Confidentiality Impact to Vulnerable System (VC): High
Elevated permissions enable secret exfiltration from any Kargo Project.
Integrity Impact to Vulnerable System (VI): High
Elevated permissions enable tampering, up to and including remote code execution, as well as secret exfiltration from any Kargo Project. Project secrets often include credentials having write permissions to GitOps repositories. Such secrets may enable pushing configurations that impact the integrity of the vulnerable system, including Kargo Projects, Kargo control plane components, and the Kargo control plane's underlying Kubernetes cluster.
Note: Because it is an integral component of Kargo's control plane, the underlying Kubernetes cluster has been counted as a component of the vulnerable system instead of a subsequent system.
Availability Impact to Vulnerable System (VA): High
Elevated permissions enable tampering, up to and including remote code execution, as well as secret exfiltration from any Kargo Project. Project secrets often include credentials having write permissions to GitOps repositories. Such secrets may enable pushing configurations that impact the availability of the vulnerable system, including Kargo control plane components and the Kargo control plane's underlying Kubernetes cluster.
Confidentiality Impact to Subsequent Systems (SC): High
Secrets exfiltrated from Project namespaces typically contain credentials for external systems. These may enable exfiltration of further confidential information from those systems.
Integrity Impact to Subsequent Systems (SI): High
Elevated permissions enable tampering, up to and including remote code execution, as well as secret exfiltration from any Kargo Project. Project secrets often include credentials having write permissions to GitOps repositories. Such secrets may enable pushing configurations that impact the integrity of subsequent systems.
Availability Impact to Subsequent Systems (SA): High
Elevated permissions enable tampering, up to and including remote code execution, as well as secret exfiltration from any Kargo Project. Project secrets often include credentials having write permissions to GitOps repositories. Such secrets may enable pushing configurations that impact the availability of subsequent systems.
Mitigating Factors
-
Exploitation requires authentication to the Kargo API server. Anonymous access is not sufficient.
-
The most severe consequences of this vulnerability depend on a privilege escalation path (via
RoleBindinginjection) that was not identified by the original reporter, suggesting it is not immediately obvious from the bug alone. -
There is no evidence of exploitation in the wild.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/akuity/kargo | ≥ 1.9.0-rc.1&&< 1.9.3 | 1.9.3go get github.com/akuity/kargo@v1.9.3 |
| 🐹Go | github.com/akuity/kargo | ≥ 1.8.0-rc.1&&< 1.8.11 | 1.8.11go get github.com/akuity/kargo@v1.8.11 |
| 🐹Go | github.com/akuity/kargo | ≥ 1.7.0&&< 1.7.8 | 1.7.8go get github.com/akuity/kargo@v1.7.8 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/akuity/kargo, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/akuity/kargo to 1.9.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-27112 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2026-27112 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2026-27112. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-27112 in your dependencies?
O3 Security finds CVE-2026-27112 across Go dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.