{"id":116,"date":"2026-01-19T15:49:46","date_gmt":"2026-01-19T14:49:46","guid":{"rendered":"https:\/\/helloblog.io\/pt\/falha-critica-plugin-modular-ds-wordpress-explorada-acesso-admin\/"},"modified":"2026-01-20T06:32:52","modified_gmt":"2026-01-20T05:32:52","slug":"falha-critica-plugin-modular-ds-wordpress-explorada-acesso-admin","status":"publish","type":"post","link":"https:\/\/helloblog.io\/pt\/falha-critica-plugin-modular-ds-wordpress-explorada-acesso-admin\/","title":{"rendered":"Falha cr\u00edtica no plugin Modular DS para WordPress est\u00e1 a ser explorada para obter acesso de administrador"},"content":{"rendered":"\n<p>Quem gere sites WordPress j\u00e1 conhece o padr\u00e3o: uma falha cr\u00edtica num plugin popular aparece e, quando damos por isso, j\u00e1 h\u00e1 tr\u00e1fego automatizado a varrer endpoints p\u00fablicos \u00e0 procura de instala\u00e7\u00f5es vulner\u00e1veis. Foi exatamente esse o alerta lan\u00e7ado para o plugin <strong>Modular DS<\/strong>, que tem mais de <strong>40.000 instala\u00e7\u00f5es ativas<\/strong> e agora est\u00e1 no centro de uma explora\u00e7\u00e3o ativa para ganhar <strong>acesso de administrador<\/strong>.<\/p>\n\n\n\n<p>A vulnerabilidade foi catalogada como <strong>CVE-2026-23550<\/strong> com <strong>CVSS 10.0<\/strong> e afeta <strong>todas as vers\u00f5es at\u00e9 2.5.1 (inclusive)<\/strong>. A corre\u00e7\u00e3o foi disponibilizada na <strong>vers\u00e3o 2.5.2<\/strong>, segundo a documenta\u00e7\u00e3o oficial do fornecedor.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">O que est\u00e1 a acontecer (em termos pr\u00e1ticos)<\/h2>\n\n\n\n<p>O problema \u00e9 uma <strong>escalada de privil\u00e9gios sem autentica\u00e7\u00e3o<\/strong> (unauthenticated privilege escalation). Na pr\u00e1tica, um atacante n\u00e3o autenticado consegue contornar a camada de autentica\u00e7\u00e3o de rotas expostas pelo plugin e, a partir da\u00ed, acionar um fluxo que pode resultar em login remoto com permiss\u00f5es elevadas \u2014 incluindo <strong>admin<\/strong>.<\/p>\n\n\n\n<p>O Modular DS exp\u00f5e endpoints sob o prefixo <code>\"\/api\/modular-connector\/\"<\/code>. A inten\u00e7\u00e3o do plugin \u00e9 proteger rotas sens\u00edveis atr\u00e1s de uma barreira de autentica\u00e7\u00e3o (middleware). O que falhou aqui foi o desenho do mecanismo de routing (roteamento) e a forma como certas requests s\u00e3o classificadas como &#8220;diretas&#8221;.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">A raiz t\u00e9cnica: routing permissivo e \u201cdirect request mode\u201d<\/h2>\n\n\n\n<p>Segundo a Patchstack, a explora\u00e7\u00e3o depende de uma combina\u00e7\u00e3o de decis\u00f5es de implementa\u00e7\u00e3o \u2014 n\u00e3o de um \u00fanico bug isolado. O ponto central \u00e9 que, quando o modo de &#8220;direct request&#8221; est\u00e1 ativo, \u00e9 poss\u00edvel <strong>bypassar a autentica\u00e7\u00e3o<\/strong> atrav\u00e9s de par\u00e2metros na query string.<\/p>\n\n\n\n<p>O bypass acontece ao enviar uma request com <code>origin=mo<\/code> e <code>type<\/code> definido para qualquer valor (por exemplo, <code>origin=mo&type=xxx<\/code>). Isso faz com que a request seja tratada como se fosse um pedido direto do ecossistema Modular, mesmo vindo da internet p\u00fablica.<\/p>\n\n\n\n<div class=\"wp-block-group callout callout-warning is-style-warning is-layout-flow wp-block-group-is-layout-flow\" style=\"border-width:1px;border-radius:8px;padding-top:1rem;padding-right:1.5rem;padding-bottom:1rem;padding-left:1.5rem\">\n\n<h4 class=\"wp-block-heading callout-title\">Porque isto \u00e9 perigoso<\/h4>\n\n\n<p>O bypass n\u00e3o cria uma liga\u00e7\u00e3o criptogr\u00e1fica (ou outra verifica\u00e7\u00e3o forte) entre a request recebida e a plataforma Modular. Assim que o site j\u00e1 estiver ligado ao Modular (tokens presentes\/renov\u00e1veis), a prote\u00e7\u00e3o pode ser contornada e rotas sens\u00edveis ficam expostas.<\/p>\n\n<\/div>\n\n\n\n<h2 class=\"wp-block-heading\">Que rotas podem ficar expostas<\/h2>\n\n\n\n<p>Com a autentica\u00e7\u00e3o contornada, um atacante pode alcan\u00e7ar rotas que permitem desde a\u00e7\u00f5es de login remoto at\u00e9 recolha de informa\u00e7\u00e3o sens\u00edvel. A Patchstack cita, entre outras, as rotas:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n\n<li><code>\/login\/<\/code><\/li>\n\n\n<li><code>\/server-information\/<\/code><\/li>\n\n\n<li><code>\/manager\/<\/code><\/li>\n\n\n<li><code>\/backup\/<\/code><\/li>\n\n<\/ul>\n\n\n\n<p>O cen\u00e1rio mais grave descrito \u00e9 a explora\u00e7\u00e3o do endpoint <code>\"\/login\/{modular_request}\"<\/code>, que pode resultar em <strong>acesso com privil\u00e9gios de administrador<\/strong> (privilege escalation). A partir da\u00ed, o risco passa a ser o de compromisso total do site: altera\u00e7\u00f5es maliciosas, instala\u00e7\u00e3o de malware, cria\u00e7\u00e3o de utilizadores admin, ou redirecionamentos para esquemas.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Sinais de explora\u00e7\u00e3o j\u00e1 observados<\/h2>\n\n\n\n<p>A Patchstack refere que a explora\u00e7\u00e3o ativa ter\u00e1 sido detetada pela primeira vez a <strong>13 de janeiro de 2026<\/strong>, por volta das <strong>02:00 UTC<\/strong>, com chamadas HTTP GET ao endpoint <code>\"\/api\/modular-connector\/login\/\"<\/code> seguidas de tentativas de <strong>cria\u00e7\u00e3o de um utilizador admin<\/strong>.<\/p>\n\n\n\n<p>Foram tamb\u00e9m partilhados IPs associados aos ataques observados:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n\n<li>45.11.89[.]19 \u2014 relat\u00f3rio no VirusTotal: https:\/\/www.virustotal.com\/gui\/ip-address\/45.11.89.19<\/li>\n\n\n<li>185.196.0[.]11 \u2014 relat\u00f3rio no VirusTotal: https:\/\/www.virustotal.com\/gui\/ip-address\/185.196.0.11<\/li>\n\n<\/ul>\n\n\n\n<div class=\"wp-block-group callout callout-info is-style-info is-layout-flow wp-block-group-is-layout-flow\" style=\"border-width:1px;border-radius:8px;padding-top:1rem;padding-right:1.5rem;padding-bottom:1rem;padding-left:1.5rem\">\n\n<h4 class=\"wp-block-heading callout-title\">Nota sobre indicadores (IOCs)<\/h4>\n\n\n<p>Um IP, por si s\u00f3, n\u00e3o \u00e9 prova definitiva (pode mudar, pode haver proxies), mas \u00e9 um bom ponto de partida para pesquisa em logs de acesso e WAF.<\/p>\n\n<\/div>\n\n\n\n<h2 class=\"wp-block-heading\">Mitiga\u00e7\u00e3o imediata: atualizar para 2.5.2<\/h2>\n\n\n\n<p>A a\u00e7\u00e3o mais importante \u00e9 simples: <strong>atualizar o Modular DS para a vers\u00e3o 2.5.2<\/strong> (ou superior, se j\u00e1 existir) o mais r\u00e1pido poss\u00edvel. A nota de seguran\u00e7a do fornecedor est\u00e1 aqui: <a href=\"https:\/\/help.modulards.com\/en\/article\/modular-ds-security-release-modular-connector-252-dm3mv0\/\">Modular DS security release (Modular Connector 2.5.2)<\/a>.<\/p>\n\n\n\n<p>Como a explora\u00e7\u00e3o \u00e9 ativa, tratar isto como &#8220;vamos ver depois&#8221; \u00e9 uma aposta arriscada \u2014 especialmente em sites que j\u00e1 estejam ligados ao Modular e expostos diretamente \u00e0 internet sem camadas adicionais (WAF, rate limiting, regras espec\u00edficas de firewall).<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Se suspeitas de compromisso: checklist de resposta<\/h2>\n\n\n\n<p>O pr\u00f3prio fornecedor recomenda uma revis\u00e3o do site \u00e0 procura de sinais de intrus\u00e3o (por exemplo, utilizadores admin inesperados ou requests suspeitas vindas de scanners). Se houver ind\u00edcios, os passos sugeridos incluem:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n\n<li>Regenerar os <strong>WordPress salts<\/strong> para invalidar sess\u00f5es existentes (for\u00e7a logout global).<\/li>\n\n\n<li>Regenerar credenciais <strong>OAuth<\/strong> associadas.<\/li>\n\n\n<li>Fazer scan ao site \u00e0 procura de plugins maliciosos, ficheiros alterados ou c\u00f3digo injetado.<\/li>\n\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">Uma li\u00e7\u00e3o de arquitetura para plugins com APIs p\u00fablicas<\/h2>\n\n\n\n<p>Os mantenedores referem que a falha estava numa camada de routing personalizada que estende o matching de rotas do <strong>Laravel<\/strong>. A partir do relato, o problema n\u00e3o foi apenas um <code>if<\/code> mal colocado: foi um conjunto de escolhas (matching por URL, modo permissivo de &#8220;direct request&#8221;, autentica\u00e7\u00e3o baseada no estado de liga\u00e7\u00e3o do site e um fluxo de login com fallback autom\u00e1tico para admin) que, em conjunto, abriu a porta.<\/p>\n\n\n\n<p>Para quem desenvolve integra\u00e7\u00f5es no ecossistema WordPress, fica o alerta: confiar em &#8220;paths internos&#8221; quando eles est\u00e3o expostos na internet p\u00fablica \u00e9 pedir problemas. Se existe um endpoint p\u00fablico, ele tem de ter valida\u00e7\u00e3o forte e expl\u00edcita \u2014 e, idealmente, n\u00e3o depender apenas de estado (ex.: &#8220;est\u00e1 ligado&#8221;) como fator de autentica\u00e7\u00e3o.<\/p>\n\n\n<div class=\"references-section\">\n                <h2>Refer\u00eancias \/ Fontes<\/h2>\n                <ul class=\"references-list\"><li><a href=\"https:\/\/thehackernews.com\/2026\/01\/critical-wordpress-modular-ds-plugin.html\" target=\"_blank\" rel=\"noopener noreferrer\">Critical WordPress Modular DS Plugin Flaw Actively Exploited to Gain Admin Access<\/a><\/li><li><a href=\"https:\/\/patchstack.com\/articles\/critical-privilege-escalation-vulnerability-in-modular-ds-plugin-affecting-40k-sites-exploited-in-the-wild\/\" target=\"_blank\" rel=\"noopener noreferrer\">Critical Privilege Escalation Vulnerability in Modular DS Plugin Affecting 40k Sites (Exploited in the Wild)<\/a><\/li><li><a href=\"https:\/\/help.modulards.com\/en\/article\/modular-ds-security-release-modular-connector-252-dm3mv0\/\" target=\"_blank\" rel=\"noopener noreferrer\">Modular DS security release (Modular Connector 2.5.2)<\/a><\/li><\/ul>\n            <\/div>","protected":false},"excerpt":{"rendered":"<p>Se tens o Modular DS instalado, h\u00e1 um cen\u00e1rio real de tomada de controlo do site: uma vulnerabilidade com CVSS 10.0 est\u00e1 a ser explorada para escalar privil\u00e9gios e entrar como admin sem autentica\u00e7\u00e3o.<\/p>\n","protected":false},"author":28,"featured_media":115,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[9],"tags":[53,12,11,52,10],"class_list":["post-116","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-seguranca","tag-patch-management","tag-plugins","tag-seguranca","tag-vulnerabilidades","tag-wordpress"],"_links":{"self":[{"href":"https:\/\/helloblog.io\/pt\/wp-json\/wp\/v2\/posts\/116","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/helloblog.io\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/helloblog.io\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/helloblog.io\/pt\/wp-json\/wp\/v2\/users\/28"}],"replies":[{"embeddable":true,"href":"https:\/\/helloblog.io\/pt\/wp-json\/wp\/v2\/comments?post=116"}],"version-history":[{"count":1,"href":"https:\/\/helloblog.io\/pt\/wp-json\/wp\/v2\/posts\/116\/revisions"}],"predecessor-version":[{"id":155,"href":"https:\/\/helloblog.io\/pt\/wp-json\/wp\/v2\/posts\/116\/revisions\/155"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/helloblog.io\/pt\/wp-json\/wp\/v2\/media\/115"}],"wp:attachment":[{"href":"https:\/\/helloblog.io\/pt\/wp-json\/wp\/v2\/media?parent=116"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/helloblog.io\/pt\/wp-json\/wp\/v2\/categories?post=116"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/helloblog.io\/pt\/wp-json\/wp\/v2\/tags?post=116"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}