Съдържание
Пълен курс по етично хакерство от нула до експерт
Хаквайте като хакери с черни шапки. Тестване за проникване, Kali Linux, хакване на WiFi и уеб сайтове, както и хакерският начин на мислене зад всичко това.
Повече от 22 милиона PHP инсталации се оказаха уязвими онлайн тази седмица, изправени пред два дефекта, които не изискват парола. Подробностите изтекоха преди да съществува корекция за сигурност. Обновяването на WordPress не отстранява проблема. Уязвимостта е в самия PHP – бекендът на по-голямата част от уеб пространството.
Във вторник, 20 октомври, подробности за две неотстранени уязвимости в PHP започнаха да се разпространяват в мрежата. Публикация в Hacker News обяви, че някой ще разкрие грешките на 22 октомври, без да има готова корекция за сигурност. Публикацията беше свалена, но екранните снимки вече бяха обиколили интернет, включително една на инструмент за експлоатация, наречен PHP2Shell. Компанията за киберсигурност watchTowr прегледа изтеклата информация и потвърди, че уязвимостите са автентични и позволяват отдалечено изпълнение на код. Екипът на PHP беше планирал дискретно, предварително насрочено отстраняване на уязвимостта. Вместо това се наложи да пусне такова, докато подробностите вече бяха публично достояние.
Екипът на PHP насрочи извънредно издание и заяви, че то може да бъде пуснато по-рано, ако се появят атаки. Cloudflare съобщи за ранни атаки срещу сайтове с PHP в сряда сутринта и въведе правила за защитната стена, за да ги неутрализира. Корекцията за сигурност пристигна следобед, малко по-рано от планираното пускане в 14:00 UTC.
Колко сериозно бе възприета ситуацията можеше да се види по това какво спря да работи. В Нидерландия сайтът digid.nl, основният правителствен вход за автентикация, показваше обикновена страница: този уебсайт е временно недостъпен. MijnOverheid също спря да функционира, както и уебсайтът на националния парламент и сайтът на агенцията за киберсигурност NCSC – хората, чиято работа е да предупреждават обществеността. Влизането с DigiD в други услуги все още работеше, но собственият му сайт, както и множество други, бяха свалени. Tweakers и Security.NL, два от най-известните технологични сайта в страната, също бяха офлайн.
Мащабът се разпростря далеч отвъд границите на една държава. Reuters съобщи, че правителствени уебсайтове в Европа и на други места са спрели работа в сряда, като агенции във Финландия са сред тези, които превантивно свалиха сайтовете си. Агенциите за киберсигурност в Европа, Австралия, Япония и Великобритания казаха на потребителите на PHP незабавно да инсталират корекции за сигурност или да спрат сайтовете си офлайн, докато успеят да го направят. CERT-EU на ЕС заяви почти същото: инсталирайте корекции за сигурност в момента, в който се появи решение, а там, където това не е възможно, обмислете изолирането на приложенията с достъп до интернет от публичната мрежа, докато то не бъде приложено.
В Германия университетът във Фрайбург свали централните си уебсайтове офлайн в 10:39 ч. същата сутрин, заедно с интранета си, платформата за обучение ILIAS и уеб пощата за студентски адреси, като същевременно нареди на факултетите си също да свалят своите PHP системи. Нито един от тези случаи не беше потвърден пробив. Това бяха организации, които решиха, че е по-безопасно да бъдат недостъпни, отколкото да продължат да работят с версия на PHP, която някой може да компрометира.
За да се разбере защо едно правителство би предпочело да спре сайтовете си, трябва да знаете какво място заема PHP. PHP управлява бекенда на по-голямата част от уеб пространството. W3Techs посочва, че той стои зад 69,3% от всички сайтове, чийто език от страна на сървъра може да бъде идентифициран, а WordPress, който сам по себе си задвижва близо 40% от всички уебсайтове, работи върху него. Същото важи и за Magento при онлайн магазините, Drupal и Joomla за по-големи сайтове, phpBB за форуми, WHMCS за фактуриране на хостинг и MediaWiki – софтуерът зад Wikipedia. Нито едно от тези приложения не съдържа грешката. Тя се намира в PHP под тях, така че можете да напишете сайт безупречно и той пак да остане уязвим.
Изданието коригира два отделни проблема. Първият, CVE-2026-109618, се корени в начина, по който PHP обработва изчерпването на паметта. Когато дадена заявка използва твърде много памет, PHP прекъсва текущите действия, за да прекрати тази заявка по контролиран начин. Проблемът е, че паметта за заявката понякога е достъпна, преди тя да бъде напълно инициализирана. Ако в този момент заделянето на памет се провали, PHP не отчита преждевременното излизане. След това стъпката по почистване работи върху данни, които никога не са били валидни, а прецизно конструирана заявка може да превърне това объркване в изпълнение на собствен код на атакуващия върху сървъра.
Това, което прави атаката практическа, е колко лесно може да бъде предизвикан този момент на изчерпване на паметта. PHP прочита тялото на качената форма – типът multipart/form-data, който браузърът изпраща при прикачване на файл – преди кодът на вашето приложение изобщо да се задейства. Заявка, която никога не декларира използваема дължина, може да заобиколи ограничението post_max_size, предназначено да спира твърде големи качвания. Празните полета за файлове не се зачитат спрямо лимита max_file_uploads, но въпреки това PHP изгражда пълен набор от вътрешни записи за всяко от тях. Комбинирайте достатъчно от тях и паметта се изчерпва по команда точно на мястото, където се намира първата уязвимост.
Вторият дефект, CVE-2026-109619, е грешка от различен тип. Работният процес (worker) на PHP запазва част от състоянието си в паметта между заявките – елементи като данни за грешки и сесии. PHP би трябвало да изчисти това състояние, преди да върне обратно паметта. Фатална грешка, включително породена от същия трик с изчерпване на паметта, може да доведе до пропускане на почистването. PHP освобождава паметта, докато работният процес все още сочи към нея. Следващата заявка чете указател към памет, която вече не ѝ принадлежи. Това представлява уязвимост от тип използване след освобождаване (use-after-free) и при правилно разпределение на паметта в динамичната памет (heap layout) също завършва с изпълнение на код с привилегиите на самия уеб сървър.
Това слабо място не е ново. През 2004 г. изследователят Стефан Есер откри първата отдалечена уязвимост в начина, по който PHP управлява лимита си на памет. През 2020 г. доклад за грешка посочи същото поведение при изчерпване на паметта около качването на файлове. През 2024 г. одит за сигурност, извършен от OSTIF и Quarkslab, откри свързан проблем с паметта, въпреки че по онова време изследователите не можаха да докажат, че той може да бъде експлоатиран. Двата дефекта, коригирани днес, са мястото, където тази дългогодишна слабост най-накрая се превърна в работеща атака.
PHP оцени и двете уязвимости с 9.2 от 10 – критична стойност, макар и не максимална оценка. Числото отразява факта, че атаката не е тривиална: изисква се висока сложност и съвпадане на точните условия. Някои първоначални доклади спрягаха оценка 10.0; официалната оценка е 9.2. Въпреки това става дума за неавтентикиран атакуващ, действащ през интернет, което завършва с изпълнение на код на сървъра. Разликата между 9.2 и 10.0 има малко значение, когато код за доказване на концепцията вече е публично достъпен.
Една подробност в бюлетина за сигурност е от съществено значение, ако управлявате сървър. За първата уязвимост собственият анализ на PHP доказа пълната атака през HTTP на Apache с mod_php – класическата конфигурация, при която PHP се изпълнява вътре в уеб сървъра при стандартни настройки. Анализът определя PHP-FPM, конфигурацията, използвана от много доставчици на споделен и управляван хостинг, също като уязвима, въпреки че срещу нея не е демонстриран пълен експлойт за тази първа уязвимост. Вторият проблем обаче променя картината. От екипа на PHP посочват, че векторът през сесиите е постигнал работещо изпълнение на код както при mod_php, така и при FPM, така че FPM не е по-сигурният вариант, за какъвто може да изглежда. И двете конфигурации се нуждаят от корекцията за сигурност незабавно.
Уязвимостите не са открити от атакуващи. Те са били докладвани на екипа на PHP, който е работил по отстраняването им, преди подробностите да станат публични. Поправката е в ядрото на PHP. Разработчиците са премахнали рисковата стъпка за аварийно прекратяване при недостиг на памет, която стои в основата на първия дефект, и са накарали работния процес да изчиства правилно остатъчното си състояние, за да затворят втория. Точно това отстранява днешното издание.
- → PHP
8.5.12 - → PHP
8.4.27 - → PHP
8.3.36 - → PHP
8.2.35
Всичко под тези версии е уязвимо. PHP 8.1 и по-старите версии вече не получават обновления от проекта PHP, а сканиране от 20 октомври установи около 884 000 сървъра, достъпни от интернет, които все още работят с 8.1 или по-стара версия. Екипът на PHP предостави минимални бекпорти за 7.4, 8.0 и 8.1 за потребителите, които компилират PHP от изходен код, но всичко отвъд това остава без поддръжка. В Индия едно сканиране преброи 19 847 сървъра с версии, които вече не получават корекции за сигурност. А за PHP 8.2, най-старият клон, който все още се поддържа, краят на жизнения цикъл настъпва на 31 декември 2026 г., така че сайтовете, използващи го, трябва да инсталират корекциите за сигурност сега и да планират преминаване към по-нова версия.
Различните скенери дават различни общи стойности, но всички те сочат в една и съща посока. VirusTotal идентифицира около 5,1 милиона интернет адреса, изпълняващи PHP. Собственото сканиране на Palo Alto маркира повече от 22,6 милиона инстанции като потенциално уязвими. Точната цифра има по-малко значение от това, което показва: PHP е един от най-масово инсталираните софтуерни продукти в интернет, работещ едновременно на милиони сървъри. Служителите по сигурността описват ясно какво означава това излагане на риск. Сървър, над който е поет контрол, може да се окаже с откраднати данни, компрометирани входни данни и свалени уеб страници.
Ако управлявате WordPress сайт, точно тук хората се подлъгват. Обновяването му не затваря пробива, нито пък обновяването на добавките ви, тъй като корекцията е за PHP, което функционира на сървъра под тях. Същото важи за всяко PHP приложение, независимо на каква база работи. Единственото от значение е версията на PHP, която вашият хостинг доставчик поддържа, и дали тя е обновена. Ако не управлявате собствен сървър, единствената поправка е тази, която инсталира хостинг доставчикът ви, затова поискайте от него да приложи обновяването на PHP незабавно.
Добрата новина е, че проверката на състоянието отнема само минута. На собствен сървър можете да проверите версията на PHP директно:
Една уловка: това показва версията на PHP за командния ред, която не винаги е версията, с която работи вашият уебсайт. Проверете какво отчита самият сайт, например чрез php-fpm8.3 -v или phpinfo страница. Ако резултатът е под 8.2.35, 8.3.36, 8.4.27 или 8.5.12, вие сте изложени на риск и се нуждаете от корекцията за сигурност. След обновяването рестартирайте PHP-FPM или Apache, тъй като вече работещите процеси запазват стария код, докато не направите това. При споделен хостинг, където нямате възможност да изпълните нищо от това, по-безопасният ход е да се свържете с хостинг доставчика си още днес и да зададете един въпрос: приложихте ли изданието за сигурност на PHP от 21 октомври. Разпространяваните промени в конфигурацията, като изключване на следенето на напредъка при качване в сесиите, блокират само един път за проникване и не правят сървъра сигурен. Единствено корекцията за сигурност затваря пробива.
По-високият номер на версията не винаги е доказателство, че сте защитени. Дистрибуциите често отстраняват уязвимости чрез бекпортиране на корекцията в пакет, който все още показва по-стара версия, така че само номерът може да ви подведе. По-сигурната проверка е регистърът на промените (changelog) на пакета. В Debian или Ubuntu изпълнението на apt changelog php8.3-cli показва последните промени; при системите на Red Hat rpm -q --changelog php прави същото. Ако един от двата CVE номера присъства там, корекцията е приложена. Ако не присъства, пакетът все още не е актуализиран, независимо какво показва версията.
Дали атакуващи вече използват това срещу реални сайтове, не е напълно ясно. Cloudflare забеляза опити за атака срещу сайтове с PHP в сряда сутринта, като хостинг компании докладваха същото. Към 21 октомври няма потвърден пробив: нидерландската агенция за киберсигурност съобщи, че не е наблюдавала активна злоупотреба, и нито една от двете уязвимости все още не фигурира в списъка на правителството на САЩ с известни експлоатирани уязвимости. От Unit 42 заявиха, че са засекли код за доказване на концепцията (proof-of-concept), но не и реално проникване. До късния следобед корекцията за сигурност беше пусната, малко преди планираното пускане в 14:00 UTC, въпреки че много сайтове, които бяха спрели работа, останаха недостъпни и през вечерта.
Това, което извади правителствени уебсайтове от строя в държава след държава, беше уязвимост, престояла с години в най-разпространения софтуер в мрежата, до деня, в който подробностите за нея изтекоха. Публичен код за доказване на концепцията вече е налице, а след подобно изтичане масовото сканиране обикновено започва в рамките на часове. Ако притежавате каквото и да е, работещо с PHP – блог, магазин, форум, фирмен сайт – това, което има значение в момента, е дали сървърът ви е бил защитен с корекции за сигурност, преди някой да започне да търси.
Знаете ли с коя версия на PHP работи вашият собствен сайт и какво вижда един атакуващ, когато го сканира отвън?
Моят пълен курс по етично хакерство от нула до експерт ви води стъпка по стъпка: разузнаване, сканиране, експлоатация и анализ на трафика, с практическа насоченост, още от първия ви ден без предишен опит с Linux или хакерство.
→ Запишете се за моя пълен курс по етично хакерство
Хакерството не е хоби, а начин на живот.
Източници: PHP бюлетин за сигурност | CVE-2026-109618 бюлетин | CVE-2026-109619 бюлетин