Ядрото на WordPress е почти недосегаемо. 91% от дупките са в плъгините, а вие имате пет часа
Почти всяка статия за сигурност на WordPress завършва на едно и също място: обновявайте всичко навреме. През 2026 г. този съвет е технически верен и оперативно безполезен, защото разстоянието между публичното оповестяване на уязвимост и масовата ѝ експлоатация вече е по-кратко от времето, за което повечето екипи изобщо забелязват, че има ново обновяване.
На 25 февруари 2026 г. Patchstack публикува доклада State of WordPress Security in 2026. От него си струва да се запомнят две числа. През 2025 г. в екосистемата на WordPress са каталогизирани 11 334 нови уязвимости, с 42% повече от предходната година. И претеглената медиана на времето от оповестяване до масова експлоатация е пет часа.
Пет часа са по-малко от един работен ден. По-малко от съгласуването на прозорец за поддръжка. По-малко от интервала, през който някой влиза в администрацията, за да провери дали има какво да се обнови. Оттук нататък статията е за това какво това число реално налага да се промени.
Какво показва докладът
Разпределението по компоненти е частта, която обръща целия разговор. Пробивът не идва през платформата.
| Показател за 2025 г. | Стойност | Какво означава на практика |
|---|---|---|
| Нови уязвимости в екосистемата | 11 334, ръст от 42% | Проблемът е в обема, не в екзотичната техника |
| Дял в плъгините | 91% | Атакуваната повърхност е решение за доставчици, не за платформа |
| Дял в темите | 9% | Конструкторите на страници и универсалните теми тежат сериозно тук |
| Намерени в ядрото на WordPress | 6, всички с нисък приоритет | Ядрото на практика не е вашият риск |
| Медиана до масова експлоатация | 5 часа | Човешкото темпо на обновяване не печели тази надпревара |
| Оповестени без наличен пач | 46% | В почти половината случаи няма към какво да се обнови |
| Критични нулеви дни в платени компоненти | 33 срещу 12 в безплатните | Плащането купува поддръжка, не сигурност |
| Специфични за WordPress атаки, спрени от хостинга | 12% | Периметърът е по-тънък, отколкото подсказва фактурата |
Една уговорка, преди някой да цитира това пред управителен съвет. Patchstack поддържа търговска база от уязвимости и продава защита, тоест отчита пазар, в който сам участва. Числата идват от собствения му поток на приемане и обработка на сигнали: това е най-пълният публичен източник за тази екосистема и същевременно остава гледната точка на един доставчик. Приемайте посоката за надеждна, а десетите – за приближение, както и при всеки друг отраслов бенчмарк.
Ядрото може да излезе от списъка с тревоги
Шест проблема с нисък приоритет за цяла година, в софтуер, който върти огромна част от мрежата, е необичайно добър резултат за платформа от такъв мащаб. Ядрото има екип по сигурността, регламент за оповестяване, фонови обновявания по подразбиране за минорните издания и достатъчно изследователско внимание, за да изплуват сериозните неща рано.
При плъгините нищо от това не е гарантирано. Един плъгин може да е писан от двама души, продаден, изоставен, препродаден и оставен в каталога с петдесет хиляди активни инсталации без поддръжка. Указанията за сигурност в наръчника за разработчици на WordPress съществуват и са добри, но нищо не задължава някого да ги прочете. Тази асиметрия обяснява изцяло числото 91%.
Оперативното следствие е неудобно: броят на плъгините на един сайт е показател за сигурност. Не за бързина и не за подреденост. Всеки допълнителен плъгин е още един независим доставчик, чиято дисциплина на издаване сте приели, без да сте я проверили. Писали сме отделно за това как в действителност се хакват сайтове на WordPress и картината при реалните инциденти съвпада със статистиката почти напълно.
Защо петте часа убиват ръчния модел
Помислете как работи типичен договор за поддръжка. Уязвимост се оповестява във вторник следобед. Някой прочита бюлетина в сряда сутрин. Пуска се задача, обновява се тестова среда, минава проверка, съгласува се прозорец с клиента и в четвъртък промяната стига до продукционния сайт. Това е компетентен, внимателен, професионален процес. И е около трийсет пъти по-бавен от прозореца за експлоатация.
Автоматичното сканиране не се съобразява с работното ви време. Щом поправката се появи в публично хранилище, самата разлика в кода описва уязвимостта и масовите опити тръгват в рамките на часове. Разстоянието между оповестяване и атака се свива от години и в момента изглежда като пет часа.
После идва числото 46%. Почти половината оповестени уязвимости не са имали поправка в момента на публикуването, тоест стратегията „обновявай бързо“ в тези случаи просто няма ход. Не може да се инсталира поправка, която не съществува. Интервалът трябва да се покрие с нещо друго.
Платеното не значи по-безопасно
Това е изводът, който най-често противоречи на съществуваща политика за покупки. Patchstack е отчел 33 критични уязвимости от нулев ден в платени и условно безплатни компоненти срещу 12 в безплатните, а делът на компонентите с потвърдена експлоатация сред платените е бил около три пъти по-висок.
Механиката не е загадъчна. Платените плъгини носят повече функционалност, повече код, собствени сървъри за лицензи и обновявания и вградени библиотеки на трети страни. Разпространяват се извън каталога wordpress.org, тоест извън автоматичния преглед, извън механизма за принудително обновяване, който каталогът може да задейства, и често изобщо извън канала за обновяване на самия сайт. Класическият случай е платен слайдер, зашит в купена тема: три версии назад е, никой не помни, че е там, и няма никакъв път за обновяване.
Правилният извод не е, че безплатното е по-безопасно. Той е, че цената не е показател за качеството на поддръжката и не бива да фигурира в критериите за избор така, сякаш е. Прогнозна стойност имат други неща: честота на изданията, история на времето до поправка, наличие на публикуван контакт по въпроси на сигурността и присъствие на компонента в база от уязвимости със записи за бързи поправки. Нашият чеклист за оценка на доставчик преди интеграция на услуга описва същата логика за услуги и тя се пренася върху плъгините без промяна.
Какво реално правят хостингът и WAF
Най-неудобното число в доклада за хостинг индустрията е, че традиционните защити са спрели само 12% от специфичните за WordPress уязвимости, при чувствително по-добър резултат срещу общия поток от атаки.
Точно тази разлика е важната. Общите правила хващат общи атаки: шаблони за SQL инжекции, познати зловредни полезни товари, очевидни скенери. Специфичната за WordPress уязвимост обикновено изглежда като легитимна заявка към легитимен маршрут с параметри, които авторът на плъгина е забравил да провери. В пакета няма нищо подозрително, освен ако правилото не познава конкретния плъгин, конкретния маршрут и конкретния параметър. Универсалният филтър няма как да ги знае.
Това не прави управлявания хостинг безполезен. Изолацията, затегнатите настройки на PHP, неизменяемите резервни копия и бързото връщане назад си струват парите и сме описали отделно къде при хостинга за бизнес не бива да се пести. Само не го купувайте с убеждението, че редът „WAF“ в тарифата покрива уязвимостите в плъгините. По данните от доклада той покрива около една от осем.
Мерките, които наистина променят числото
При прозорец от пет часа, 46% оповестявания без поправка и 12% прихващане на периметъра стратегията спира да бъде „обновявай по-бързо“ и става „имай по-малко за обновяване и покривай интервала, в който обновяването е невъзможно“.
| Мярка | На кое число отговаря | Разход | Какво остава непокрито |
|---|---|---|---|
| Съкращаване на броя плъгини, премахване на неактивните | 91% в плъгините | Един одит, после на тримесечие | Нищо не променя за останалите |
| Правила за произход при нови плъгини | Нулевите дни в платените компоненти | Политика плюс десет минути на решение | Всичко, което вече е инсталирано |
| Виртуално пачване на ниво приложение | 5 часа, 46% без поправка | Абонамент и настройка | Това, което още не е оповестено |
| Автоматични минорни и защитни обновявания | Прозорецът от 5 часа | Само конфигурация | Мажорните версии и рискът от лошо издание |
| Мажорни обновявания през копие на продукцията | Риск от счупване при автоматика | Отделна среда | Добавя забавяне, затова върви с виртуално пачване |
| Контрол на целостта на файлове и изходящите заявки | Откриване, когато превенцията се провали | Настройка и човек, който чете сигналите | Открива, но не предотвратява |
| Изпробвано възстановяване, а не само резервни копия | Времето за връщане в работа след пробив | Едно учение на тримесечие | Данните, записани между пробива и откриването |
Три от тях заслужават разгръщане.
Виртуалното пачване е прекият отговор на онези 46%. Правило, написано за една известна уязвимост в известен компонент, блокира точно формата на заявката, с която тя се използва, без да се пипа кодът на плъгина. То купува интервала между оповестяването и появата на истинска поправка, тоест точно интервала, в който се губят сайтове. Такива правила се строят върху публични тракери като базата от уязвимости на Patchstack и каталога на CISA с известни експлоатирани уязвимости, за които си струва да се абонирате и директно, ако поддържате повече от няколко сайта.
Поетапните автоматични обновявания означават да разделите потока, вместо да избирате между „всичко ръчно“ и „всичко автоматично“. Защитните и минорните издания тръгват автоматично, защото очакваната загуба от рядко счупен блок е далеч по-малка от очакваната загуба при петчасова откритост. Мажорните версии минават през тестова среда. WordPress поддържа това разделение стандартно чрез константите за фонови обновявания, а повечето екипи никога не ги настройват, защото самият разговор се води в режим „всичко или нищо“.
Наблюдението съществува, защото първите три мерки някой ден ще се провалят. След това значение има само изтеклото време. Компрометиране, открито за час, е инцидент; същото компрометиране, открито след три месеца, е проблем с данни, с репутация и вероятно с регулатор. Базовият набор за по-малки екипи сме описали в материала за киберсигурност за малкия бизнес.
Какво тези числа не оправдават
- Отказ от WordPress. Шест проблема с нисък приоритет в ядрото за година е силен резултат. Преминаването към друга платформа води до друг набор зависимости с по-малко публично внимание, а не до по-малка атакувана повърхност.
- Изключване на всички автоматични обновявания след едно неуспешно издание. Тази размяна заменя рядка видима авария с честа невидима. Пресметнете и двете страни, преди да решите.
- Купуване на плъгин за сигурност с усещането, че въпросът е затворен. Повечето от това, което променя изхода, е дисциплина на инвентаризация и политика за обновяване, а те не се инсталират от каталог.
- Паника заради ръста от 42%. Част от него отразява повече изследователи и по-добро отчитане. Оперативно сериозните находки са петте часа и 46% без поправка, а не самият обем.
Накратко
Ядрото на WordPress е дало през 2025 г. шест уязвимости с нисък приоритет, а плъгините – 91% от 11 334. Медианата от оповестяване до масова експлоатация е пет часа, 46% от оповестяванията са излезли без налична поправка, платените компоненти са произвели близо три пъти повече критични нулеви дни от безплатните, а защитите на ниво хостинг са спрели около една от осем специфични за WordPress атаки. Прочетени заедно, тези числа казват, че лостът не е скоростта на обновяване. Лостовете са броят плъгини, произходът им, виртуалното пачване, разделената политика за обновяване и проверен път за възстановяване.
Ако един сайт е натрупал за няколко години трийсет или четирийсет плъгина, никой няма опис какво правят, а в темата са зашити компоненти, които не могат да се обновят, честното решение обикновено е структурно, а не процедурно. Точно с такива случаи се сблъскваме най-често при миграция и пресглобяване на сайт, където смисълът на упражнението е накрая да получите списък със зависимости, който е реалистично да поддържате обновен, вместо да го обещавате на думи.
