Ето една прогноза: предстои ни звездно тримесечие за компаниите в сферата на сигурността на приложенията. PHP2Shell е напът да се превърне в най-силния бюджетен аргумент, с който доставчиците на решения за сигурност на приложения са разполагали от години. Изкуственият интелект помогна на изследователите да открият две уязвимости за отдалечено изпълнение на код в езика, стоящ зад 69% от уеб пространството, атакуващите се насочиха към тях още преди публикуването на корекцията за сигурност, а посланието за продажби се оформя от само себе си: намирайте повече грешки и ги отстранявайте по-бързо.

Корпоративните организации трябва да преосмислят тази идея. Екипите по сигурност не могат да инсталират корекции за сигурност с машинна скорост, но могат да ограничат до какво има достъп атакуващият след пробива, като се фокусират върху идентичността като основна контролна равнина.

Отвъд първоначалната експлоатация крайната тежест на инцидента зависи до голяма степен от това кои служебни акаунти, API ключове, облачни роли и токени може да използва компрометираният работен товар и до какво осигуряват достъп те.

От уязвимост към експлоатация

Първо, трябва да разберем колко по-бързо се извършва експлоатацията в наши дни. Двата проблема зад PHP2Shell са присъствали в кода на PHP още от 2012 г. Изследователи от Calif и Wiz ги откриха през август с помощта на модели на OpenAI и Google и ги оповестиха съвместно с OpenAI.

Amazon регистрира опит за експлоатация на 17 октомври — четири дни преди официалното оповестяване. PHP пусна корекцията за сигурност на 21 октомври, като watchTowr отчете опити за експлоатация в реална среда още същия ден. Cloudflare наблюдава рязко нарастване на атаките след оповестяването, а на 26 октомври CISA добави двата дефекта към своя списък с известни експлоатирани уязвимости.

Днес експлоатацията често започва още преди официалното разкриване на проблема. За съжаление мерките за отстраняване на уязвимостите не напредват със същата скорост. Според доклада DBIR за 2026 г. на Verizon средното време за отстраняване на известна експлоатирана уязвимост е 43 дни. По данни на Qualys средното време за коригиране е 21,2 дни, а 63% от критичните уязвимости остават неотстранени дори след една седмица. И всичко това се случва при положение, че всеки ден се публикуват около 195 нови CVE.

Справянето с PHP2Shell ще отнеме повече време от обичайното. PHP се разпространява интегриран в хардуерни устройства и контролни панели за хостинг, които клиентите не могат да обновят сами. Освен това версии 8.1 и по-старите изобщо не получиха официални компилации.

Към 27 октомври Censys отчете 32,5 милиона интернет услуги, базирани на PHP, които все още използват потенциално уязвими версии, както и над 60 милиона други, които изобщо не съобщават версията си.

Както и да погледнем на ситуацията, скоростта на отстраняване на уязвимостите ще остане по-ниска от темпото на експлоатация в обозримо бъдеще, дори когато самото инсталиране на корекции за сигурност се възползва значително от работни процеси, базирани на изкуствен интелект.

Всеки агент се нуждае от идентичност

Днес софтуерните агенти действат във вашите системи с нива на достъп, които никой не е прегледал.

Решението AI Agent Security на Token Security открива всеки агент, свързва го със собственик и ограничава действията му. Ред, базиран на идентичността, за овладяване на хаоса от агентния изкуствен интелект.

Откриването не означава отстраняване

С нарастващата разлика между експлоатацията и корекциите изглежда изкушаващо да инвестирате всичко възможно в опит да удържите вълната. Но дори сканиране с помощта на изкуствен интелект утре да открие 2000 нови zero-day уязвимости във вашата инфраструктура, това няма да доведе до по-високо ниво на сигурност.

Това просто ще ви даде списък. Някои от елементите ще бъдат лесни за коригиране, докато други ще изискват повече време, отколкото екипът ви разполага.

За поддържаните клонове на PHP прякото решение беше лесно: инсталиране на обновената версия. Въпреки това правителствени институции и компании спираха уебсайтовете си, докато изчакваха появата ѝ.

Ето един друг, по-оптимистичен начин за разглеждане на въпроса. Уязвимостите водят до експлойти, а експлойтите водят до атаки, но в корпоративна среда въздействието на една атака се определя от това докъде могат да достигнат компрометираните идентичности. Достъпът през шел до PHP сървър дава на атакуващия възможност да прочете всичко, до което самият сървър има достъп — от системни променливи до облачни ключове в конфигурационни файлове.

PHP2Shell може също така да доведе до изтичане на паметта на работните процеси, включително пароли, токени и API ключове. Атакуващ, който изпълнява код на един хост, отваря врата към общ коридор, но истински ценните активи обикновено се намират зад заключени врати.

А мерките за сигурност, които ограничават страничното движение (lateral movement), не зависят от това дали ще спечелите надпреварата по бързина при откриването на уязвимости. Намирането на дефекти е безкраен процес, докато ограничаването на обхвата на даден служебен акаунт е измерима и постижима задача.

Атакуващите избират най-лесния път

Този подход има своите граници. Ако уязвимостта се намира в доставчика на идентичност (IdP) или в мениджъра на тайни (secrets manager), възможностите за странично движение са вградени по подразбиране. Ако тя е в базата данни или при доставчика на хранилище, атакуващият вече е достигнал желаната цел.

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

Този залог поставя тежестта на уязвимостта (оценката по CVSS) пред радиуса на поражение. Атакуващите не търсят най-директния път — те търсят най-лесния път. Използването на изтекли идентификационни данни за придвижване в мрежата е далеч по-лесно от навързването на поредица от уязвимости от тип нулев ден за директен достъп до база данни.

Други водещи заглавия от октомври илюстрират именно този сценарий. В случая с LiteLLM киберпрестъпниците използваха главен ключ, изложен в публично хранилище, за да извлекат токен на собственик на GitHub организация с неограничени права от вътрешна платформа за агенти. Тази компрометирана идентичност им позволи да откраднат още два токена на поддържащи проекта лица, да манипулират процеса по издаване на версии и да разпространят компоненти за кражба на идентификационни данни.

Първо свийте радиуса на поражение

Не можете да спечелите състезанието по инсталиране на корекции за сигурност на всеки сървър, преди да са пристигнали атакуващите, но можете да определите каква стойност носи компрометираният сървър за тях. Открийте и опишете всеки AI агент и всяка нечовешка идентичност, след което започнете със защитата на онези, които имат най-широк достъп.

Задайте отговорен собственик, ограничете достъпа стриктно според целта и предназначението, премахнете неизползваните идентификационни данни и непрекъснато управлявайте жизнения цикъл на идентичностите. При AI агентите направете още една стъпка напред и предоставяйте права въз основа на конкретното намерение. Ето какво означава идентичността да се третира като основна контролна равнина.

Инсталирането на корекции за сигурност определя колко бързо ще затворите пробива. Управлението на идентичността решава какво ще получи атакуващият, когато не успеете да го направите навреме.