آسیب‌پذیری PHP در ایزابل ۴ و ۵: بررسی PHP2Shell و کاهش ریسک

در ۲۱ اکتبر ۲۰۲۶ دو آسیب‌پذیری PHP با شناسه‌های CVE-2026-109618 و CVE-2026-109619 اعلام شدن که با اسم PHP2Shell هم شناخته میشن. این مشکل برای ادمین ایزابل مهمه، چون پنل وب Issabel از PHP استفاده میکنه و در شرایط مشخص، درخواست HTTP/HTTPS بدون لاگین میتونه به اجرای کد از راه دور برسه.

نتیجهٔ بررسی روی این دو نصب یکسان نبود. روی سرور Issabel 5 که بررسی کردم، خاموش کردن Upload Progress به معنی رفع کامل PHP2Shell نیست.

PHP2Shell چیه و کدوم بخش ایزابل درگیره؟

PHP2Shell اسم رایج دو آسیب‌پذیری در پردازش درخواست‌های PHP هست. CVE-2026-109618 به خطای مدیریت حافظه هنگام کمبود حافظه مربوطه. در CVE-2026-109619، بخشی از وضعیت یک درخواست ممکنه بعد از آزاد شدن حافظه باقی بمونه و درخواست بعدی همون Worker ازش استفاده کنه. اگه شرایط سوءاستفاده فراهم باشه، مهاجم میتونه با دسترسی کاربر سرویس وب کد اجرا کنه. این دسترسی لزوماً root نیست.

قابلیت Session Upload Progress برای پیگیری پیشرفت آپلود در PHP استفاده میشه و یکی از مسیرهای شناخته‌شدهٔ این مشکل هست. خاموش کردنش مسیرهای مربوط به Session رو میبنده، ولی همهٔ شکل‌های آسیب‌پذیری رو پوشش نمیده. استفاده از PHP-FPM هم به‌تنهایی به معنی امن بودن سرور نیست.

در ۲۳ اکتبر، PHP مورد جداگانهٔ CVE-2026-115560 رو هم اعلام کرد. طبق اطلاعیهٔ رسمی PHP دربارهٔ Session Upload Progress، این مورد به ترکیب خاصی از تنظیمات و تغییر Session Handler در کد برنامه نیاز داره. خاموش کردن Upload Progress جلوی همون وضعیت توضیح‌داده‌شده رو میگیره. این مورد رو نباید با رفع دو CVE قبلی یکی دونست.

سطح حمله اینجا سرویس وب HTTP/HTTPS هست. SIP، RTP و Asterisk مستقیماً عامل این آسیب‌پذیری‌های PHP نیستن. با این حال نفوذ به وب سرور میتونه مرکز تلفن رو هم در معرض خطر بذاره. داشتن پسورد قوی برای پنل، جای Patch رو نمیگیره.

Issabel 4 و 5 به یک شکل آسیب‌پذیر هستن؟

نه لزوما! نوع پکیج PHP و روش اجرای اون تعیین‌کننده‌ هست. جدول زیر وضعیت دو سروری که توی لابراتوار بررسی کردم رو نشون میده. برای سرورهای دیگه باید پکیج و تنظیمات خودشون رو بررسی کنید:

Red Hat در RHSB-2026-013 میگه کد لازم برای CVE-2026-109618 در PHP عرضه‌شده با RHEL 7 وجود نداره و خاموش کردن Upload Progress، مسیر آسیب‌پذیری CVE-2026-109619 رو برای همون پکیج میبنده. سرور Issabel 4 که بررسی کردم، از خانوادهٔ EL7 بود، اما پکیج CentOS، پکیج تحت پشتیبانی Red Hat نیست. پس اگه PHP سرورتون رو تغییر دادید یا پکیج دیگه‌ای نصب کردید، نمیشه همین نتیجه رو بدون بررسی به اون هم تعمیم داد.

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

اول مشخص کنید روی سرورتون چی نصب شده

دستورها رو داخل پنل وب ایزابل وارد نکنید. با SSH، مثلاً از PuTTY یا Terminal، یا از Console ماشین مجازی وارد خود سرور Issabel بشید. دستورهای این بخش فقط وضعیت فعلی رو نشون میدن و پکیجی نصب نمیکنن:

cat /etc/redhat-release
php -v
rpm -q php php-fpm
LC_ALL=C rpm -qi php | grep -E 'Vendor|Release'

خط اول سیستم‌عامل، خط دوم نسخهٔ PHP در Command Line، و دو خط بعد شمارهٔ دقیق RPM و Vendor رو نشون میدن. نبودن پکیج php-fpm روی نصب mod_php میتونه طبیعی باشه. اگه از SCL یا اسم پکیج متفاوت استفاده میکنید، این دستورها ممکنه پکیج PHP فعال روی سرورتون رو نشون ندن.

برای تشخیص اولیهٔ روش اجرا، این دستورها رو با دسترسی ادمین اجرا کنید:

httpd -M | grep -i php
systemctl is-active php-fpm

دیدن php5_module یعنی mod_php روی Apache بارگذاری شده. فعال بودن PHP-FPM فقط وجود سرویس رو نشون میده. باید اتصال وب‌سایت به Pool مربوطه هم تأیید بشه. اگه هیچ‌کدوم با نصب شما جور نیست، بخش تغییر تنظیمات رو اجرا نکنید.

خروجی php -v وضعیت PHP وب رو ثابت نمیکنه. از طرف دیگه، شمارهٔ قدیمی نسخه لزوماً به معنی نبود Security Patch نیست. بعضی Vendorها اصلاح امنیتی رو به همون نسخه Backport میکنن. شمارهٔ کامل RPM و توضیحات Vendor مهمن.

قبل از تغییر: بکاپ، زمان مناسب و دسترسی root

• بکاپ قابل بازیابی از سرور و تنظیمات داشته باشید و روش Restore رو بشناسید. Snapshot ماشین مجازی کمک میکنه، ولی جای بکاپ مستقل رو نمیگیره.
• کار رو در Maintenance Window انجام بدید. Restart وب ممکنه درخواست‌های در حال اجرا و دسترسی پنل رو قطع کنه. Console رو برای مواقع قطع دسترسی آماده نگه دارید.
• دستورهای تغییر فایل و Restart در ادامه به دسترسی root نیاز دارن. اگه با کاربر معمولی وارد شدید، اول با روشی که توی سازمانتون مجازه، یک سشن با دسترسی root باز کنید.
• PHP رو صرفاً برای بزرگ‌تر شدن شمارهٔ نسخه به PHP 8 تغییر ندید. سازگاری Issabel، افزونه‌ها و تنظیمات باید جدا بررسی بشه.

توی هر دو تست، تنظیمات رو تغییر دادم، سرویس مربوطه رو کامل Restart کردم و مقدار فعال رو توی PHP وب بررسی کردم. مراحل زیر همین روش رو قدم‌به‌قدم توضیح میدن و دستورهای بررسی و Rollback رو هم کنارش دارن. توی این بررسی، Update جدید PHP نصب نکردم و نتیجه‌ای از تست Rollback هم ثبت نکردم.

Issabel 4: کاهش ریسک با تنظیم Apache mod_php

مراحل این بخش برای سروری نوشته شده که CentOS/EL7، PHP 5.4 و Apache mod_php داره. اگه PHP رو با Remi، SCL یا نسخهٔ دیگه جایگزین کردید، اول راهنمای همون پکیج رو بررسی کنید.

۱. فایل قبلی رو بررسی و از تنظیمات بکاپ بگیرید

با root، اول وجود فایل رو بررسی کنید:

ls -l /etc/httpd/conf.d/zz-php-cve-2026-109619-mitigation.conf

اگه فایل وجود داره، محتوای اون رو بررسی کنید و دوباره ایجادش نکنید. پیام No such file or directory فقط یعنی فایل پیدا نشده. خطاهای دسترسی رو نادیده نگیرید. اگه این فایل وجود نداره، قبل از ادامه از تنظیمات Apache بکاپ بگیرید:

BK4="$(mktemp -d /root/issabel4-php-backup-XXXXXX)" &&
cp -a /etc/httpd/conf.d "$BK4/conf.d" &&
printf '%s\n' "$BK4"

فقط اگه همهٔ دستورها موفق بودن ادامه بدید. مسیری که نشون میده رو یادداشت کنید. بکاپ تنظیمات جای بکاپ کل سرور رو نمیگیره.

۲. تنظیم مدیریتی رو اضافه کنید

دستور زیر در یک سشن root، فایل جدید ایجاد میکنه. set -C برای جلوگیری از اینه که روی فایل فعلی بازنویسی بشه:

(
  set -C
  printf '%s\n' \
    'php_admin_flag session.upload_progress.enabled Off' \
    > /etc/httpd/conf.d/zz-php-cve-2026-109619-mitigation.conf
)

اگه خطا دیدید، همین‌جا متوقف بشید. تنظیم php_admin_flag در کانفیگ مدیریتی Apache اعمال میشه. قرار نیست با ini_set() داخل برنامه جایگزین بشه.

۳. Syntax رو تست کنید، بعد Apache رو کامل Restart کنید

httpd -t

خروجی این دستور باید Syntax OK باشه. با وجود خطا، Restart نکنید. فایلی که ایجاد کردید رو طبق بخش Rollback حذف کنید و دوباره Syntax رو بررسی کنید. بعد از تست موفق:

systemctl restart httpd && systemctl is-active httpd

خروجی این دستور باید active باشه. Reload به‌تنهایی کافی نیست. تمام Workerهای قبلی PHP باید متوقف بشن. در نصب mod_php این کار با Restart کامل Apache انجام میشه.

نتیجهٔ ثبت‌شده و Rollback

توی بررسی من روی Issabel 4، بعد از اعمال این تنظیم و Restart، مقدار Upload Progress در PHP وب به 0 رسید. Apache و Asterisk فعال موندن. توی این تست، تماس واقعی رو بررسی نکردم. این نتیجه، نصب Patch PHP یا امن شدن کامل CentOS 7 رو ثابت نمیکنه.

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

rm -- /etc/httpd/conf.d/zz-php-cve-2026-109619-mitigation.conf
httpd -t && systemctl restart httpd
systemctl is-active httpd

Rollback، حفاظت اضافه‌شده رو هم برمیداره. تا بررسی علت مشکل، دسترسی وب رو به شبکهٔ مدیریت محدود نگه دارید.

Issabel 5: اول Update سازگار، بعد Mitigation موقت

روی سرور Rocky Linux 8.10 که بررسی کردم، PHP نسخهٔ 7.4.33-8.el8.remi با PHP-FPM اجرا میشد. CVE-2026-109618 روی این سرور رفع نشده و خاموش کردن Upload Progress هم اون رو اصلاح نمیکنه. راهکار اصلی برای دو آسیب‌پذیری، نصب Security Patch سازگار و تأییدشده هست. باید مطمئن بشید پکیج مقصد، اصلاحات مربوط به این CVEها رو داره.

۱. پکیج و Update پیشنهادی رو بررسی کنید

rpm -q php php-fpm php-cli php-common
LC_ALL=C rpm -qi php | grep -E 'Vendor|Release'
dnf module list --enabled php
dnf repolist --enabled

این‌ها وضعیت نصب، Module Stream و Repositoryهای فعال رو نشون میدن. برای دیدن تراکنش پیشنهادی، بدون تأیید نصب:

dnf --assumeno upgrade php php-fpm php-cli php-common

--assumeno نصب رو تأیید نمیکنه، ولی DNF ممکنه Metadata مخزن رو دریافت و Cache محلی رو تغییر بده. قبل از نصب واقعی، نسخهٔ مقصد، وابستگی‌ها، افزونه‌های PHP و سازگاری با Issabel رو بررسی کنید. حذف پکیج یا تغییر ناخواستهٔ Stream رو نپذیرید.

خروجی Nothing to do لزوماً یعنی «Patch وجود نداره» نیست. توی بررسی من هم با تنظیمات فعلی DNF، Update مناسب نمایش داده نشد. Remi برای PHP 7.4.33-31 در ۲۲ اکتبر از Mitigation مربوط به CVE-2026-109618 و CVE-2026-109619 نام برده. این عبارت به‌تنهایی تضمین پوشش کامل تمام مسیرها نیست. وجود پکیج در Upstream با قابل‌نصب و سازگار بودنش روی سرور شما فرق داره.

توی بررسی Issabel 5، هیچ Update جدید PHP نصب نکردم و سازگاری نصب پکیج جدید Remi رو هم تأیید نکردم. به همین دلیل اینجا دستور عمومی برای Reset یا تغییر DNF Module Stream پیشنهاد نمیکنم. ادمین باید مسیر Update رو روی نسخهٔ آزمایشیِ مشابه بررسی کنه، بعد با بکاپ و بازبینی تراکنش روی سرور اصلی اجرا کنه. Changelog هم برای بررسی اولیه مفیده، ولی جای تأیید Vendor رو نمیگیره:

rpm -q --changelog php | head -40

۲. اگه فعلاً Patch سازگار ندارید، Pool درست رو پیدا کنید

روی سروری که بررسی کردم، Pool فعال [www] در /etc/php-fpm.d/www.conf بود. اول تنظیمات اتصال Apache و آدرس Listen هر Pool رو ببینید:

grep -R -nE 'SetHandler|proxy:unix:|fcgi://' /etc/httpd/conf /etc/httpd/conf.d
grep -nE '^\[|^[[:space:]]*listen[[:space:]]*=' /etc/php-fpm.d/*.conf

Socket یا آدرس مقصد Apache باید به Listen همون Pool برسه. اگه خروجی خالی بود یا چند Pool دیدید، حدس نزنید. از ادمین بخواید Includeها و VirtualHost فعال رو بررسی کنه. اگه Pool پنل شما www نیست، مسیرها و نام بخش در ادامه باید متناسب با همون Pool عوض بشن.

۳. از فایل Pool، بکاپ بگیرید و تنظیم تکراری نسازید

بعد از تأیید Pool و با دسترسی root:

BK5="$(mktemp -d /root/issabel5-php-backup-XXXXXX)" &&
cp -a /etc/php-fpm.d/www.conf "$BK5/www.conf" &&
printf '%s\n' "$BK5"

اگه بکاپ موفق نبود ادامه ندید. مسیری که نشون میده رو نگه دارید. قبل از ویرایش، تنظیم‌های قبلی رو پیدا کنید:

grep -R -nF 'session.upload_progress.enabled' \
  /etc/php.ini /etc/php.d /etc/php-fpm.conf /etc/php-fpm.d

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

vi /etc/php-fpm.d/www.conf

داخل بخش [www]، اگه این تنظیم از قبل وجود داره، مقدارش رو اصلاح کنید. اگه وجود نداره، این خط رو اضافه کنید:

php_admin_flag[session.upload_progress.enabled] = off

توی vi برای ویرایش i رو بزنید. برای ذخیره و خروج، Esc و بعد :wq رو وارد کنید. این تنظیم مدیریتی Pool هست. گذاشتن اون در .user.ini یا تغییر در کد برنامه، جای این مرحله رو نمیگیره.

۴. Syntax رو تست و PHP-FPM رو کامل Restart کنید

php-fpm -t

فقط با تست موفق و بدون خطای کانفیگ ادامه بدید. بعد:

systemctl restart php-fpm && systemctl is-active php-fpm

خروجی این دستور باید active باشه. Restart کامل PHP-FPM لازمه. Reload یا فقط Restart کردن Apache کافی نیست. توی تست من، برای این تغییر نیازی به Restart Asterisk یا Apache نبود.

این تغییر چی رو پوشش می‌ده و چی رو نمیده؟

• CVE-2026-109618: خاموش کردن Upload Progress این مورد رو رفع نمیکنه. روی سروری که بررسی کردم هم هنوز رفع نشده.
• CVE-2026-109619: مسیرهای شناخته‌شدهٔ Session Upload Progress محدود میشن. طبق Advisory PHP، یک تنظیم عمومی وجود نداره که همهٔ مسیرهای این آسیب‌پذیری رو ببنده.
• CVE-2026-115560: خاموش بودن Upload Progress در PHP وب جلوی شرایطی که برای این CVE اعلام شده رو میگیره. البته تست نکردم که این دو سرور از طریق همین CVE قابل نفوذ بودن یا نه.

توی تست من روی Issabel 5، مقدار Upload Progress در PHP وب به 0 رسید و PHP-FPM، Apache و Asterisk فعال موندن. این نتیجه فقط اعمال تنظیم رو تأیید میکنه. از این نتیجه نمیشه گفت که دو آسیب‌پذیری اصلی کامل رفع شدن.

Rollback تنظیم PHP-FPM

اگه بعد از تغییر مشکل داشتید، فایل رو از بکاپ دقیق همین عملیات برگردونید. این دستورها فقط در همون سشن و با متغیر معتبر BK5 اجرا بشن:

test -n "$BK5" && test -f "$BK5/www.conf" &&
cp -a "$BK5/www.conf" /etc/php-fpm.d/www.conf &&
php-fpm -t && systemctl restart php-fpm
systemctl is-active php-fpm

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

چرا اسکریپت اطلاعیهٔ Issabel با این مراحل فرق داره؟

اطلاعیهٔ انجمن Issabel علاوه بر خاموش کردن Upload Progress، تغییر محدودیت حافظه و اندازهٔ درخواست رو هم مطرح کرده. راهنمای فعلی PHP هم برای کاهش بعضی مسیرهای CVE-2026-109618 از حذف محدودیت حافظهٔ هر درخواست صحبت میکنه، اما اون رو رفع کامل نمیدونه.

تنظیم memory_limit=-1 میتونه محدودیت مصرف حافظهٔ PHP رو برداره. بدون طراحی محدودیت مناسب cgroup یا Container، ریسک مصرف RAM و اختلال مرکز تلفن رو بالا میبره. این تغییرها رو روی دو سرور تست اجرا نکردم، پس اینجا به‌عنوان دستور عمومی پیشنهادشون نمیکنم. قبل از اجرای اسکریپت، نسخه و سازگاری اون رو هم بررسی کنید. دریافت و اجرای مستقیم یک اسکریپت اینترنتی جای این بررسی رو نمیگیره.

چطور مطمئن بشید تنظیم واقعاً اعمال شده؟

اول وضعیت سرویس‌ها رو بررسی کنید. برای Issabel 4:

systemctl is-active httpd asterisk

برای Issabel 5:

systemctl is-active php-fpm httpd asterisk

هر سرویس باید active باشه. اگه نیست، خروجی وضعیت و لاگ رو بررسی کنید. برای نمونه، بسته به سرویس:

systemctl status httpd --no-pager
journalctl -u httpd -n 30 --no-pager

در نصب PHP-FPM، به‌جای httpd نام php-fpm رو بذارید. فعال بودن سرویس به‌تنهایی تأیید نمیکنه که آسیب‌پذیری رفع شده.

بررسی تنظیم فعال در PHP وب، مخصوص ادمین

دیدن Off در فایل یا خروجی php -i کافی نیست. ادمین باید از همون VirtualHost و همون PHP Handler/Pool پنل مقدار مؤثر ini_get('session.upload_progress.enabled') رو بررسی کنه. توی تست خودم، این مقدار رو با یک فایل موقت و دسترسی محدود به localhost بررسی کردم. مقدار نهایی 0 بود.

برای این کار صفحهٔ عمومی phpinfo() نسازید. ادمین باید قبل از ایجاد فایل، دسترسی به مسیر اون رو محدود کنه و مطمئن بشه از بیرون باز نمیشه. بعد مقدار موردنیاز رو از PHP وب بخونه و در پایان، فایل و تنظیمات موقت رو حذف کنه. پشت Reverse Proxy، اینکه IP مبدأ localhost دیده بشه، لزوماً به معنی خصوصی بودن مسیر نیست. اگه این کنترل رو بلد نیستید، تأیید Runtime رو به ادمین بسپارید.

چک‌لیست عملکرد بعد از Restart

• ورود به پنل و باز شدن بخش‌های اصلی.
• Registration داخلی‌ها و تماس داخلی.
• تماس ورودی و خروجی، IVR و Queue، اگه استفاده میکنید.
• CDR، ضبط تماس و یک آپلود معمولی پنل، در صورت استفاده.

توی این بررسی، فعال موندن سرویس‌های اصلی رو چک کردم. تماس واقعی و همهٔ قابلیت‌های PBX رو تست نکردم. اگه بعد از کار با Registration مشکل داشتید، راهنمای رجیستر نشدن داخلی در ایزابل برای عیب‌یابی اون بخشه. برای حل این CVEها نیازی به باز کردن پورت SIP یا غیرفعال کردن SELinux ندارید.

چند اقدام امنیتی که کنار این کار لازمه

پیشنهاد میکنم حتی اگه Patch کردید، پنل وب ایزابل رو روی اینترنت پابلیش نکنید. سرویس تلفن برای ارتباط روزمرهٔ سازمان مهمه و اختلال یا نفوذ به اون میتونه تماس‌های کاری رو مختل کنه. بهتره پنل فقط از طریق Management Network و VPN سازمانی خودتون در دسترس باشه. قبل از تغییر Firewall هم مطمئن بشید که دسترسی مدیریتی و Console رو از دست نمیدید.

• LAN رو کاملاً قابل‌اعتماد فرض نکنید. یک دستگاه آلودهٔ داخلی هم میتونه به پنل وب درخواست بفرسته.
• Patchهای سازگار PHP و وابستگی‌ها رو از Vendor پیگیری کنید. برای CentOS 7 و PHPهای EOL، برنامهٔ مهاجرت به پلتفرم تحت پشتیبانی داشته باشید.

توی این تست، دسترسی دو سرور از اینترنت و وضعیت Firewall بالادستی رو جداگانه بررسی نکردم. بنابراین تأیید نمیکنم که Network Isolation روی اون‌ها برقرار بوده. محدودسازی شبکه هم جایگزین Security Patch نیست. برای آشنایی با مشکل مخزن‌های قدیمی، مطلب مشکل Update ایزابل ۴ رو ببینید. دسترسی دوباره به آرشیو پکیج‌ها به معنی دریافت Patch امنیتی جدید نیست و دستورهای عمومی Update اون مطلب، راهکار این رخداد محسوب نمیشن.

برای یادگیری عملی مدیریت ایزابل

اگه میخواید نصب، مدیریت و امنیت مرکز تلفن رو منظم‌تر یاد بگیرید، توی دورهٔ آموزش ویپ VoIP: ایزابل و استریسک سناریوهای عملی رو با Issabel 5 جلو بردم و تفاوت‌های Issabel 4 رو هم بررسی کردم. مباحث Linux و امنیت VoIP هم بخشی از دوره هستن. برای پیگیری وضعیت این CVEهای تازه، مرجع اصلی همون اطلاعیه‌های امنیتی روزه.

جمع‌بندی

اول پکیج PHP و روش اجرای وب رو مشخص کنید، بکاپ بگیرید و فقط راهکار متناسب با نصب خودتون رو اجرا کنید. توی تست من روی Issabel 4، بعد از تنظیم Apache و Restart کامل، خاموش بودن Upload Progress در PHP وب تأیید شد. روی Issabel 5، همین تنظیم در Pool و Restart PHP-FPM فقط بخشی از ریسک رو کم کرده. CVE-2026-109618 همچنان رفع نشده و رفع کامل CVE-2026-109619 هم تأیید نشده. هنوز باید Patch سازگار رو پیگیری کنید، تنظیم فعال در PHP وب رو بررسی کنید و دسترسی وب رو محدود نگه دارید.

منابع و تاریخ بررسی

منابع رو در ۲۴ اکتبر ۲۰۲۶، برابر با ۲ آبان ۱۴۰۵، بررسی کردم. وضعیت Patchها ممکنه بعد از این تاریخ تغییر کنه.

• Red Hat: بولتن PHP2Shell و تفاوت RHEL 7 با نسخه‌های دیگه
• PHP: گزارش رسمی CVE-2026-109618
• PHP: گزارش رسمی CVE-2026-109619 و محدودیت Mitigation
• PHP: اطلاعیهٔ ۲۳ اکتبر دربارهٔ CVE-2026-115560
• مخزن رسمی RPMهای Remi و یادداشت نگه‌داری پکیج‌های PHP 7.4
• اطلاعیهٔ امنیتی انجمن Issabel
• راهنمای رسمی تنظیم Pool در PHP-FPM

نویسنده

رامتین رحمانی‌نژاد

Issabel Certified Advisorمشاهدهٔ گواهی ↗