CVE-2025-61673: Karapace Auth Bypass Vulnerability

CVE-2025-61673 Overview

CVE-2025-61673 is an authentication bypass vulnerability in Karapace, an open-source implementation of Kafka REST proxy and Schema Registry maintained by Aiven. Versions 5.0.0 and 5.0.1 fail to enforce OAuth 2.0 Bearer Token authentication when a request omits the Authorization header. The token validation logic is skipped entirely under this condition, allowing unauthenticated attackers to read and write to Schema Registry endpoints. The flaw effectively neutralizes the OAuth authentication mechanism on affected deployments. The issue is tracked as [CWE-288: Authentication Bypass Using an Alternate Path or Channel] and is fixed in version 5.0.2.

Critical Impact

Unauthenticated network attackers can read and modify Kafka Schema Registry data on Karapace 5.0.0 and 5.0.1 deployments configured with OAuth 2.0 Bearer Token authentication.

Affected Products

• Karapace 5.0.0
• Karapace 5.0.1
• Deployments configured to use OAuth 2.0 Bearer Token authentication

Discovery Timeline

• 2025-10-03 - CVE-2025-61673 published to the National Vulnerability Database (NVD)
• 2026-04-15 - Last updated in NVD database

Technical Details for CVE-2025-61673

Vulnerability Analysis

Karapace exposes HTTP endpoints that act as a Kafka REST proxy and Confluent-compatible Schema Registry. When operators configure OAuth 2.0 Bearer Token authentication, the server is expected to validate a JWT supplied in the Authorization: Bearer <token> header on every request. In versions 5.0.0 and 5.0.1, the authentication middleware reaches the token validation routine only when the header is present. Requests that omit the header bypass validation entirely and are processed as if authenticated.

The impact extends to both read and write operations against Schema Registry endpoints, including subject creation, schema registration, and schema deletion. An attacker can poison schemas, register incompatible versions, or exfiltrate schema definitions describing internal data models. Because Schema Registry data governs serialization across Kafka producers and consumers, malicious modifications can break production pipelines or enable downstream deserialization attacks.

Root Cause

The root cause is a missing default-deny branch in the authentication handler. The code conditionally invoked OAuth token validation only when the Authorization header existed, instead of rejecting requests that lacked credentials. This is a classic [CWE-288] pattern where an alternate request path bypasses the intended security control. The fix in pull request #1143 ensures that missing or malformed Authorization headers result in an authentication failure rather than implicit success.

Attack Vector

Exploitation requires only network access to the Karapace HTTP endpoint. An attacker issues standard REST requests to Schema Registry paths such as /subjects, /subjects/{subject}/versions, or /config without supplying any Authorization header. The server processes these requests with full privileges. No user interaction, prior credentials, or social engineering is required, and the attack is trivial to automate.

No verified public proof-of-concept code is available. See the GitHub Security Advisory GHSA-vq25-vcrw-gj53 for vendor technical details.

Detection Methods for CVE-2025-61673

Indicators of Compromise

• HTTP requests to Karapace endpoints (/subjects, /schemas, /config, /compatibility) that lack an Authorization header but receive 2xx responses.
• Unexpected schema registrations, deletions, or compatibility setting changes that do not correlate with known producer or CI/CD activity.
• Access log entries showing successful Schema Registry writes from source IPs outside the approved producer or operator network ranges.

Detection Strategies

• Audit Karapace access logs for requests missing the Authorization header on protected paths and treat any successful responses as confirmed exploitation.
• Compare current Schema Registry subject and version inventories against known-good baselines to identify unauthorized changes.
• Enable verbose authentication logging in Karapace and alert on requests where token validation was not executed.

Monitoring Recommendations

• Place Karapace behind a reverse proxy or API gateway that enforces presence of the Authorization header at the edge.
• Forward Karapace and gateway logs to a centralized SIEM and build alerts for anomalous Schema Registry write volume or source diversity.
• Monitor Kafka broker activity for producers using newly registered schema IDs that do not match expected application identifiers.

How to Mitigate CVE-2025-61673

Immediate Actions Required

• Upgrade Karapace to version 5.0.2 or later, which contains the official fix from pull request #1143.
• Restrict network access to Karapace endpoints using firewall rules or service mesh policies until the upgrade is complete.
• Review Schema Registry state for unauthorized subjects, versions, or compatibility changes introduced while running 5.0.0 or 5.0.1.

Patch Information

The vulnerability is fixed in Karapace 5.0.2. Release notes are published at the Karapace 5.0.2 release page, and the corresponding security advisory is GHSA-vq25-vcrw-gj53. Operators should validate the upgrade by issuing a test request without an Authorization header and confirming the server returns an authentication error.

Workarounds

• Deploy an authenticating reverse proxy in front of Karapace that rejects any request lacking a valid Authorization header before it reaches the application.
• Apply network segmentation so that only trusted producer, consumer, and operator subnets can reach Karapace HTTP ports.
• Temporarily disable the Karapace REST interface if OAuth authentication is the only access control in place and an immediate upgrade is not feasible.

# Example NGINX snippet to enforce Authorization header presence at the edge
location / {
    if ($http_authorization = "") {
        return 401;
    }
    proxy_pass http://karapace_upstream;
}