Уязвимостта PHP2Shell получи публичен PoC експлойт за тестове за сигурност

Публично хранилище с доказателство за концепция (proof-of-concept) предоставя инструменти за валидация и тестова лабораторна среда за две критични уязвимости в PHP, известни като php2shell. Дефектите, проследявани от изследователите като CVE-2026-109618 и CVE-2026-109619, засягат функцията session.upload_progress на PHP и при определени условия биха могли да доведат до отдалечено изпълнение на код.

Публикацията добавя технически детайли към бързо развиващ се проблем със сигурността. Екипът по сигурността на PHP обяви, че извънредно издание ще отстрани две критични уязвимости, всяка с оценка 9.2 по CVSS v4.0, и призова потребителите да се подготвят за надграждане.

В известието пускането на корекциите бе насрочено за 21 октомври в 14:00 UTC. Към момента на писане този час все още не е настъпил, така че официалното известие на PHP все още не е потвърдило техническите подробности, засегнатите версии или коригираните компилации, описани в изследователското хранилище.

Според хранилището уязвимостите засягат версии на PHP от 5.4.0 до 8.5.11. В него се посочват PHP 8.2.35, 8.3.36, 8.4.27 и 8.5.12 като планирани коригирани версии, но администраторите трябва да ги проверят спрямо официалния бюлетин на екипа на PHP преди актуализиране. Предварителното известие на проекта PHP потвърждава сериозността и планираното издание, но не и тези конкретни версии.

Това са клоновете, които отговарят на условията за официални корекции за сигурност. PHP 8.1 и по-старите — включително PHP 8.0, 7.x и 5.x — са с изтекъл жизнен цикъл (end-of-life) и няма да получат официални поправки от проекта PHP.

PoC експлойт за уязвимостта PHP2Shell

Докладът на изследователя описва няколко начина за изпълнение на код, вместо един универсален експлойт, работещ срещу всеки PHP уебсайт. Една от веригите комбинира инжектиране във файла на сесията с уязвимост от тип локално включване на файлове (LFI) в самото приложение.

Според хранилището този вектор зависи от това дали проследяването на качването (upload progress) е активирано, както и от дефект в приложението, позволяващ включване на локален файл. Грешка от тип локално включване на файлове възниква, когато дадено приложение може да бъде подведено да зареди файл от собствения си сървър по непредвиден начин.

В хранилището се посочва, че модулът за обработка на напредъка при качване на PHP съхранява подадено име на файл в данните на сесията, без да го валидира. Също така се съобщава, че идентификатор на сесия, изпратен в тялото на POST заявка, може да заобиколи настройката session.use_only_cookies, чиято цел е да ограничи начините за приемане на сесийни идентификатори.

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

Вторият докладван проблем е свързан с use-after-free — грешка при работата с паметта, която може да възникне, когато софтуерът продължава да използва данни, след като паметта за тях вече е освободена. Изследователят посочва, че повторно влизане в деструктора var_destroy може да предизвика това състояние, и потвърждава, че го е възпроизвел с AddressSanitizer — инструмент, използван за откриване на грешки в паметта.

В хранилището се описва също така състояние на сериализатора в PHP-FPM, което може да се запази между отделни заявки, както и несъответствие в обработчиците, което може да доведе до стартиране на деструктор след неуспешна десериализация. Изследователите отбелязват, че някои от тези вектори изискват допълнителни условия, като например приложен „джаджет“ (gadget) или достъп до локален файл.

Тези технически твърдения остават в рамките на независимия изследователски проект, докато не бъдат съпоставени с пълния бюлетин и официалните корекции за сигурност от PHP. Екипите по сигурност не бива да приемат всеки посочен вектор като независимо потвърден за всички версии или конфигурации. Хранилището за верификация на проекта предоставя преглед на изследването и лабораторни файлове. Неговата обявена цел е контролирано тестване, а не използване срещу системи без разрешение.

PHP захранва широк спектър от уебсайтове и приложения, така че дефект в базовата обработка на сесиите може да засегне множество видове внедрявания. Рискът може да бъде по-голям, когато дадено приложение вече съдържа уязвимост за включване на файлове или небезопасна десериализация.

Доклад на Mallory подчертава мащаба на остарелите PHP инсталации, докато администраторите се подготвят за обновяванията за сигурност срещу php2shell. Използвайки данни от Shodan, събрани на 20 октомври, компанията идентифицира 883 717 хоста, достъпни през интернет, които работят с PHP 8.1 или по-стара версия.

Това представлява около 59% от приблизително 1,5 милиона хоста, които разкриват версията си на PHP. Тези клонове вече не получават официални корекции за сигурност от проекта PHP, което превръща миграцията към поддържана версия в първостепенна задача.

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

Докладваната оценка от 9.2 сигнализира за критичен проблем, но тя не показва на администраторите дали конкретен сървър е уязвим. Това зависи от версията на PHP, конфигурацията, поведението на приложението и наличието на необходимите условия за конкретна верига от действия. Публичното хранилище включва лабораторна среда с PHP-FPM и Nginx за тестове. Организациите трябва да използват такива среди само за оторизирана валидация и не трябва да изпълняват концептуален код (PoC) срещу продукционни системи.

Администраторите трябва да направят инвентаризация на инсталациите на PHP на уеб сървъри, контейнери и среди за управляван хостинг, след което да проверят официалното издание за сигурност на PHP за потвърдените засегнати и коригирани версии. След като бъде налична подходяща актуализация, инсталирайте корекциите за сигурност своевременно и рестартирайте PHP-FPM или съответната уеб услуга, за да влязат в сила новите изпълними файлове.

Системите, използващи версии на PHP с изтекъл жизнен цикъл, изискват специално внимание, тъй като те може да не получат официални поправки. Хранилището идентифицира PHP 5.x, 7.x, 8.0 и 8.1 като неподдържани, но екипите трябва да потвърдят статуса на поддръжка с проекта PHP.

Изследователят посочва изключването на session.upload_progress и задаването на session.use_only_cookies на стойност On като временни мерки за защита. Тези настройки могат да намалят излагането на риск при някои от докладваните вектори, но хранилището предупреждава, че те не спират всяка атакуваща верига.

Те не са заместител на инсталирането на корекции за сигурност. Прегледайте приложенията за проблеми с локално включване на файлове и небезопасна десериализация и проверявайте сървърните логове за необичайни заявки, свързани с обработката на сесии в PHP, докато трае прегледът на официалния бюлетин.

Засега публичният концептуален експлойт трябва да се разглежда най-вече като сигнал за подготовка и безопасна валидация. Ключовата следваща стъпка е твърденията от изследването да се съпоставят с детайлите от официалното издание на PHP, след което уязвимостите на засегнатите системи да се коригират незабавно, щом проектът публикува потвърдените фиксирани версии.