1 de outubro de 2026 · Security-Advisory · Schwachstellenmanagement · IT-Sicherheit · Zero Trust

Atualização de segurança do Keycloak: vá para 26.7.5 ou superior

As versões 26.7.4 e 26.7.5 do Keycloak corrigem várias vulnerabilidades, entre elas uma elevação de privilégios via papel de impersonation. Objetivo: 26.7.5 ou superior.

O projeto Keycloak publicou, em curto intervalo, duas versões de manutenção com correções de segurança. A 26.7.4 (16 de setembro) fecha as seis falhas descritas aqui; a 26.7.5 (30 de setembro), outras: as suas release notes listam 14 correções de segurança, quatro delas em dependências. A 1 de outubro veio ainda a 26.8.0. O objetivo para os operadores é, portanto, a 26.7.5 ou superior. Uma das falhas da 26.7.4 permite que uma conta com direitos administrativos restritos se passe por administrador do realm.

Este artigo é dirigido a organizações que operam o Keycloak por conta própria – como login central para colaboradores, para portais de clientes ou para aplicações de negócio. Contextualiza as seis vulnerabilidades da 26.7.4 e descreve o que fazer antes e depois da atualização.

Porque é que um fornecedor de identidade merece atenção especial

Um fornecedor de identidade (IdP) não é um serviço entre muitos. Emite os tokens nos quais todas as aplicações ligadas confiam. Quem controla o IdP não precisa de atacar nenhuma aplicação individualmente: pode iniciar sessão em qualquer uma delas como quem quiser, e pode alterar logins de modo que ninguém se aperceba.

Em arquiteturas de segurança, um sistema assim é por isso atribuído ao nível de proteção mais alto. A Microsoft, por exemplo, inclui sistemas centrais de identidade, no seu Enterprise Access Model, no plano de controlo, que surgiu do antigo «Tier 0». Um IdP é, portanto, tão crítico quanto controladores de domínio. Daí decorrem três regras práticas: aí, atualizações não são adiadas; aí, direitos administrativos são concedidos de forma especialmente restrita; e aí, acessos de gestão não são alcançáveis pela internet. Uma vulnerabilidade que, numa aplicação de negócio, seria «apenas» uma elevação de privilégios é, no IdP, uma elevação de privilégios para tudo o que está atrás dele.

As seis vulnerabilidades da 26.7.4

As classificações vêm das issues do projeto e da GitHub Advisory Database.

CVE-2026-17526 – Elevação de privilégios via papel de impersonation (alta, CVSS 7,2). Um utilizador com o papel «impersonation» pode fazer-se passar por um administrador do realm e obtém com isso, segundo a descrição no advisory, o controlo administrativo total sobre o realm – incluindo a gestão de utilizadores, clients e papéis. É a falha com maior alavanca, porque transforma um papel deliberadamente restrito num irrestrito.

CVE-2026-74909 – Contorno do Policy Enforcer (alta, CVSS 8,1). O Policy Enforcer não normaliza corretamente caminhos com determinados caracteres codificados, como um ponto e vírgula com codificação percentual. Um utilizador autenticado pode, assim, acionar uma política menos rigorosa do que a prevista e aceder a endpoints protegidos. O projeto descreve a correção expressamente como complemento de um fix anterior incompleto. Isso é relevante para aplicações que aplicam as suas regras de acesso por meio do Keycloak Policy Enforcer.

CVE-2026-90997 – Reutilização de artefactos de uso único (alta). É afetado o modo de operação sem estado (stateless) com MySQL ou MariaDB. Por causa de uma contagem divergente das linhas de base de dados afetadas, a proteção contra replay não reconhece artefactos já utilizados. São citados JWT client assertions, provas DPoP e códigos TOTP não reutilizáveis: quem intercetar um artefacto desses pode usá-lo novamente no endpoint de token ou no fluxo de login. A revogação de tokens, segundo a issue, não é afetada.

CVE-2026-79651 – Negação de serviço via tags de idioma (alta, CVSS 7,5). Os endpoints de localização aceitam tags de idioma arbitrárias de pedidos não autenticados para uma cache de memória ilimitada. Muitas tags diferentes bastam para derrubar o servidor.

CVE-2026-18212 – Fuga de memória no SAML Redirect Binding (CVSS 7,5 na GitHub Advisory Database, marcada como «medium» na issue do projeto). A memória nativa não é libertada no processamento de pedidos SAML. Pedidos malformados repetidos, sem autenticação, esgotam a memória até que o sistema operativo termine o processo.

CVE-2026-19607 – Bloqueio de conta via colisão de nome de utilizador (média, CVSS 5,3). No fluxo do primeiro login através de um fornecedor de identidade externo, um atacante pode registar um nome de utilizador correspondente no fornecedor externo e, assim, provocar uma colisão que bloqueia o utilizador legítimo. Isto é relevante para todos os realms em que utilizadores iniciam sessão através de um fornecedor de identidade externo – por exemplo, por uma federação com um parceiro ou por um social login.

Duas das seis falhas podem ser exploradas sem autenticação para derrubar o serviço. Para um serviço central de login, também uma indisponibilidade não é tema secundário: se o IdP para, para tudo o que depende dele.

O que fazer agora

  • Atualizar para 26.7.5 ou superior. Antes da atualização, o projeto remete ao guia de migração com a lista completa das mudanças. Leia-o antes da atualização, não depois, e teste a atualização numa instância de staging com configuração realista – em especial integrações de identity providers, clients SAML e themes próprios.
  • Determinar a versão em uso. As release notes não indicam faixas de versões afetadas. Parta, portanto, do princípio de que qualquer versão anterior à 26.7.4 pode ser afetada e verifique, para as linhas 26.4 e 26.6, se o fabricante disponibiliza versões corrigidas.
  • Verificar o papel de impersonation – e antes da atualização. O papel «impersonation» é um client role do client integrado «realm-management» em cada realm; para gestão entre realms, existem papéis correspondentes nos clients <Realm-Name>-realm do master realm. Determine que utilizadores, grupos e composite roles o contêm direta ou indiretamente. A documentação cita como finalidade típica o suporte: reproduzir um problema do ponto de vista do utilizador afetado. Verifique, por isso, especialmente contas de helpdesk e de suporte. Toda a conta com esse papel podia, nas versões afetadas, tornar-se administrador do realm.
  • Procurar vestígios. Em sessões de impersonation, o Keycloak regista o identificador e o nome de utilizador da conta que se passa pela outra como nota de sessão. Verifique, na medida em que regista admin events e eventos de login, se contas de administrador foram personificadas e se, nesse contexto, papéis, clients ou configurações de identity providers foram alterados.
  • Manter o papel restrito depois. Também após a atualização vale: quem pode personificar pode iniciar sessão como outra pessoa. Conceda o papel apenas onde for necessário e use as permissões administrativas granulares (fine-grained admin permissions) para excluir por princípio a personificação de administradores.
  • Verificar base de dados e modo de operação. Se opera o modo sem estado com MySQL ou MariaDB, a CVE-2026-90997 afeta-o diretamente.

Planear a atualização sem a adiar

Uma atualização do IdP afeta cada login, e justamente por isso costuma ser adiada. O Upgrading Guide do projeto estabelece as balizas. A partir do Keycloak 26.6.0, rolling updates são suportados para patch releases; se são possíveis no seu ambiente, descreve o guia de rolling updates. Quem já está na 26.7 pode, eventualmente, atualizar dentro dessa linha sem interrupção; a mudança da 26.6 para a 26.7 é um upgrade minor e exige, segundo o Upgrading Guide, uma paragem.

O guia estabelece, além disso, que primeiro se atualiza o servidor e depois os adaptadores. Antes de cada atualização, o guia exige um backup da instalação – configuração, themes – e da base de dados. O motivo é importante para o planeamento de retorno: o Keycloak não suporta reverter alterações da base de dados. Quem precisar de voltar atrás restaura a instalação antiga e a base de dados a partir do backup. Esse backup não é, portanto, um acessório, mas o único caminho de volta. Crie-o antes de começar e verifique se pode ser restaurado.

A gestão não pertence à internet

A elevação de privilégios pressupõe uma conta com direitos administrativos. Quanto menos contas desse tipo existirem e quanto menos caminhos levarem à consola de administração, menor será a superfície de ataque – não só para esta falha, mas para a próxima. As páginas de login precisam de ser alcançáveis; a consola de administração, por regra, não. Contas de administração devem ficar atrás de uma autenticação multifator, e a sua concessão deve passar por uma recertificação regular.

Como a sector7 apoia

Apoiamo-lo em conceitos de papéis e permissões, na gestão de contas privilegiadas e em processos de login seguros com autenticação multifator. Isso inclui análises recorrentes de vulnerabilidades com correção priorizada por meio da gestão de patches. Mais sobre isso em Cibersegurança.

Fontes

Vamos falar sobre a sua situação.

Marcar uma conversa+49 212 240915 0