باگ بحرانی PHP؛ آیا سایت شما در خطر هک است؟

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

تیم PHP در اطلاعیه رسمی ۲۱ اکتبر ۲۰۲۶، شناسه های CVE-2026-109618 و CVE-2026-109619 را اعلام و بر به روز رسانی فوری تاکید کرده است. در این مقاله، خطر را بدون اغراق توضیح می دهیم، نسخه های اصلاح شده را معرفی می کنیم و نشان می دهیم چرا شماره نسخه PHP همیشه تمام واقعیت امنیتی سرور را مشخص نمی کند.

باگ بحرانی PHP چیست و چرا باید جدی گرفته شود؟

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

دو نقص جدید با عنوان PHP2Shell نیز شناخته می شوند و امتیاز شدت آن ها در معیار CVSS نسخه ۴ برابر با ۹٫۲ اعلام شده است. این عدد نشان دهنده اولویت بالای رسیدگی است، اما به معنی اثبات هک شدن همه سایت ها نیست. باید بین «وجود یک مسیر آسیب پذیر» و «وقوع نفوذ تایید شده» تفاوت گذاشت.

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

دو آسیب پذیری جدید PHP چگونه عمل می کنند؟

CVE-2026-109618؛ اختلال حافظه هنگام پردازش درخواست

طبق توضیح فنی پروژه PHP، در شرایط کمبود حافظه ممکن است پردازش درخواست زمانی متوقف شود که بخشی از داده های داخلی هنوز کامل آماده نشده است. سپس مرحله پاک سازی می تواند این داده نامعتبر را معتبر فرض کند. این مسئله از جنس خطای ایمنی حافظه است و در شرایط قابل بهره برداری می تواند به اجرای کد منجر شود.

CVE-2026-109619؛ باقی ماندن وضعیت نامعتبر بین درخواست ها

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

برای خواننده غیر فنی، نکته کاربردی این است که تغییر رمز وردپرس یا حذف یک افزونه به تنهایی این دو خطای هسته PHP را اصلاح نمی کند. مشکل باید در لایه ای برطرف شود که مسئول اجرای کد PHP است. اقدامات امنیتی داخل سایت همچنان لازم هستند، اما هر کدام وظیفه جداگانه ای دارند.

کدام سایت ها و سرورها باید بررسی شوند؟

اطلاعیه رسمی PHP همه نصب هایی را که درخواست وب پردازش می کنند، در دامنه بررسی قرار می دهد؛ از جمله PHP-FPM، Apache با mod_php، php-cgi، FrankenPHP و LiteSpeed. بالاترین خطر اعلام شده مربوط به mod_php است و نمونه بهره برداری تایید شده می تواند پیش از اجرای کد برنامه فعال شود. استفاده از وب سروری دیگر، مجوز نادیده گرفتن وصله نیست.

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

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

نسخه های اصلاح شده PHP کدام هستند؟

پروژه PHP نسخه های زیر را برای رفع این دو آسیب پذیری منتشر کرده است. جدول به انتشارهای رسمی پروژه اشاره دارد؛ بسته های توزیع کننده ممکن است از روش انتقال وصله به نسخه قبلی استفاده کنند.

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

چرا PHP با شماره قدیمی تر می تواند وصله شده باشد؟

در بعضی توزیع های تجاری، اصلاح امنیتی به بسته موجود منتقل می شود؛ روشی که Backport نام دارد. در نتیجه، شماره اصلی PHP می تواند ثابت بماند و فقط شماره انتشار بسته تغییر کند. برای نمونه، مستندات CloudLinux برای alt-php82 بسته 8.2.34-7 و برای alt-php83 بسته 8.3.35-6 را در فهرست ساخت های اصلاح شده آورده اند.

این مثال ها فقط درباره همان خانواده بسته و محیط اعلام شده معتبر هستند. نباید هر نصب PHP 8.2.34 یا 8.3.35 را امن فرض کرد. نام کامل بسته، انتشار، مخزن تامین کننده و سابقه تغییرات آن باید با اطلاعیه فروشنده تطبیق داده شود. cPanel نیز برای EasyApache و بسته های تامین شده از CloudLinux اطلاعات جداگانه ارائه کرده است.

پس پاسخ حرفه ای به پرسش «آیا PHP من امن است؟» صرفا یک عدد کوتاه نیست. از پشتیبانی بخواهید مشخص کند کدام بسته برای دامنه شما اجرا می شود و رفع هر دو شناسه CVE چگونه تایید شده است. توضیح مبهم «نسخه جدید است» برای ثبت نتیجه بررسی کافی نیست.

آیا نصب افزونه امنیتی یا فعال بودن WAF کافی است؟

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

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

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

مدیر سایت اکنون چه کار کند؟

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

بعد از تایید رسیدگی زیرساخت، مسیرهای مهم کسب و کار را آزمایش کنید: ورود، فرم تماس، ارسال ایمیل و آپلود مورد نیاز برنامه. در فروشگاه، سبد خرید و فرایند ثبت سفارش را نیز کنترل کنید. هدف این آزمون ها تشخیص اختلال عملکرد است؛ موفق بودن خرید یا ورود، به تنهایی آزمون امنیتی رفع CVE محسوب نمی شود.

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

چرا نصب بسته پایان کار نیست؟

ممکن است بسته جدید روی دیسک نصب شده باشد، اما پردازشگرهای قدیمی همچنان فعال بمانند. مستندات CloudLinux بر راه اندازی مجدد سرویس های اجراکننده PHP تاکید می کند و درباره LiteSpeed یادآور می شود که راه اندازی مجدد وب سرور همیشه همه پردازش های lsphp را متوقف نمی کند. مدیر سرور باید نتیجه را در محیط واقعی کنترل کند.

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

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

آیا بررسی از بیرون سایت نسخه دقیق و وضعیت وصله را مشخص می کند؟

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

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

اگر نشانه مشکوک دیده شد چه اقدامی لازم است؟

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

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

پرسش های متداول درباره باگ بحرانی PHP

آیا این مشکل فقط مربوط به وردپرس است؟

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

آیا تغییر رمز مدیریت مشکل را برطرف می کند؟

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

چرا هاست من هنوز PHP 8.2.34 نشان می دهد؟

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

آیا فعال بودن LiteSpeed به معنی رفع خطر است؟

خیر. LiteSpeed نیز در دامنه اطلاعیه PHP قرار دارد. وضعیت PHP مورد استفاده و پردازشگرهای فعال باید بررسی شود.

آیا مشتری هاست باید خودش دستور به روز رسانی سرور اجرا کند؟

در هاست اشتراکی، رسیدگی زیرساخت با میزبان است. مشتری باید وضعیت را پیگیری و عملکرد برنامه خود را کنترل کند. در سرور بدون مدیریت، مسئولیت با مالک یا مدیر تعیین شده او است.

منابع رسمی برای پیگیری

اطلاعات فنی این مقاله بر اساس اطلاعیه پروژه PHP درباره انتشار امنیتی ۲۱ اکتبر ۲۰۲۶، گزارش های فنی CVE-2026-109618 و CVE-2026-109619، راهنمای بسته های اصلاح شده cPanel و مستند تایید وصله در CloudLinux تهیه شده است. برای نگهداری برنامه نیز راهنمای رسمی ایمن سازی وردپرس قابل مراجعه است.

اطلاعیه ارومیا سرور: هر ۴۳ سرور به روز رسانی شده اند

امنیت زیرساخت بخشی از مسئولیت ما در برابر کسب و کارهایی است که به خدمات میزبانی اعتماد کرده اند. در ارتباط با این رخداد امنیتی PHP، به اطلاع مشتریان می رسانیم: تمامی ۴۳ سرور ارومیا سرور به روز رسانی شده اند.

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