Um CVE recém-publicado afeta versões do OpenAM anteriores à 16.1.3. A vulnerabilidade reside na interface SOAP JAX-RPC legada, e o resumo é brutal: um atacante não autenticado pode enviar uma requisição SOAP manipulada para /jaxrpc/*, passar um identificador de sessão não verificado junto com um nome de classe escolhido e fazer o servidor instanciar essa classe. Nenhuma credencial é necessária.

O risco imediato é a queda do servidor e o mapeamento do classpath. O risco mais grave é a execução de código por meio de cadeias de gadgets, exatamente o tipo de situação que transforma um achado "moderado" em um incidente de fim de semana. Se você executa o OpenAM na frente de qualquer coisa sensível, e provavelmente executa dado o que o OpenAM é, isso não é uma situação de aplicar o patch no próximo trimestre.

O que chama atenção aqui é a superfície que tornou isso possível: um endpoint SOAP JAX-RPC legado que presumivelmente ainda é distribuído porque alguém, em algum lugar, depende dele. Na minha experiência, esses endpoints de protocolos antigos são os que nunca recebem o mesmo nível de escrutínio de hardening que os fluxos modernos de OIDC e SAML. Eles estão em execução, estão acessíveis e ninguém os examina há anos. Se as suas regras de WAF estão ajustadas para REST e você não está bloqueando ou monitorando explicitamente o tráfego em /jaxrpc/*, você tem um ponto cego.

O bypass de autenticação é o problema central. Um identificador de sessão que não é verificado antes do carregamento de classes representa uma falha de design, não um erro de configuração. Isso significa que qualquer instância alcançável pela rede está exposta, independentemente de quão bem você tenha protegido seus fluxos de login ou suas políticas de MFA. Uma autenticação forte na camada superior não faz nada para proteger um endpoint que ignora a verificação por completo.

Aplique o patch para a versão 16.1.3 imediatamente. Se não for possível aplicar o patch agora, bloqueie ou restrinja o acesso a /jaxrpc/* no seu load balancer ou WAF como controle temporário, e trate essa regra como provisória, não como uma correção definitiva. Após o patch, analise os logs de acesso desse endpoint e procure qualquer tráfego SOAP inesperado. Se encontrar requisições que não consegue explicar, trate a situação como um potencial comprometimento e investigue a partir daí. Não assuma que baixo volume significa ausência de exploração.