یک نقص امنیتی بحرانی در Red Hat Quay شناسایی شده است که به هر کسی که به سرور کلید (Key Server) یک رجیستری دسترسی داشته باشد، اجازه می‌دهد فرآیند امضای توکن (Token Signing) را تصاحب کند. این آسیب‌پذیری با شناسه CVE-2026-123710 و امتیاز CVSS 9.8 رده‌بندی شده است.
جزئیات فنی نقص امنیتی
Quay یک رجیستری سازمانی برای ذخیره و ارائه ایمیج‌های کانتینر است. نقطه ضعف این سیستم در سرور کلیدهای سرویس (Service Key Server) نهفته است. زمانی که یک کاربر درخواست چرخش کلید امضا (Signing Key Rotation) می‌دهد، سرور تنها بررسی می‌کند که JWT توسط یک کلید تأیید شده امضا شده باشد و دارای Audience و Issuer صحیح باشد؛ اما بررسی نمی‌کند که آیا آن توکن واقعاً برای چرخش کلید صادر شده است یا خیر.
در صورتی که قابلیت FEATURE_ANONYMOUS_ACCESS فعال باشد، یک توکن ناشناس از اندپوینت /v2/auth می‌تواند این بررسی را دور بزند. از آنجایی که مقدار Audience مستقیماً از پارامترهای ارسالی کلاینت گرفته می‌شود، مهاجم کنترل کاملی بر آن دارد.
پیامدهای حمله و سطح دسترسی
مهاجم با استفاده از این توکن، کلید اختصاصی خود را به اندپوینت /keys ارسال می‌کند. این کلید جدید، تأییدیه‌های کلید قبلی را کپی کرده و می‌تواند بدون تاریخ انقضا ذخیره شود. در نتیجه، Quay بلافاصله به این کلید اعتماد می‌کند.
- دسترسی به ایمیج‌های خصوصی: مهاجم می‌تواند توکن‌هایی را امضا کند که دسترسی خواندن و نوشتن در هر مخزنی (Repository) را فراهم می‌کند.
- نشت اسرار (Secrets): ایمیج‌های خصوصی اغلب حاوی اطلاعات حساس هستند که نشت آن‌ها می‌تواند فراتر از رجیستری اثر بگذارد.
- مسموم‌سازی ایمیج‌ها: مهاجم می‌تواند تگ‌های مخازن را تغییر داده و ایمیج‌های مخرب را جایگزین کند که در نهایت توسط سیستم‌های Build دریافت و اجرا می‌شوند.
نسخه‌های آسیب‌پذیر و اقدامات اصلاحی
این نقص امنیتی در ایمیج‌های Quay 3 و Quay 5 مشاهده شده است و تنها در محیط‌هایی که اندپوینت /keys برای کلاینت‌های غیرقابل اعتماد در دسترس است، خطر ایجاد می‌کند. طبق تحلیل‌ها، این نقص منطقی از اولین نسخه‌های عمومی این نرم‌افزار وجود داشته است.
راهکارهای مقابله و کاهش ریسک
برای مقابله با این تهدید، اقدامات زیر توصیه می‌شود:
- محدود کردن دسترسی: دسترسی به اندپوینت /keys در سطح Proxy یا Load Balancer محدود شود تا تنها اجزای داخلی مورد اعتماد به آن دسترسی داشته باشند.
- بررسی لاگ‌های Audit: لاگ‌ها برای شناسایی رویدادهای service_key_rotate و service_key_delete که دارای expiration_date تهی (null) هستند، بررسی شوند.
- پاک‌سازی کلیدها: هرگونه کلید سرویس تأیید شده‌ای که ناشناخته است، حذف گردد.
باید توجه داشت که حذف کلیدهای غیرمجاز راهکار دائمی نیست، زیرا مهاجم می‌تواند مجدداً کلید جدیدی نصب کند. بنابراین، مسدود کردن دسترسی به /keys تا زمان انتشار پَچ نهایی ضروری است. تا این لحظه نسخه اصلاح‌شده‌ای معرفی نشده است.
