آشتی دادن گذشته: تصحیح سوابق برای CVE های Kubernetes ثابت‌نشده 😊

پروژه Kubernetes برای توانمندسازی مدیران خوشه و محققان امنیتی روی شفافیت تکیه دارد. یکی از ابزارهای مهم این شفافیت، انتشار رکوردهای CVE در پایگاه داده مشترک آسیب‌پذیری‌هاست. در جریان بررسی و بلوغ دادن به فید رسمی CVEهای Kubernetes، تیم‌ها متوجه برخی ناسازگاری‌ها در سوابق قدیمی شدند؛ رکوردهایی که برای مشکلات رفع‌نشده به‌طرز نادرستی شامل «نسخهٔ ثابت‌شده» (fixed version) بودند. کمیته پاسخ امنیتی Kubernetes (SRC) این سوابق آسیب‌دیده را در 1 ژوئن 2026 اصلاح می‌کند.

این به‌روزرسانی ممکن است باعث شود اسکنرهای آسیب‌پذیری در محیط‌هایی این مشکلات را شناسایی کنند که قبلاً آن‌ها را نشان نمی‌دادند. هدف این اقدام، کمک به کاهش و مدیریت دقیق‌تر این سه ضعف فنی است که قبلاً فاش شده ولی عملاً «ثابت» نشده بودند؛ یعنی CVE-2020-8561، CVE-2020-8562 و CVE-2021-25740.

چرا الآن این اصلاح؟ این CVEها برای سال‌ها عمومی بوده‌اند، اما کار اخیر روی فایل‌های رسمی منبع باز نشان داد که برخی رکوردها به‌اشتباه برچسب «fixed» دارند. در واقع این موارد ناشی از محدودیت‌ها یا طراحیِ معماری هستند و با اصلاح صرفاً کد نمی‌توان آن‌ها را حل کرد بدون این‌که عملکرد اصلی Kubernetes مختل شود.

دلایل اهمیت اصلاح رکوردها برای جامعه:

• اتوماسیون وفاداری: اسکنرهای مدرن به محدوده‌های نسخه‌ای دقیق وابسته‌اند. برچسب «fixed» نادرست باعث منفی کاذب می‌شود و احساس امنیتِ غلط ایجاد می‌کند. 🔎

• مستندسازی ریسک: با علامت‌زدن این موارد به‌عنوان «ثابت‌نشده»، به تیم‌های ارائه‌دهنده و مدیران پلتفرم هشدار می‌دهیم که کاهش‌های اداری (administrative mitigations) همچنان لازم‌اند.

• استانداردسازی: رکوردها برای استفاده از قالب نسخهٔ استانداردتر به‌روزرسانی می‌شوند تا خوانایی و یکپارچگی بهتر شود.

تحلیل فنی — جمع‌بندی کوتاه: پروژه Kubernetes این آسیب‌پذیری‌های معماری را در خود محصول رفع نمی‌کند. مسائل فنی و مکانیک دقیق‌تر را می‌توانید در GitHub issues مربوطه دنبال کنید. در ادامه شرح فنی هر CVE، چرا «ثابت‌نشده» است و چه کاهش‌هایی پیشنهاد می‌شود ارائه شده است.

CVE-2020-8561 — تغییر مسیر Webhook در kube-apiserver
Severity: متوسط (4.1).
موضوع: kube-apiserver هنگام تماس با admission webhooks از HTTP redirects تبعیت می‌کند. با داشتن حق پیکربندی AdmissionWebhookConfiguration، یک بازیگر می‌تواند درخواست‌ها را به شبکه‌های داخلی هدایت کند (Server-Side Request Forgery سبک داخل شبکه).
چرا «ثابت» نیست: محدود کردن کامل این رفتار یعنی تغییر رفتار استاندارد یک HTTP client، که بسیاری از ادغام‌های قانونی روی آن حساب می‌کنند—بنابراین رفع سادهٔ کد باعث شکستن سازگاری می‌شود.
کاهش پیشنهادی: سطح profiling سرور API را کمتر از 10 تنظیم کنید (برای جلوگیری از تغییرات غیرمجاز در سطح گزارش). مثال تنظیم پرچم: –profiling=false 🔧

CVE-2020-8562 — دور زدن پروکسی از طریق DNS TOCTOU
Severity: کم (3.1).
موضوع: یک شرایط رقابتی «time-of-check to time-of-use» (TOCTOU) وجود دارد: سیستم ابتدا یک بررسی DNS برای اعتبارسنجی IP انجام می‌دهد و سپس رزولوشن دیگری برای اتصال واقعی انجام می‌شود؛ مهاجم می‌تواند بینِ این دو عمل تغییری ایجاد کند و پروکسی‌ها را دور بزند.
چرا «ثابت» نیست: رفع کامل این مشکل مستلزم پین کردن IPهای حل‌شده است که با افق‌های DNS پیچیده و محیط‌های IP پویا سازگار نیست—یعنی یک تغییر معماری بزرگ لازم است.
کاهش پیشنهادی: از یک DNS caching محلی روی گره‌های کنترل (مثلاً dnsmasq یا resolver کش شبیه به آن) استفاده کنید تا بین بررسی و اتصال پاسخ‌های ثابتی اعمال شوند و پنجره TOCTOU کاهش یابد. 🛡️

CVE-2021-25740 — ارسال فضای نام متقاطع از طریق Endpoints
Severity: کم (3.1).
موضوع: طراحی Endpoints و EndpointSlice به کاربران امکان می‌دهد آدرس‌های IP را دستی وارد کنند؛ این رفتار می‌تواند برای نشان دادن backendهای ناخواسته یا مسیرهای بازگشتی به‌کار رود.
چرا «ثابت» نیست: این یک ویژگی بنیادی در API Endpoints است که ابزارها و اپراتورهای شبکه به آن متکی‌اند؛ حذف یا تغییر آن نیازمند بازطراحی بزرگ است.
کاهش پیشنهادی: دسترسی نوشتن به Endpoints (legacy Endpoints) و EndpointSlices را محدود کنید. توجه کنید که در Kubernetes 1.22، حالت مجوز RBAC پیش‌فرض برای برخی از рол‌ها تغییر کرده است؛ برای خوشه‌هایی که از نسخه‌های قدیمی‌تر ارتقا یافته‌اند، مدیران باید به‌صورت دستی ClusterRoleها را بازبینی و مطابقت دهند (مثلاً aggregate-to-edit).

نکته مهم: در 1 ژوئن 2026، این سوابق CVE به‌روزرسانی شدند تا نشان دهند همه نسخه‌ها تحت تأثیر قرار گرفته‌اند؛ بنابراین ممکن است این موارد اکنون در نتایج اسکنرها ظاهر شوند — این نتیجهٔ شفاف‌سازی و تطبیق رکوردهاست، نه کشف یک مشکل جدید.

اقدامات پیشنهادی برای مدیران (خلاصه و عملی):

• CVE-2020-8561 — کم کردن سطح profiling یا غیرفعال‌سازی آن: –profiling=false. (Severity ~4.1) ✅

• CVE-2020-8562 — استقرار یک DNS caching محلی روی گره‌های کنترل (مثلاً dnsmasq) تا پاسخ‌های DNS بین چک و اتصال ثابت‌تر بمانند. (Severity ~3.1) ✅

• CVE-2021-25740 — بازبینی و محدودسازی دسترسی نوشتن به Endpoints/EndpointSlices از طریق RBAC؛ برای خوشه‌های ارتقا یافته، ClusterRoleها و aggregated roles (مثل aggregate-to-edit) را دستی بررسی کنید. (Severity ~3.1) ✅

توصیه عملی: قبل از اعمال تغییرات در محیط تولید، این تنظیمات را در یک محیط غیرتولیدی تست و اعتبارسنجی کنید. ارزیابی ریسک را بر اساس مدل تهدید و تحمل ریسک سازمان خود انجام دهید؛ برخی از این کاهش‌ها هزینهٔ عملکرد یا قابلیت‌پذیری دارند و نیاز به سنجش دقیق دارند.

نتیجه‌گیری: اصلاح این سوابق نشانهٔ بلوغ بیشتر اکوسیستم امنیتی Kubernetes است. به‌جای پنهان‌کردن بدهی‌های معماری با برچسب «patched»، این شفاف‌سازی به تیم‌ها دادهٔ دقیق‌تری می‌دهد تا اقدامات محافظتی مناسب را برنامه‌ریزی و اجرا کنند. برای پرسش‌های فنی دقیق‌تر و مکانیک هر نقص، به GitHub issues مربوطه مراجعه کنید و کاهش‌ها را بر اساس نیازهای محیط خود تطبیق دهید. 🙏