CVE-2026-119977؛ وقتی پنجرهٔ ارتقای وردپرس به مسیر اجرای کد تبدیل می‌شود
خلاصهٔ اجرایی
CVE-2026-119977 یک آسیب‌پذیری اجرای کد از راه دور در WordPress Core است که طبق رکورد NVD، نسخه‌های ۴.۷ تا ۷.۱.۳ را در بر می‌گیرد. توصیف ثبت‌شده، دو نکته را هم‌زمان برجسته می‌کند: ارتقای «بستهٔ کامل هسته» و مسیرهای staging قابل پیش‌بینی که از وب قابل دسترسی‌اند. حاصل این ترکیب، یک وضعیت کلاسیک Time-of-check Time-of-use یا TOCTOU است؛ یعنی برنامه در یک لحظه دربارهٔ یک فایل یا مسیر بررسی انجام می‌دهد، اما در فاصلهٔ میان بررسی و استفاده، همان منبع می‌تواند به شکلی متفاوت دیده یا مصرف شود. در این پرونده، NVD صریحاً می‌گوید مهاجمِ بدون احراز هویت می‌تواند در پنجرهٔ زمانی ارتقا روی سرور کد اجرا کند.
امتیاز ۸.۱ با شدت HIGH و بردار CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H از سوی CNA یعنی Wordfence ثبت شده است؛ NVD برای خودش هنوز امتیاز ارزیابی‌شده‌ای ارائه نکرده و مقدار آن در صفحهٔ NVD N/A است. درج CVE در KEV نیز جدا از امتیازدهی است. CISA تاریخ افزودن را ۳ نوامبر ۲۰۲۶ و deadline را ۶ نوامبر ۲۰۲۶ ثبت کرده است.
آنچه NVD ثبت کرده است
شناسهٔ مورد بحث CVE-2026-119977 است و منبع توصیف در اطلاعات سریع صفحه، Wordfence درج شده است. تاریخ انتشار NVD، ۳۱ اکتبر ۲۰۲۶، و آخرین اصلاح رکورد، ۴ نوامبر ۲۰۲۶، ثبت شده‌اند. این تاریخ‌ها را نباید با تاریخ انتشار نسخهٔ اصلاحی، تاریخ کشف، یا تاریخ افزوده‌شدن به KEV یکی دانست. آخرین اصلاح صرفاً نشان می‌دهد رکورد NVD تغییر کرده است؛ KEV یک وضعیت و برنامهٔ اقدام جداگانه دارد.
دامنهٔ محصول در NVD WordPress Foundation و محصول WordPress است. توصیف اصلی، محدودهٔ کلی را از ۴.۷ تا ۷.۱.۳ اعلام می‌کند. در بخش نسخه‌ها، NVD نمایش نمونه‌ای از ۲۵ نسخهٔ semver را نشان می‌دهد و بخشی از بازه‌های شاخه‌ای را به‌صورت ۴.۷.۰ تا ۴.۷.۳۸، ۴.۸.۰ تا ۴.۸.۳۳، ۴.۹.۰ تا ۴.۹.۳۴، ۵.۰.۰ تا ۵.۰.۳۰ و ۵.۱.۰ تا ۵.۱.۲۷ علامت‌گذاری کرده است. چون صفحه در همان بخش می‌گوید تنها پنج مورد از ۲۵ نسخه در نمای اولیه دیده می‌شود، مدیر سامانه نباید از این نمایش محدود نتیجه بگیرد که شاخه‌های میان ۵.۱ و ۷.۱.۳ بیرون از دامنه‌اند. برای تصمیم عملی، نسخهٔ دقیق هر نصب و وضعیت شاخهٔ آن باید با رکورد کامل NVD و اعلامیهٔ رسمی فروشنده تطبیق داده شود.
TOCTOU دقیقاً کجای جریان رخ می‌دهد؟
TOCTOU نام خطایی است که در آن «بررسی» و «استفاده» اتمیک و یکپارچه نیستند. یک تشبیه ساده، بررسی قفل یک در و سپس بازکردن همان در است: اگر فرد دیگری در فاصلهٔ دو عمل وضعیت قفل یا خود در را عوض کند، نتیجهٔ بررسی اولیه دیگر تضمین‌کنندهٔ چیزی نیست. در نرم‌افزار، این فاصله ممکن است بسیار کوتاه باشد، اما برای یک فرایند دیگر، درخواست هم‌زمان، یا مهاجمی که مسیر را از بیرون می‌بیند کافی است.
در WordPress Core، زمینهٔ آسیب‌پذیری فرآیند ارتقای بستهٔ کامل است. نصب‌کننده معمولاً باید بسته را دریافت کند، آن را در محل موقت باز کند، فایل‌ها را بررسی و آماده کند، و سپس مجموعه‌ای از فایل‌های هسته را جابه‌جا یا جایگزین کند. از توصیف NVD می‌توان معماری خطر را روشن کرد: بخشی از فرآیند برای staging به مسیرهایی تکیه دارد که قابل پیش‌بینی‌اند و از وب قابل دسترسی هستند. اگر آزمون امنیتی یا انتخاب فایل در زمان «check» روی یک وضعیت انجام شود و بعد در زمان «use» همان مسیر به فایل دیگری اشاره کند، مرز میان دادهٔ موقت و فایلی که مفسر وب می‌تواند اجرا کند تضعیف می‌شود.
دو ویژگی مهم است: «predictable» بودن مسیر و «web-accessible» بودن آن. مسیر تصادفی به‌تنهایی درمان کامل نیست، اما حدس‌پذیری یافتن staging را آسان می‌کند. فایل موقتی که باید فقط در اختیار فرآیند ارتقا باشد، اگر از وب قابل درخواست باشد، وارد سطح حملهٔ سرویس می‌شود. حال اگر مهاجم بتواند در فاصلهٔ میان بررسی و استفاده فایل یا محتوای مسیر را تحت تأثیر قرار دهد، فرآیند ارتقا ممکن است چیزی را پردازش کند که با فرض اولیهٔ آن مطابقت ندارد.
این همان نقطه‌ای است که TOCTOU به RCE تبدیل می‌شود. خود race condition الزاماً اجرای کد نیست؛ race، شکاف زمانی و ناسازگاری میان تصمیم و عمل است. RCE زمانی شکل می‌گیرد که خروجی آن شکاف بتواند یک فایل قابل تفسیر یا محتوای اجرایی را به جای دادهٔ بی‌خطر وارد مسیر پردازش وب یا جایگزینی هسته کند. NVD نتیجه را به‌صراحت «Remote Code Execution» می‌نامد، ولی برای استفادهٔ دفاعی لازم نیست و نباید payload یا دستور اجرایی ساخته شود. درک مرز زمانی، مالکیت مسیر، سطح دسترسی و قابلیت مشاهده از وب برای کاهش ریسک کافی است.
چرا «بدون احراز هویت» و «در پنجرهٔ ارتقا» مهم است؟
عبارت unauthenticated به این معناست که مهاجم برای سناریوی ثبت‌شده، نیاز به حساب کاربری معتبر ندارد. این موضوع با «هر درخواست عادی فوراً موفق می‌شود» یکی نیست. بردار Wordfence مقدار AC:H دارد؛ یعنی پیچیدگی حمله بالا ارزیابی شده است. بنابراین مهاجم به شرایط مناسب زمانی و محیطی نیاز دارد، اما PR:N نشان می‌دهد داشتن مجوز یا ورود به حساب پیش‌شرط بردار نیست. UI:N نیز در بردار آمده و به تعامل کاربر نیازمند نیست. این مؤلفه‌ها باید کنار هم خوانده شوند، نه اینکه تنها برچسب HIGH دیده شود.
«پنجرهٔ ارتقا» نیز دامنهٔ زمانی حمله را محدود می‌کند، اما ریسک را بی‌اهمیت نمی‌سازد. تا وقتی بستهٔ کامل آماده، باز، بررسی یا جایگزین می‌شود، مسیرها و فایل‌هایی وجود دارند که در حالت عادی ممکن است اصلاً حاضر نباشند. پایان موفق ارتقا شاید این پنجره را ببندد، ولی یک ارتقای شکست‌خورده، متوقف‌شده یا نیمه‌تمام می‌تواند مدت بیشتری وضعیت غیرعادی ایجاد کند. از طرف دیگر، چون سامانه‌های مدیریت محتوا اغلب مستقیماً روی اینترنت هستند، باید فرض کرد اسکنرها و مهاجمان می‌توانند زمان‌بندی یا نشانه‌های ارتقا را پایش کنند.
اثرهای پایهٔ بردار نیز قابل توجه است: محرمانگی، تمامیت و دسترس‌پذیری هر سه با H مشخص شده‌اند؛ با این حال S:U نشان می‌دهد دامنهٔ اثرگذاری در همان مرجع امنیتی سنجیده شده است. این برچسب‌ها پیش‌بینی قطعی خسارت در هر نصب نیستند. پشتیبان‌گیری، جداسازی حساب سرویس، محدودیت‌های سیستم‌عامل، معماری reverse proxy و کنترل‌های میزبان می‌توانند پیامد را تغییر دهند، اما نباید برای حذف اصل آسیب‌پذیری به آنها تکیه کرد.
CVSS را چگونه درست بخوانیم؟
NVD در بخش CVSS 3.x دو منبع را جدا نشان می‌دهد. در ردیف NIST، Base Score برابر N/A است و عبارت «NVD assessment not yet provided» دیده می‌شود. در ردیف CNA، Wordfence امتیاز ۸.۱ و سطح HIGH را ثبت کرده و همان بردار CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H را ارائه کرده است. بنابراین عبارت دقیق و مسئولانه این است: «امتیاز CNA Wordfence برابر ۸.۱ است»؛ نه اینکه بگوییم NVD CVSS ۸.۱ را ارزیابی کرده است. NVD خودش یادآور می‌شود که اطلاعات CVSS ارائه‌شده از منابع دیگر نیز نمایش داده می‌شود.
این تفکیک برای اولویت‌بندی مهم است. N/A به معنی کم‌خطر نیست؛ فقط می‌گوید ارزیابی NVD در زمان مشاهده ارائه نشده است. امتیاز CNA سیگنال اولیه است و مدیر باید مواجههٔ اینترنتی، زمان‌بندی ارتقا و حساسیت دارایی را نیز بسنجد.
جایگاه CISA KEV و موعدها
بخش جداگانهٔ NVD تأیید می‌کند که این CVE در CISA Known Exploited Vulnerabilities Catalog قرار دارد. نام آسیب‌پذیری در جدول CISA به‌صورت «WordPress WordPress Core Time-of-check Time-of-use (TOCTOU) Race Condition Vulnerability» آمده است. تاریخ افزوده‌شدن، ۳ نوامبر ۲۰۲۶، و Due Date، ۶ نوامبر ۲۰۲۶، هستند. این دو تاریخ را باید عیناً و جدا از تاریخ‌های NVD گزارش کرد: انتشار NVD در ۳۱ اکتبر، آخرین اصلاح NVD در ۴ نوامبر، افزودن به KEV در ۳ نوامبر، و deadline در ۶ نوامبر.
اقدام جدول، اعمال کاهش ریسک مطابق دستورهای فروشنده و رعایت راهنمای BOD 26-04 دربارهٔ اولویت‌بندی به‌روزرسانی بر اساس ریسک است و به Forensics Triage Requirements نیز ارجاع می‌دهد. تیم باید مواجههٔ اینترنتی، شواهد و انطباق با موعد را ثبت کند. اگر کاهش ریسک ممکن نباشد، متن KEV توقف استفاده از محصول را مطرح می‌کند؛ این تصمیم باید با تحلیل اثر کسب‌وکار و برنامهٔ جایگزین همراه باشد.
وضعیت اصلاحیه و آنچه باید راستی‌آزمایی شود
در فهرست ارجاع‌های NVD، دو نشانی از WordPress Trac برای برچسب ۷.۱.۴ با برچسب Patch دیده می‌شود: یکی در class-wp-upgrader.php در خط ۳۴۶ و دیگری در update-core.php در خط ۱۵۴۵. همان صفحهٔ NVD، پیوند WordPress.org با مسیر اخبار ۷.۱.۴ را با برچسب Release Notes فهرست می‌کند. این شواهد رسمی، ۷.۱.۴ را به‌عنوان شاخهٔ اصلاحی ارجاع‌شده برای بررسی مطرح می‌کنند؛ اما از یک پیوند مربوط به این شاخه نباید بدون تطبیق، نتیجه گرفت که تمام شاخه‌های قدیمی دقیقاً همان مسیر ارتقا یا همان اصلاح را دارند.
نسخهٔ دقیق نصب و شاخهٔ پشتیبانی را ثبت کنید، مرجع WordPress.org و تغییرات Trac را بررسی کنید و ارتقا را ابتدا در محیط آزمایشی و سپس، پس از آزمون سلامت افزونه‌ها و قالب، در تولید انجام دهید. بسته‌شدن پنجرهٔ فعلی جایگزین اصلاحیه نیست؛ ارتقای بعدی می‌تواند شرایط را دوباره ایجاد کند.
اقدامات موقت، با احتیاط
اقدام موقت باید به‌عنوان کنترل جبرانی و نه رفع آسیب‌پذیری معرفی شود. در قدم اول، زمان‌بندی ارتقاهای خودکار و دستی را تا تعیین تکلیف در یک پنجرهٔ کنترل‌شده قرار دهید؛ این کار ممکن است سطح مواجهه را کم کند، ولی به‌تعویق‌انداختن وصله نیز ریسک‌های دیگری دارد. هم‌زمان، دسترسی عمومی به مسیرهای staging و فایل‌های موقت را در reverse proxy یا وب‌سرور با سیاست حداقلی محدود کنید، مشروط بر اینکه این محدودسازی عملکرد عادی سایت و سازوکار رسمی به‌روزرسانی را نشکند. نام مسیرها، الگوهای URL و قوانین فایروال را بر اساس مستندات واقعی همان نصب تنظیم کنید، نه با حدس یا کپی‌کردن یک قاعدهٔ عمومی.
جداسازی سرویس ارتقا از ترافیک عمومی، کاهش سطح دسترسی فرآیند وب و محدودکردن مجوز فایل‌های موقت می‌تواند لایهٔ دفاعی اضافه کند، اما حذف race را ثابت نمی‌کند. خاموش‌کردن بی‌برنامهٔ ارتقا نیز ممکن است سایت را بی‌پچ بگذارد؛ هر تغییر باید مالک و برنامهٔ بازگشت داشته باشد.
پایش و پاسخ‌گویی
پایش را پیش از اصلاح شروع کنید. لاگ‌های reverse proxy، وب‌سرور، PHP و مدیریت محتوا را برای درخواست غیرعادی به staging، خواندن فایل موقت، خطاهای ارتقا و تغییر فایل‌های هسته بررسی کنید. این نشانه‌ها اثبات بهره‌برداری نیستند؛ هدف، ساخت خط مبنا و مشخص‌کردن موارد نیازمند تریاژ است. زمان، شناسهٔ درخواست، مبدأ، مسیر و نتیجهٔ HTTP را نگه دارید و اطلاعات حساس را محدود کنید.
برای یکپارچگی، فهرست فایل‌های هسته و مالکیت آنها را در یک نقطهٔ سالم ثبت و پس از ارتقا با آن مقایسه کنید. ایجاد فایل PHP ناشناخته، تغییر ناگهانی زمان فایل، تغییرات خارج از فرایند انتشار، حساب یا کلید جدید، cron ناشناس و اتصال خروجی غیرمنتظره، همگی شاخص‌های نیازمند تریاژ هستند. مشاهدهٔ هر شاخص به معنای پاک‌سازی فوری بدون حفظ شواهد نیست. ابتدا میزبان مشکوک را از مسیر مناسب ایزوله کنید، تصویر یا شواهد لازم را طبق رویهٔ سازمان حفظ کنید، اعتبار نشست‌ها و اسرار را ارزیابی کنید، سپس با نسخهٔ پاک و فرآیند قابل بازتولید بازیابی کنید.
از ساخت یا انتشار payload خودداری کنید. برای اعتبارسنجی کنترل‌ها، از آزمون‌های بی‌خطر در محیط جداگانه، مقایسهٔ نسخه و بررسی لاگ استفاده کنید. همچنین مانیتورینگ باید بعد از اصلاحیه ادامه یابد، زیرا مهاجمی که در پنجرهٔ ارتقا به سامانه دسترسی یافته ممکن است اثر ماندگار ایجاد کرده باشد. بسته‌شدن مسیر آسیب‌پذیر، به‌تنهایی پاک‌شدن اثرات قبلی را ثابت نمی‌کند.
جمع‌بندی برای مدیران IROSG
CVE-2026-119977 یک مسئلهٔ صرفاً نظری در کد قدیمی نیست: NVD آن را RCE در WordPress Core می‌داند، دامنهٔ ۴.۷ تا ۷.۱.۳ را اعلام می‌کند، و بخش CISA آن را در KEV با تاریخ اقدام کوتاه ثبت کرده است. ریشهٔ فنی، پیوند TOCTOU با staging قابل پیش‌بینی و web-accessible در ارتقای بستهٔ کامل است. ریسک دسترسی شبکه‌ای و بی‌نیازی از احراز هویت باید در کنار پیچیدگی حملهٔ بالا خوانده شود. امتیاز ۸.۱ متعلق به Wordfence به‌عنوان CNA است و NVD هنوز امتیاز مستقل ارائه نکرده است.
اولویت عملی، شناسایی نسخه‌ها و مواجههٔ اینترنتی، بررسی مرجع رسمی ۷.۱.۴ و تطبیق آن با شاخهٔ نصب، اجرای تغییر کنترل‌شده، و ثبت شواهد است. تا زمان اصلاح، کنترل‌های محدودکننده و پایش می‌توانند احتمال یا زمان کشف را بهتر کنند، اما جایگزین اصلاحیه نیستند. تیم‌ها باید deadline ششم نوامبر ۲۰۲۶ را به‌عنوان موعد CISA در برنامهٔ اقدام خود ثبت کنند، تاریخ‌های NVD و KEV را با هم اشتباه نگیرند، و هر تصمیم توقف، جداسازی یا بازگشت را بر مبنای ریسک مستند انجام دهند.
