شناسه CVE-2025-9074 :CVE
CWE-668 :CWE
yes :Advisory
منتشر شده: آگوست 20, 2025
به روز شده: آگوست 20, 2025
امتیاز: 9.3
نوع حمله: Server Side Request Forgery-SSRF

اثر گذاری: Privilege Escalation
حوزه: سیستم‌های مجازی‌سازی و مدیریت ابری
برند: Docker
محصول: Docker Desktop
وضعیتPublished :CVE
Yes :POC
وضعیت آسیب پذیری: patch شده

چکیده

یک آسیب‌پذیری بحرانی در Docker Desktop شناسایی شده است که به کانتینرهای لینوکس در حال اجرا به صورت لوکال اجازه می‌دهد بدون نیاز به احراز هویت، به API داخلی Docker Engine از طریق زیرشبکه پیش‌فرض 192.168.65.7:2375 دسترسی پیدا کنند. این ضعف امنیتی امکان اجرای دستورات با سطح دسترسی بالا، مانند کنترل کانتینرهای موجود، ایجاد کانتینرهای جدید و حتی دسترسی به فایل‌های سیستم میزبان را فراهم می‌کند.

توضیحات

آسیب‌پذیری CVE-2025-9074 در Docker Desktop، یک پلتفرم محبوب برای مدیریت کانتینرها در سیستم‌های ویندوز و MacOS، ناشی از دسترسی غیرمجاز به API Docker Engine از طریق زیرشبکه پیش‌فرض 192.168.65.7:2375 مطابق با CWE-668 است.

این ضعف به کانتینرهای لینوکس در حال اجرا به‌صورت لوکال اجازه می‌دهد بدون نیاز به احراز هویت یا مونت کردن سوکت Docker، به API داخلی دسترسی یافته و دستورات با سطح دسترسی بالا مانند ایجاد کانتینرهای جدید، کنترل کانتینرهای موجود، مدیریت ایمیج ها یا حتی مونت کردن درایوهای میزبان به‌ویژه در ویندوز با بک‌اند WSL2 را اجرا کنند.

این آسیب‌پذیری بدون توجه به فعال بودن قابلیت Enhanced Container Isolation (ECI) یا پیکربندی گزینه “Expose daemon on tcp://localhost:2375 without TLS” قابل بهره‌برداری است، که آن را به یک تهدید جدی تبدیل می‌کند.

در ویندوز، مهاجمان می‌توانند کل فایل‌سیستم میزبان را مونت کرده، فایل‌های حساس را بخوانند یا فایل‌های سیستمی مانند DLLها را بازنویسی کنند تا به سطح دسترسی مدیریتی (administrator) ارتقاء یابند.

در MacOS ، به دلیل وجود لایه‌های ایزولاسیون و نیاز به تأیید کاربر برای دسترسی به دایرکتوری‌های خاص، دامنه تأثیر محدودتر است، اما همچنان امکان دستکاری پیکربندی Docker یا کنترل کانتینرها وجود دارد.

این آسیب‌پذیری نسخه‌های 4.25 تا پیش از 4.44.3 را تحت تأثیر قرار می‌دهد و در لینوکس به دلیل استفاده از سوکت‌های یونیکس به جای TCP، بی‌تأثیر است. یک کد اثبات مفهومی (PoC) منتشر شده است که با استفاده از دو درخواست ساده HTTP POST (ایجاد و راه‌اندازی کانتینر) نشان می‌دهد چگونه می‌توان درایو C: ویندوز را مونت کرده و فایل‌های میزبان را دستکاری کرد. این PoC حتی از طریق حملات جعل درخواست سمت سرور(SSRF) نیز قابل اجرا است و نیازی به اجرای مستقیم کد در کانتینر ندارد. این آسیب پذیری اثرات گسترده ای بر محرمانگی، یکپارچگی و دسترس‌پذیری دارد، زیرا مهاجمان می‌توانند داده‌های حساس را استخراج کرده،کنترل سیستم را به دست آورند یا به زنجیره‌های حملات پیچیده‌تر مانند حملات زنجیره تأمین متصل شوند.

تیم Docker این ضعف را در نسخه 4.44.3 پچ کرده است. در این نسخه دسترسی به API داخلی محدود شده و کنترل‌های احراز هویت را اعمال می‌کند.

CVSS

Score	Severity	Version	Vector String
9.3	CRITICAL	4.0	CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

لیست محصولات آسیب پذیر

Versions	Platforms	Product
affected from 4.25 before 4.44.3	Windows, MacOS, Linux, x86, ARM	Docker Desktop

لیست محصولات بروز شده

Versions	Platforms	Product
4.44.3 and later	Windows, MacOS, Linux, x86, ARM	Docker Desktop

استفاده محصول در ایران

در این جدول، تعداد صفحات ایندکس‌شده در گوگل با دامنه .ir که Docker Desktop را ذکر کرده اند، ثبت شده است. این داده صرفاً برای برآورد تقریبی حضور محصولات در وب ایران استفاده شده و نمایانگر میزان نصب یا استفاده واقعی از آن نیست.

Approx. Usage in .ir Domain via Google (Total Pages)	Product
11,600	Docker Desktop

نتیجه گیری

با توجه به شدت بحرانی این آسیب‌پذیری و امکان دسترسی غیرمجاز کانتینرهای لوکال به API داخلی Docker Engine، توصیه می‌شود اقدامات زیر برای کاهش ریسک انجام شود:

به‌روزرسانی فوری Docker Desktop: به روزرسانی به نسخه 4.44.3 یا بالاتر که این آسیب‌پذیری در آن پچ شده است.
محدود کردن دسترسی به API Docker Engine: اجتناب از اتصال TCP بدون TLS (Transport Layer Security) و بدون احراز هویت به Docker Daemon و استفاده از کانال‌های امن و احراز هویت‌شده.
فعال‌سازی ایزولاسیون قوی کانتینرها: استفاده از Enhanced Container Isolation (ECI) و سایر پیکربندی های امنیتی برای جداسازی کانتینرها از میزبان.
مانیتورینگ و لاگ‌گیری دقیق: بررسی فعالیت‌های مشکوک در سطح کانتینر و دسترسی به API برای شناسایی تلاش‌های غیرمجاز.
نظارت بر ترافیک کانتینرها: نظارت بر ترافیک کانتینرها به آدرس 192.168.65.7:2375، اعمال قوانین فایروال برای مسدود کردن دسترسی‌های غیرمجاز و بررسی ایمیج های کانتینرها برای جلوگیری از اجرای کد مخرب.
اجرای اصل حداقل دسترسی (Least Privilege): اطمینان از اینکه کاربران کانتینرها تنها دسترسی های ضروری به سیستم میزبان دارند.
آموزش و آگاهی کاربران: اطلاع‌رسانی به تیم‌های DevOps و کاربران درباره ریسک ناشی از اجرای کانتینرهای ناامن و شناسایی فعالیت‌های مشکوک.

اجرای همزمان این اقدامات، احتمال بهره‌برداری موفق از آسیب‌پذیری را به حداقل رسانده و امنیت محیط‌های مبتنی بر Docker Desktop را به‌طور مؤثر تضمین می‌کند.

امکان استفاده تاکتیک های Mitre attack

Initial Access (TA0001)
T1566 – Phishing / T1190 – Exploit Public-Facing Application
مهاجم می‌تواند با ارسال درخواست HTTP مخرب از کانتینر لوکال یا از طریق SSRF به آدرس 168.65.7:2375، به Docker Engine داخلی دسترسی پیدا کند، بدون نیاز به احراز هویت.
Execution (TA0002)
T1059 – Command and Scripting Interpreter
پس از دسترسی به Docker Engine، مهاجم قادر است دستورات دلخواه مانند ایجاد یا اجرای کانتینرها را اجرا کند و روی سیستم میزبان کدهای سطح بالا را به اجرا درآورد.
Persistence (TA0003)
T1543 – Create or Modify System Process
مهاجم ممکن است کانتینرهای جدید ایجاد یا کانتینرهای موجود را تغییر دهد تا دسترسی خود را حفظ کند.
Privilege Escalation (TA0004)
T1068 – Exploitation for Privilege Escalation
در ویندوز با WSL2، مهاجم می‌تواند سطح دسترسی خود را به Administrator ارتقاء دهد و کنترل کامل سیستم میزبان را به دست آورد.
Credential Access (TA0006)
T1003 – Credential Dumping
با دسترسی به فایل‌های میزبان، مهاجم ممکن است داده‌های حساس و اعتبارنامه‌های ذخیره‌شده را استخراج کند.
Impact (TA0040)
T1499 – Endpoint Denial of Service / T1486 – Data Encrypted for Impact
مهاجم می‌تواند فایل‌های سیستم میزبان را تغییر دهد، کانتینرهای حیاتی را متوقف کند یا داده‌ها را دستکاری کند و سرویس‌های سیستم را مختل سازد.

منابع

گزارش اثبات آسیب‌پذیری CVE-2025-9074

اطلاعات آسیب‌پذیری

عنوان: نقص کنترل دسترسی درداکر دسکتاپ منجر به دسترسی غیرمجاز به Docker Engine API و افزایش امتیاز از طریق کانتینرهای لوکال

شناسه: CVE-2025-9074

وضعیت مشاوره: Advisory / Patch Available

نمره CVSS تقریبی: CVSS v4.0: 9.3 (Critical)

محصول / نسخه‌های آسیب‌پذیر: Docker Desktop (برای ویندوز، macOS و لینوکس)

در نسخه‌های زیر (پیش از اعمال وصله امنیتی):
◦ Docker Desktop نسخه‌های 25 تا پیش از 4.44.3.
نسخه‌های قدیمی‌تر (مانند سری 2x) نیز ممکن است تحت تأثیر باشند.
محیط‌های درگیر:
◦ محیط‌های توسعه و تست نرم‌افزار که از Docker Desktop به عنوان موتور زمان‌اجرای کانتینر استفاده می‌کنند.
◦ ایستگاه‌های کاری مهندسان، سیستم‌های CI/CD خودمیزبان و سرورهای توسعه‌ای که Docker Desktop بر روی آن‌ها نصب است.
◦ محیط‌های عملیاتی نهایی (Production) که به‌اشتباه از Docker Desktop به عنوان بستر اجرای کانتینرهای مأموریتی استفاده می‌شود.
◦ سیستم‌های چندکاربره یا اشتراکی که در آن کاربران مجاز به اجرای کانتینر هستند.
◦ معماری‌های مجازی‌سازی دسکتاپ (VDI) یا محیط‌های ابری دسکتاپ که Docker Desktop را در اختیار کاربران قرار می‌دهند.

کامپوننت‌های آسیب‌پذیر:

لایه شبکه داخلی و پیکربندی سرویس Docker Engine در Docker Desktop.
رابط برنامه‌نویسی (API) Docker Engine که در آدرس داخلی 168.65.7:2375 در معرض دسترسی قرار دارد.
مکانیزم‌های کنترل دسترسی و جداسازی شبکه بین کانتینرهای میهمان و موتور میزبان Docker.
رابط مدیریتی Docker Desktop که عملیات سطح بالا روی کانتینرها و میزبان را تسهیل می‌کند.

ریشه مشکل (Root Cause Analysis)

ریشه اصلی این آسیب‌پذیری در یک نقص طراحی و پیکربندی در معماری شبکه داخلی Docker Desktop نهفته است که منطبق بر طبقه‌بندی CWE-668 (افشای منبع به حوزه نادرست) است. این آسیب‌پذیری ناشی از در معرض قرار گرفتن سرویس Docker Engine API، که یک سرویس با سطح دسترسی بسیار بالا محسوب می‌شود، در یک آدرس IP داخلی ثابت و قابل پیش‌بینی (192.168.65.7:2375) است. در حالی که این در معرض قرارگیری ممکن است برای اهداف ارتباط داخلی اجزای Docker Desktop طراحی شده باشد، مرزهای امنیتی کافی برای جلوگیری از دسترسی مستقیم کانتینرهای در حال اجرا بر روی همان میزبان به این نقطه انتهایی حیاتی اعمال نشده است. به عبارت دیگر، اصل حداقل دسترسی (Principle of Least Privilege) در سطح ارتباطات شبکه بین کانتینر و موتور میزبان نقض شده است. این طراحی، فرض اساسی جداسازی کانتینرها از کنترل‌پنل مدیریتی میزبان را تضعیف می‌کند و یک کانال ارتباطی قدرتمند و بدون احراز هویت را در اختیار هر کدی که در داخل یک کانتینر اجرا می‌شود، قرار می‌دهد. این نقص، فارغ از فعال‌بودن یا نبودن ویژگی‌های امنیتی پیشرفته‌ای مانند Enhanced Container Isolation (ECI) یا تنظیمات دستی مربوط به در معرض قرار دادن daemon، وجود دارد که بیانگر عمق ریشه این مسئله در لایه‌های پایه‌ای معماری محصول است.

بخش آسیب‌پذیر

رفتار نا امن سیستم:

ارائه دسترسی بدون احراز هویت از کانتینرهای میهمان به API مدیریتی Docker Engine که بر روی آدرس IP داخلی 168.65.7 و پورت 2375 گوش می‌دهد.
عدم اعمال فیلترینگ یا کنترل دسترسی مبتنی بر هویت در سطح شبکه بین فضای نام شبکه کانتینر و فضای شبکه اختصاصی موتور Docker Desktop.
نقض اصل جداسازی (Isolation) به این صورت که یک پردازه با سطح دسترسی محدود (کانتینر) می‌تواند مستقیماً به پردازه‌ای با سطح دسترسی بالا (Docker Daemon) که خارج از محدوده محصورسازی آن اجرا می‌شود، دستور صادر کند.

نحوه سوءاستفاده مهاجم:

مهاجم با دسترسی اولیه برای اجرای یک کانتینر (حتی با کمترین سطح دسترسی) بر روی یک میزبان دارای Docker Desktop آسیب‌پذیر، اقدامات زیر را انجام می‌دهد:

مهاجم یک کانتینر مخرب را بر روی سیستم هدف اجرا می‌کند یا کد خود را درون یک کانتینر موجود تزریق می‌نماید.
مهاجم از داخل کانتینر، درخواست‌های HTTP مستقیمی به آدرس داخلی Docker Engine API (192.168.65.7:2375) ارسال می‌کند.
با استفاده از این دسترسی، مهاجم می‌تواند کانتینرهای دیگر را متوقف کند، کانتینرهای جدید با سطح دسترسی بالا ایجاد نماید و یا حافظه‌های میزبان (Host Volumes) را به کانتینرهای تحت کنترل خود متصل کند.
در سناریوی ویژه ویندوز با بک‌اند WSL2، مهاجم با مونت کردن کل درایو سیستم میزبان، به فایل‌های حساس سیستم عامل، اطلاعات اعتباری و داده‌های کاربر دسترسی پیدا کرده و مسیر را برای افزایش سطح دسترسی به سطح Administrator هموار می‌سازد.

نقش این آسیب‌پذیری در زنجیره حمله

این آسیب‌پذیری به‌عنوان یک نقطه نفوذ اولیه (Initial Access) یا یک ابزار قدرتمند برای تشدید امتیاز (Privilege Escalation) و حرکت جانبی (Lateral Movement) در محیط‌های توسعه‌ای عمل می‌کند. مهاجم با بهره‌برداری از این ضعف می‌تواند کنترل کامل محیط کانتینری میزبان را به دست گیرد، که این خود می‌تواند منجر به افشای داده‌های حساس توسعه، سرقت مالکیت فکری، تخریب محیط‌های تست یا حتی نفوذ به زنجیره تأمین نرم‌افزار از طریق دستکاری imageهای ساخت شود. در بدترین حالت، در سیستم‌هایی که مرز بین محیط توسعه و عملیاتی به درستی تعریف نشده، این آسیب‌پذیری می‌تواند به عنوان پلی برای نفوذ به شبکه‌های داخلی سازمان مورد استفاده قرار گیرد.

پیش‌نیازهای بهره‌برداری (Prerequisites)

وجود Docker Desktop در نسخه‌های آسیب‌پذیر بر روی سیستم عامل میزبان (ویندوز، macOS یا لینوکس).
توانایی مهاجم برای اجرای کانتینر بر روی سیستم هدف، که می‌تواند از طریق یک image مخرب، یک آسیب‌پذیری در یک اپلیکیشن موجود داخل کانتینر، یا دسترسی فیزیکی/منطقی به حساب کاربری دارای مجوز اجرای دستورات Docker حاصل شود.
عدم وجود قواعد فایروال میزبان یا شبکه که به صراحت ارتباط از محدوده آدرس‌های داخلی کانتینرها به پورت 2375 بر روی آدرس 168.65.7 را مسدود کند.
فعال نبودن مکانیزم‌های امنیتی شخص ثالث خارج از چارچوب Docker Desktop که بتوانند چنین رفتار ارتباطی غیرعادی را شناسایی و مسدود نمایند.

رفتار مورد انتظار در حالت امن (Expected Secure Behavior)

در یک طراحی امن، انتظار می‌رود که:

API مدیریتی Docker Engine به هیچ وجه از طریق شبکه، حتی شبکه داخلی، در دسترس کانتینرهای میهمان قرار نگیرد. تمام ارتباطات مدیریتی باید از طریق مکانیزم‌های امن و کنترل‌شده مانند سوکت یونیکس با مجوزهای فایل سیستم محدود یا از طریق کانال‌های ارتباطی با احراز هویت قوی برقرار شود.
در صورت نیاز به دسترسی محدود API برای سناریوهای خاص، این دسترسی باید مبتنی بر سیاست‌های دقیق کنترل دسترسی (RBAC)، احراز هویت توکن‌محور و فهرست سفید (Allow-list) برای منابع و عملیات مجاز باشد.
جداسازی شبکه بین فضای کانتینر و فضای مدیریت میزبان باید به‌گونه‌ای اعمال شود که کانتینر نتواند به زیرشبکه‌ها یا سرویس‌های حیاتی میزبان که برای عملکرد آن ضرورتی ندارند، دسترسی پیدا کند.
سیستم در مواجهه با درخواست‌های مدیریتی از آدرس‌های غیرمجاز (مانند آدرس IP داخلی کانتینرها) باید آن‌ها را رد کرده و رویداد امنیتی با سطح هشدار بالا را در لاگ ثبت نماید.

راهکارها و کاهش ریسک (Mitigation / Patch Guidance)

اقدامات فوری برای کاهش ریسک

به‌روزرسانی فوری Docker Desktop به آخرین نسخه پایدار و اصلاح‌شده (نسخه 44.3 یا جدیدتر) که توسط تیم Docker برای رفع این آسیب‌پذیری منتشر شده است.
بررسی و حذف هرگونه کانتینر فعال مشکوک یا ناشناخته بلافاصله پس از اعمال به‌روزرسانی.
در صورت عدم امکان به‌روزرسانی فوری، غیرفعال کردن موقت سرویس Docker Desktop در سیستم‌های حیاتی و در معرض خطر تا زمان رفع کامل مشکل.

اقدامات کوتاه‌مدت / میان‌مدت برای کاهش ریسک

بازبینی و اعمال سیاست‌های سخت‌گیرانه فایروال میزبان برای مسدودسازی کلیه ترافیک‌های خروجی از محدوده IP کانتینرها به سمت پورت‌ها و آدرس‌های داخلی مدیریتی میزبان، به ویژه پورت 2375.
پیاده‌سازی و اجرای سیاست‌های امنیتی مبتنی بر تصاویر (Image Policy) برای جلوگیری از اجرای کانتینرهای مبتنی بر تصاویر غیرمطمئن یا ثبت‌نشده در رجیستری‌های داخلی.
فعال‌سازی و پیکربندی قابلیت Enhanced Container Isolation (ECI) در Docker Desktop به عنوان یک لایه دفاعی عمقی اضافی، اگرچه این اقدام به تنهایی آسیب‌پذیری را برطرف نمی‌کند.
تفکیک محیط‌های توسعه از محیط‌های عملیاتی و اطمینان از اینکه Docker Desktop صرفاً بر روی ایستگاه‌های کاری توسعه استفاده شده و در سرورهای سمت سرویس‌دهنده از موتورهای زمان‌اجرای سرور-محور و امن‌تر مانند Docker Engine (برای لینوکس) با پیکربندی امن استفاده شود.

اقدامات بلندمدت برای کاهش ریسک

بازبینی معماری امنیتی چرخه توسعه نرم‌افزار برای حذف وابستگی‌های غیرضروری به Docker Desktop در مراحل ساخت و تست خودکار.
آموزش مستمر تیم‌های توسعه و عملیات در مورد مخاطرات امنیتی مرتبط با کانتینرها، اصول پیکربندی امن موتورهای کانتینری و بهترین روش‌های استفاده از آن‌ها.
ادغام ابزارهای تحلیل امنیتی استاتیک و دینامیک کد (SAST/DAST) و اسکنرهای امنیتی imageهای کانتینر در خط لوله CI/CD به منظور شناسایی زودهنگام الگوهای کدنویسی ناامن یا استفاده از بسته‌های آسیب‌پذیر.
استقرار راهکارهای مدیریت یکپارچه امنیت کانتینرها (CSPM/CWPP) که توانایی نظارت بر پیکربندی، شناسایی ناهنجاری‌های رفتاری و اعمال سیاست‌های امنیتی یکسان در تمامی محیط‌های کانتینری را دارا باشند.

تشخیص و مانیتورینگ (Detection & Monitoring)

نشانه‌های تلاش برای سوءاستفاده

نشانه‌های زیر می‌توانند بیانگر تلاش برای بهره‌برداری از آسیب‌پذیری موردنظر باشند و لازم است به‌صورت مستمر پایش شوند:

وجود لاگ‌های دسترسی غیرعادی در Docker Daemon که نشان‌دهنده درخواست‌های API از آدرس‌های IP داخلی متعلق به محدوده شبکه‌های bridge یا docker0 (مانند 172.x.x) به سمت رابط 2375 میزبان است.
ایجاد ناگهانی کانتینرهای جدید با پارامترهای خطرناک مانند –privileged، –cap-add=ALL یا mount pointهایی که به مسیرهای حساس میزبان مانند /, /etc, C اشاره می‌کنند، بدون فراخوانی مستقیم توسط کاربر نهایی.
تغییرات غیرمنتظره در وضعیت کانتینرهای در حال اجرا (توقف، حذف، restart) که توسط مدیر سیستم یا فرآیندهای اتوماسیون شناخته‌شده آغاز نشده‌اند.
مشاهده ترافیک شبکه خروجی از کانتینرها به سمت پورت 2375 بر روی آدرس 168.65.7 در گزارش‌های شبکه‌ای یا ابزارهای مانیتورینگ میزبان.
خطاهای احراز هویت یا دسترسی ممنوع در لاگ‌های برنامه‌های کاربردی که سعی در استفاده از سوکت Docker دارند، در صورت تلاش daemon برای اعمال کنترل‌های دسترسی پس از وصله.

منابع پیشنهادی برای مانیتورینگ و پایش

به‌منظور تشخیص به‌موقع و مؤثر تلاش‌های سوءاستفاده، پایش منابع زیر توصیه می‌شود:

لاگ‌های Docker Daemon (یا فایل‌های لاگ مخصوص سیستم عامل) با تمرکز بر رویدادهای مربوط به اتصال کلاینت‌ها، ایجاد/حذف کانتینر و عملیات مدیریتی سطح بالا.
خروجی دستور docker events –since <timeframe> برای نظارت بلادرنگ بر رویدادهای Docker.
گزارش‌های سیستم مانیتورینگ میزبان (مانند Performance Monitor در ویندوز یا sysstat در لینوکس) برای شناسایی افزایش ناگهانی در استفاده از منابع (CPU، حافظه، I/O) مرتبط با فرآیندهای Docker.
راهکارهای امنیت نقطه پایانی (Endpoint Detection and Response – EDR) که قابلیت شناسایی رفتارهای غیرعادی پردازه‌های مرتبط با Docker (مانند dockerd، containerd) و ارتباطات شبکه‌ای مشکوک آن‌ها را دارند.
خروجی ابزارهای امنیتی کانتینر-محور مانند Falco برای تشخیص رفتارهای غیرمجاز در سطح runtime کانتینرها.

واکنش به حادثه (Incident Response)

اقدامات اضطراری که در صورت مشاهده نشانه‌های نفوذ باید اتخاذ شود:

ایزوله کردن فوری سیستم میزبان مشکوک از شبکه سازمانی برای جلوگیری از حرکت جانبی احتمالی مهاجم.
توقف کامل سرویس Docker Desktop و تمامی کانتینرهای در حال اجرا بر روی آن سیستم.
ایجاد یک ایمیج forensic از حافظه (Memory Dump) و دیسک سیستم آلوده پیش از هرگونه اقدام اصلاحی، جهت حفظ شواهد برای تحلیل آتی.
بررسی دقیق لاگ‌های Docker Daemon، تاریخچه دستورات Docker (در صورت فعال بودن) و لاگ‌های سیستم عامل برای ردیابی اقدامات مهاجم.
شناسایی و ارزیابی کامل کانتینرها، ایمیج ها و volumeهای ایجاد یا دستکاری‌شده توسط مهاجم.
پاکسازی محیط با حذف تمامی کانتینرها، تصاویر و volumeهای غیرمطمئن و نصب مجدد Docker Desktop از نسخه‌های اصلاح‌شده رسمی.
تغییر تمامی اعتبارنامه‌ها، کلیدهای API و توکن‌های دسترسی که ممکن است بر روی سیستم میزبان ذخیره شده یا توسط مهاجم قابل دسترسی بوده باشند.
مستندسازی کامل timeline حادثه، اقدامات پاسخ و درس‌های آموخته شده برای به‌روزرسانی برنامه پاسخ به حوادث سایبری (CSIRT).

جریان حمله (Attack Flow)

در شکل ۱جریان کلی بهره‌برداری از این آسیب‌پذیری نشان داده شده است. در این سناریو مهاجم با دسترسی اولیه به یک حساب کاربری در سیستم توسعه‌دهنده، یک کانتینر مبتنی بر یک ایمیج به ظاهر بی‌خطر را اجرا می‌کند. کد مخرب جاسازی‌شده در داخل این کانتینر، بلافاصله پس از راه‌اندازی، شروع به کاوش شبکه داخلی می‌کند و نقطه انتهایی Docker Engine API را در آدرس شناخته‌شده داخلی شناسایی می‌نماید. مهاجم سپس با ارسال درخواست‌های HTTP خام به این API، کنترل موتور کانتینری را به دست می‌گیرد. این کنترل، امکان ایجاد یک کانتینر ثانویه با دسترسی بالا و متصل به فایل‌سیستم میزبان را فراهم می‌سازد. در محیط ویندوز، این دسترسی میزبان به مهاجم اجازه می‌دهد تا فایل‌های حیاتی سیستم را دستکاری کرده یا اعتبارنامه‌ها را استخراج کند، که نهایتاً منجر به در اختیار گرفتن کنترل کامل سیستم می‌شود. کل این فرآیند بدون نیاز به تعامل کاربر، سوءاستفاده از هیچ آسیب‌پذیری نرم‌افزاری دیگر در سیستم عامل میزبان و تنها با سوءاستفاده از پیکربندی ناامن شبکه داخلی Docker Desktop صورت می‌پذیرد.

اثبات مفهوم (PoC) – کاملاً غیرمخرب

آزمایشگاه تخصصی Vulnerbyte این آسیب‌پذیری را در یک محیط ایزوله و کنترل‌شده مورد بررسی قرار داده است. اثبات مفهوم ارائه‌شده صرفاً با هدف درک مکانیزم نقض و تأکید بر اهمیت وصله امنیتی طراحی شده است.

این اثبات مفهوم به‌صورت توصیفی نشان می‌دهد که چگونه یک کانتینر ساده مبتنی بر Alpine Linux می‌تواند با استفاده از ابزار curl، به API مدیریتی دسترسی یافته و یک کانتینر جدید ایجاد کند.
کد واقعی exploit یا دستورات مخربی که منجر به آسیب‌رسانی می‌شوند، در این گزارش گنجانده نشده‌اند.
این بررسی نشان می‌دهد که حتی بدون هیچ گونه پیکربندی خاص یا فعال‌سازی گزینه‌های خطرناک، مسیر حمله به‌طور پیش‌فرض باز است.

تصویر ارائه‌شده در شکل ۲ نمایانگر خروجی یک درخواست آزمایشی موفقیت‌آمیز به API آسیب‌پذیر است که در محیط آزمایشگاهی ثبت شده است.

شکل ２: خروجی آزمایشی دسترسی غیرمجاز به Docker Engine API (اثبات مفهوم)

رفع مسئولیت

این گزارش صرفاً با هدف آموزش، تحلیل فنی و ارتقای امنیت سازمانی تهیه شده است. هرگونه استفاده مخرب یا خارج از چارچوب‌های قانونی و اخلاقی از محتوای آن ممنوع است. هدف اصلی، آگاه‌سازی جامعه امنیتی و کمک به سازمان‌ها در اولویت‌بندی وصله‌های حیاتی است.

منابع (References)

Docker Desktop

CVE-2025-9074 – Local Privilege Escalation via Unrestricted Docker Engine API Access from Containers

Affects

Docker Desktop
Platforms:
- Docker Desktop for Windows (including WSL backend)
- Docker Desktop for macOS
- Docker Desktop for Linux
Applies regardless of:
- Enhanced Container Isolation (ECI) being enabled or disabled
- The “Expose daemon on tcp://localhost:2375 without TLS” option being enabled or disabled
Default affected configuration includes access to the Docker Engine API via:
- 192.168.65.7:2375 (Docker Desktop internal subnet)

Description

CVE-2025-9074 is a local privilege escalation and container escape–adjacent vulnerability in Docker Desktop.

The vulnerability allows locally running Linux containers to directly access the Docker Engine API through the Docker Desktop internal network interface. Because the Docker Engine API provides highly privileged control over the container runtime, this access effectively breaks container isolation assumptions.

A malicious container can interact with the engine API to perform powerful administrative actions, including:

managing or stopping other containers,
creating new containers with elevated privileges,
pulling and modifying images,
accessing sensitive runtime configuration.

In certain environments—most notably Docker Desktop for Windows using the WSL backend—this issue may allow an attacker to mount the host filesystem with the same privileges as the user running Docker Desktop, significantly increasing impact.

Attack Vector

Primary Attack Vector:
Local / Container-to-Host via Internal Network Access

Attack Scenario:

An attacker gains the ability to run a Linux container locally (for example, via:
- a malicious image,
- a compromised development environment,
- untrusted container workloads).
The container accesses the Docker Desktop internal subnet.
The container connects to the Docker Engine API endpoint
192.168.65.7:2375 (default).
The Docker Engine API accepts and processes requests from the container.
The attacker gains effective control over the Docker Engine.

Key Characteristics:

No authentication is required at the API level in this context.
No user interaction is required once the container is running.
The vulnerability is independent of common Docker Desktop security options.
Exploitation occurs entirely within the local host environment.

Conditions Increasing Risk:

Running untrusted or third-party containers.
Developer workstations with Docker Desktop installed.
CI/CD runners or automation systems using Docker Desktop.
Windows systems using Docker Desktop with the WSL backend.

Observed Exploitation & Threat Activity

At the time of disclosure, there are no confirmed reports of widespread in-the-wild exploitation.
The vulnerability presents a high-risk local attack surface, especially for:
- multi-user systems,
- development environments,
- shared workstations.
Similar Docker API exposure issues have historically been abused for:
- privilege escalation,
- container breakout,
- lateral movement on developer machines.

Severity & Metrics

CVSS v3.1: High (commonly assessed in the 7.8 – 8.8 range)
Attack Vector: Local
Privileges Required: Low (ability to run a container)
User Interaction: None
Impact:
- Confidentiality: High
- Integrity: High
- Availability: High

Relevant CWE:

CWE-284 – Improper Access Control
CWE-668 – Exposure of Resource to Wrong Sphere
CWE-269 – Improper Privilege Management

Patch & Vendor Status

Docker has acknowledged the issue and released security updates addressing CVE-2025-9074.
The fix restricts container-level access to the Docker Engine API and enforces stronger isolation boundaries between containers and the engine.

Users should update Docker Desktop to the latest patched release immediately.

Mitigation & Remediation

Immediate Actions

Upgrade Docker Desktop to a version containing the fix for CVE-2025-9074.
Restart Docker Desktop after upgrading to ensure changes take effect.
Review and audit containers running on developer machines.

Temporary Compensating Controls (If Upgrade Is Delayed)

Avoid running untrusted or third-party containers.
Restrict local user access to Docker Desktop.
Use dedicated, hardened systems for container workloads.
Prefer remote Docker hosts or server-side container runtimes for sensitive workloads.

These mitigations reduce exposure but do not fully eliminate the vulnerability.

Detection & Hunting

Indicators of Potential Abuse:

Containers interacting unexpectedly with the Docker Engine API.
Creation of containers without user initiation.
Containers with unexpected privileged flags or mounted host paths.
Unusual Docker API activity originating from container network ranges.

Recommended Monitoring:

Docker daemon logs for unexpected API requests.
Host monitoring for new or modified containers.
File system monitoring for unauthorized host mounts.
Network monitoring for traffic to 192.168.65.7:2375.

Post-Incident Response

If exploitation is suspected:

Stop Docker Desktop immediately.
Inspect running and recently created containers.
Review Docker daemon logs and container history.
Remove suspicious containers and images.
Upgrade Docker Desktop to a patched version.
Assess host filesystem access and data exposure.
Rotate credentials if sensitive data may have been accessed.

Summary Table

Category	Details
Vulnerability	Unauthorized Docker Engine API access
Attack Vector	Local container → Docker Engine
Impact	Privilege escalation, container control, host access
Affected Product	Docker Desktop
Severity	High
Patch Available	Yes
User Interaction	None

References

Docker Security Advisory – CVE-2025-9074
NVD – CVE-2025-9074
Docker Desktop Documentation – Engine API Security

CVE-2025-9074

Docker Desktop Allows Unauthenticated Access To Docker Engine API From Containers