На 21 октомври 2026 г. PHP публикува поправки за две критични уязвимости: CVE-2026-109618 и CVE-2026-109619. Поправените версии са 8.2.35, 8.3.36, 8.4.27 и 8.5.12. Това вече е налична актуализация, а не само предупреждение за предстоящо издание. За операторите на уеб платформи следващата задача е да установят кои работещи инсталации са получили поправката.

Официалното съобщение обхваща PHP, обслужващ уеб заявки, включително FPM и Apache mod_php. И двете уязвимости са оценени с 9.2 по CVSS 4.0. Оценката показва сериозност, но сама по себе си не доказва извършена атака срещу конкретен сайт.

Две различни грешки в управлението на паметта

При CVE-2026-109618 обработката на недостиг на памет може да прекъсне инициализацията и да остави опасно състояние за последващото почистване. CVE-2026-109619 засяга състояние от приключила заявка, което остава достъпно в дълго живеещ работен процес. И двата проблема могат да доведат до изпълнение на код.

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

Защо това има значение и за AI услугите

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

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

Как да се организира проверката

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

След актуализацията е разумно да се изпълнят обичайните проверки на продукта: вход, права за достъп, сесии, качване на разрешени файлове и основните потребителски операции. Резултатът трябва да бъде записан заедно с времето на проверката. При проблем планът за връщане трябва да избягва повторно излагане на непоправена среда; ако няма сигурна работеща версия, временно ограничаване на услугата заслужава отделно оперативно решение.

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

Какво остава ограничение

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

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

Източникът, предложен от читателя, е използван като отправна точка. Фактите за наличните версии и CVE са проверени по съобщението на PHP и двете официални advisories. Илюстрацията е създадена с AI и не показва действителна атака или конкретен сървър.

Проверено по посочените източници: 2026-10-21T16:25:46.969844+00:00. Корица: AI илюстрация.