PHP2Shell (CVE-2026-109618 и CVE-2026-109619): што треба сега да направат компаниите што користат PHP

Техничар со лаптоп работи покрај серверски орман

На 21 октомври 2026 проектот PHP ги објави PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35 за да поправи две ранливости што „можат да овозможат далечинско извршување код без автентикација“. Кажано едноставно: секој што може да испрати HTTP барање до вашиот веб-сајт можеби ќе може да изврши свој код на вашиот сервер. Не му треба лозинка, а кај некои конфигурации нападот успева уште пред вашата апликација да изврши и една линија код. Ранливостите го добија името PHP2Shell, а PHP ги оценува двете со 9,2 (CVSS 4.0, на скала до 10).

Овој водич е за луѓето што треба да постапат: сопствениците на веб-сајтови и онлајн продавници на PHP, ИТ менаџерите и секој што има добавувач кој за него одржува PHP. Напишан е на 22 октомври 2026, денот по изданието, врз основа на безбедносните известувања на самиот проект PHP, насоките на националните агенции за сајбер безбедност и бројките што ги објавија компаниите од бранша. Каде што изворите не се согласуваат, тоа го кажуваме.

Накратко

Ажурирајте го самиот PHP, а потоа рестартирајте го. Ажурирањето на WordPress, Drupal, Laravel или некој приклучок не го решава проблемот. Пропустот е во PHP, под вашата апликација.
Секоја инсталација на PHP што опслужува веб-барања е во опсег, според PHP: PHP-FPM, Apache со mod_php, php-cgi, FrankenPHP и LiteSpeed. PHP смета дека Apache со mod_php носи најголем ризик.
Речиси половина од веб-сајтовите на PHP работат на гранка за која проектот PHP повеќе не објавува изданија (наше читање на податоците на W3Techs, подолу). За нив нема официјален пакет што може да се инсталира.
Поставките и заштитните ѕидови купуваат време, не безбедност. PHP наведува привремени мерки и вели дека тие „не ја прават инсталацијата безбедна“.
Ако не можете да закрпите денес, агенциите на САД, Обединетото Кралство и ЕУ го даваат истиот совет: исклучете го системот од интернет додека тоа не стане можно.

Што се случи, по ред

19 август 2026. Истражувачите од Wiz го наоѓаат првиот од пропустите, според нивното објавување, и на 24 август ги пријавуваат на безбедносниот тим на PHP. Безбедносните известувања на PHP им даваат заслуга и на истражувачи од неколку други фирми.
20 октомври. Броевите CVE протекуваат на интернет два дена пред планираното објавување. PHP го поместува изданието за еден ден порано, на 21 октомври во 14:00 UTC, и им порачува на сите да се подготват.
21 октомври, 03:02 UTC. Cloudflare вклучува правила на заштитниот ѕид за секој корисник на неговиот WAF, вклучувајќи го и бесплатниот пакет. Подоцна известува дека „забележал сообраќај од напади насочен кон нашите корисници“ и видел напаѓачи како „го менуваат payload-от на нападот за да се обидат да ги заобиколат нашите заштити“.
21 октомври, околу 14:00 UTC. PHP ги објавува поправките и своето безбедносно известување. Истиот ден CISA во САД, британскиот NCSC, CERT-EU и заедничката изјава на Европската комисија, ENISA, CERT-EU, Европол и националните CSIRT во ЕУ им порачуваат на организациите веднаш да закрпат.

Колку е сериозно?

Три работи го издвојуваат ова од вообичаената месечна закрпа.

На напаѓачот не му треба ништо освен едно барање. Без најава, и никој не мора да кликне на линк. Безбедносното известување на PHP опишува демонстриран експлоит против Apache со mod_php, „каде што барање без автентикација може да го активира нападот пред да се изврши каков било код на апликацијата“. Wiz демонстрираше напади врз актуелните WordPress, Drupal и Joomla и наведува дека „дури и едноставна апликација ‚Hello World‘ што работи на погодена верзија на PHP може да биде ранлива“. Кодот извршен на овој начин ги има правата на корисничката сметка под која работи веб-серверот, а таа на повеќето сајтови може да ја чита конфигурацијата на апликацијата: лозинката за базата на податоци, API клучевите, пристапните податоци за е-пошта и плаќања. За вториот пропуст, CVE-2026-109619, PHP потврдува и откривање меморија: податоци од меморијата на серверот истекуваат надвор, дури и без целосно извршување код.

Бројот на инсталации е огромен. Според W3Techs, PHP го користат 69,3% од веб-сајтовите чиј серверски јазик е познат (бројки од 22 октомври 2026). Unit 42 на Palo Alto Networks брои над 22,6 милиони изложени инстанци што се потенцијално ранливи, според сопственото скенирање на интернетот, и известува дека барем една европска влада го исклучила својот веб-сајт од мрежата од претпазливост.

Работата на експлоитите напредува брзо. CERT-EU известува дека првите докази за концепт (proof of concept) „почнаа да кружат“. Безбедносната фирма watchTowr вели дека нејзините honeypot системи бележат искористување од 21 октомври. Cloudflare известува за сообраќај од напади. А Wiz вели дека неговите истражувачи користеле модели на вештачка интелигенција во текот на целата работа, па еден истражувач за една недела го направил она за што „на тим од светска класа би му требале месеци“. Напаѓачите што прилагодуваат експлоит за вашата верзија на PHP ги имаат истите алатки.

Да бидеме фер и кон другата страна: кога CISA го објави своето предупредување на 21 октомври, немаше забележано искористување, а ниту еден од пропустите сè уште не беше во нејзиниот каталог Known Exploited Vulnerabilities (познати искористени ранливости). Red Hat го оценува проблемот како „Important“ (важен), а не како критичен, бидејќи стандарден сервер со Red Hat Enterprise Linux користи PHP-FPM, каде што искористувањето е потешко. Потешко не значи невозможно: PHP потврдува дека една патека за вториот пропуст функционира и на PHP-FPM. Ништо од ова не менува што треба да направите. Менува само колку однапред ќе бидете предупредени.

На која верзија сте? Бројките

W3Techs објавува и кои верзии на PHP ги користат веб-сајтовите, при што ги брои сајтовите што ја откриваат својата верзија. Кога ќе ги споиме неговите две табели од 22 октомври 2026:

Гранка на PHP	Удел меѓу веб-сајтовите на PHP	Поправка од проектот PHP
8.3, 8.4, 8.5	околу 34%	Да: 8.3.36, 8.4.27, 8.5.12
8.2	околу 18%	Да: 8.2.35. Но самата гранка 8.2 го достигнува крајот на животниот век на 31 декември 2026
8.0, 8.1	околу 14%	Нема издание. 8.0 и 8.1: само backport во изворниот код
7.x	26,9%	Нема издание. 7.4: само backport во изворниот код; 7.3 и постари: ништо
5.x и постари	7,8%	Ништо

Значи, околу 48% од веб-сајтовите на PHP работат на гранка за која проектот PHP не објавува поправено издание, а уште 18% ја добиваат поправката сега и ја губат поддршката за десет недели.

Две забелешки. W3Techs ги гледа само сајтовите што ја покажуваат својата верзија. И една Linux дистрибуција можеби сама закрпила стара гранка: Ubuntu тоа го направи, како што ќе видите подолу. Самиот број на верзијата не ви кажува дали сте заштитени. Тоа ви го кажува верзијата на пакетот од вашиот добавувач.

Чекор 1: пронајдете ја секоја инсталација на PHP што ја имате

Не можете да закрпите нешто што не сте го пописале, а PHP добро се крие. Британскиот NCSC бара од организациите да го пронајдат секој PHP систем, прво оние изложени на интернет, и додава: „не ограничувајте го пребарувањето на застарени верзии на PHP“. Заедничката изјава на ЕУ предупредува дека некои производи „може да бидат погодени од овие ранливости дури и ако не изгледа дека директно користат PHP“.

Каде да барате:

Веб-сајтови и продавници: WordPress и WooCommerce, Drupal, Joomla, Magento и Adobe Commerce, Shopware, PrestaShop, TYPO3 и сè што е изградено на Laravel или Symfony.
Заборавените: микросајтови од кампањи, стара јазична верзија, staging и тест сервери достапни од интернет, веб-поштата или системот за поддршка што некој ги инсталирал пред години.
Контејнери: секоја слика изградена од основната слика php носи свој PHP. Ажурирањето на хостот не прави ништо за неа.
Контролни панели за хостинг: cPanel, Plesk и слични панели доаѓаат со сопствени build-ови на PHP покрај оној на системот. Секоја верзија овозможена во панелот е посебна работа за ажурирање.
Производи со PHP внатре: наменски уреди, алатки за мониторинг, CRM системи, системи за поддршка и административни интерфејси на добавувачите. Холандскиот NCSC води јавен список на такви производи со нивниот статус, добавувач по добавувач.
Добавувачи: вашата хостинг компанија, вашата агенција, секоја услуга за која знаете дека под неа има PHP. Прашајте ги писмено кои верзии на PHP работат на вашите системи и кога ќе бидат закрпени.

За секоја од нив запишете ја верзијата на PHP, како работи PHP (mod_php, PHP-FPM, LiteSpeed, FrankenPHP, контејнер), дали е достапна од интернет и кој може да ја закрпи.

Чекор 2: закрпете по правилен редослед

Почнете со сè што е достапно од интернет, а меѓу тоа, со конфигурациите со Apache и mod_php.

На поддржана гранка (од 8.2 до 8.5). Ажурирајте на 8.5.12, 8.4.27, 8.3.36 или 8.2.35, или на пакетот од вашата дистрибуција што ја содржи поправката. PHP вели дека Linux дистрибуциите ги добиле закрпите однапред. Досега е потврдено:

Ubuntu: поправени пакети за секое издание од 14.04 до 26.10. На 22.04 и понови стигнуваат со вообичаените ажурирања; на 20.04 и постари бараат претплата на Ubuntu Pro, која е бесплатна за најмногу пет машини (известувањето на Canonical).
Debian: php8.4 8.4.27 за Debian 13 (DSA-6574-1) и php8.2 8.2.35 за Debian 12 (DLA-4848-1).
Red Hat Enterprise Linux: безбедносниот билтен на Red Hat RHSB-2026-013 ги наведува пакетите по издание.
Репозиториумот Remi, широко користен за понови верзии на PHP на системи од фамилијата Red Hat: на 21 октомври CERT-EU забележа дека тој нема пакети на денот на изданието и советуваше преминување на пакетите од дистрибуцијата или компајлирање од изворен код. Пред да се потпрете на него, проверете дали во меѓувреме ги објавил.

На PHP 7.4, 8.0 или 8.1. Проектот PHP не објавува издание за овие гранки. Неговиот безбедносен тим направи минимални backport-и во изворниот код за трите гранки, што помагаат ако сами го компајлирате PHP. Инаку поправката мора да дојде од вашиот добавувач (Ubuntu Pro, на пример, го покрива PHP 7.4 на Ubuntu 20.04) или од надградба на PHP. Советот на CISA за секој на 8.1 или постара верзија што не може да ажурира е директен: исклучете го системот од мрежата додека не биде закрпен или надграден.

На PHP 7.3 или постар. Од проектот PHP не доаѓа ништо. Ако ниеден добавувач повеќе не го закрпува вашиот build, изборот е меѓу надградба и исклучување на системот од мрежата.

Рестартирајте по ажурирањето. Инсталирањето пакет не го заменува PHP што веќе работи. Известувањето на Ubuntu го кажува тоа јасно: апликацијата „веројатно ќе треба да се рестартира“. Рестартирајте ги PHP-FPM, Apache, LiteSpeed или контејнерот на секој сервер. Потоа проверете ја верзијата што веб-серверот навистина ја користи, не само php -v во командната линија, што може да биде друг build.

Контејнери: изградете ги сликите повторно од закрпена основна слика и распоредете ги повторно. Закрпен хост на кој работи стара слика е сè уште изложен.

Управуван хостинг: прашајте го вашиот давател за датумот и верзијата, а потоа проверете сами.

Чекор 3: ако не можете да закрпите денес

Безбедносното известување на PHP наведува привремени мерки и ги воведува со предупредување: тие „ја намалуваат изложеноста на одредени патеки на напад, но не ја прават инсталацијата безбедна“. Накратко, за тој што ви ги води серверите:

За CVE-2026-109618: поставете memory_limit=-1 така што апликацијата да не може да го промени (на пример со php_admin_value во pool-от на PHP-FPM или во конфигурацијата на Apache); поставете низок post_max_size (PHP предлага 8M без прикачување датотеки, 32M со прикачување); ограничете ја големината на барањата, бројот на полиња и бројот на multipart делови на веб-серверот или проксито; и користете ограничување на меморијата преку контејнер или cgroup, никогаш RLIMIT_AS или RLIMIT_DATA.
За CVE-2026-109619: поставете session.upload_progress.enabled=0 во php.ini или во конфигурацијата на серверот (не со ini_set() ниту со датотека .user.ini) и рестартирајте го секој worker. На PHP 8.5 поставете и fatal_error_backtraces=0.

Две предупредувања. Поставката за сесиите што широко се рашири на 20 октомври затвора само патеки на вториот пропуст, како што истакна член на безбедносниот тим на PHP; против првиот не прави ништо. А memory_limit=-1 го отстранува сопственото ограничување на меморијата на PHP, па едно тешко барање сега може да го исцрпи серверот. Комбинирајте го со ограничувањето преку контејнер или cgroup.

Заштитниот ѕид за веб-апликации помага, малку. Правилата на Cloudflare се стандардно вклучени во секој пакет што го има неговиот WAF, вклучувајќи го и бесплатниот, а Palo Alto Networks и други добавувачи објавија свои заштити. Cloudflare сепак им порачува на корисниците да го закрпат PHP „дури и со WAF заштита“, и забележа како напаѓачите ги менуваат своите payload-и за да се провлечат покрај неговите правила. Освен тоа, WAF го штити само сообраќајот што минува низ него. Ако вашиот сервер одговара на сопствената IP адреса, напаѓачот може да го заобиколи.

Ако ништо од ова не може да се направи брзо, CISA, CERT-EU, NCSC и заедничката изјава на ЕУ укажуваат во иста насока: исклучете го системот од јавниот интернет додека не биде поправен. Еден ден со страница за одржување чини помалку од сервер изграден одново.

Чекор 4: проверете дали веќе сте биле компромитирани

Прозорецот се отвори на 20 октомври, кога почна протекувањето, а сообраќај од напади беше пријавен следното утро. Ако некој систем бил достапен и незакрпен во тој прозорец, закрпата ја затвора вратата, но не ви кажува дали некој влегол пред тоа. NCSC бара од секој што не можел веднаш да закрпи да провери дали има знаци на компромитирање и задни врати (backdoors).

На што да внимавате, според објавените насоки и вообичаената практика при инциденти:

PHP процеси што прават работи што PHP никогаш не ги прави, на пример стартуваат shell или преземаат алатки (CISA).
Невообичаени multipart барања проследени со грешки поврзани со ограничувањето на меморијата или со повторени HTTP 500 одговори, PHP worker процеси што се рестартираат без јасна причина и невообичаено големи или неправилно формирани колачиња PHPSESSID во одговорите (Wiz).
Нови или изменети PHP датотеки во папките за прикачување, папките за кеш или во коренскиот директориум на сајтот (web root), нови администраторски сметки во вашиот CMS и закажани задачи што никој не ги создал.

Чистите логови не се доказ. Безбедносното известување на PHP за вториот пропуст предупредува токму за тоа, а Wiz забележува дека логовите на апликацијата може да содржат малку контекст.

Ако најдете нешто, третирајте го како инцидент, а не како задача за закрпување. Изолирајте го серверот, зачувајте ги доказите, ангажирајте давател на услуги за одговор на инциденти и сменете ја секоја тајна што веб-серверот можел да ја прочита: лозинки за бази на податоци, API клучеви, пристапни податоци за плаќања и е-пошта, клучеви за потпишување. Бидејќи вториот пропуст може да открие содржина од меморијата, размислете да ги замените најчувствителните од тие тајни на секој сервер што со денови бил изложен и незакрпен, дури и ако нема знаци на упад.

Чекор 5: што можеби ќе треба да пријавите

Самата ранливост не е инцидент што мора да се пријави. Искористената може да биде.

NIS2: ако вашата организација е опфатена, а компромитирањето е значаен инцидент, раното предупредување до вашиот национален CSIRT мора да се испрати во рок од 24 часа. Видете го нашиот водич за NIS2.
GDPR: ако некој пристапил до лични податоци, надзорниот орган мора да биде известен во рок од 72 часа откако ќе дознаете за повредата, освен ако не е веројатно дека таа ќе претставува ризик за луѓето. Видете го нашиот водич за GDPR.
Cyber Resilience Act: ако продавате софтвер или уред со PHP внатре, вие сте негов производител според CRA. Од 11 септември 2026 производителите се обврзани да пријавуваат активно искористени ранливости во своите производи преку единствената платформа за пријавување CRA, како што потсетува заедничката изјава на ЕУ. Видете го нашиот водич за CRA.
Вашите клиенти: ако хостирате или одржувате PHP за клиенти, тие ќе прашуваат. Кратка писмена белешка (што користите, кога е закрпено, што сте провериле) одговара на прашањата на повеќето од нив, а тоа е истата белешка што ќе сака да ја види ревизорот или сајбер осигурителот.

По итната ситуација: што да промените

На повеќето добро одржувани сервери PHP2Shell ќе биде закрпен за неколку дена. Она што го откри за вашите системи ќе остане точно и потоа.

Знајте колку време ви треба за закрпа. Од безбедносното известување до рестартирањето на секој сервер: часови, денови или недели? Ако искрениот одговор е „ќе треба да ја прашаме агенцијата“, решете го тоа пред следната ранливост. Кога истражувачите велат дека вештачката интелигенција им ја скратила работата на експлоитот од месеци на една недела, претпоставете дека и напаѓачите можат да се движат со тоа темпо.
Чувајте го пописот што штотуку го направивте. Тоа беше најтешкиот дел од одговорот, а застарува во моментот кога никој не е задолжен за него.
Напуштете ги верзиите на PHP на крајот на животниот век. Сајт на 7.4 или 8.1 овој пат имаше потреба од добавувач или од backport во изворниот код; следниот пат може да нема ниту едното ниту другото. PHP 8.2 го достигнува крајот на животниот век на 31 декември 2026, па сајт што ја напушта 8.1 треба да оди директно на 8.3 или понова. Преминувањето на нова верзија на PHP често значи и ажурирање на апликацијата: нашата статија за крајот на животниот век на Drupal, Umbraco и Kentico покажува што вклучува тоа за еден CMS.
Претпочитајте PHP-FPM пред mod_php каде што можете. Овој пат тоа беше конфигурацијата со помал ризик.
Оставете го следењето на напредокот на прикачувањето исклучено ако не го користите. Безбедносното известување на PHP предлага session.upload_progress.enabled да остане исклучено и по закрпувањето кога апликацијата нема потреба од него.
Внесете ги роковите за закрпи во договорите. Прашајте ги вашиот давател на хостинг и вашата агенција колку брзо применуваат критични поправки за PHP и добијте го одговорот писмено.

Список за проверка за оваа недела

Попишете ја секоја инсталација на PHP, вклучувајќи контејнери, контролни панели, производи на добавувачи и staging сервери.
Прво закрпете ги системите изложени на интернет, почнувајќи со Apache mod_php.
Рестартирајте го секој PHP процес и проверете ја верзијата што ја пријавува веб-серверот.
Изградете ги повторно сликите на контејнерите и распоредете ги повторно.
Каде што не можете да закрпите денес, применете ги привремените поставки на PHP, пренасочете го сообраќајот низ WAF или исклучете го системот од мрежата.
Побарајте од добавувачите и давателите на хостинг писмено да ги наведат верзијата на PHP и датумот на закрпата.
Прегледајте ги логовите и промените на датотеките на сè што било изложено и незакрпено од 20 октомври.
Одлучете дали важи обврска за пријавување (NIS2, GDPR, CRA).
Испланирајте го преминот од PHP 8.1 и постари, и од 8.2 пред 31 декември.

Каде можеме да помогнеме

На повеќето компании не им недостига волја да закрпат. Им недостига јасна слика за тоа што користат, или луѓе што ќе ја завршат работата оваа недела. Тоа е делот што го преземаме ние:

Попис и закрпување, за неколку дена. Ги наоѓаме вашите инсталации на PHP низ серверите, контејнерите, хостинг панелите и добавувачите, ги закрпуваме, рестартираме и проверуваме, и ви оставаме писмен запис за тоа што е направено и кога. Тој запис е и вашиот одговор до клиентите и ревизорите.
Излез од стар PHP. Апликации заглавени на PHP 7.x, 8.0 или 8.1 затоа што кодот не работи на ништо поново: ги пренесуваме на поддржана верзија во рамки на нашата услуга за одржување наследени системи.
Зајакнување и рутина за закрпување, така што следното безбедносно известување ќе биде закажана работа наместо итна ситуација.

Ако најдете знаци на упад, прво повикајте давател на услуги за одговор на инциденти. Ние можеме да ја преземеме повторната изградба и надградбата заедно со нив.

Пишете ни на office@c9group.dev што користите, и ќе ви одговориме што би направиле прво.

Извори

Проверено на 22 октомври 2026. Ситуацијата сè уште се менува: особено статусот на искористувањето и пакетите на добавувачите можеби се промениле оттогаш.

Проектот PHP

Агенции

Истражувачи, добавувачи и податоци