CVE-2026-33413: Etcd Auth Bypass Vulnerability

CVE-2026-33413 Overview

CVE-2026-33413 is an authorization bypass vulnerability (CWE-862: Missing Authorization) in etcd, a distributed key-value store commonly used for storing configuration data in distributed systems. Prior to versions 3.4.42, 3.5.28, and 3.6.9, unauthorized users may bypass authentication or authorization checks and call certain etcd functions in clusters that expose the gRPC API to untrusted or partially trusted clients.

Critical Impact

Unauthorized attackers can bypass authentication to enumerate cluster topology, disrupt operations via Alarm API abuse, interfere with TTL-based keys through Lease APIs, and trigger compaction to permanently remove historical revisions—impacting watch, audit, and recovery workflows.

Affected Products

• etcd versions prior to 3.4.42
• etcd versions prior to 3.5.28
• etcd versions prior to 3.6.9

Discovery Timeline

• 2026-03-26 - CVE CVE-2026-33413 published to NVD
• 2026-03-26 - Last updated in NVD database

Technical Details for CVE-2026-33413

Vulnerability Analysis

This vulnerability stems from missing authorization checks in etcd's gRPC API implementation. When etcd authentication is enabled, certain RPC endpoints fail to properly validate caller permissions, allowing unauthorized users to invoke sensitive functions. The vulnerability is exploitable over the network without requiring any privileges or user interaction, making it particularly dangerous for internet-exposed etcd deployments.

In affected configurations, attackers can perform multiple unauthorized operations including calling MemberList to discover cluster topology (member IDs and advertised endpoints), invoking the Alarm API for operational disruption, manipulating Lease APIs to interfere with TTL-based keys, and triggering compaction operations that permanently remove historical revisions.

It is important to note that typical Kubernetes deployments are not affected by this vulnerability because Kubernetes does not rely on etcd's built-in authentication and authorization. Instead, the Kubernetes API server handles authentication and authorization itself before interacting with etcd.

Root Cause

The root cause is CWE-862: Missing Authorization. Specific gRPC RPC handlers in etcd do not perform adequate authorization checks when etcd authentication is enabled. These affected RPCs—including MemberList, Alarm, Lease-related APIs, and compaction operations—can be invoked by any client with network access to the gRPC endpoint, regardless of their authentication status.

Attack Vector

The attack vector is network-based. An attacker with network access to the etcd gRPC API port (typically port 2379) can send crafted gRPC requests to the vulnerable endpoints. Since the authorization checks are missing, these requests are processed without verifying the caller's identity or permissions.

The vulnerability affects etcd clusters where the gRPC API is exposed to untrusted or partially trusted network segments and etcd's built-in authentication is relied upon for access control. Exploitation does not require any authentication credentials or user interaction.

The attack flow involves an attacker connecting to the exposed etcd gRPC endpoint and invoking sensitive RPCs such as MemberList for reconnaissance, Alarm for denial of service, Lease APIs to disrupt TTL-based workflows, or compaction to destroy historical data needed for audit and recovery purposes.

Detection Methods for CVE-2026-33413

Indicators of Compromise

• Unusual gRPC requests to MemberList, Alarm, Lease, or Compaction endpoints from unexpected source IPs
• Increased alarm creation or deletion activity in etcd audit logs
• Unexpected compaction operations that remove historical revisions
• Lease manipulation from clients that should not have access to lease management

Detection Strategies

• Monitor etcd audit logs for unauthorized RPC calls to sensitive endpoints
• Implement network-level monitoring to detect connections to etcd gRPC ports from untrusted sources
• Alert on unexpected MemberList queries that could indicate reconnaissance activity
• Track compaction operations and correlate with authorized maintenance windows

Monitoring Recommendations

• Enable comprehensive etcd audit logging to capture all RPC invocations
• Configure network intrusion detection rules to identify anomalous gRPC traffic patterns
• Implement alerting for any etcd API access from non-whitelisted IP addresses
• Regularly review etcd cluster membership and lease activity for unauthorized changes

How to Mitigate CVE-2026-33413

Immediate Actions Required

• Upgrade etcd to version 3.4.42, 3.5.28, or 3.6.9 depending on your version branch
• Restrict network access to etcd server ports so only trusted components can connect
• Implement mTLS with tightly scoped client certificate distribution for transport-layer authentication
• Treat affected RPCs as unauthenticated in practice until patched

Patch Information

Patches are available in etcd versions 3.4.42, 3.5.28, and 3.6.9. These versions address the missing authorization checks in the affected gRPC RPC handlers. Organizations should upgrade to the appropriate patched version for their deployment branch.

For detailed patch information and security advisory, see the GitHub Security Advisory GHSA-q8m4-xhhv-38mg.

Workarounds

• Restrict network access to etcd gRPC ports (typically 2379) using firewall rules to allow only trusted components
• Require strong client identity at the transport layer by implementing mTLS with tightly scoped client certificate distribution
• Deploy etcd behind a network boundary or service mesh that provides additional authentication enforcement
• Consider using Kubernetes-managed etcd deployments where the API server handles authentication independently

# Example: Restrict etcd access using iptables
# Allow only specific trusted IPs to connect to etcd gRPC port
iptables -A INPUT -p tcp --dport 2379 -s 10.0.0.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 2379 -j DROP

# Example: Enable mTLS in etcd configuration
# etcd.conf.yml
# client-transport-security:
#   cert-file: /path/to/server.crt
#   key-file: /path/to/server.key
#   client-cert-auth: true
#   trusted-ca-file: /path/to/ca.crt