Критична уязвимост в Modular DS за WordPress се експлоатира активно: какво да провериш и как да се защитиш

Уязвимост с максимална тежест (CVSS 10.0) в WordPress плъгинa Modular DS се експлоатира активно, според анализ на Patchstack. Проблемът е класифициран като неавтентикирана ескалация на привилегии — тоест атакуващ може да стигне до администраторски достъп без валиден вход, при определени условия.

Засегнати са всички версии до и включително 2.5.1, а корекцията е налична в 2.5.2. Плъгинът е с над 40 000 активни инсталации, което прави темата особено спешна за всеки, който поддържа WordPress сайтове в продукция.

Какво точно е проблемът (без маркетинг, само механика)?

Modular DS излага набор от маршрути (routes) под префикса "/api/modular-connector/". Тези маршрути са част от собствен routing слой, който (по описание на поддържащите) разширява логика за route matching от Laravel. Идеята е чувствителни endpoints да са „зад“ authentication бариера (middleware).

На практика обаче се получава комбинация от решения в дизайна, която позволява заобикаляне на защитата, когато е активиран режимът “direct request”. Ако заявката съдържа параметри като origin=mo и type=<каквато_и_да_е_стойност>, тя може да бъде третирана като Modular direct request и така да мине през слоя за автентикация, без реална криптографска връзка между входящата заявка и самата Modular услуга.

Ключовият риск

Щом сайтът вече е свързан към Modular (налични/подновяеми tokens), атакуващ може да прескочи auth middleware и да достигне чувствителни маршрути през публичния интернет.

Кои маршрути стават достъпни и защо това води до админ достъп?

Според Patchstack, заобикалянето отваря достъп до няколко маршрута, включително: /login/, /server-information/, /manager/ и /backup/. В различна степен това позволява действия от тип „remote login“ и извличане на чувствителна системна или потребителска информация.

Най-критичният сценарий е злоупотреба с route от типа "/login/{modular_request}", която може да доведе до администраторски достъп (privilege escalation). След като атакуващ получи admin права, компромисът обикновено е пълен: промени по съдържание, инжектиране на зловреден код, добавяне на backdoor плъгини/файлове или пренасочвания към измами.

Как изглежда атаката „в дивото“ (наблюдавани индикатори)?

Patchstack съобщава, че експлоатацията е засечена за първи път на 13 януари 2026 около 02:00 UTC. Описаната последователност включва HTTP GET заявки към endpoint "/api/modular-connector/login/", последвани от опити за създаване на администраторски потребител.

Като източник на атаки са посочени следните IP адреси (добри кандидати за временно блокиране/допълнително наблюдение, ако нямаш по-добър сигнал):

45.11.89[.]19
185.196.0[.]11

Най-важното: какво да направиш веднага (приоритети)?

Обнови Modular DS до версия 2.5.2 възможно най-бързо (пачът е наличен).
Провери за неочаквани администраторски акаунти: нови users с administrator роля, странни имейли, или акаунти създадени извън нормалния процес.
Прегледай логовете за подозрителни заявки към "/api/modular-connector/", особено "/api/modular-connector/login/" и заявки с origin=mo и произволен type параметър.
Ако има сигнал за компромис: предприеми действия за анулиране на сесии/токени и сканиране (детайли по-долу).

Практичен подход за екипи

При сайтове с висок трафик/оборот най-работещата стратегия е: 1) пач веднага, 2) бърз triage за нови админи и подозрителни заявки, 3) ако има индикации — моментално ротация на секрети и форензик сканиране.

Ако вече подозираш компромис: конкретни remediation стъпки

Modular DS препоръчва да се прегледа сайтът за признаци на компромис (неочаквани admin users, подозрителни заявки от автоматизирани скенери). Ако има индикации, следвай тези стъпки:

Regenerate WordPress salts – целта е да се инвалидира наличната автентикация и активните сесии (cookies/sessions).
Regenerate OAuth credentials – ако сайтът е свързан към външни услуги чрез OAuth, ротацията на креденшъли намалява риска от повторно използване на компрометирани токени.
Сканирай сайта за зловредни плъгини, файлове или код – търси непознати плъгини, нови PHP файлове в wp-content/uploads, подозрителни mu-plugins, и инжекции в theme файлове.

Какво ни казва този случай за архитектурата на плъгини и „вътрешни“ маршрути

Този инцидент е добър пример колко опасно е имплицитното доверие към „вътрешни“ request пътища, когато реално са изложени към публичния интернет. По думите на Patchstack проблемът не е единичен бъг, а натрупване от решения: URL-базирано route matching, твърде либерален direct request режим, автентикация базирана само на състоянието „сайтът е свързан“, плюс login flow, който може да се върне към администраторски акаунт.

От гледна точка на разработка това е сигнал да се избягват дизайни, в които “специални” режими (direct/internal) се активират само с параметри в URL, без силна проверка на произхода (напр. подпис, HMAC, mTLS, или поне строго валидиран webhook secret).

Къде е пачът

Официалният security release за корекцията е обявен като Modular Connector 2.5.2. Ако поддържаш сайтове на клиенти, провери инсталираната версия и планирай обновяване при първа възможност — при активна експлоатация прозорецът за реакция обикновено е кратък.