Kapacitor v1.8.6 vulnerabiltity

Hello,
We are testing kapacitor and found that we can authenticate as any user by using a JWT token signed with an empty shared-secret. This is an authentication bypass whenever shared-secret is left empty in the configuration.

It occurs in Kapacitor/services/httpd/handler.go, in the BearerAuthentication case (lines 613–630):

‘’’

case BearerAuthentication:

keyLookupFn := func(token \*jwt.Token) (interface{}, error) {

    // Check for expected signing method.

    if \_, ok := token.Method.(\*jwt.SigningMethodHMAC); !ok {

        return nil, fmt.Errorf("unexpected signing method: %v", token.Header\["alg"\])

    }

    return \[\]byte(h.sharedSecret), nil

}

// Parse and validate the token.

token, err := jwt.Parse(creds.Token, keyLookupFn)

if err != nil {

    HttpError(w, fmt.Sprintf("invalid token: %s", err.Error()), false, http.StatusUnauthorized)

    return

} else if !token.Valid {

    HttpError(w, "invalid token", false, http.StatusUnauthorized)

    return

}

‘’’

The code does not check that h.sharedSecret is non-empty, it is returned directly as the HMAC verification key. The JWT library in use (github.com/golang-jwt/jwt/v4 v4.5.2) does not reject an empty key either: its SigningMethodHMAC.Verify validates only the key type ([]byte), never its length. So, when shared-secret is empty (the default in the generated config), an attacker can sign an HS256 token with the empty key and it passes token.Valid. The handler then trusts the username claim (line ~646) and resolves that user via AuthService.User(username).

This is the same root cause as CVE-2019-20933 ( Password bypass vulnerability · Issue #12927 · influxdata/influxdb · GitHub ), in the same code lineage.

So, anyone who can reach the Kapacitor API can forge a Bearer token for any username, without knowing any secret, and bypass authentication. Even with an authentication backend enabled ([auth] enabled = true), this allows impersonating any user, including administrators, with full read and modify access to tasks, templates, and configuration.

Suggest remediation:

Reject JWT authentication when the shared secret is empty. In the Bearer branch, fail closed before parsing:

case BearerAuthentication:

if h.sharedSecret == "" {

HttpError(w, "bearer authentication is not enabled", false, http.StatusUnauthorized)

return

}

// ... existing keyLookupFn / jwt.Parse ...

This mirrors the InfluxDB fixes for CVE-2019-20933.

Hey there,

For issues like these, please contact us by email at security@influxdata.com, as that goes directly to our security team and notifies them immediately. The community forum isn’t really the best venue to have these conversations. I have already alerted them to this post and they’re looking into it, and they can give you a full reply if you reach out at that email address.

Hello,
I will send the info to the team at security@influxdata.com
Thank you for the reply.