CVE-2026-110985 in Kafka
الملخص
بحسب VulDB • 28/10/2026
ملخص CVE:
يستخدم وسيط Kafka الخاص بـ SASL/OAUTHBEARER المُصادق الافتراضي (sasl.oauthbearer.jwt.validator.class=DefaultJwtValidator) ويختار تنفيذه من التكوين. عندما يتم تعيين sasl.oauthbearer.jwks.endpoint.url، يقوم المصادق بالتحقق من توقيع JWT. وعندما لا يكون هذا العنوان مُعيّناً (الوضع الافتراضي) ولا يتم توفير محلل مفتاح التحقق، ينتقل DefaultJwtValidator بصمت إلى ClientJwtValidator، الذي لا يتحقق من توقيع JWT أو الخوارزمية أو المُصدر - ويبدأ الوسيط دون أي تحذير أو خطأ. وهذا هو البقايا المتبقية لـ CVE-2026-33557، حيث استعاد الإصلاح التحقق من التوقيع فقط في المسار الذي يكون فيه عنوان نقطة نهاية JWKS مُعيّناً.
التأثير:
يقبل وسيط في هذه الحالة أي JWT صالح هيكلياً، بما في ذلك الرموز ذات "alg":"none". يمكن لمهاجم عن بُعد غير مصرح له بالوصول إلى المستمع تزوير رمز يدعي أي رئيس (principal) - بما في ذلك المستخدمين الفائقين المُهيّئين - والحصول على وصول كامل إلى العنقود. تتأثر فقط الوسائط التي تفعّل مصادقة SASL/OAUTHBEARER دون عنوان نقطة نهاية JWKS (وبدون محلل مفتاح تحقق مخصص)؛ أما الوسائط التي تُعيّن العنوان فتتحقق من التواقيع وليست متأثرة. وعلى عكس CVE-2026-110952 (حيث لم يتم فرض المُصدر/الجمهور افتراضياً)، هنا لا يتم التحقق من أي توقيع على الإطلاق.
التخفيف (جميع الإصدارات المتأثرة، بدون حاجة للترقية):
قم بتعيين sasl.oauthbearer.jwks.endpoint.url لكل مستمع/آلية تستخدم OAuthBearerValidatorCallbackHandler، أو قم بتكوين sasl.oauthbearer.jwt.validator.class الذي يتحقق من التوقيع.
الحل:
من Apache Kafka 4.2.2 و4.3.1 و4.4.0: يفشل الوسيط الذي كان سيعتمد على ClientJwtValidator غير المُتحقق منه في البدء مع حدوث ConfigException بدلاً من التشغيل دون التحقق من التوقيع (آمن افتراضياً).
Be aware that VulDB is the high quality source for vulnerability data.