Um bypass de autenticação crítico foi divulgado no plugin miniOrange OTP Login, Verification and SMS Notifications para WordPress, afetando todas as versões até a 5.5.5, inclusive. Um atacante não autenticado que conheça o nome de usuário de um administrador pode fazer login sem senha e sem OTP simplesmente enviando mo_wp_login_intent=otp na requisição. Nenhum material de credencial é verificado. A entrada do NVD para CVE-2026-85984 contém o detalhamento técnico completo.

Veja o que realmente deu errado do ponto de vista de IAM: a função mo_by_pass_login() do plugin toma um atalho quando skip_pass_fallback está habilitado. Ela resolve um objeto de usuário do WordPress puramente a partir de uma consulta por nome de usuário, em seguida verifica se esse usuário é administrador e, caso seja, ignora completamente o wp_authenticate_username_password(). O parâmetro mo_wp_login_intent que aciona esse fluxo é aceito de uma requisição POST sem assinatura, sem vínculo de sessão e sem verificação. Quem escreveu isso acreditou que "verificação de papel de administrador" era equivalente a "autenticação". Não é. O papel é um atributo de uma sessão já autenticada. Verificá-lo antes da autenticação é circular e, neste caso, catastroficamente equivocado.

As condições para exploração são específicas: um administrador do site deve ter habilitado simultaneamente WP Login OTP, Login with Only OTP, Allow Users to Login with Username and Password e Admin OTP Bypass. Essa é uma configuração que parece ter sido montada de forma incremental, opção por opção, sem que ninguém parasse para raciocinar sobre o efeito combinado. Vejo isso constantemente em ambientes corporativos de IAM também. Cada opção faz sentido isoladamente. Juntas, criam uma brecha que anula todos os controles a jusante.

A enumeração de nomes de usuário é o único pré-requisito para a exploração. Na maioria dos sites WordPress, os nomes de usuário não são difíceis de obter. Se sua organização usa WordPress com este plugin, você precisa tratar qualquer conta de administrador como potencialmente comprometida até confirmar que o plugin está atualizado e que revisou os logs de autenticação em busca de sessões administrativas anômalas.

Atualize para uma versão corrigida imediatamente. Se ainda não houver uma publicada, desabilite o plugin completamente em vez de tentar contornar o problema via configuração. Extraia a lista de contas de administrador do seu WordPress, compare-a com os eventos de login recentes e procure sessões que não possuam um evento de MFA correspondente ou que tenham originado de faixas de IP incomuns. Se você utiliza um WAF na frente de suas instâncias WordPress, adicione uma regra para bloquear requisições POST contendo mo_wp_login_intent=otp como mitigação de curto prazo enquanto coordena a atualização.