مقدمه

تیم توسعه PHP در تاریخ ۲۶ اکتبر ۲۰۲۶، بسته‌های رسمی PHP برای سیستم‌عامل ویندوز را با اصلاحیه امنیتی جدید منتشر کرد. هدف این به‌روزرسانی، رفع آسیب‌پذیری امنیتی (با شناسه CVE-2026-111497) موجود در کتابخانه فشرده‌سازی Brotli است؛ نقصی که در شرایط مشخص می‌تواند به تخریب حافظه و در نهایت اجرای کد توسط مهاجم منجر شود.

این به‌روزرسانی تنها پنج روز پس از انتشار نسخه‌های امنیتی قبلی PHP ارائه شده است؛ نسخه‌هایی که دو آسیب‌پذیری مهم با قابلیت اجرای کد از راه دور، موسوم به PHP2Shell، را برطرف کردند.

بر اساس گزارش منتشرشده توسط The Hacker News و اطلاعیه رسمی پروژه PHP، مدیران سرورهای ویندوزی که از بسته‌های رسمی این زبان استفاده می‌کنند، باید نسخه بسته نصب‌شده خود را بررسی کرده و در صورت نیاز، بسته بازسازی‌شده جدید را دریافت و نصب کنند.

آسیب‌پذیری CVE-2026-111497 چیست؟

این آسیب‌پذیری در کتابخانه Brotli قرار دارد؛ کتابخانه‌ای که برای فشرده‌سازی و از حالت فشرده خارج کردن داده‌ها استفاده می‌شود و در نرم‌افزارها و ابزارهای مختلف، از جمله برخی بسته‌های PHP، مورد استفاده قرار می‌گیرد.

مشکل امنیتی مورد بحث از نوع نوشتن خارج از محدوده حافظه (Out-of-Bounds Write) است. چنین نقصی زمانی رخ می‌دهد که نرم‌افزار هنگام پردازش داده‌ها، اطلاعاتی را در بخشی از حافظه می‌نویسد که خارج از محدوده مجاز آن قرار دارد.

بسته به شرایط اجرای برنامه و نحوه بهره‌برداری، این وضعیت می‌تواند باعث خرابی فرایند، تخریب حافظه یا اجرای کد مخرب شود.

در این مورد، نسخه آسیب‌پذیر Brotli در بسته‌های رسمی ویندوز PHP وجود داشته و مسیر بالقوه دسترسی به نقص از طریق افزونه cURL و قابلیت رمزگشایی خودکار پاسخ‌های HTTP قابل فشرده‌سازی بوده است.

نکته مهم آن است که وجود افزونه cURL به‌تنهایی به معنای فعال بودن این مسیر آسیب‌پذیر نیست؛ شرایط پیکربندی و نحوه استفاده برنامه از آن نیز اهمیت دارد.

سازوکار احتمالی حمله چگونه است؟

برای درک بهتر ریسک، باید زنجیره پردازش درخواست‌های HTTP را بررسی کنیم.

فرض کنید یک برنامه PHP روی ویندوز، از طریق cURL یا یک کتابخانه HTTP مانند Guzzle به یک سرویس خارجی متصل می‌شود. اگر رمزگشایی خودکار پاسخ‌ها فعال باشد، برنامه می‌تواند پاسخ فشرده‌شده دریافتی از سرور مقصد را به‌صورت خودکار از حالت فشرده خارج کند.

در شرایط آسیب‌پذیر، اگر پاسخ دریافتی به‌گونه‌ای طراحی شده باشد که نقص موجود در رمزگشای Brotli را فعال کند، امکان ایجاد خطای حافظه وجود خواهد داشت.

زنجیره کلی این سناریو به شکل زیر است:

۱. برنامه PHP یک درخواست HTTP به سرور مقصد ارسال می‌کند.

۲. سرور مقصد یک پاسخ فشرده‌شده و دست‌کاری‌شده برمی‌گرداند.

۳. cURL یا کتابخانه HTTP مورد استفاده، پاسخ را به‌صورت خودکار رمزگشایی می‌کند.

۴. رمزگشای آسیب‌پذیر Brotli داده‌ها را پردازش می‌کند و ممکن است عملیات نوشتن خارج از محدوده حافظه رخ دهد.

۵. در صورت موفقیت بهره‌برداری و فراهم بودن شرایط لازم، مهاجم ممکن است بتواند به اجرای کد مخرب دست پیدا کند.

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

همچنین، مهاجم لزوماً نمی‌تواند صرفاً با ارسال یک درخواست مستقیم به هر سرور PHP از این نقص بهره‌برداری کند؛ مسیر مورد بحث به پردازش پاسخ HTTP از سوی برنامه آسیب‌پذیر مربوط است.

کدام نسخه‌های PHP تحت تأثیر قرار گرفته‌اند؟

پروژه PHP بسته‌های رسمی ویندوز را برای شاخه‌های 8.2 تا 8.5 بازسازی کرده است. نسخه‌های جدید با پسوند -1 در نام بسته مشخص می‌شوند.

توجه: این جدول مربوط به بسته‌های رسمی ویندوز است. پسوند -1 به معنی انتشار مجدد بسته با وابستگی اصلاح‌شده است، نه تغییر شماره نسخه اصلی موتور PHP.

در این بسته‌ها، کتابخانه Brotli به نسخه 1.2.1 ارتقا یافته است که این نقص را برطرف می‌کند.

نسخه‌های قبلی PHP که در جدول بالا نیامده‌اند نیز نباید صرفاً به دلیل نبود نامشان در این فهرست ایمن فرض شوند. مدیران سیستم‌هایی که از نسخه‌های قدیمی‌تر، بسته‌های سفارشی یا توزیع‌های ثالث استفاده می‌کنند، باید وضعیت پشتیبانی و اصلاحیه‌های ارائه‌شده توسط تأمین‌کننده خود را بررسی کنند.

چرا دستور php -v برای تشخیص کافی نیست؟

یکی از نکات مهم این به‌روزرسانی، تفاوت میان نسخه موتور PHP و نسخه بسته نصب‌شده است.

در بسته‌های بازسازی‌شده، شماره نسخه اصلی PHP تغییر نمی‌کند. بنابراین ممکن است پس از نصب بسته اصلاح‌شده، اجرای دستور زیر همچنان همان شماره نسخه قبلی را نمایش دهد:

php -v

این رفتار طبیعی است و به‌تنهایی نشانه شکست به‌روزرسانی نیست.

برای تشخیص صحیح، مدیر سیستم باید نام فایل بسته نصب‌شده، نسخه وابستگی‌ها و در صورت امکان هش SHA-256 فایل دریافت‌شده را بررسی کند.

برای نمونه، نام یک بسته اصلاح‌شده می‌تواند به شکل زیر باشد:

php-8.5.12-1-nts-Win32-vs17-x64.zip

مقادیر نسخه، نوع ساخت و معماری باید با محیط نصب شما مطابقت داشته باشند. برای تأیید اصالت فایل، هش آن را با مقدار منتشرشده در صفحه رسمی دانلود PHP مقایسه کنید.

نقش cURL و کتابخانه Guzzle در افزایش ریسک

افزونه cURL در PHP برای ارتباط با سرویس‌های HTTP و سایر پروتکل‌های پشتیبانی‌شده استفاده می‌شود. این افزونه می‌تواند پاسخ‌های فشرده را دریافت و در صورت فعال بودن تنظیمات مربوطه، به‌صورت خودکار رمزگشایی کند.

گزینه CURLOPT_ENCODING در cURL برای فعال کردن این رفتار کاربرد دارد. تنظیم مقدار خالی برای این گزینه به cURL اجازه می‌دهد قالب‌های فشرده‌سازی پشتیبانی‌شده را بپذیرد.

برای مثال:

curl_setopt($ch, CURLOPT_ENCODING, '');

این کد به‌خودی‌خود مخرب نیست و در بسیاری از برنامه‌ها برای دریافت و پردازش پاسخ‌های فشرده استفاده می‌شود؛ اما در محیطی که بسته آسیب‌پذیر Brotli نصب شده است، می‌تواند مسیر مورد بحث را در دسترس قرار دهد.

کتابخانه Guzzle نیز از جمله ابزارهای رایج ارسال درخواست HTTP در PHP است. بر اساس بررسی کد نسخه‌های اشاره‌شده در گزارش The Hacker News، این کتابخانه در درخواست‌هایی که از cURL استفاده می‌کنند، می‌تواند رمزگشایی خودکار محتوا را فعال کند.

در نتیجه، بررسی امنیت نباید تنها به جست‌وجوی مستقیم curl_setopt در کد برنامه محدود شود. کتابخانه‌های شخص ثالث، فریم‌ورک‌ها و سرویس‌هایی که در پس‌زمینه از cURL استفاده می‌کنند نیز باید در ارزیابی ریسک لحاظ شوند.

شدت آسیب‌پذیری و وضعیت بهره‌برداری

ارزیابی شدت این نقص در منابع مختلف یکسان نیست:

• Google: امتیاز 9.2 از 10 بر اساس CVSS نسخه 4.0 و طبقه‌بندی بحرانی (Critical).
• Red Hat: امتیاز 8.1 بر اساس CVSS نسخه 3.1 و طبقه‌بندی مهم (Important).

این تفاوت لزوماً تناقض نیست؛ زیرا نسخه‌های متفاوت CVSS از روش‌های ارزیابی متفاوتی استفاده می‌کنند.

گزارش The Hacker News اعلام می‌کند که پژوهشگران Imperva توانسته‌اند در یکی از ساخت‌های رسمی Node.js از این نقص برای اجرای کد استفاده کنند، هرچند بهره‌برداری به چندین تلاش نیاز داشته است. این موضوع اهمیت نقص را نشان می‌دهد، اما به‌تنهایی اثبات نمی‌کند که همان سناریو در تمام بسته‌های PHP نیز با موفقیت اجرا می‌شود.

بر اساس اطلاعات منتشرشده در گزارش، اطلاعیه PHP حمله تأییدشده‌ای را برای این نقص اعلام نکرده بود و ارزیابی CISA در تاریخ ۲۳ اکتبر ۲۰۲۶ نیز بهره‌برداری از آن را ثبت نکرده بود.

بنابراین باید بین امکان فنی بهره‌برداری، اثبات مفهوم (PoC) و حمله موفق در محیط واقعی تفاوت قائل شد.

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

۱. بسته رسمی PHP ویندوز را به‌روزرسانی کنید

اولویت اصلی، دریافت بسته بازسازی‌شده از وب‌سایت رسمی PHP است:

https://windows.php.net/download/

بسته متناسب با شاخه PHP، معماری سیستم‌عامل و نوع ساخت مورد استفاده خود را انتخاب کنید. پیش از جایگزینی فایل‌ها، از تنظیمات و محیط فعلی نسخه پشتیبان تهیه کرده و سازگاری افزونه‌ها و وابستگی‌ها را بررسی کنید.

پس از نصب، سرویس‌های وابسته به PHP را مطابق معماری محیط خود راه‌اندازی مجدد کنید تا فرایندهای فعال از فایل‌های جدید استفاده کنند.

۲. فقط به شماره نسخه PHP اعتماد نکنید

از آنجا که شماره نسخه موتور PHP در بسته بازسازی‌شده تغییر نمی‌کند، برای تأیید اصلاحیه باید خود بسته نصب‌شده و وابستگی‌های آن بررسی شوند.

در محیط‌های سازمانی، بهتر است شماره ساخت، هش فایل، تاریخ استقرار و نتیجه آزمون پس از به‌روزرسانی در سوابق مدیریت تغییرات ثبت شوند.

۳. استفاده از رمزگشایی خودکار را تا زمان به‌روزرسانی محدود کنید

اگر امکان نصب فوری اصلاحیه وجود ندارد، غیرفعال کردن رمزگشایی خودکار پاسخ‌های HTTP می‌تواند یک اقدام موقت برای کاهش سطح مواجهه باشد.

در cURL، از تنظیم CURLOPT_ENCODING خودداری کنید؛ البته تنها در صورتی که برنامه به این قابلیت وابسته نباشد.

برای نمونه، در کد زیر این گزینه عمداً تنظیم نشده است:

$ch = curl_init('https://example.com/api');
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);

$response = curl_exec($ch);

این مثال صرفاً نشان می‌دهد که گزینه فعال‌کننده رمزگشایی خودکار تنظیم نشده است؛ سایر تنظیمات و نیازهای امنیتی برنامه همچنان باید جداگانه بررسی شوند.

در Guzzle نیز می‌توان گزینه decode_content را برای درخواست موردنظر روی false قرار داد:

$response = $client->request('GET', 'https://example.com/api', [
    'decode_content' => false,
]);

این تغییر، رمزگشایی خودکار محتوا را غیرفعال می‌کند و ممکن است باعث شود پاسخ‌های فشرده، از جمله پاسخ‌های gzip، به شکل فشرده به برنامه تحویل داده شوند. بنابراین کد مصرف‌کننده پاسخ باید با این رفتار سازگار باشد.

مهم: این تنظیمات راهکار موقت کاهش ریسک هستند، نه جایگزین اصلاحیه امنیتی. همچنین حذف صرف نام br از هدر Accept-Encoding تضمین نمی‌کند که سرور مقصد هرگز پاسخ Brotli ارسال نکند.

۴. وابستگی‌های نرم‌افزاری را بررسی کنید

اگر برنامه شما از Guzzle، فریم‌ورک‌های PHP یا کتابخانه‌های HTTP دیگر استفاده می‌کند، مشخص کنید که آیا این ابزارها از cURL و رمزگشایی خودکار پاسخ‌ها استفاده می‌کنند یا خیر.

در پروژه‌های بزرگ، بررسی فایل‌های قفل وابستگی مانند composer.lock و شناسایی مسیرهای ارتباطی برنامه با سرویس‌های خارجی می‌تواند به اولویت‌بندی بررسی‌ها کمک کند.

۵. محیط‌های غیر ویندوزی را نیز فراموش نکنید

این خبر درباره بازسازی بسته‌های رسمی PHP برای ویندوز است؛ اما کتابخانه Brotli در نرم‌افزارهای دیگری نیز استفاده می‌شود.

مدیران سیستم‌های لینوکسی باید وضعیت بسته Brotli و PHP را از طریق مخازن رسمی توزیع یا تأمین‌کننده خود بررسی کنند. صرف انتشار بسته جدید ویندوز به این معنا نیست که تمام محیط‌های لینوکسی یا نرم‌افزارهایی که Brotli را به‌صورت مستقل عرضه می‌کنند، به‌طور خودکار اصلاح شده‌اند.

جمع‌بندی

آسیب‌پذیری CVE-2026-111497 یادآوری می‌کند که امنیت یک برنامه تنها به کد نوشته‌شده توسط توسعه‌دهنده وابسته نیست. کتابخانه‌های جانبی، افزونه‌های زبان برنامه‌نویسی و اجزایی که برای پردازش داده‌های دریافتی از شبکه استفاده می‌شوند نیز می‌توانند سطح حمله قابل‌توجهی ایجاد کنند.

برای مدیران سرورهای ویندوزی، اقدام پیشنهادی روشن است: بسته رسمی PHP را بررسی کنید، نسخه بازسازی‌شده متناسب با محیط خود را نصب کنید و تنها به خروجی php -v اکتفا نکنید.

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

منابع

۱. The Hacker News — PHP Issues Second Windows Security Update in Five Days to Fix Brotli Code Execution Flaw، منتشرشده در ۲۶ اکتبر ۲۰۲۶:

https://thehackernews.com/2026/10/php-issues-second-windows-security.html

۲. PHP.net — آرشیو اطلاعیه‌های رسمی PHP در سال ۲۰۲۶:

https://www.php.net/archive/2026.php

۳. PHP for Windows — صفحه رسمی دریافت بسته‌های PHP ویندوز:

https://windows.php.net/download/

این مقاله بر اساس گزارش منبع اصلی و اطلاعیه‌های رسمی پروژه PHP بازنویسی شده است. برای تصمیم‌گیری عملیاتی، اطلاعیه‌های امنیتی رسمی و وضعیت بسته نصب‌شده در محیط خود را ملاک قرار دهید.