Imagina a cena: você está numa entrevista para uma vaga sênior de Java, tudo correndo bem, e o entrevistador solta a pergunta que separa quem decorou tutorial de quem já apanhou em produção. "Como você protege os segredos do seu Spring Cloud Config Server num cluster Kubernetes?" Você começa a falar de criptografia de propriedades, e ele te corta: "E o que você faria diante da CVE-2026-40981?"
Em 6 de maio de 2026 saíram duas falhas de severidade ALTA no Spring Cloud Config Server. Uma delas, a CVE-2026-40981, deixa qualquer cliente com acesso de rede ler segredos de qualquer projeto GCP usando um único header HTTP, sem autenticação nenhuma (CVSS 7.5). A outra, a CVE-2026-41002, abre o repositório Git do servidor a um ataque de tempo-de-checagem contra tempo-de-uso (TOCTOU). Neste artigo você vai entender o vetor de cada uma, ver o código que demonstra o problema, aplicar o patch certo e, de quebra, ficar pronto para aquela pergunta de entrevista.
Imagina a cena: você está numa entrevista para uma vaga sênior de Java, tudo correndo bem, e o entrevistador solta a pergunta que separa quem decorou tutorial de quem já apanhou em produção. "Como você protege os segredos do seu Spring Cloud Config Server num cluster Kubernetes?" Você começa a falar de criptografia de propriedades, e ele te corta: "E o que você faria diante da CVE-2026-40981?"
Em 6 de maio de 2026 saíram duas falhas de severidade ALTA no Spring Cloud Config Server. Uma delas, a CVE-2026-40981, deixa qualquer cliente com acesso de rede ler segredos de qualquer projeto GCP usando um único header HTTP, sem autenticação nenhuma (CVSS 7.5). A outra, a CVE-2026-41002, abre o repositório Git do servidor a um ataque de tempo-de-checagem contra tempo-de-uso (TOCTOU). Neste artigo você vai entender o vetor de cada uma, ver o código que demonstra o problema, aplicar o patch certo e, de quebra, ficar pronto para aquela pergunta de entrevista.
O que é o Spring Cloud Config e por que ele virou alvo
Antes de falar de falha, bora alinhar o cenário. O Spring Cloud Config Server é o serviço que centraliza a configuração de todos os seus microsserviços num lugar só. Em vez de cada aplicação carregar o próprio application.yml com URLs de banco, chaves de API e segredos, elas pedem essas propriedades ao Config Server quando sobem. O backend costuma ser um repositório Git, e em ambientes cloud é comum plugar um cofre de segredos como o Google Secret Manager ou o Vault.
Esse desenho é ótimo para o dia a dia: você muda uma propriedade num repositório, dá refresh e a frota inteira passa a enxergar o novo valor. O problema é que esse mesmo serviço passa a ser o cofre central da sua arquitetura. Quem controla o Config Server controla os segredos de todos os serviços que dependem dele. É por isso que ele é um alvo tão valioso, e é por isso que duas CVEs nele de uma vez merecem atenção imediata.
Na empresa em que trabalhei como Tech Leader, a gente tratava o Config Server com o mesmo carinho que se trata um banco de dados de produção: acesso de rede restrito, autenticação obrigatória e auditoria de quem leu o quê. A maioria dos times, porém, sobe o Config Server "dentro do cluster" e assume que rede interna é zona segura. As CVEs de maio mostram exatamente onde essa premissa quebra.
CVE-2026-40981: um header HTTP que vaza segredos GCP
Essa é a mais grave das duas, e a que vai te custar a entrevista se você não souber explicar. Quando o Config Server usa o backend de Google Secret Manager, ele aceita um header HTTP para indicar de qual projeto GCP os segredos devem ser lidos. A falha está em que o servidor confia nesse header sem validar se o cliente tem permissão para aquele projeto. Resultado: qualquer pod com acesso de rede ao Config Server pode pedir segredos de um projeto GCP que não é o dele.
O vetor é constrangedor de tão simples. Veja como um atacante com acesso de rede ao serviço pediria os segredos de um projeto que nem deveria enxergar:
# O Config Server confia no header X-Project-ID sem checar permissao
# Um pod comprometido no mesmo cluster faz a leitura de outro projeto GCP
curl -H "X-Project-ID: projeto-financeiro-prod" \
http://config-server:8888/billing-service/production
# Resposta: as propriedades do billing-service, incluindo
# spring.datasource.password e a chave do gateway de pagamento
Repare que não há token, não há credencial, não há nada. O servidor recebe o nome do projeto via header e devolve os segredos. Num cluster Kubernetes onde dezenas de serviços compartilham a mesma rede, basta um único pod comprometido (uma dependência vulnerável, um sidecar mal configurado) para que o atacante leia segredos de projetos inteiros. É movimento lateral em estado puro.
Segundo o advisory oficial da Spring sobre a CVE-2026-40981, a falha afeta todas as versões suportadas do Spring Cloud Config que usam o backend GCP Secret Manager. O CVSS de 7.5 reflete o que mais assusta: baixíssima complexidade de ataque e nenhuma necessidade de autenticação.
CVE-2026-41002: o TOCTOU no basedir do Git
A segunda falha é mais sutil, mas igualmente perigosa. O Config Server, ao usar backend Git, clona o repositório num diretório de trabalho local chamado basedir. A CVE-2026-41002 explora uma condição de corrida do tipo TOCTOU (Time-Of-Check to Time-Of-Use): entre o momento em que o servidor verifica o caminho do arquivo e o momento em que ele realmente lê esse arquivo, um atacante consegue trocar o alvo, por exemplo através de um link simbólico.
Na prática, isso permite que um repositório malicioso, ou um atacante com escrita no basedir, faça o Config Server ler arquivos fora do diretório esperado. Pensa em ler o /etc/passwd, um arquivo de credenciais montado no pod ou a service account do Kubernetes. O ataque depende de timing, então não é tão trivial quanto o header do GCP, mas em ambientes multi-tenant ele é viável e foi classificado como severidade alta pela própria equipe da Spring.
O detalhe que entrega a vulnerabilidade está em como o caminho era resolvido. O código antigo checava o caminho canônico e só depois abria o arquivo, deixando uma janela entre as duas operações. A correção fecha essa janela validando e abrindo de forma atômica, sem dar tempo para a troca do alvo no meio do caminho.
O patch e a configuração segura: jeito errado contra jeito certo
Agora a parte que importa na sexta-feira de plantão. A correção de ambas as CVEs veio nas versões mais recentes do Spring Cloud Config. O primeiro passo é subir a dependência. Se você usa o Spring Cloud BOM, ajuste a versão do release train para a linha já corrigida:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<!-- use a versao corrigida do release train (2026.x patch) -->
<version>2026.0.2</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
Subir a versão fecha o vetor, mas o erro de mentalidade continua se você deixar o Config Server aberto na rede. O jeito errado, que vejo em quase todo projeto, é subir o servidor sem nenhuma autenticação porque "está dentro do cluster":
# JEITO ERRADO: Config Server exposto sem autenticacao
# Qualquer pod na rede do cluster le qualquer configuracao
spring:
cloud:
config:
server:
git:
uri: https://git.interno/config-repo
# sem spring.security, sem nada. Rede interna tratada como confiavel.
O jeito certo, como os sêniores fazem, é tratar o Config Server como superfície de ataque. Isso significa autenticação obrigatória, autorização por serviço e nunca confiar em header de cliente para decidir de qual projeto ler segredos. Veja uma configuração de segurança real com Spring Security travando o acesso:
package br.com.meuuniversonerd.config.security;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.web.SecurityFilterChain;
@Configuration
public class ConfigServerSecurity {
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
return http
// toda rota do config server exige autenticacao
.authorizeHttpRequests(auth -> auth
.requestMatchers("/actuator/health").permitAll()
.anyRequest().authenticated())
// HTTP Basic ou mTLS entre servicos, nunca acesso anonimo
.httpBasic(org.springframework.security.config.Customizer.withDefaults())
// Config Server e stateless: nada de sessao
.sessionManagement(s -> s.disable())
.csrf(csrf -> csrf.disable())
.build();
}
}
E o ponto que mata a CVE-2026-40981 de vez: pare de deixar o projeto GCP ser decidido por um header de cliente. Fixe o projeto no servidor, via variável de ambiente ou propriedade controlada pela infraestrutura, e ignore qualquer header que tente sobrescrever isso:
# JEITO CERTO: projeto GCP fixado pela infra, nao pelo cliente
spring:
cloud:
config:
server:
gcp-secret-manager:
# projeto vem do ambiente controlado, header de cliente e ignorado
project-id: ${GCP_PROJECT_ID}
application-label: ${spring.application.name}
security:
user:
name: ${CONFIG_USER}
password: ${CONFIG_PASSWORD}
Depois de aplicar, valide. Tente repetir o ataque do header e confirme que o servidor agora responde 401 ou ignora o header malicioso. Patch sem validação é só esperança, e esperança não passa em auditoria de segurança.
O que muda na prática (e quando você está exposto)
Vamos ao concreto. Você está exposto à CVE-2026-40981 se rodar Spring Cloud Config Server com backend Google Secret Manager e o acesso ao servidor não for autenticado por serviço. Você está exposto à CVE-2026-41002 se usar backend Git num ambiente onde mais de um ator tem acesso de escrita ao host ou ao basedir, cenário típico de clusters multi-tenant ou pipelines de build compartilhados.
O impacto, quando explorado, não é teórico. Estamos falando de leitura de senhas de banco, chaves de API de gateways de pagamento, tokens de serviços de terceiros e credenciais de service accounts. Um único pod comprometido vira a chave do reino inteiro. Foi por isso que o registro na base de vulnerabilidades do NIST (NVD) classificou o vetor de rede com complexidade baixa: o trabalho do atacante é mínimo depois que ele tem qualquer ponto de apoio na rede.
Como prioridade de remediação, eu seguiria esta ordem: primeiro, suba a versão corrigida (fecha o vetor de código). Segundo, ligue autenticação no Config Server se ela não existir. Terceiro, fixe o projeto GCP pela infra. Quarto, restrinja a rede com NetworkPolicy no Kubernetes para que só os serviços autorizados alcancem a porta 8888. Quem faz observabilidade direito ainda consegue um quinto passo: alertar sobre qualquer leitura de configuração fora do padrão esperado.
Por que isso cai em entrevista sênior
Aqui está a conexão com carreira que diferencia o conteúdo deste blog. Pergunta de feature qualquer dev decora. Pergunta sobre incidente de segurança real, com CVE recente, é o que o entrevistador usa para medir senioridade de verdade. Quando alguém pergunta "como você protege segredos no Config Server", o que ele quer ouvir não é "uso variável de ambiente". Ele quer ouvir que você entende o Config Server como superfície de ataque, que você sabe que rede interna não é zona de confiança e que você conhece o tipo de falha que a CVE-2026-40981 representa.
No mercado de hoje, segurança em cloud é o que separa pleno de sênior na faixa salarial. Saber subir um microsserviço qualquer um sabe. Saber explicar um TOCTOU, raciocinar sobre movimento lateral num cluster e propor defesa em camadas é o que coloca seu currículo no topo da pilha. Se você conseguir, numa entrevista, descrever o vetor do header GCP e a mitigação em camadas que mostramos aqui, você acabou de provar que pensa como quem já segurou produção de pé.
Para se aprofundar, vale revisar como funciona a autenticação moderna no ecossistema Spring no nosso guia de Spring Security e JWT do Meu Universo Nerd, entender o impacto das mudanças de CSRF no nosso artigo sobre APIs REST retornando 403 no Spring Boot 4 e fechar o ciclo com nosso material de observabilidade de aplicações Java em Kubernetes, que ensina a detectar leituras suspeitas como as dessas CVEs.
Perguntas frequentes
A CVE-2026-40981 afeta quem não usa Google Secret Manager?
O vetor específico do header X-Project-ID está ligado ao backend GCP Secret Manager. Quem usa só Git ou Vault não cai nesse vetor exato, mas deve aplicar a versão corrigida do mesmo jeito, porque a CVE-2026-41002 do basedir Git pode atingir backends Git independentemente.
Subir a versão do Spring Cloud já resolve tudo?
Subir a versão fecha o vetor de código das duas CVEs, e esse é o passo número um. Mas se o seu Config Server continuar aberto na rede sem autenticação, você segue com um cofre central acessível a qualquer pod. O patch corrige a falha; a arquitetura segura evita a próxima.
Como sei se já fui explorado?
Procure nos logs do Config Server requisições com headers de projeto inesperados e leituras de configuração de serviços que aquele cliente não deveria consultar. Sem observabilidade configurada, essa análise fica cega, e é por isso que monitorar o acesso à configuração faz parte da defesa.
Dá para mitigar sem atualizar agora, em caso de janela de deploy travada?
Como mitigação temporária, ligue autenticação no servidor, bloqueie a porta 8888 via NetworkPolicy para só os serviços autorizados e fixe o projeto GCP pela infra ignorando o header do cliente. Isso reduz o risco enquanto você agenda o upgrade, mas não substitui a versão corrigida.
Vale a pena trocar o Config Server por outra solução?
Não precisa. O Spring Cloud Config segue uma escolha sólida quando bem configurado. O que essas CVEs ensinam não é "abandone a ferramenta", é "trate seu cofre de configuração com o rigor de segurança que ele merece".
Conclusão e próximo passo
Recapitulando o essencial para você sair daqui pronto:
- Duas CVEs de severidade alta no Spring Cloud Config saíram em 06/05/2026: header GCP vazando segredos (CVE-2026-40981) e TOCTOU no basedir Git (CVE-2026-41002).
- O patch é subir a versão do release train corrigido, mas a defesa real é tratar o Config Server como superfície de ataque: autenticação, projeto GCP fixado pela infra e NetworkPolicy.
- Rede interna não é zona de confiança. Esse é o erro de premissa que as duas falhas exploram, e é exatamente isso que cai em entrevista sênior.
E você, já tinha parado para pensar no seu Config Server como alvo de ataque, ou ele está lá rodando "dentro do cluster" sem autenticação? Conta nos comentários como é a segurança de configuração na sua stack, quero saber como os times estão tratando isso na prática.
Na próxima semana eu vou mostrar como montar uma NetworkPolicy no Kubernetes do zero para isolar serviços sensíveis como o Config Server, com YAML pronto para você colar no seu cluster. Fica de olho aqui no blog e no nosso canal.