Kargo Cult Security: Bypassing Auth with a Placebo Token

Kargo is the traffic controller for your Kubernetes application lifecycle. It automates the promotion of software artifacts across different stages—testing, staging, production. Because it manages this flow, it inherently holds sensitive knowledge: where your clusters are, how they are configured, and the credentials (or privileged context) needed to talk to them.

In the world of continuous delivery, components like Kargo are high-value targets. If you control the promotion logic, you control what runs in production. Usually, these tools are locked down tight with OIDC, JWTs, and rigorous identity checks.

But in CVE-2026-24748, we found that Kargo's front door wasn't locked. In fact, the bouncer at the door had a very specific, very flawed set of instructions: "If you don't recognize the ID card, assume they are a VIP and let them in."

The vulnerability lies in the authInterceptor.authenticate method within internal/server/option/auth.go. This middleware is responsible for looking at the Authorization header and deciding who you are.

Kargo supports multiple auth schemes: its own JWTs, OIDC tokens, and—crucially—Kubernetes bearer tokens. The logic flow was intended to be:

1. Is it a Kargo JWT? Verify it.
2. Is it an OIDC token? Verify it.
3. If it's neither, it must be a Kubernetes token. Let the Kubernetes API handle it later.

The fatal flaw was in step 3. The code was designed to be "fail-open" for non-JWTs. It assumed that if a token wasn't a well-formed JWT, it was an opaque token meant for the Kubernetes API server. It essentially shrugged and said, "Not my problem, the downstream API will catch it if it's fake."

> [!WARNING] > The Logic Gap: The problem is that not all endpoints backed by this interceptor actually forwarded requests to the Kubernetes API in a way that verified the token. Endpoints like GetConfig() used an internal privileged client or local data, meaning the "junk" token was never challenged. It was accepted as valid credentials for a "Kubernetes User."

Let's look at the vulnerable code in internal/server/option/auth.go. This is a classic example of implicit trust.

// BEFORE: Vulnerable Logic
untrustedClaims := jwt.RegisteredClaims{}
if _, _, err := a.parseUnverifiedJWTFn(rawToken, &untrustedClaims); err != nil {
    // This token isn't a JWT, so it's probably an opaque bearer token for the
    // Kubernetes API server. Just run with it.
    return user.ContextWithInfo(
        ctx,
        user.Info{
            BearerToken: rawToken,
        },
    ), nil
}

The comment literally says "Just run with it." In security auditing, this is what we call a "resume-generating comment."

The fix introduces a fail-closed mechanism. Instead of assuming the token is valid, Kargo now performs a "canary" request to the Kubernetes API to verify it.

// AFTER: Patched Logic
if _, _, err := a.parseUnverifiedJWTFn(rawToken, &untrustedClaims); err != nil {
    // Validate the token against the K8s API before trusting it
    if err := a.verifyKubernetesToken(ctx, rawToken); err != nil {
        return nil, connect.NewError(connect.CodeUnauthenticated, err)
    }
    // If K8s says 200 OK, then we proceed.
    return user.ContextWithInfo(...)
}

Exploiting this requires zero technical sophistication. You don't need to forge a signature. You don't need a leaked secret. You just need a non-empty string.

Because the parser fails on anything that isn't a JWT, passing a garbage string triggers the vulnerable "It must be a K8s token" path. Since the GetConfig endpoint doesn't validate the token against K8s, you get full access.

The Attack Chain:

1. Target: Identify the Kargo API (e.g., port 8080 or 443).
2. Payload: A simple GET request with a dummy Bearer token.

curl -k -X GET https://kargo.target.local/api/v1alpha1/config \
     -H "Authorization: Bearer I_AM_A_HACKER"

3. Result: The server returns 200 OK with a JSON payload containing internal cluster configurations, Argo CD endpoints, and namespace details.

It is effectively a skeleton key made of cardboard. As long as you present something, the door opens.

Why should you care about a CVSS 6.9?

1. Information Disclosure: The GetConfig() endpoint leaks the topography of your delivery pipeline. Attackers can learn where your clusters are located and how your applications are partitioned. This is the reconnaissance phase of a much larger attack.

2. Denial of Service (The Infinite Loop): The RefreshResource endpoint is also vulnerable. An attacker can hammer this endpoint with a script.

Each request triggers a reconciliation loop in Kargo. If an attacker floods this endpoint, they force the Kargo controller to constantly attempt to reconcile resources, spiking CPU usage and potentially overwhelming the underlying Kubernetes API server with status update requests. It's a fantastic way to burn your cloud budget or freeze your deployment pipeline during a critical release.