Накратко: Общото между PHP2Shell и Log4Shell е, че са критични уязвимости в много разпространен основен градивен елемент, чрез които нападателите могат да изпълняват код без вход. Различават се по видимост, по оценка и по положението с известните атаки. Най-важната поука от Log4Shell важи днес непроменена: който знае къде работи засегнатият компонент, действа за часове вместо за седмици.
Защо сравнението се появява точно сега навсякъде
През декември 2021 г. Log4Shell държеше ИТ света в напрежение седмици наред. BSI (Федералната служба за информационна сигурност на Германия) обяви тогава най-високото ниво на предупреждение - червено. Почти пет години по-късно при PHP2Shell в много статии се споменава същото име, често със въпроса: „Пак ли ще е толкова зле?“
Сравнението е логично и е полезно, ако се прави правилно. То показва кои модели се повтарят и кои опити фирмите могат да ползват днес директно. Как BSI оценява сегашната ситуация, обяснява статията Ниво на предупреждение оранжево на BSI.
PHP2Shell и Log4Shell в пряко сравнение
| Характеристика | Log4Shell (2021) | PHP2Shell (2026) |
|---|---|---|
| Засегнат софтуер | Java библиотека Log4j | самата PHP среда за изпълнение |
| Идентификатор | CVE-2021-44228 | CVE-2026-109618, CVE-2026-109619 |
| Оценка | CVSS 10.0 (v3) | CVSS v4.0 9,2 |
| Въздействие | изпълнение на код без вход | изпълнение на код без вход |
| Ниво на предупреждение на BSI | 4 / червено | 3 / оранжево |
| Положение при предупреждението | според тогавашните съобщения компрометирания известни | съобщени опити за атака, според BSI първоначално няма потвърдени успешни атаки в голям мащаб |
| Видимост | често дълбоко скрит в приложения | видим на сървъра, но състоянието на пача трудно се чете заради backport-ове |
| Последващи съобщения | още няколко CVE в рамките на седмици | указание за CVE-2026-115560 на 23.10. |
Какво е общото между двете уязвимости
Основен градивен елемент, безброй приложения. Log4j беше в Java софтуер от всякакъв вид, PHP носи WordPress, Shopware, TYPO3 и безброй собствени разработки. И в двата случая не е засегнат един продукт, а фундамент.
Не е нужен вход. И двете уязвимости позволяват отдалечено изпълнение на код без вход. Това ги прави привлекателни за автоматизирани атаки.
Пачът не е краят. При Log4Shell се оказа, че много системи са били атакувани още преди актуализацията. И при PHP2Shell важи: пачът не премахва внесен зловреден софтуер. Според медийни съобщения първи опит за атака е наблюдаван още на 17 октомври.
Последващи съобщения. След Log4Shell в рамките на няколко седмици излязоха още CVE за Log4j. При PHP два дни след пачовете дойде указанието за CVE-2026-115560. Защо още съобщения са вероятни, обяснява След PHP2Shell: защо още съобщения са вероятни.
Къде сравнението куца
Най-голямата разлика е във видимостта. Log4j често беше вграден като част от приложение, понякога многократно вложен. Много оператори просто не знаеха, че го използват. PHP обратно не е тайна на един уеб сървър. Затова при PHP2Shell възниква друга неяснота: дистрибуциите и хостинг доставчиците инсталират поправки като backport, показаният номер на версията остава същият. PHP се вижда, но не веднага дали е пачнат.
Втора разлика е изходното положение при актуализацията. При Log4Shell често производителите на специализирани приложения първо трябваше да доставят нови версии. При PHP2Shell актуализации има за всички поддържани клонове. Трудно става при PHP 8.1 и по-стари, за които PHP проектът вече не публикува официални актуализации.
Трета разлика засяга мястото на атаката. При Log4Shell опасно можеше да бъде всяко място, където приложение записваше входни данни в лог, тоест и вътрешни системи, които получаваха данни от интернет само индиректно. При PHP2Shell в центъра е уеб сървърът, който приема заявките директно. Това прави търсенето на засегнати системи малко по-прегледно: първо идват всички публично достъпни PHP услуги, после вътрешните приложения.
Накрая се различава положението с експлоатацията. За Log4Shell рано зациркулираха прости инструменти за атака, а компрометирания според тогавашните съобщения са били известни още към момента на предупреждението. При PHP2Shell Cloudflare и Patchstack съобщават за опити за атака, watchTowr според собствените си данни е възпроизвела една от уязвимостите, потвърдени успешни атаки в голям мащаб BSI първоначално не съобщи. Това може да се промени. Но това е причина сравнението да не е подходящо за прогноза.
Ползвайте опита от Log4Shell във Вашата организация: Кои списъци, процеси и контакти помогнаха тогава? Голяма част от тях могат директно да се използват повторно за PHP2Shell.
Пет поуки от Log4Shell, които помагат днес
- Инвентар преди пач: Който през 2021 г. имаше актуален списък на системите си, беше по-бърз. Това важи и днес. Ръководство предлага статията Инвентар на всички уебсайтове и сървъри.
- Познавайте зависимостите: Спецификация на софтуерните компоненти, накратко SBOM, отговаря на въпроса „Къде използваме това?“ за минути. За PHP приложенията помага погледът в Composer, както го описва Проверка на зависимостите на Composer.
- Пазете логовете: След Log4Shell много фирми не можеха да изяснят дали са били засегнати, защото логове липсваха. Специализираната преса съветва при PHP2Shell да се запазят логове от 20 октомври.
- Проверявайте и впоследствие: Пачът не отговаря какво е станало преди това. Проверката за следи е част от работата.
- Бъдете подготвени за последващи съобщения: Първата актуализация рядко е последната. Който веднъж е изградил добре пътя за актуализация, го повтаря бързо.
Как помага PHP SOS конкретно?
- Инвентаризация: Установяваме къде във Вашата фирма работи PHP, в каква версия и режим на работа.
- Пач и рестарт: Инсталираме актуализации и доказваме състоянието за всяка система.
- Проверка за следи: Запазваме логове и проверяваме за необичайни находки от 17 октомври.
- Постоянно наблюдение: Следим Вашите системи, за да не започват последващите съобщения отново от нула.
Как изглежда текущото наблюдение, описва Мониторинг на сигурността на уеб сървъри.
Заключение
PHP2Shell не е Log4Shell, но се римува с нея. И двете засягат фундамент, и двете изискват повече от един пач. Фирмите, които са взели от 2021 г. инвентар, съхранение на логове и пътища за актуализация, са днес в предимство. За всички останали сега е моментът да наваксат.
Често задавани въпроси
PHP2Shell толкова ли е лоша, колкото Log4Shell?
И двете са критични уязвимости в много разпространен софтуер, чрез които нападателите могат да изпълняват код без вход. BSI оцени Log4Shell през 2021 г. с червено, а PHP2Shell с оранжево. Важна разлика: при Log4Shell според тогавашните съобщения към момента на предупреждението вече са били известни компрометирания, а при PHP2Shell според BSI първоначално не е имало потвърдени успешни атаки в голям мащаб.
Какво беше Log4Shell?
Log4Shell беше критична уязвимост в Java библиотеката Log4j, станала известна през декември 2021 г. и водена под CVE-2021-44228. Log4j беше вграден като градивен елемент в много голям брой приложения, често без операторите да знаят за това.
Ще излязат ли още уязвимости след PHP2Shell?
Възможно е. След Log4Shell в рамките на няколко седмици последваха още CVE за Log4j. При PHP на 23 октомври вече имаше указание за CVE-2026-115560, което действа само при необичайна конфигурация. Предвидете последващи съобщения.
Какво е SBOM?
Software Bill of Materials е спецификация на всички софтуерни компоненти, от които се състои едно приложение. С нея при нова уязвимост бързо може да се установи къде се ползва засегнатият компонент.