PHP2Shell: двете критични уязвимости в PHP и какво направихме във forge.bg

Днес, 21 октомври 2026 г., екипът на PHP пусна версии 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Те поправят две уязвимости, CVE-2026-109618 и CVE-2026-109619, които PHP оценява с 9,2 по CVSS v4.0. И двете позволяват на човек без акаунт на сайта да изпълни свой код на сървъра с правата на уеб процеса, като изпрати няколко подготвени HTTP заявки. Изследователите ги наричат PHP2Shell.

Всички сървъри на forge.bg вече работят с поправените версии на PHP и с обновен DirectAdmin, а защитната стена cPGuard на сървърите ни има ново правило срещу атаката.

Как бяха открити

Уязвимостите намери Райън Остин (Ryan Austin) от изследователската фирма Calif по време на одит на PHP в рамките на програмата на OpenAI Patch the Planet. В публикацията си Calif посочват като откриватели себе си, OpenAI и Wiz. В работата от самото начало е включен и Фолкер Душ (Volker Dusch) от PHP Foundation.

Остин тръгва от стари грешки. През 2004 г. Щефан Есер (Stefan Esser) публикува първата отдалечена уязвимост в PHP, свързана с ограничението на паметта memory_limit. През 2020 г. в PHP е докладван бъг #78876: дълги имена на полета в multipart заявка изчерпват паметта. При одита на PHP от OSTIF и Quarkslab през 2024 г. подобен проблем излиза отново, но тогава никой не доказва, че с него може да се атакува, и той остава непоправен.

Остин проверява дали в кода са останали грешки от същия вид и преглежда изходния код с езиков модел като помощник. По думите му не е ползвал специални инструменти или модели, до които други нямат достъп. На 1 август 2026 г., няколко дни след началото на одита, намира как да предизвика изчерпване на паметта по желание и първото място, където това прекъсване оставя PHP в опасно състояние. С него сглобява атака срещу WordPress. След това намира още два пътя, които работят надеждно срещу Apache с mod_php и срещу PHP-FPM.

Потвърждение, изтичане и поправка

Екипът на PHP потвърди първата уязвимост на 15 август 2026 г., след като пусна работещия експлойт на Calif. Поправките трябваше да излязат утре, 22 октомври, но информацията изтече вчера и PHP ги пусна с ден по-рано.

Към 17:00 българско време Huntress не са видели атаки в системите на своите клиенти, но други изследователи вече съобщават за опити. Според GMO Flatt Security в интернет вече се разпространява код, за който авторите твърдят, че използва уязвимостите.

Какво правят двете уязвимости

И двете уязвимости оставят в паметта на PHP недовършени или вече освободени данни, които по-късно се използват, все едно са валидни. Това дава на атакуващия възможност да пише и чете памет, а оттам да изпълни свой код.

CVE-2026-109618 засяга обработката на грешка при изчерпване на паметта. Ако PHP стигне memory_limit, докато подготвя данните на заявката, работата спира по средата и част от вътрешните структури остават недовършени. При почистването след заявката PHP ги чете като истински. Calif показват как атакуващият стига дотам: изпраща multipart заявка със стотици празни полета за файлове с вложени имена от вида files[a][b][c]. Тялото на заявката остава под 8 MB (стандартният post_max_size), а в паметта PHP заделя над 128 MB (стандартният memory_limit). Всичко става, преди да се изпълни кодът на сайта. Екипът на PHP е проверил пълно изпълнение на код срещу Apache с mod_php със стандартните ограничения за входни данни и памет.

CVE-2026-109619 е използване на памет след освобождаването ѝ (use-after-free). Вътрешно състояние на една заявка оцелява, след като паметта под него е освободена, и ако същият работен процес поеме следваща заявка, PHP го ползва, преди да го нулира. Потвърденият път минава през функцията session upload progress, която отваря сесия, докато PHP още чете тялото на заявката. Ако първата заявка прекъсне с фатална грешка точно тогава, данните на сесията остават да сочат в освободена памет, а втора заявка без файл ги използва. Освен изпълнение на код, Wiz показват, че по този начин от паметта могат да изтекат пароли, токени, API ключове и сертификати. Calif описват и вариант, при който атаката минава през unserialize() в приложението и работи и срещу PHP-FPM.

Кой е засегнат

Според екипа на PHP засегната е всяка инсталация, която обслужва уеб заявки: PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Най-висок е рискът при mod_php, където атаката може да започне, преди да се изпълни и ред от кода на сайта.

Най-ранният уязвим път, който Calif са намерили, е в PHP 5.4.0.

PHP 8.1 и по-старите версии вече не получават официални поправки. Екипът на PHP публикува минимални кръпки в изходен код за 7.4, 8.0 и 8.1 за тези, които компилират PHP сами. PHP 8.2 ще получава поправки до 31 декември 2026 г.

Кои сайтове са застрашени

Уязвимостите са в самия PHP, затова е застрашен всеки сайт, който работи на непоправена версия, независимо дали самата система и плъгините ѝ са обновени. Ето най-разпространените системи, които работят на PHP:

Calif са проверили атака без вход в системата срещу WordPress 7.1.2, Drupal 11.4.3, Joomla 6.1.4, MediaWiki 1.46.2, Roundcube 1.7.4, Magento 2.4.9, phpMyAdmin 5.2.3, Nextcloud 35.0.1, Laravel 13.11, Symfony 8.1 и WHMCS. За останалите системи в таблицата няма публикувана проверка, но екипът на PHP смята за засегната всяка инсталация, която обслужва уеб заявки. Същото важи и за сайтове, писани на чист PHP без система.

Как да се предпазите

Единствената пълна защита е обновяване на PHP до 8.5.12, 8.4.27, 8.3.36 или 8.2.35. Ако поддържате собствен сървър, направете следното:

1. Обновете PHP. Linux дистрибуциите и доставчиците с дългосрочна поддръжка са получили кръпките преди публикуването, затова проверете за обновени пакети в CloudLinux, AlmaLinux, RHEL, Ubuntu или Debian. Хранилището rpms.remirepo.net днес няма да има обновления и PHP препоръчва да минете на пакетите на дистрибуцията или да компилирате от изходен код.
2. Ако обновяването трябва да почака, сложете временни настройки. Според PHP те затварят конкретни пътища на атаката, но не правят сървъра безопасен:
   • session.upload_progress.enabled = 0 в главния php.ini на всяка инсталирана версия на PHP или в конфигурацията на FPM pool. Задаването през ini_set() или .user.ini не помага, защото се прилага твърде късно. Проверете и дали някой pool или потребителски ini файл не включва настройката обратно.
   • memory_limit = -1, зададено с php_admin_value, за да не може приложението да го смени. Това маха ограничението на паметта на PHP, затова PHP съветва да сложите лимит на ниво контейнер или cgroup.
   • Нисък post_max_size: 8M за сайтове без качване на файлове, 32M за сайтове с качване, като upload_max_filesize остава под post_max_size.
   • На PHP 8.5: fatal_error_backtraces = 0.
3. Рестартирайте PHP-FPM, Apache или LiteSpeed, за да заредят работните процеси новите настройки.
4. Прегледайте логовете. Huntress съветват да търсите процеси на PHP (php-fpm, php-cgi, httpd, apache2), които стартират sh, bash, python, perl, curl или wget, и нови файлове в папката на сайта.

Качването на файлове в WordPress, Joomla, Magento и други системи работи и с изключен session upload progress. Спират само лентите за напредък, които четат PHP_SESSION_UPLOAD_PROGRESS.

Какво направихме във forge.bg

Обновихме всички наши сървъри до последните издадени версии на PHP и на DirectAdmin. Сайтовете, които работят с PHP 8.2, 8.3, 8.4 или 8.5, вече ползват съответно 8.2.35, 8.3.36, 8.4.27 или 8.5.12.

Сървърите ни са защитени и с cPGuard на OpsShield. Днес OpsShield пуснаха ново правило за защитната стена (WAF) на cPGuard, което по думите на екипа им дава временна защита срещу атаката през session upload progress. Правилото проверява тялото на входящите multipart заявки за подозрителни параметри на upload progress и ги спира, преди да стигнат до PHP. IP адресите, от които идват опити за атака, cPGuard блокира автоматично. Новото правило вече работи на всички наши сървъри. Основната защита е поправеният PHP, а правилото в WAF спира атаката по-рано, още на входа на сървъра.

Източници

• Обявлението на PHP за изданието от 21 октомври 2026 г.
• Calif: php2shell, описание и хронология
• Huntress: php2shell, Leaked Critical PHP Vulnerabilities
• GMO Flatt Security: php2shell (на японски)
• OpsShield: PHP2Shell Mitigation Steps and cPGuard WAF Protection