PHP2Shell: Какво се случи с PHP и как да защитим сайта си

Последна актуализация: 22 октомври 2026 г.

На 21 октомври 2026 г. PHP публикува извънредни security поправки за две критични уязвимости - CVE-2026-109618 и CVE-2026-109619, наричани общо PHP2Shell. При определени условия те могат да позволят дистанционно изпълнение на код без предварително влизане в системата. Проблемът е в PHP runtime, а не само в WordPress, Symfony или Laravel. Официалните поправки са налични, но това не означава, че автоматично са инсталирани на всеки сървър.

Какво означава PHP2Shell?

PHP изпълнява сървърната логика на сайтове, магазини и бизнес приложения. При PHP2Shell определени специално конструирани HTTP заявки могат да доведат до опасно състояние на паметта. В успешен сценарий атакуващият може да изпълни собствен код с правата на PHP процеса, което би позволило достъп до файлове, конфигурации, секрети и бази данни, достъпни за този процес. Не всеки сайт е експлоатируем по идентичен начин: значение имат версията и конфигурацията.

Технически детайли за двете CVE

CVE-2026-109618: проблем при изчерпване на паметта

При специфична грешка от тип Out-of-Memory PHP може да прекъсне обработката преди вътрешни структури да бъдат подготвени коректно. По-късната обработка на тези структури може да доведе до опасна паметова грешка. Особено сериозен е документираният сценарий при Apache mod_php, който може да се задейства преди изпълнение на приложния PHP код. Следователно дори безопасен Symfony контролер не решава дефект в runtime.

CVE-2026-109619: Use-After-Free

Втората уязвимост е свързана с използване на препратка към вече освободена памет. PHP worker-и могат да обработват множество заявки последователно, а определени грешки могат да оставят невалидно вътрешно състояние за следваща заявка. Това се нарича Use-After-Free (UAF). Точните предпоставки са описани в официалните advisory за CVE-2026-109618 и advisory за CVE-2026-109619.

Хронология: как се разви ситуацията?

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

Кои PHP версии са поправени?

Внимание: Linux дистрибуциите може да поставят security поправка в пакет с по-стар основен номер на PHP. Проверявайте пълния package release и changelog, а не само php -v.

Как реагираха доставчиците на хостинг и защита?

Cloudflare

Cloudflare активира WAF правила и допълнителен механизъм за анализ на заявките и отговорите, наречен Full Transaction Detection. Това е полезна временна защита, но не поправя PHP и може да не покрие всички варианти на атаката. Уверете се, че origin сървърът не може да бъде заобиколен чрез директен достъп. Прочетете анализа на Cloudflare.

Ubuntu

Canonical публикува USN-8948-1 с security patches за поддържани Ubuntu издания, включително backport за PHP 8.1 в Ubuntu 22.04. При такива системи често не е необходима незабавна миграция към нов основен PHP клон, за да се отстранят конкретните CVE.

cPanel, CloudLinux и стари версии

cPanel публикува EasyApache4 поправки и за PHP 7.4, 8.0 и 8.1, а CloudLinux/TuxCare има специфични поправени пакети за част от старите среди. Това не означава, че всяка стара PHP 7.x инсталация е защитена. Необходима е проверка на точния доставчик и ревизия на пакета. Официално съобщение на cPanel.

Споделен хостинг, VPS и Docker

При управляван споделен хостинг доставчикът обичайно поддържа PHP. При self-managed VPS или облачна виртуална машина отговорността често е на клиента. Docker контейнерите изискват обновяване на PHP image и нов deployment: пач на хост машината сам по себе си не променя PHP в контейнера.

Защитени ли са Symfony, Laravel и WordPress?

Не автоматично. Актуален framework не отстранява уязвимост в самия PHP. Необходима е поддръжка на PHP runtime, ОС, уеб сървъра, framework зависимостите и приложния код. Отделните обновления не са взаимозаменяеми.

Временни мерки и техните ограничения

Официалните advisories обсъждат ограничения върху HTTP POST/multipart заявките, изключване на session.upload_progress.enabled за определени сценарии, изолация на PHP процесите и ограничаване на повторното използване на worker-и. При конкретни условия се обсъжда memory_limit=-1, но това създава сериозен риск от неограничена консумация на памет и не бива да се използва като универсална настройка. pm.max_requests=1 може значително да влоши производителността. Пълното блокиране на multipart формите ще повреди качването на файлове и някои нормални функции. Нито една от тези мерки не заменя инсталирането на официален пач.

Конкретен checklist за техническия екип

1. Инвентаризация. Избройте всички production приложения, домейни, PHP версии, ОС, доставчици и отговорни администратори.
2. Проверка на runtime. Използвайте php -v, но проверете отделно реалния PHP-FPM/mod_php. При Ubuntu/Debian вижте dpkg -l 'php*' и package changelog.
3. Проверка на patch status. Съпоставете версията с upstream поправките или съответния vendor backport; проверете дали е инсталирана, а не само налична в repository.
4. Архив и тестова среда. Подгответе rollback; по възможност проверете съвместимостта на staging.
5. Security update. При стандартни Ubuntu/Debian инсталации използвайте подходящите системни обновления, например sudo apt update и sudo apt upgrade; за custom repositories следвайте указанията на доставчика.
6. Рестарт на PHP worker-ите. Уверете се, че Nginx/Apache обслужва заявките с реално обновен PHP runtime.
7. Функционални тестове. Проверете вход, сесии, колички, поръчки, плащания, качване на файлове, API и ERP/CRM интеграции, cron и queue процеси.
8. Преглед за компрометиране. Проверете HTTP, WAF, PHP и системни логове. Пачването не премахва евентуално вече поставен злонамерен код.
9. Постоянен процес. Въведете наблюдение на security advisories, инвентаризация, редовни обновления и отговорник за всяка система.

PHP2Shell обяснено на човешки език: въпроси и отговори

Имам обикновен фирмен сайт. Засяга ли ме?

Възможно е, ако сайтът се изпълнява с уязвим PHP. Не е нужно да е онлайн магазин.

Може ли да ме атакуват без да знаят паролата?

При определени условия да. Това е основната причина уязвимостите да са критични.

Cloudflare достатъчна защита ли е?

Не. WAF е полезен допълнителен слой, но не заменя PHP поправката.

Ако обновя WordPress или Symfony, готово ли е?

Не. PHP runtime е отделен компонент и трябва да се обнови самостоятелно.

Кой отговаря за поправката при споделен хостинг?

Обикновено доставчикът. Поискайте писмено потвърждение за двете CVE за вашата среда.

Трябва ли да инсталирам директно PHP 8.5?

Не винаги. Ако използвате поддържан клон или официално поправен vendor пакет, може първо да приложите security update в същия клон. Голямата миграция тествайте отделно.

След пача сигурен ли съм, че никога не е имало пробив?

Не. Пачът предотвратява конкретната уязвимост занапред. При съмнения трябва да се прегледат логовете и състоянието на системата.

Не съм технически човек - какво да направя?

Поискайте от хостинг доставчика потвърждение дали CVE-2026-109618 и CVE-2026-109619 са отстранени. Ако използвате собствен VPS, потърсете системен администратор.

Заключение

PHP2Shell показва, че сигурността зависи не само от кода на сайта, но и от инфраструктурата. Към 22 октомври 2026 г. поправките съществуват, но само проверка на конкретната production среда може да потвърди, че са приложени.

Нуждаете се от съдействие за проверка или обновяване на PHP?

Sirius Software разработва и поддържа PHP/Symfony приложения, онлайн магазини, CRM/ERP системи и интеграции. Можем да съдействаме с анализ на PHP версиите, оценка на риска, инсталиране на поправки, миграция на стари приложения и тестове след обновяването.

Изпратете адреса на вашия сайт, PHP версията (ако я знаете) и информация за хостинга. Ще обсъдим конкретните технически стъпки и необходимия обхват. Свържете се със Sirius Software.

Официални източници

• PHP - Security Releases
• CVE-2026-109618 - PHP advisory
• CVE-2026-109619 - PHP advisory
• Cloudflare
• Canonical / Ubuntu
• cPanel