Falha crítica no plugin Modular DS para WordPress está a ser explorada para obter acesso de administrador

Quem gere sites WordPress já conhece o padrão: uma falha crítica num plugin popular aparece e, quando damos por isso, já há tráfego automatizado a varrer endpoints públicos à procura de instalações vulneráveis. Foi exatamente esse o alerta lançado para o plugin Modular DS, que tem mais de 40.000 instalações ativas e agora está no centro de uma exploração ativa para ganhar acesso de administrador.

A vulnerabilidade foi catalogada como CVE-2026-23550 com CVSS 10.0 e afeta todas as versões até 2.5.1 (inclusive). A correção foi disponibilizada na versão 2.5.2, segundo a documentação oficial do fornecedor.

O que está a acontecer (em termos práticos)

O problema é uma escalada de privilégios sem autenticação (unauthenticated privilege escalation). Na prática, um atacante não autenticado consegue contornar a camada de autenticação de rotas expostas pelo plugin e, a partir daí, acionar um fluxo que pode resultar em login remoto com permissões elevadas — incluindo admin.

O Modular DS expõe endpoints sob o prefixo "/api/modular-connector/". A intenção do plugin é proteger rotas sensíveis atrás de uma barreira de autenticação (middleware). O que falhou aqui foi o desenho do mecanismo de routing (roteamento) e a forma como certas requests são classificadas como “diretas”.

A raiz técnica: routing permissivo e “direct request mode”

Segundo a Patchstack, a exploração depende de uma combinação de decisões de implementação — não de um único bug isolado. O ponto central é que, quando o modo de “direct request” está ativo, é possível bypassar a autenticação através de parâmetros na query string.

O bypass acontece ao enviar uma request com origin=mo e type definido para qualquer valor (por exemplo, origin=mo&type=xxx). Isso faz com que a request seja tratada como se fosse um pedido direto do ecossistema Modular, mesmo vindo da internet pública.

Que rotas podem ficar expostas

Com a autenticação contornada, um atacante pode alcançar rotas que permitem desde ações de login remoto até recolha de informação sensível. A Patchstack cita, entre outras, as rotas:

• /login/
• /server-information/
• /manager/
• /backup/

O cenário mais grave descrito é a exploração do endpoint "/login/{modular_request}", que pode resultar em acesso com privilégios de administrador (privilege escalation). A partir daí, o risco passa a ser o de compromisso total do site: alterações maliciosas, instalação de malware, criação de utilizadores admin, ou redirecionamentos para esquemas.

Sinais de exploração já observados

A Patchstack refere que a exploração ativa terá sido detetada pela primeira vez a 13 de janeiro de 2026, por volta das 02:00 UTC, com chamadas HTTP GET ao endpoint "/api/modular-connector/login/" seguidas de tentativas de criação de um utilizador admin.

Foram também partilhados IPs associados aos ataques observados:

• 45.11.89[.]19 — relatório no VirusTotal: https://www.virustotal.com/gui/ip-address/45.11.89.19
• 185.196.0[.]11 — relatório no VirusTotal: https://www.virustotal.com/gui/ip-address/185.196.0.11

Mitigação imediata: atualizar para 2.5.2

A ação mais importante é simples: atualizar o Modular DS para a versão 2.5.2 (ou superior, se já existir) o mais rápido possível. A nota de segurança do fornecedor está aqui: Modular DS security release (Modular Connector 2.5.2).

Como a exploração é ativa, tratar isto como “vamos ver depois” é uma aposta arriscada — especialmente em sites que já estejam ligados ao Modular e expostos diretamente à internet sem camadas adicionais (WAF, rate limiting, regras específicas de firewall).

Se suspeitas de compromisso: checklist de resposta

O próprio fornecedor recomenda uma revisão do site à procura de sinais de intrusão (por exemplo, utilizadores admin inesperados ou requests suspeitas vindas de scanners). Se houver indícios, os passos sugeridos incluem:

1. Regenerar os WordPress salts para invalidar sessões existentes (força logout global).
2. Regenerar credenciais OAuth associadas.
3. Fazer scan ao site à procura de plugins maliciosos, ficheiros alterados ou código injetado.

Uma lição de arquitetura para plugins com APIs públicas

Os mantenedores referem que a falha estava numa camada de routing personalizada que estende o matching de rotas do Laravel. A partir do relato, o problema não foi apenas um if mal colocado: foi um conjunto de escolhas (matching por URL, modo permissivo de “direct request”, autenticação baseada no estado de ligação do site e um fluxo de login com fallback automático para admin) que, em conjunto, abriu a porta.

Para quem desenvolve integrações no ecossistema WordPress, fica o alerta: confiar em “paths internos” quando eles estão expostos na internet pública é pedir problemas. Se existe um endpoint público, ele tem de ter validação forte e explícita — e, idealmente, não depender apenas de estado (ex.: “está ligado”) como fator de autenticação.