Накратко: За уязвимостта на PHP 8.1 PHP2Shell няма официална актуализация. Проектът PHP предоставя за 7.4, 8.0 и 8.1 само минимални backport-ове на изходния код, а не готови издания. Който ползва тези версии, се нуждае от потвърден backport от своя доставчик или от временни мерки и трябва още сега да планира преминаване към поддържана версия.
Има ли актуализация срещу уязвимостта на PHP 8.1?
Не от проекта PHP. На 21 октомври 2026 г. излязоха официални поправки само за поддържаните клонове: 8.5.12, 8.4.27, 8.3.36 и 8.2.35. PHP 8.1 и по-старите версии вече не получават официални актуализации.
Засегнати са въпреки това. Според специализираната преса уязвимите версии стигат почти непрекъснато чак до PHP 5.4. Който ползва някоя от тези версии, достъпна публично, има критична уязвимост с CVSS v4.0 9,2 без готов пач.
За много фирми това е изненада, защото такива системи често работят стабилно и незабележимо от години. Че една версия не получава повече актуализации, не се забелязва в ежедневието, докато не се появи уязвимост като PHP2Shell. Backport-овете на изходния код за 7.4, 8.0 и 8.1 са изключение, а не възобновяване на редовната поддръжка.
Какво означават backport-овете на изходния код
За 7.4, 8.0 и 8.1 има минимални backport-ове на изходния код. Това са поправки в изходния код, пренесени в тези по-стари клонове. Те не са официално издание с номер на версия, тестван пакет и changelog.
На практика това означава: някой трябва да поеме backport-а, да компилира PHP наново от него, да го тества и да го внедри. Това може да стане по три пътя:
- Вашата дистрибуция вгражда поправката в пакетите си, например в рамките на дългосрочна поддръжка.
- Вашият хостинг доставчик изгражда собствени PHP пакети и внася backport-а.
- Вие сами или външен изпълнител компилирате PHP от изходния код. Това е взискателно и трябва да се повтаря при всяка следваща уязвимост.
Дали Вашата система е получила backport, проверявате по changelog-а на пакета:
apt changelog php8.1-fpm | grep -i -E "CVE-2026-109618|CVE-2026-109619" # Debian/Ubuntu
rpm -q --changelog php-fpm | grep -i -E "CVE-2026-109618|CVE-2026-109619" # семейство RHEL
Имената на пакетите се различават според дистрибуцията и източника на пакети. Ако записът липсва, попитайте доставчика. Как работи проверката в детайли, е описано на страницата Как да проверите правилно PHP версията и състоянието на пача.
Осигуряване на стария сървър до миграцията
Докато не работи потвърден backport, важат временните мерки на php.net: непрезаписваемо memory_limit=-1 с ограничение на паметта чрез cgroup, post_max_size от 8M или 32M с upload_max_filesize под него и session.upload_progress.enabled=0 в конфигурацията на сървъра, след това рестартиране на всички worker процеси. Те не са пълна защита. Подробности има на страницата Незабавни мерки, когато още не можете да пачнете.
Към това се добавят мерки, които намаляват достъпността: администраторски области само през VPN или от разрешени IP адреси, изключване на ненужните уебсайтове, тясно ограничаване на достъпа до сървъра. BSI препоръчва сървърите без актуализация да се изключат временно от мрежата. За старо, трудно мигрируемо приложение изолирано решение може да е по-честният отговор от работа в отворения интернет.
Ако сървър с PHP 8.1 или по-стар е работил незащитен в мрежата от 17 октомври, приемете го сериозно: BSI очакваше бърза мащабна експлоатация. Запазете логовете от 20 октомври нататък и поискайте проверка за следи, преди да мигрирате.
Планиране на миграцията: до коя версия?
Целта е версия, която проектът PHP поддържа и която Вашето приложение понася. PHP 8.2 затваря уязвимостта от 8.2.35, но на 31.12.2026 г. достига края на поддръжката. Който мигрира сега, трябва затова по възможност да премине към 8.3 или по-нова, ако приложението го позволява. Актуалното състояние посочва php.net на страницата за поддържаните версии.
Коя PHP версия поддържа Вашият CMS или магазин, проверете според системните изисквания на производителя, например на wordpress.org, shopware.com или typo3.org. Често първо трябва да се актуализира самото приложение, преди PHP да може да се смени. Типичен случай са по-стари магазини, които описваме на страницата Shopware 5. Основите за последиците от остарелите версии ще намерите на страницата PHP End of Life: рискове от остарели версии.
| Стъпка | Съдържание |
|---|---|
| Състояние | PHP версия, приложение, разширения, собствени адаптации |
| Изисквания | поддържани PHP версии според производителя |
| Тестова среда | копие с нова PHP версия, анализ на протокола за грешки |
| Преминаване | планиран прозорец за поддръжка, подготвен път за връщане |
| Последваща работа | проверка на преходните стойности, настройване на наблюдение |
Как помага PHP SOS конкретно?
С миграцията от PHP 8.1 и по-стари Ви водим от старата версия до поддържана:
- Незабавно осигуряване: проверка на състоянието на backport-а, задаване на временни мерки, намаляване на достъпността.
- Проверка на следите: запазване на логовете от 20 октомври нататък и анализ за аномалии.
- Подготовка на миграцията: изясняване на съвместимостта според производителя, изграждане на тестова среда, отстраняване на грешки.
- Преминаване и доказателство: внасяне на новата PHP версия, рестартиране на всички процеси, документиране на състоянието.
Често задавани въпроси
Засегнат ли е PHP 8.1 от PHP2Shell?
Според специализираната преса са засегнати почти всички версии чак до PHP 5.4, включително PHP 8.1. Проектът PHP вече не публикува официални актуализации за 8.1, а само минимални backport-ове на изходния код.
Какво е backport на изходния код?
Поправка в изходния код, пренесена в по-стар клон на версиите. Тя не е готово издание: някой трябва да я поеме, да компилира PHP наново, да го тества и да го внедри. Това може да поеме доставчикът на Вашата дистрибуция, хостинг доставчикът или външен изпълнител.
Достатъчно ли е да премина към PHP 8.2?
Краткосрочно PHP 8.2.35 затваря уязвимостта. PHP 8.2 обаче достига на 31.12.2026 г. края на поддръжката. Който така или иначе мигрира, трябва затова да провери дали приложението според производителя поддържа и 8.3 или по-нова.
Моят магазин работи само с PHP 7.4. Какво сега?
Тогава са нужни две неща паралелно: сървърът да се осигури с временни мерки и изолация, а приложението да се доведе до версия, която понася поддържана PHP версия. Коя е тя, пише в системните изисквания на производителя.