etcd is a distributed key-value store for the data of a distributed system. 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. In unpatched etcd clusters with etcd auth enabled, unauthorized users are able to call MemberList and learn cluster topology, including member IDs and advertised endpoints; call Alarm, which can be abused for operational disruption or denial of service; use Lease APIs, interfering with TTL-based keys and lease ownership; and/or trigger compaction, permanently removing historical revisions and disrupting watch, audit, and recovery workflows. Kubernetes does not rely on etcd’s built-in authentication and authorization. Instead, the API server handles authentication and authorization itself, so typical Kubernetes deployments are not affected. Versions 3.4.42, 3.5.28, and 3.6.9 contain a patch. If upgrading is not immediately possible, reduce exposure by treating the affected RPCs as unauthenticated in practice. Restrict network access to etcd server ports so only trusted components can connect and/or require strong client identity at the transport layer, such as mTLS with tightly scoped client certificate distribution.
CVE-2026-33413 is a critical authentication bypass vulnerability in etcd versions prior to 3.4.42, 3.5.28, and 3.6.9 that allows unauthorized users to access sensitive cluster operations including topology discovery, lease manipulation, and compaction. This affects etcd clusters with authentication enabled that expose gRPC APIs to untrusted networks. While Kubernetes deployments are typically protected by API server-level authentication, standalone etcd deployments and non-Kubernetes distributed systems are at significant risk of operational disruption and data integrity compromise.
IMMEDIATE ACTIONS:
1. Inventory all etcd deployments across your infrastructure and identify versions prior to 3.4.42, 3.5.28, and 3.6.9
2. Assess network exposure: determine if etcd gRPC ports (default 2379-2380) are accessible from untrusted networks
3. Review etcd authentication configuration and audit logs for unauthorized access attempts
PATCHING GUIDANCE:
1. Upgrade etcd to patched versions: 3.4.42, 3.5.28, 3.6.9 or later immediately
2. Plan upgrades during maintenance windows with zero-downtime rolling updates where possible
3. Test patches in non-production environments first
4. Verify cluster health and member status post-upgrade
COMPENSATING CONTROLS (if immediate patching not possible):
1. Implement network segmentation: restrict etcd server port access (2379-2380) to only trusted components using firewall rules
2. Deploy mTLS (mutual TLS) with tightly scoped client certificates for all etcd connections
3. Disable or restrict access to vulnerable RPC methods: MemberList, Alarm, Lease APIs, and Compact operations
4. Implement API gateway or proxy layer with additional authentication/authorization checks
5. Monitor and log all etcd API calls for anomalous access patterns
DETECTION RULES:
1. Alert on MemberList RPC calls from unauthorized sources
2. Monitor for Alarm RPC invocations outside normal operational windows
3. Track Lease API modifications and compaction operations
4. Detect gRPC connections from unexpected network segments
5. Flag authentication failures followed by successful RPC execution
6. Monitor etcd audit logs for privilege escalation patterns
الإجراءات الفورية:
1. قم بحصر جميع نشرات etcd عبر البنية التحتية الخاصة بك وحدد الإصدارات السابقة للإصدارات 3.4.42 و 3.5.28 و 3.6.9
2. قيّم التعرض للشبكة: حدد ما إذا كانت منافذ gRPC الخاصة بـ etcd (الافتراضية 2379-2380) يمكن الوصول إليها من الشبكات غير الموثوقة
3. راجع تكوين المصادقة في etcd وسجلات التدقيق لمحاولات الوصول غير المصرح به
إرشادات التصحيح:
1. قم بترقية etcd إلى الإصدارات المصححة: 3.4.42 و 3.5.28 و 3.6.9 أو أحدث على الفور
2. خطط للترقيات أثناء نوافذ الصيانة مع تحديثات متدرجة بدون توقف حيث أمكن
3. اختبر التصحيحات في بيئات غير الإنتاج أولاً
4. تحقق من صحة المجموعة وحالة العضو بعد الترقية
الضوابط التعويضية (إذا لم يكن التصحيح الفوري ممكناً):
1. تنفيذ تقسيم الشبكة: تقييد الوصول إلى منفذ خادم etcd (2379-2380) فقط للمكونات الموثوقة باستخدام قواعد جدار الحماية
2. نشر mTLS (TLS المتبادل) مع شهادات عميل محدودة النطاق لجميع اتصالات etcd
3. تعطيل أو تقييد الوصول إلى طرق RPC الضعيفة: MemberList و Alarm و Lease APIs وعمليات Compact
4. تنفيذ بوابة API أو طبقة وكيل مع فحوصات مصادقة/تفويض إضافية
5. مراقبة وتسجيل جميع استدعاءات API الخاصة بـ etcd للأنماط الشاذة
قواعد الكشف:
1. تنبيه على استدعاءات MemberList RPC من مصادر غير مصرح بها
2. مراقبة استدعاءات Alarm RPC خارج نوافذ التشغيل العادية
3. تتبع تعديلات Lease API وعمليات الضغط
4. كشف اتصالات gRPC من قطاعات شبكة غير متوقعة
5. وضع علم على فشل المصادقة متبوعاً بتنفيذ RPC ناجح
6. مراقبة سجلات تدقيق etcd لأنماط تصعيد الامتيازات