CVE-2026-32828: Kargo SSRF Vulnerability

CVE-2026-32828 Overview

CVE-2026-32828 is a Server-Side Request Forgery (SSRF) vulnerability in Kargo, a platform that manages and automates the promotion of software artifacts. The vulnerability exists in the http and http-download promotion steps, which fail to properly restrict requests to link-local addresses. This allows authenticated attackers with appropriate permissions to access cloud instance metadata endpoints, most critically 169.254.169.254, enabling exfiltration of sensitive data such as IAM credentials.

Critical Impact

Authenticated attackers can leverage this SSRF vulnerability to access cloud instance metadata endpoints and exfiltrate IAM credentials, potentially leading to full cloud account compromise.

Affected Products

• Kargo versions 1.4.0 through 1.6.3
• Kargo versions 1.7.0-rc.1 through 1.7.8
• Kargo versions 1.8.0-rc.1 through 1.8.11
• Kargo versions 1.9.0-rc.1 through 1.9.4

Discovery Timeline

• 2026-03-20 - CVE CVE-2026-32828 published to NVD
• 2026-03-20 - Last updated in NVD database

Technical Details for CVE-2026-32828

Vulnerability Analysis

This vulnerability is classified under CWE-918 (Server-Side Request Forgery). The flaw resides in Kargo's promotion step functionality, specifically within the http and http-download steps. These components allow users to make HTTP requests as part of the promotion workflow, but they fail to implement adequate restrictions on the target addresses that can be requested.

The vulnerability is particularly dangerous because the affected steps provide full control over request headers and HTTP methods. This capability renders cloud provider header-based SSRF mitigations completely ineffective, as attackers can craft requests that bypass security controls designed to protect metadata endpoints.

An authenticated attacker with permissions to create or update Stages, or craft Promotion resources, can exploit this vulnerability by submitting a malicious Promotion manifest. The response data from the SSRF request can be retrieved through multiple channels: Promotion status fields, Git repositories, or via a secondary http step configured to exfiltrate the data.

Root Cause

The root cause of this vulnerability is insufficient input validation and lack of proper URL filtering in the http and http-download promotion steps. The code fails to block requests to link-local addresses (169.254.0.0/16), allowing attackers to target cloud metadata services that reside at 169.254.169.254. Combined with the ability to control request headers and methods, this creates a complete bypass of typical cloud provider SSRF protections.

Attack Vector

The attack vector is network-based and requires authentication. An attacker must have permissions to create or update Stages within Kargo, or be able to craft Promotion resources. The attack flow involves:

1. Crafting a malicious Promotion manifest that targets the cloud instance metadata endpoint
2. Submitting the manifest through Kargo's normal promotion workflow
3. Leveraging the http step's ability to set arbitrary headers to bypass cloud provider protections
4. Retrieving the exfiltrated data through Promotion status fields, Git repository commits, or a secondary HTTP request

The vulnerability allows access to sensitive cloud metadata including IAM credentials, instance identity documents, and other configuration data that could facilitate further attacks against cloud infrastructure.

Detection Methods for CVE-2026-32828

Indicators of Compromise

• Unusual HTTP requests from Kargo pods targeting 169.254.169.254 or other link-local addresses
• Promotion manifests containing references to metadata endpoint URLs in http or http-download steps
• Unexpected IAM credential usage patterns that may indicate credential theft from instance metadata

Detection Strategies

• Monitor Kargo Promotion resources for suspicious URL patterns targeting link-local addresses (169.254.x.x range)
• Implement network-level monitoring for outbound connections from Kargo components to cloud metadata endpoints
• Review audit logs for creation or modification of Stages and Promotion resources by unexpected users
• Deploy runtime security tools to detect anomalous HTTP requests from Kargo containers

Monitoring Recommendations

• Enable verbose logging for Kargo promotion steps to capture HTTP request destinations
• Configure cloud provider logging (e.g., AWS CloudTrail, GCP Cloud Audit Logs) to detect unusual metadata access patterns
• Set up alerts for Promotion resources that fail with network-related errors indicating blocked metadata requests

How to Mitigate CVE-2026-32828

Immediate Actions Required

• Upgrade Kargo to patched versions: 1.6.4, 1.7.9, 1.8.12, or 1.9.5
• Review existing Promotion resources and Stages for potentially malicious configurations targeting metadata endpoints
• Audit user permissions to ensure only trusted users have access to create or modify Stages and Promotions
• Consider implementing network policies to block Kargo pod access to link-local addresses as a defense-in-depth measure

Patch Information

Kargo has released security patches that address this SSRF vulnerability. Users should upgrade to the following fixed versions:

• Version 1.6.4 for users on the 1.6.x branch
• Version 1.7.9 for users on the 1.7.x branch
• Version 1.8.12 for users on the 1.8.x branch
• Version 1.9.5 for users on the 1.9.x branch

The fix is available in commit fd25620c2473ed19bec4be4d0f181287ef0f0391. For additional details, refer to the GitHub Security Advisory and the commit implementing the fix.

Workarounds

• Implement Kubernetes NetworkPolicies to block egress traffic from Kargo pods to the 169.254.0.0/16 CIDR range
• Restrict permissions for creating and updating Stages and Promotion resources to only highly trusted users
• Consider deploying a web proxy that filters requests to link-local addresses from Kargo components
• If cloud provider supports it, enable IMDSv2 with hop limit of 1 to reduce metadata exposure (note: this does not fully mitigate the vulnerability due to header control)

# Example Kubernetes NetworkPolicy to block metadata endpoint access
kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: block-metadata-endpoint
  namespace: kargo
spec:
  podSelector:
    matchLabels:
      app: kargo
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 169.254.0.0/16
EOF