Estão em curso tentativas de exploração contra duas falhas críticas de contorno de autenticação no plugin miniOrange SAML 2.0 Single Sign On para WordPress, que permitem a um atacante sem credenciais forjar uma resposta SAML e entrar no site como qualquer utilizador existente, incluindo administradores. As vulnerabilidades, identificadas como CVE-2026-61979 e CVE-2026-15981, foram descritas pela Patchstack como dois contornos de autenticação não autenticados que tornavam possível iniciar sessão como qualquer utilizador WordPress, incluindo administradores, e há já tentativas de exploração observadas na Internet. O caso ganha contornos invulgares porque o problema não está apenas no código: está também na forma como o fabricante distribui o produto, que deixou milhares de instalações pagas sem qualquer aviso de atualização.
Resposta rápida: Duas falhas no plugin miniOrange SAML 2.0 Single Sign On para WordPress (CVE-2026-61979 e CVE-2026-15981) permitem forjar assinaturas SAML e obter acesso de administrador sem autenticação prévia. O plugin é distribuído em sete edições com numerações diferentes sob o mesmo identificador, pelo que muitos sites com edições pagas nunca viram um aviso de atualização no painel. Confirme a edição e a versão instalada, aplique manualmente a correção correspondente, invalide as sessões ativas e reveja os registos de autenticação SAML.
Um plugin que transforma o WordPress em porta de entrada corporativa
O plugin em causa é usado para integrar sites WordPress com fornecedores de identidade empresariais. Segundo a BleepingComputer, o miniOrange SAML SSO transforma um site WordPress num service provider SAML, permitindo autenticação através de plataformas como Microsoft Entra ID, Okta, Google Workspace ou OneLogin em vez de credenciais WordPress próprias; criado pela Xecurify, o miniOrange é uma família de sete plugins, com a versão gratuita a somar 10 000 descarregamentos e cerca de 30 000 clientes nas restantes seis. Por outras palavras, falamos de instalações tipicamente empresariais, com intranets, portais de clientes e áreas reservadas ligadas ao diretório de identidade da organização.
Como funciona o encadeamento das duas falhas
A primeira vulnerabilidade é um caso clássico de confusão de algoritmo de assinatura. O plugin permitia que a resposta SAML recebida escolhesse o próprio método de assinatura, incluindo HMAC-SHA1, passando depois a tratar a chave pública RSA do fornecedor de identidade como segredo partilhado do HMAC; como essa chave pública é, por definição, pública, um atacante podia gerar uma asserção forjada que o plugin aceitava como legítima. A chave pode ser obtida a partir do endpoint de metadados do fornecedor de identidade.
A segunda falha é um erro de programação com consequências severas. A função openssl_verify() devolve 1 para assinatura válida, 0 para inválida e -1 em caso de erro do OpenSSL; como o plugin fazia uma verificação booleana permissiva, o PHP interpretava o -1 como verdadeiro, permitindo que assinaturas malformadas que provocassem um erro passassem na validação. De acordo com a descrição divulgada, o problema reside na função mo_saml_validate_signature(), que avalia de forma permissiva o inteiro de três estados devolvido pelo openssl_verify() do PHP. Encadeadas, as duas fraquezas permitem obter um cookie de sessão de administrador.
| Identificador | Natureza | Correção (edição Standard) |
|---|---|---|
CVE-2026-61979 | Escalada de privilégios não autenticada por confusão de algoritmo de assinatura | 17.0.5 |
CVE-2026-15981 | Contorno de autenticação por aceitação de assinaturas malformadas | 17.0.6 |
Segundo a divulgação da Patchstack, a CVE-2026-61979 recebeu pontuação CVSS 8.1 e a CVE-2026-15981 pontuação 9.8, corrigidas, respetivamente, nas versões 17.0.5 e 17.0.6 da edição Standard. Note-se que parte da cobertura noticiosa atribui a pontuação 9.8 a ambas as falhas, pelo que convém confirmar sempre os valores na base de dados de vulnerabilidades de referência antes de os usar em relatórios internos.
Um identificador, sete edições: porque é que muitos sites nunca souberam
O aspeto mais relevante deste caso não é técnico, é de gestão de divulgação. A Patchstack explica que o plugin é distribuído sob um único identificador no WordPress.org, mas essa listagem contém sete planos de produto com numerações independentes; os avisos públicos de segurança cobriram apenas a edição gratuita, e as seis edições pagas foram corrigidas sem registo de alterações público nem aviso, pelo que nenhuma base de dados de vulnerabilidades as listou e sites vulneráveis eram incorretamente reportados como não afetados — uma versão 16.x vulnerável não recebe sequer notificação de atualização, obrigando ao carregamento manual da correção.
A edição gratuita foi corrigida na versão 5.4.5, enquanto as edições pagas seguem intervalos de versões completamente distintos — incluindo ramos 13.x, 16.x, 20.x, 26.x, 32.x e 35.x — o que levou bases de dados e scanners convencionais a classificar instalações vulneráveis como já corrigidas; uma instalação Standard na versão 16.1.9, por exemplo, podia parecer não afetada quando comparada apenas com o número da correção da edição gratuita. Recorde-se ainda que um aviso anterior relativo ao mesmo slug, a CVE-2026-15013, afetava todas as versões até à 5.4.3 inclusive e tinha na origem a mesma confusão de algoritmo de assinatura na função Mo_SAML_Utilities::mo_saml_cast_key().
Cronologia conhecida
| Data | Acontecimento |
|---|---|
| Julho de 2026 | Divulgação pública e correção das falhas, com aviso limitado à edição gratuita |
| 16 de agosto de 2026 | A DigitalOcean deteta e bloqueia uma tentativa de sessão de administrador WordPress vinda de fora da sua rede de confiança |
| 17 de agosto de 2026 | A DigitalOcean reporta o problema e partilha uma reprodução funcional contra a edição Standard 16.1.9 |
| Agosto de 2026 | Publicação da análise conjunta, alargamento da cobertura na base de dados de vulnerabilidades e registo de rastreio ativo |
A Patchstack indica que as duas vulnerabilidades foram divulgadas publicamente e corrigidas em julho, mas o aviso do fabricante cobriu apenas a edição gratuita, deixando as seis edições pagas sem alerta, apesar de terem recebido correções. A cronologia publicada situa a 16 de agosto de 2026 a deteção e bloqueio pela DigitalOcean de uma tentativa de sessão de administrador aparentemente vinda de fora da rede de confiança, e a 17 de agosto a partilha de uma reprodução funcional contra a edição Standard 16.1.9, tendo sido identificado que as edições com versões independentes sob um único slug explicam a ausência de cobertura nas bases de dados.
O que os defensores estão a observar
Segundo a Patchstack, o atacante já tinha usado o contorno para obter um cookie de sessão de administrador, mas ficou bloqueado porque as operações do painel de administração estavam restringidas atrás da rede de confiança. Esta segmentação foi, na prática, o controlo que impediu o comprometimento — um bom argumento a favor da defesa em profundidade. A Patchstack registou atividade de rastreio a partir de vários endereços IP e considera que “a dispersão sugere um rastreio oportunista em vez de uma campanha direcionada”, acrescentando que quem está por trás desta atividade parece atirar o exploit a todos os sites com o plugin instalado, sem verificar edição ou versão; a existência de código de prova de conceito aumenta a urgência de aplicar as correções. De acordo com a análise divulgada, o rastreio observado partiu de infraestrutura localizada na Bélgica, Nigéria, Alemanha e Estados Unidos. A lista completa de indicadores de comprometimento e de endereços de rastreio foi publicada pelos investigadores para uso das equipas de deteção.
Passos concretos de mitigação
- Identifique a edição (gratuita, Standard, Premium, VIP, etc.) e a versão exata instalada — não confie apenas na ausência de notificação no painel do WordPress.
- Atualize manualmente para a versão corrigida correspondente à sua edição; em alguns casos é necessário carregar o ficheiro do plugin à mão, porque o mecanismo habitual não oferece o salto entre ramos de versão.
- Se não conseguir corrigir de imediato, restrinja o acesso a
/wp-admin, reveja os registos de SAML e de autenticação e investigue sessões de administrador com origem em endereços IP inesperados. - Considere uma regra de firewall aplicacional que bloqueie pedidos ao endpoint ACS cujo método de assinatura seja baseado em HMAC, exija autenticação multifator nas contas de administrador e mantenha temporariamente os utilizadores privilegiados em autenticação nativa do WordPress enquanto o plugin estiver desativado.
- Invalide todas as sessões ativas, rode chaves e salts, e audite a lista de administradores, plugins instalados, tarefas agendadas e ficheiros modificados recentemente. Mesmo depois de aplicadas as correções, os sistemas continuam expostos se sessões e credenciais antigas não forem revistas.
Porque é que isto importa em Portugal
Muitas organizações portuguesas usam WordPress para portais institucionais, áreas de clientes e intranets ligadas ao diretório corporativo. Um contorno de autenticação SSO não é um problema apenas do site: dá acesso privilegiado a um sistema que frequentemente contém dados pessoais de clientes, colaboradores ou utentes. Nesse cenário, aplica-se o dever de notificação de violações de dados pessoais à CNPD previsto no RGPD, com o prazo de 72 horas a contar do conhecimento do incidente, e a eventual comunicação aos titulares quando o risco for elevado.
Para as entidades abrangidas pelo Regime Jurídico da Cibersegurança, que transpõe a diretiva NIS2, o caso toca em três obrigações estruturais: gestão de vulnerabilidades e de atualizações, segurança da cadeia de fornecimento (aqui, um componente de terceiros cujo processo de divulgação falhou) e notificação de incidentes significativos ao CNCS/CERT.PT. A lição prática é direta: um inventário de software que registe apenas o nome do plugin, sem edição e versão exata, pode dar uma falsa sensação de conformidade. Para PME sem equipa própria, vale a pena pedir ao fornecedor de alojamento ou à agência responsável uma confirmação escrita da edição instalada e da correção aplicada, além de ativar a monitorização de alterações a contas privilegiadas.
Perguntas frequentes
Como sei se o meu site está vulnerável?
Verifique se tem o plugin miniOrange SAML 2.0 Single Sign On ativo e confirme a edição e o número de versão exato no ficheiro do plugin ou junto do fabricante. A Patchstack alerta que não deve confiar apenas no painel do WordPress, uma vez que instalações Standard 16.x vulneráveis podem não receber qualquer aviso automático da versão corrigida 17.x, exigindo carregamento manual.
Quais são as versões corrigidas?
A edição gratuita foi corrigida na versão 5.4.5 e a edição Standard recebeu a correção da CVE-2026-61979 na versão 17.0.5, com a versão 17.0.6 a resolver a CVE-2026-15981. As restantes edições pagas seguem numerações próprias, pelo que deve confirmar a versão corrigida específica da sua edição junto do fabricante.
Houve ataques bem-sucedidos?
A Patchstack refere que houve tentativas de exploração e que os controlos de defesa em profundidade da DigitalOcean detetaram e bloquearam a atividade na sua infraestrutura, tendo os indicadores identificados sido partilhados para reforçar a deteção em todo o ecossistema. Não há, até ao momento, confirmação pública de comprometimentos consumados noutras organizações.
Devo notificar o incidente se detetar exploração?
Se houver indícios de acesso não autorizado a dados pessoais, aplica-se o dever de notificação à CNPD no prazo de 72 horas. Entidades abrangidas pelo Regime Jurídico da Cibersegurança devem ainda avaliar a obrigação de reportar incidentes significativos ao CNCS/CERT.PT, mantendo registos e evidências para a investigação.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Patchstack, pela equipa de segurança da DigitalOcean e em bases de dados públicas de vulnerabilidades.