Modular DS spraga (CVE-2026-23550) realiai išnaudojama: kaip patikrinti WordPress svetainę ir ką daryti dabar

WordPress ekosistemoje kritinės spragos dažniausiai skausmingos ne dėl pačios CVSS reikšmės, o dėl to, kaip greitai jas „paima“ automatizuoti skeneriai. Šįkart kalba apie Modular DS papildinį: pagal Patchstack, spraga jau aktyviai išnaudojama, o scenarijus nemalonus – galima gauti administratoriaus prieigą neturint jokios autentifikacijos.

Kas įvyko: CVE-2026-23550 esmė

Spraga registruota kaip CVE-2026-23550 (CVSS 10.0). Ji apibūdinama kaip neautentifikuota privilegijų eskalacija (unauthenticated privilege escalation), paveikianti visas Modular DS versijas iki 2.5.1 imtinai. Pataisymas išleistas 2.5.2 versijoje (pagal gamintojo saugumo pranešimą). Papildinys, kaip nurodoma, turi daugiau nei 40 000 aktyvių diegimų, todėl masinio skenavimo tikimybė čia yra labai reali.

Kodėl ši spraga tokia pavojinga: autentifikacijos apeinimas per routing logiką

Pagal Patchstack analizę, problema nėra „viena klaida eilutėje“. Ji susideda iš kelių dizaino sprendimų, kurie kartu sukuria pavojingą grandinę: maršrutų (routes) atpažinimas pagal URL, per daug atviras „direct request“ režimas, autentifikacijos logika, kuri remiasi vien tuo, kad svetainė jau sujungta su paslauga (tokenai yra), ir prisijungimo (login) srautas, kuris gali automatiškai „nusėsti“ ant administratoriaus paskyros.

Techninis branduolys – papildinys viešai eksponuoja savo endpoint’us po prefiksu /api/modular-connector/ ir bando dalį jautrių maršrutų užrakinti per autentifikacijos barjerą. Tačiau šis barjeras gali būti apeinamas, kai aktyvuojamas „direct request“ kelias, tiesiog pridėjus užklausos parametrus origin=mo ir type su bet kokia reikšme (pvz., origin=mo&type=xxx). Tada užklausa traktuojama kaip „Modular direct request“ ir praeina pro middleware’ą.

Kokie endpoint’ai atsiduria rizikoje

Apeinus autentifikaciją, atsiveria keli maršrutai, kurie pagal Patchstack leidžia atlikti veiksmus nuo nuotolinio prisijungimo iki jautrios informacijos gavimo. Minimi šie keliai: /login/, /server-information/, /manager/, /backup/.

Kritiškiausias scenarijus – pasinaudoti /api/modular-connector/login/{modular_request} (praktikoje atakose fiksuotas GET į /api/modular-connector/login/) ir gauti administratoriaus prieigą. Turint admin teises, toliau jau klasika: įdiegiami kenkėjiški papildiniai, įterpiamas kodas, sukuriami nauji vartotojai, daromi peradresavimai į sukčiavimo puslapius ir pan.

Kas žinoma apie realias atakas

Patchstack teigimu, išnaudojimas „laukinėje gamtoje“ (in the wild) pirmą kartą pastebėtas 2026-01-13 apie 02:00 UTC. Tipinis srautas: HTTP GET į "/api/modular-connector/login/", po kurio seka bandymai sukurti administratoriaus vartotoją.

Taip pat publikuoti du IP adresai, iš kurių, kaip nurodoma, kilo srautas:

• 45.11.89[.]19
• 185.196.0[.]11

Ką daryti dabar: prioritetai WordPress administratoriui

Jei prižiūri svetaines (agentūroje ar in-house), čia svarbu veikti kaip incidento metu: pirmiausia sumažinti riziką (patch), tada patikrinti kompromitacijos požymius, ir tik tada „švarinti“.

1) Atnaujink Modular DS iki pataisytos versijos

Pagal pranešimą, spraga pataisyta 2.5.2 versijoje. Jei Modular DS naudojamas bent vienoje tavo prižiūrimoje instaliacijoje, atnaujinimas turėtų būti laikomas skubiu. Oficiali informacija apie pataisymą: Modular DS security release – Modular Connector 2.5.2.

2) Patikrink, ar neatsirado netikėtų admin vartotojų

Kadangi fiksuota taktika – bandymai sukurti admin vartotoją, greita peržiūra per Users → All Users dažnai duoda atsakymą per minutę. Ieškok:

• naujų vartotojų, kurių niekas iš komandos neprisimena
• admin teisių priskyrimų redaktoriams ar servisiniams vartotojams
• keistų el. paštų domenų, atsitiktinių vardų (pvz., „wpadmin2“, „support_…“)

3) Peržvelk prieigos žurnalus (access logs) dėl /api/modular-connector/ užklausų

Jei turi Nginx/Apache access log’us ar WAF įrašus, filtruok pagal kelią. Tikslo pavyzdys – pamatyti bandymus į login endpoint’ą ir užklausas su origin=mo.

# Surasti Modular DS connector užklausas
grep -R "/api/modular-connector/" /var/log/nginx/access.log*

# Fokusas į login maršrutą
grep -R "/api/modular-connector/login/" /var/log/nginx/access.log*

# Užklausos su direct request parametrais
grep -R "origin=mo" /var/log/nginx/access.log*

# Surasti Modular DS connector užklausas
grep -R "/api/modular-connector/" /var/log/nginx/access.log*

# Fokusas į login maršrutą
grep -R "/api/modular-connector/login/" /var/log/nginx/access.log*

# Užklausos su direct request parametrais
grep -R "origin=mo" /var/log/nginx/access.log*

4) Jei įtari kompromitaciją – atnaujink raktus ir išvalyk sesijas

Modular DS rekomenduoja kelis standartinius incidento atsako veiksmus, kurie realiai padeda „išmušti“ aktyvias sesijas ir atnaujinti integracijų paslaptis:

• pergeneruoti WordPress salts (tam, kad būtų invalidintos esamos sesijos)
• pergeneruoti OAuth credentials (jei naudota OAuth integracija)
• nuskenuoti svetainę dėl kenkėjiškų papildinių, failų ar įterpto kodo

Pamoka kūrėjams: „vidiniai“ keliai internete nėra vidiniai

Šita istorija gerai primena vieną taisyklę, kuri aktuali ne tik WordPress papildiniams. Jei endpoint’as pasiekiamas iš viešo interneto, jis turi būti apsaugotas taip, lyg būtų viešas nuo pirmos dienos. „Direct request“ režimai, URL-based route matching ir autentifikacija, paremta tik „sujungta/ne sujungta“ būsena, yra klasikiniai pavyzdžiai, kaip atsiranda implicit trust.

Papildinio kūrėjai nurodė, kad pažeidžiamumas buvo jų custom routing sluoksnyje, kuris plečia Laravel maršrutizavimo (route matching) funkcionalumą, ir kad logika buvo per daug leidžianti – sukonstruotos užklausos galėjo atitikti saugomus endpoint’us be tinkamos autentifikacijos validacijos.

Santrauka

1. Modular DS (iki 2.5.1) turi kritinę spragą CVE-2026-23550, leidžiančią be autentifikacijos gauti admin teises.
2. Spraga siejama su maršrutizavimo ir „direct request“ režimo apeinimu per origin=mo ir type=... parametrus.
3. Atakos jau fiksuotos: GET į /api/modular-connector/login/ ir bandymai kurti admin vartotojus.
4. Pagrindinis veiksmas – atnaujinti iki 2.5.2 ir patikrinti kompromitacijos požymius (vartotojai, log’ai, failai), esant įtarimui – regeneruoti salts ir OAuth kredencialus.