21 октомври 2026 | PHP | ИТ-безбедност
На 21 октомври 2026 безбедносниот тим на PHP објави ажурирања за сите сè уште поддржани PHP-верзии. Тие затвораат две критични ранливости што станаа познати како PHP2Shell. BSI издаде предупредување за тоа и бара засегнатите системи да се закрпат веднаш. Кој работи веб-сервер со PHP, треба да постапи уште денес. Тоа важи и за сите што „само“ работат WordPress, Nextcloud или Joomla, бидејќи овие апликации работат на PHP.
Овој напис резимира што се случи, кои PHP-верзии се засегнати, која верзија ви е потребна сега и како за неколку минути да проверите дали вашиот сервер е обезбеден.
Содржина на овој напис
- Што се случи? Временски тек
- Двете PHP-ранливости накратко
- Кој е засегнат?
- Овие PHP-верзии се безбедни
- Како да го проверите и ажурирате вашиот сервер
- PHP 8.1 и постари: нема официјално ажурирање
- Преодни мерки и прашањето „Да се исклучи ли серверот?“
- Често поставувани прашања
- Поддршка од Biricon IT Services
Што се случи? Временски тек
Безбедносниот тим на PHP однапред ја најави објавата на поправките за хостерите и администраторите да имаат време да се подготват. Самата објава се случи на 21 октомври 2026. BSI го издаде своето предупредување (верзија 1.1) истиот ден.
- 20 октомври 2026: Претходно предупредување од безбедносниот тим на PHP дека следниот ден ќе излезат безбедносни ажурирања.
- 21 октомври 2026, 14:00 UTC (16:00 часот CEST): Се објавуваат закрпите за PHP 8.5, 8.4, 8.3 и 8.2.
- 21 октомври 2026: BSI предупредува за „критичните ранливости што ги загрозуваат веб-апликациите ширум светот“ и препорачува да се закрпи веднаш. Според податоците на BSI, големи хостинг-провајдери делумно претпазливо ги исклучиле серверите.
Двете PHP-ранливости накратко
Станува збор за две одделни грешки во јадрото на PHP: CVE-2026-109618 и CVE-2026-109619. И двете, според податоците на безбедносниот тим на PHP, можат да доведат до тоа напаѓач да може да изврши програмски код на серверот без да се најави (unauthenticated Remote Code Execution). Ранливостите се оценуваат со CVSS v4.0: 9,2 (критично).
| Својство | Значење |
|---|---|
| Идентификатори | CVE-2026-109618 и CVE-2026-109619 |
| Оценка | CVSS v4.0: 9,2 — критично |
| Влијание | Извршување на код на серверот (Remote Code Execution), без најава |
| Причина 1 | Оштетена меморија кога PHP при обработката не добива повеќе работна меморија (Out-of-Memory) |
| Причина 2 | Застарена глобална состојба што помеѓу барањата останува во меморијата |
| Особено загрозени | Apache со mod_php |
Според оценката на BSI, во моментот на објавата немаше потврдени напади, но имаше непотврдени знаци за обиди за искористување. Кај критични пропусти во толку раширен софтвер, според искуството, треба да се смета дека напаѓачите ги анализираат поправките и подготвуваат автоматизирани напади. Временскиот прозорец за закрпување затоа е краток.
Кој е засегнат?
Принципиелно е засегнат секој сервер на кој работи PHP, независно од тоа како е поврзан PHP: PHP-FPM, mod_php во Apache, php-cgi, FrankenPHP или LiteSpeed. Според безбедносниот тим на PHP, ризикот е највисок кај Apache со mod_php.
BSI изречно именува апликации што се засноваат на PHP и затоа може да бидат исто така засегнати:
- Системи за управување со содржина: WordPress, Drupal, TYPO3, Joomla
- Системи за продавници: Magento
- Облак и складирање датотеки: Nextcloud
- Интерфејси на заштитни ѕидови: pfSense, OPNsense
Самата апликација за тоа не мора да биде погрешна. Пропустот е во PHP, затоа ажурирање само на WordPress, Nextcloud & Co. не помага. Мора да се ажурира PHP-верзијата на серверот. Кај заштитни ѕидови како pfSense и OPNsense, поправената PHP-верзија доаѓа преку соодветното firmware-ажурирање од производителот.
Овие PHP-верзии се безбедни
Ранливостите се отстранети во следните верзии. Сè под тоа се смета за ранливо.
| PHP-гранка | Најмалку потребно | Напомена |
|---|---|---|
| PHP 8.5 | 8.5.12 | актуелна гранка |
| PHP 8.4 | 8.4.27 | |
| PHP 8.3 | 8.3.36 | |
| PHP 8.2 | 8.2.35 | Поддршката завршува на 31 декември 2026 |
| PHP 8.1 и постари | нема официјално ажурирање, види долу | |
Како да го проверите и ажурирате вашиот сервер
1. Утврдете ја инсталираната PHP-верзија
На командната линија на серверот php -v ја покажува верзијата на PHP за командна линија. Веб-серверот може да користи друга PHP-верзија. Затоа проверете ја и верзијата на PHP-FPM односно на модулот на Apache, на пример со php-fpm8.3 -v или преку страница што ја испишува phpinfo() (потоа веднаш отстранете ја).
2. Инсталирајте го ажурирањето преку управувањето со пакети
Кај Debian, Ubuntu, RHEL и сродни системи, поправената верзија доаѓа преку вообичаеното управување со пакети, на пример apt update && apt upgrade или dnf upgrade. Кај надворешни извори како Sury-PPA или Remi-Repository новите пакети обично се појавуваат брзо.
apt changelog php8.3-fpm или rpm -q --changelog php | grep CVE-2026-1096).
3. Рестартирајте ја PHP-услугата
Само ажурирање на пакетот не е доволно: PHP-процесите што работат го задржуваат стариот код во меморијата. Рестартирајте го PHP-FPM (systemctl restart php8.3-fpm) односно Apache (systemctl restart apache2) и потоа проверете дали процесите се стартувани по ажурирањето.
4. Хостирани веб-страници
Кај shared hosting ажурирањето по правило го врши провајдерот. Во менито за клиенти обично може да се постави PHP-верзијата по веб-страница. Изберете таму една од горенаведените безбедни верзии или прашајте го провајдерот за состојбата на закрпите. Според податоците на BSI, поединечни провајдери претпазливо ги исклучиле серверите од мрежата. Ако вашата страница накратко не е достапна, тоа може да биде причината.
PHP 8.1 и постари: нема официјално ажурирање
За PHP 8.1 и постари веќе нема официјални безбедносни ажурирања. Операторите на такви системи имаат две можности:
- Преминување на поддржана верзија (препорачано). Колку е постара верзијата, толку е поголем трудот за приспособување на апликацијата и проширувањата, затоа преминот треба претходно да се тестира.
- Враќање на поправките наназад (backport). Безбедносниот тим на PHP ги стави поправките во развојните гранки на GitHub. Кој сам го компајлира PHP, може да ги преземе овие измени во постари верзии. Тоа е преодно решение и бара стручно знаење.
И PHP 8.2 е поддржан само до 31 декември 2026. Планирајте го преминот на PHP 8.4 или 8.5 затоа сега и не го одложувајте за крајот на годината.
Преодни мерки и прашањето „Да се исклучи ли серверот?“
Безбедносниот тим на PHP со најавата опиша и привремени заштитни мерки. Тие го намалуваат ризикот, но не ги затвораат пропустите целосно. Не го заменуваат ажурирањето и се наменети само да го премостат времето до ажурирањето.
Дали серверот до ажурирањето треба да се исклучи од мрежата, зависи од неговата важност и достапност. BSI наведува дека големите провајдери го направиле овој чекор. Како практично правило важи:
- Јавно достапен сервер, ажурирањето е можно сега: закрпете веднаш, не е потребно исклучување.
- Јавно достапен сервер, ажурирањето не е можно во краток рок: ограничете го пристапот (на пример преку заштитен ѕид само за познати адреси) или привремено исклучете ја услугата, особено кај
mod_php. - Сервер достапен само внатрешно: закрпете навремено, итноста е помала.
Често поставувани прашања
Дали морам да ажурирам WordPress, Joomla или Nextcloud?
Не поради оваа ранливост. Таа се наоѓа во PHP, а не во апликацијата. Ажурирајте ја верзијата на PHP на серверот. Ажурирањето на апликацијата е сепак препорачливо, независно од ова.
Како да препознаам дали некој веќе ја искористил ранливоста?
Сигурен одговор тешко е да се даде. Сомнителни се непознати PHP-датотеки во веб-директориумот, невообичаени процеси под корисникот на веб-серверот, нови кориснички сметки или cron-задачи и невообичаен излезен сообраќај на податоци. При конкретно сомнение системот треба да се прегледа форензички и, при сомнеж, повторно да се постави од почеток.
Дали е доволен Web Application Firewall?
Огнен ѕид може да ги запре познатите шеми на напад, но не е замена за ажурирањето. Повеќе за соработката на повеќе слоеви на заштита прочитајте во нашиот напис Обезбедување на Odoo 19: огнен ѕид, 2FA & Web RBL. Принципите важат за секоја веб-апликација.
Дали е засегнат Odoo?
Не. Odoo е напишан во Python и не работи на PHP. Засегнати би биле само PHP-апликации што работат на истиот сервер.
Каде можам да ги најдам официјалните информации?
Објавата на безбедносниот тим на PHP ќе ја најдете во архивата на вести на php.net (запис од 20 октомври 2026 година), а верзиите на php.net/downloads. Предупредувањето на BSI го носи бројот 2026-297981-1032 и е објавено на bsi.bund.de .
Поддршка од Biricon IT Services
Ако не сте сигурни која верзија на PHP работи на вашиот сервер или ви треба помош при крпењето, со задоволство ќе ве поддржиме: при попис на сите PHP-системи, при инсталирање на ажурирањата, при преминување на поддржана верзија на PHP и при проверка за компромитирање. Како ИТ-давател на услуги се грижиме за сервери, огнени ѕидови и веб-апликации за мали и средни претпријатија.
Состојба: 21 октомври 2026 година. Ситуацијата може брзо да се промени; меродавни се објавите на безбедносниот тим на PHP и на BSI.