Kritisk sårbarhed i WordPress-plugin’et Modular DS udnyttes aktivt: sådan reducerer du risikoen nu

Der er kommet en alvorlig sag på WordPress-banen: plugin’et Modular DS er ramt af en sårbarhed med maksimal CVSS-score (10.0), og den bliver ifølge Patchstack udnyttet aktivt i naturen. Sårbarheden gør det muligt for en angriber uden autentificering at eskalere privilegier og opnå administratoradgang, hvilket i værste fald ender i fuld kompromittering af sitet.

I det her indlæg får du et teknisk overblik over, hvad der går galt, hvem der er ramt, og hvilke konkrete skridt der giver mest effekt her og nu: opdatering, log-tjek og oprydning, hvis der allerede er tegn på indbrud.

Hvad er det for en sårbarhed?

Sårbarheden er registreret som CVE-2026-23550 og beskrives som en unauthenticated privilege escalation – altså at en angriber kan få højere rettigheder (helt op til admin) uden at være logget ind. Patchstack angiver, at alle versioner til og med 2.5.1 er påvirket, og at problemet er rettet i 2.5.2.

Modular DS har ifølge kilden mere end 40.000 aktive installationer, så det er præcis den type issue, der hurtigt bliver et mål for automatiserede scans og masseudnyttelse.

Den tekniske kerne: routing + “direct request” + implicit tillid

Ifølge Patchstack ligger roden i plugin’ets routing-lag (routing = mekanismen der matcher URL’er/paths til konkrete handlers). Plugin’et eksponerer sine ruter under præfikset "/api/modular-connector/" og har designet en barriere, der skulle beskytte følsomme endpoints bag autentificering.

Problemet opstår, når plugin’et ender i en tilstand, hvor “direct request”-mode kan trigges via parametre i URL’en. Patchstack beskriver, at sikkerhedslaget kan omgås ved at sende en request med en origin-parameter sat til mo og en type-parameter sat til en vilkårlig værdi (fx origin=mo&type=xxx). Det får requesten til at blive behandlet som en Modular “direct request”.

Patchstack peger på, at flere designvalg tilsammen gør udfaldet kritisk: URL-baseret route matching, en for permissiv direct-request-tilstand, autentificering der kun afhænger af “connection state”, og et login-flow der kan falde tilbage til en administrator-konto.

Hvilke endpoints eksponeres – og hvad kan angriberen gøre?

Når auth-laget kan omgås, bliver flere følsomme ruter tilgængelige. Patchstack nævner bl.a. "/login/", "/server-information/", "/manager/" og "/backup/". Konsekvensen spænder fra fjern-login til udlæsning af system- eller brugerdata.

Den mest alvorlige del er, at en angriber kan udnytte ruten "/login/{modular_request}" til at få administratoradgang, hvilket åbner for klassiske efterfølgende angreb: ændringer i tema/plugins, indsprøjtning af malware, oprettelse af nye admin-brugere eller redirects til scam-sider.

Aktiv udnyttelse: hvad ved vi?

Patchstack rapporterer, at udnyttelse blev observeret fra 13. januar 2026 omkring kl. 02:00 UTC, hvor angribere lavede HTTP GET-kald mod endpointet "/api/modular-connector/login/" og derefter forsøgte at oprette en admin-bruger.

De observerede angreb kom ifølge Patchstack fra bl.a. disse IP-adresser:

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

Akut: sådan handler du, hvis du har Modular DS installeret

Hvis Modular DS er i brug på et site, er den vigtigste prioritet at fjerne angrebsfladen ved at opdatere. Derefter handler det om at afgøre, om der allerede er sket kompromittering.

1) Opdater til den rettede version

Opdater Modular DS til version 2.5.2, som ifølge udgivelsesnoten indeholder sikkerhedsrettelsen.

Udgivelsesinfo: https://help.modulards.com/en/article/modular-ds-security-release-modular-connector-252-dm3mv0/

2) Kig efter tegn på kompromittering

Modular DS anbefaler at gennemgå sitet for indikatorer som uventede admin-brugere eller mistænkelige requests fra automatiserede scannere. Det matcher også Patchstacks observation af login-endpointet efterfulgt af admin-oprettelse.

• Gennemgå listen over brugere med administratorrolle for nyligt oprettede eller ukendte konti.
• Tjek webserver-logs (access logs) for kald til "/api/modular-connector/login/" og relaterede ruter under "/api/modular-connector/".
• Se efter mønstre med query-parametre der inkluderer origin=mo samt en vilkårlig type-værdi.
• Kig efter ændringer i plugins/temaer og uventede filer eller kodefragmenter.

3) Hvis du finder noget: invalider sessions og roter credentials

Hvis du ser tegn på kompromittering, peger Modular DS på tre konkrete oprydningsskridt:

1. Regenerér WordPress salts for at invalidere eksisterende sessions.
2. Regenerér OAuth credentials.
3. Scan sitet for malicious plugins, filer eller kode.

Hvad kan vi lære af det her (som udviklere)?

Patchstack formulerer en pointe, der er værd at tage med videre i egen plugin-/app-udvikling: implicit tillid til “interne” request paths er farlig, når de reelt ligger på det offentlige internet. Når routing, feature flags (som “direct request”), og autentificering bliver koblet til tilstand (fx “site er connected”) fremfor en stærk, kryptografisk verificering af afsenderen, kan små designbeslutninger pludselig give en straight line til admin.

Plugin-maintainerne beskriver, at sårbarheden blev fundet i et custom routing-lag, der udvider Laravels route matching. Ifølge dem var match-logikken for permissiv, så crafted requests kunne matche beskyttede endpoints uden korrekt validering af autentificering.

Kort opsummering

• CVE-2026-23550 rammer Modular DS ≤ 2.5.1 og udnyttes aktivt.
• Angrebet kan give admin-adgang uden login via routing/auth-bypass i "/api/modular-connector/".
• Opdater til 2.5.2 med det samme.
• Tjek logs og admin-brugere; ved fund: regenerér salts, roter OAuth credentials og scan efter ondsindet kode.