CVE-2025-61673: Karapace OAuth Authentication Bypass Issue

CVE-2025-61673 Overview

CVE-2025-61673 is an authentication bypass vulnerability in Karapace, an open-source implementation of the Kafka REST proxy and Schema Registry. The flaw affects Karapace versions 5.0.0 and 5.0.1 when configured to use OAuth 2.0 Bearer Token authentication. The token validation logic is skipped entirely when a request omits the Authorization header. An unauthenticated remote attacker can read and write to Schema Registry endpoints that should be protected by OAuth. This renders the OAuth authentication mechanism ineffective and allows tampering with schemas managed by the registry. The issue is resolved in Karapace version 5.0.2.

Critical Impact
Unauthenticated attackers can read and modify Schema Registry data on Karapace 5.0.0 and 5.0.1 instances, bypassing OAuth 2.0 Bearer Token authentication entirely.

Affected Products

Karapace 5.0.0 (OAuth 2.0 Bearer Token authentication configurations)
Karapace 5.0.1 (OAuth 2.0 Bearer Token authentication configurations)
Kafka Schema Registry and REST endpoints exposed by the affected Karapace versions

Discovery Timeline

2025-10-03 - CVE-2025-61673 published to NVD
2026-04-15 - Last updated in NVD database

Technical Details for CVE-2025-61673

Vulnerability Analysis

Karapace exposes HTTP endpoints for managing Kafka schemas and producing or consuming records through the REST proxy. When deployed with OAuth 2.0 Bearer Token authentication, Karapace is expected to validate the JSON Web Token (JWT) presented in the Authorization header on every protected request. In versions 5.0.0 and 5.0.1, the authentication middleware short-circuits when the Authorization header is missing instead of rejecting the request. The token validation path is not reached, and the request proceeds as if it were authorized. The vulnerability is categorized under [CWE-288: Authentication Bypass Using an Alternate Path or Channel].

Root Cause

The root cause is a missing default-deny check in the OAuth request handler. The handler only enforces token validation when an Authorization header is present, treating its absence as a non-authenticated path rather than an unauthorized request. Operators relying on OAuth as the sole access control mechanism for the Schema Registry have no compensating gate. The fix in version 5.0.2 rejects requests that lack the required credentials before any handler logic executes. See the GitHub Security Advisory GHSA-vq25-vcrw-gj53 and the corresponding pull request commit for the code-level remediation.

Attack Vector

The vulnerability is reachable over the network with no authentication and no user interaction. An attacker who can reach the Karapace HTTP listener sends standard Schema Registry requests, such as GET /subjects or POST /subjects/{subject}/versions, without an Authorization header. The server processes the requests and returns or modifies schema data. Write access lets an attacker register, evolve, or delete schemas, which can disrupt downstream Kafka producers and consumers that rely on schema compatibility checks.

No verified public exploit code is available at this time. The vulnerability mechanism is described in prose based on the upstream advisory and patch commit referenced above.

Detection Methods for CVE-2025-61673

Indicators of Compromise

HTTP requests to Karapace Schema Registry endpoints (/subjects, /schemas, /config, /compatibility) that lack an Authorization header but receive 2xx responses.
Unexpected schema registrations, version bumps, or deletions in audit logs from sources outside the normal CI/CD pipeline.
Access log entries for Karapace listeners showing requests from IP ranges that do not match known service or application clients.

Detection Strategies

Inspect Karapace and upstream reverse-proxy access logs for requests missing the Authorization header on protected paths.
Diff the current schema inventory against the last known-good export to identify unauthorized changes introduced during the exposure window.
Correlate Schema Registry write events with deployment pipeline activity to surface out-of-band modifications.

Monitoring Recommendations

Forward Karapace HTTP access and application logs into a centralized log platform with retention sufficient to cover the period since 5.0.0 was deployed.
Alert on POST, PUT, and DELETE requests to Schema Registry endpoints that originate from unexpected source addresses or user agents.
Track the rate of 401 responses; a sudden drop following a deployment of 5.0.0 or 5.0.1 may indicate the bypass is being exercised.

How to Mitigate CVE-2025-61673

Immediate Actions Required

Upgrade all Karapace instances running 5.0.0 or 5.0.1 to version 5.0.2.
Restrict network access to Karapace HTTP listeners to known client CIDR ranges until the upgrade is complete.
Audit Schema Registry contents for unauthorized schema additions, modifications, or deletions since 5.0.0 was deployed.

Patch Information

The vendor fix is included in Karapace 5.0.2. The patch ensures that requests without a valid Authorization header are rejected before reaching protected handler logic. Refer to the Karapace 5.0.2 release notes and the fix commit for details.

Workarounds

Place Karapace behind a reverse proxy or API gateway that enforces presence and validation of the Authorization header before forwarding requests.
Apply network-level access controls (firewall rules, security groups, service mesh policies) that limit Schema Registry access to authenticated service identities.
Temporarily disable write methods (POST, PUT, DELETE) at the proxy layer for clients that only require read access until the upgrade is applied.

bash

# Example NGINX snippet to require an Authorization header in front of Karapace
location / {
    if ($http_authorization = "") {
        return 401;
    }
    proxy_pass http://karapace_backend;
}