Faille critique dans Modular DS : une escalade de privilèges WordPress exploitée pour obtenir un accès admin

Une alerte à prendre très au sérieux circule dans l’écosystème WordPress : le plugin Modular DS (plus de 40 000 installations actives) est touché par une faille d’escalade de privilèges non authentifiée qui permet, dans certaines conditions, de finir avec un accès administrateur sur le site. Patchstack indique que la vulnérabilité est activement exploitée dans la nature.

Le point clé : ce n’est pas un simple bug isolé, mais un enchaînement de choix d’architecture dans le mécanisme de routage et une logique de “direct request” trop permissive, combinés à un flux de login capable de basculer automatiquement sur un compte admin.

Ce qui est vulnérable (CVE, versions, sévérité)

La vulnérabilité est référencée CVE-2026-23550 avec un score CVSS 10.0. Elle affecte toutes les versions jusqu’à 2.5.1 inclus et a été corrigée en 2.5.2 (release de sécurité côté “Modular Connector”).

Impact concret

Un attaquant non authentifié peut obtenir un accès administrateur (privilege escalation), ce qui ouvre la porte à une compromission complète : modification de contenu, ajout de backdoors, dépôt de malware, redirections vers des pages de phishing, etc.

Origine du problème : routage et “direct request” mal verrouillés

Modular DS expose des routes sous le préfixe /api/modular-connector/. Le plugin est censé placer certaines routes sensibles derrière une barrière d’authentification (middleware). Patchstack explique néanmoins qu’il existe un scénario de contournement lorsque le mode “direct request” est activé.

Dans ce mode, il suffirait d’envoyer une requête avec des paramètres qui font passer l’appel pour une requête “directe” provenant de Modular, notamment via un couple de paramètres du type : origin=mo et type=. À partir de là, la couche de protection peut être court-circuitée.

Pourquoi c’est dangereux

Le contournement repose sur un manque de liaison cryptographique entre la requête entrante et un appel réellement émis par Modular. En clair : l’API fait confiance à des marqueurs de requête trop faciles à falsifier.

Routes exposées et actions possibles

Selon Patchstack, ce bypass ouvre l’accès à plusieurs routes, dont notamment : /login/, /server-information/, /manager/ et /backup/. Les conséquences vont de la connexion à distance à l’exposition d’informations système et de données utilisateur.

Le scénario le plus critique est l’exploitation de la route /login/{modular_request}, qui permettrait d’obtenir un accès administrateur sans authentification préalable.

Signaux d’exploitation observés

Patchstack indique que les attaques ont été détectées à partir du 13 janvier 2026 vers 02:00 UTC, avec des appels HTTP GET vers l’endpoint /api/modular-connector/login/, suivis de tentatives de création d’un utilisateur administrateur.

Deux adresses IP sont citées comme sources d’activité :

45.11.89[.]19 — https://www.virustotal.com/gui/ip-address/45.11.89.19
185.196.0[.]11 — https://www.virustotal.com/gui/ip-address/185.196.0.11

Plan d’action côté prod : corriger vite, puis vérifier

Dans ce type de faille (auth bypass + escalade de privilèges), la priorité est double : patcher immédiatement puis chercher des traces de compromission. Comme l’exploitation est active, considérer qu’un site exposé et non patché est potentiellement à risque.

1) Mettre à jour Modular DS

Mettre à jour le plugin vers la version corrigée 2.5.2 via l’annonce officielle : Modular DS security release (Modular Connector 2.5.2).

2) Chercher des signes d’intrusion

Modular DS recommande de contrôler notamment :

La présence d’utilisateurs admin inattendus (nouveaux comptes, e-mails bizarres, comptes “service”).
Des requêtes suspectes ou des scans automatisés visant /api/modular-connector/ (logs Nginx/Apache, WAF, CDN).
Des modifications récentes de plugins/thèmes/fichiers (ajouts PHP inconnus, webshells, mu-plugins non sollicités).

3) Remédiation si suspicion confirmée

Les étapes proposées côté éditeur et relayées par Patchstack sont classiques mais efficaces pour couper l’accès aux sessions et jetons déjà établis :

Régénérer les WordPress salts pour invalider les sessions actives.
Régénérer les identifiants OAuth utilisés par la connexion à Modular.
Scanner le site à la recherche de plugins/fichiers/code malveillants.

Point d’attention WordPress

La régénération des salts déconnecte tout le monde (y compris toi). Planifie l’opération et prévois un accès de secours (SSH/SFTP, accès panel d’hébergement) au cas où.

Lecture “architecture” : quand une API interne devient une surface d’attaque publique

Ce cas est un bon rappel : dès qu’un plugin expose des endpoints (ici une API sous /api/modular-connector/), une logique pensée comme “interne” doit être sécurisée comme une API publique. Patchstack insiste sur le danger de la confiance implicite dans des chemins de requêtes internes lorsqu’ils sont exposés sur Internet.

Les mainteneurs du plugin précisent que la faille se situait dans une couche de routage personnalisée étendant la logique de matching des routes de Laravel, avec un matching trop permissif permettant à des requêtes forgées d’atteindre des endpoints protégés sans validation d’authentification suffisante.

Résumé opérationnel

Si Modular DS est installé : mets à jour en 2.5.2 immédiatement.
Inspecte les logs pour des accès à /api/modular-connector/login/ et vérifie la liste des admins.
En cas de doute : régénère salts + credentials OAuth et lance un scan d’intégrité (fichiers/plugins).