# PHP2Shell и Log4Shell: какво е общото между уязвимостите

> PHP2Shell и Log4Shell в сравнение: какво свързва уязвимостите, къде се различават и какви поуки от 2021 г. могат да ползват фирмите днес.

Източник: https://phpsos.de/bg/blog/php2shell-und-log4shell/  
Актуалност: 25.10.2026  
Доставчик: PHP SOS, Спешна помощ за PHP и сигурност на сървъри. Незабавна помощ по WhatsApp: https://wa.me/491736494914?text=%D0%97%D0%B4%D1%80%D0%B0%D0%B2%D0%B5%D0%B9%D1%82%D0%B5%2C%20PHP%20SOS%2C%20%D0%B8%D0%BC%D0%B0%D0%BC%D0%B5%20%D0%BD%D1%83%D0%B6%D0%B4%D0%B0%20%D0%BE%D1%82%20%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%20%D1%81%20%D0%BD%D0%B0%D1%88%D0%B8%D1%8F%20PHP%20%D1%81%D1%8A%D1%80%D0%B2%D1%8A%D1%80.%20%D0%A4%D0%B8%D1%80%D0%BC%D0%B0%3A%20%E2%80%A6%20%D0%A3%D0%B5%D0%B1%D1%81%D0%B0%D0%B9%D1%82%3A%20%E2%80%A6

**Накратко:** Общото между PHP2Shell и Log4Shell е, че са критични уязвимости в много разпространен основен градивен елемент, чрез които нападателите могат да изпълняват код без вход. Различават се по видимост, по оценка и по положението с известните атаки. Най-важната поука от Log4Shell важи днес непроменена: който знае къде работи засегнатият компонент, действа за часове вместо за седмици.

## Защо сравнението се появява точно сега навсякъде

През декември 2021 г. Log4Shell държеше ИТ света в напрежение седмици наред. BSI (Федералната служба за информационна сигурност на Германия) обяви тогава най-високото ниво на предупреждение - червено. Почти пет години по-късно при PHP2Shell в много статии се споменава същото име, често със въпроса: „Пак ли ще е толкова зле?“

Сравнението е логично и е полезно, ако се прави правилно. То показва кои модели се повтарят и кои опити фирмите могат да ползват днес директно. Как BSI оценява сегашната ситуация, обяснява статията [Ниво на предупреждение оранжево на BSI](https://phpsos.de/bg/blog/bsi-warnstufe-orange-erklaert/).

## 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: защо още съобщения са вероятни](https://phpsos.de/bg/blog/weitere-php-meldungen/).

## Къде сравнението куца

Най-голямата разлика е във видимостта. Log4j често беше вграден като част от приложение, понякога многократно вложен. Много оператори просто не знаеха, че го използват. PHP обратно не е тайна на един уеб сървър. Затова при PHP2Shell възниква друга неяснота: дистрибуциите и хостинг доставчиците инсталират поправки като backport, показаният номер на версията остава същият. PHP се вижда, но не веднага дали е пачнат.

Втора разлика е изходното положение при актуализацията. При Log4Shell често производителите на специализирани приложения първо трябваше да доставят нови версии. При PHP2Shell актуализации има за всички поддържани клонове. Трудно става при PHP 8.1 и по-стари, за които PHP проектът вече не публикува официални актуализации.

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

Накрая се различава положението с експлоатацията. За Log4Shell рано зациркулираха прости инструменти за атака, а компрометирания според тогавашните съобщения са били известни още към момента на предупреждението. При PHP2Shell Cloudflare и Patchstack съобщават за опити за атака, watchTowr според собствените си данни е възпроизвела една от уязвимостите, потвърдени успешни атаки в голям мащаб BSI първоначално не съобщи. Това може да се промени. Но това е причина сравнението да не е подходящо за прогноза.

> **Съвет:**
> Ползвайте опита от Log4Shell във Вашата организация: Кои списъци, процеси и контакти помогнаха тогава? Голяма част от тях могат директно да се използват повторно за PHP2Shell.

## Пет поуки от Log4Shell, които помагат днес

1. **Инвентар преди пач:** Който през 2021 г. имаше актуален списък на системите си, беше по-бърз. Това важи и днес. Ръководство предлага статията [Инвентар на всички уебсайтове и сървъри](https://phpsos.de/bg/blog/inventar-websites-server/).
2. **Познавайте зависимостите:** Спецификация на софтуерните компоненти, накратко SBOM, отговаря на въпроса „Къде използваме това?“ за минути. За PHP приложенията помага погледът в Composer, както го описва [Проверка на зависимостите на Composer](https://phpsos.de/bg/ratgeber/composer-abhaengigkeiten-pruefen/).
3. **Пазете логовете:** След Log4Shell много фирми не можеха да изяснят дали са били засегнати, защото логове липсваха. Специализираната преса съветва при PHP2Shell да се запазят логове от 20 октомври.
4. **Проверявайте и впоследствие:** Пачът не отговаря какво е станало преди това. Проверката за следи е част от работата.
5. **Бъдете подготвени за последващи съобщения:** Първата актуализация рядко е последната. Който веднъж е изградил добре пътя за актуализация, го повтаря бързо.

## Как помага PHP SOS конкретно?

- **Инвентаризация:** Установяваме къде във Вашата фирма работи PHP, в каква версия и режим на работа.
- **Пач и рестарт:** Инсталираме актуализации и доказваме състоянието за всяка система.
- **Проверка за следи:** Запазваме логове и проверяваме за необичайни находки от 17 октомври.
- **Постоянно наблюдение:** Следим Вашите системи, за да не започват последващите съобщения отново от нула.

Как изглежда текущото наблюдение, описва [Мониторинг на сигурността на уеб сървъри](https://phpsos.de/bg/leistungen/security-monitoring/).

## Заключение

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 е спецификация на всички софтуерни компоненти, от които се състои едно приложение. С нея при нова уязвимост бързо може да се установи къде се ползва засегнатият компонент.

## Източници

- [BSI: Федерална служба за информационна сигурност](https://www.bsi.bund.de/)
- [php.net: Съобщения за сигурност](https://www.php.net/)
- [TechTarget: PHP2Shell, 22M exposed servers at risk](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)