TL;DR

CVE-2025-49844, apelidada de RediShell. CVSS 10.0. Bug do tipo use-after-free no binding de Lua do Redis que permite escapar do sandbox e chegar a execução remota de código no host. A exploração exige acesso autenticado ao Redis. Há muitos ambientes que ainda expõem o Redis ou usam credenciais fracas. Atualizações mínimas para ficar seguro: 8.2.2, 8.0.4, 7.4.6, 7.2.11 e 6.2.20 conforme a família. Se não puder atualizar agora, bloqueie scripting via ACL e restrinja rede.

Fase 1. Qual é o problema nessa CVE

O que é a RediShell

O problema é um use-after-free na integração do Redis com Lua. Um atacante com acesso autenticado envia um script Lua especialmente construído, manipula o garbage collector, sai do sandbox e executa código arbitrário. Na prática, isso vira shell reverso partindo do processo redis-server e abre caminho para exfiltração de chaves e movimento lateral. Classificação crítica, CVSS 10.0.

Por que ela é especial

Este bug existe há cerca de 13 anos no código que suporta scripting em Lua. O impacto é amplo porque Lua está presente nas versões modernas do Redis e scripting é muito usado para operações atômicas no lado do servidor. A exploração pede autenticação, mas exposição de Redis é um fenômeno conhecido e perigoso. Estimativas recorrentes falam em centenas de milhares de instâncias acessíveis na internet e dezenas de milhares sem autenticação. A combinação má configuração e patching tardio transforma o que seria um detalhe técnico em incidente real.

Histórico recente

Nos últimos 12 meses o Redis já recebeu outros avisos relevantes que reforçam a necessidade de disciplina contínua em patching e hardening, especialmente para tudo que tangencia Lua. O recado é simples: falhas em scripting e em exposição de serviço são previsíveis, basta minimizar a superfície e manter versões em dia.

Diagrama simples do root cause

Veja aqui mais detalhes do diagrama: https://www.mermaidchart.com/d/331349a9-e715-4a86-afc4-6dbec832bfca

Fase 2. O que ela afeta e cenários de exploração

Versões afetadas e correções

Afeta todas as versões com suporte a Lua. Corrigido em:

• Série 8. 8.2.2 e 8.0.4

• Série 7. 7.4.6 e 7.2.11

• Série 6 mantida. 6.2.20

Recomendação: Atualize no mínimo para as versões acima e faça rollout controlado. Faça sua subscrição na imagem Redis sem CVEs em quor.dev.

Pré-requisitos e superfície de ataque

• Requer acesso autenticado ao Redis

• O risco dispara quando há exposição em rede sem camada de controle, quando protected-mode está desativado ou quando a autenticação é fraca

• Em Kubernetes, Redis acessível sem NetworkPolicy ou sem controles de egress e ingress pode ser explorado a partir de workloads comprometidos na mesma VPC ou cluster

Cenários práticos de ataque em Kubernetes

1. Aplicação comprometida no cluster com variáveis de ambiente contendo credenciais de Redis. O atacante usa a conta do app para enviar EVAL e aciona o bug. Resultado esperado. Execução remota no host, leitura de volumes e fuga do escopo do pod.

2. Redis exposto via Service tipo LoadBalancer sem lista de IPs permitidos. Credenciais fracas ou vazadas. O atacante autentica e executa o exploit.

3. Pipeline de CI com job que tem acesso direto ao Redis em rede interna. Credenciais nos secrets do pipeline. Comprometimento do runner vira pivô para o Redis e depois para o host do nó onde o Redis roda.

Táticas que realmente aparecem

• Shell reverso a partir do processo redis-server

• Exfiltração de secrets armazenados no host, chaves SSH, tokens IAM e certificados

• Movimentação lateral na VPC e varredura de alvos próximos

• Implantação de crypto-miners em nodes menos monitorados

Matriz de risco resumida

Fase 3. Como corrigir?

Atualizar agora

• Série 8. 8.2.2, 8.0.4

• Série 7. 7.4.6, 7.2.11

• Série 6 mantida. 6.2.20

• Redis Stack e edições enterprise conforme o seu fornecedor

Se usa Docker, prefira tag exata ou digest da versão corrigida. Faça sua subscrição na imagem Redis sem CVEs em quor.dev.

Outras opções se a atualização não pode ser feita de emergência.

Endurecer o acesso no próprio Redis com ACL

Bloqueie scripting para todos os usuários que não precisam dessa permissão. Exemplo simples de criação de usuário de app sem scripting.

ACL SETUSER app reset
ACL SETUSER app on >senha_super_forte ~* +@all -@scripting -eval -evalsha
ACL SAVE
ACL LIST

NetworkPolicy para Redis no Kubernetes

Permite somente pods clientes autorizados. Ajuste seletores conforme seus labels.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: redis-allow-only-apps
  namespace: data
spec:
  podSelector:
    matchLabels:
      app: redis
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              name: apps
          podSelector:
            matchLabels:
              role: api
      ports:
        - protocol: TCP
          port: 6379
  egress:
    - to:
        - ipBlock:
            cidr: 10.0.0.0/8
      ports:
        - protocol: TCP
          port: 53
    - to:
        - namespaceSelector:
            matchLabels:
              name: observability
      ports:
        - protocol: TCP
          port: 3100

Admission Policies com CEL

A validação nativa com ValidatingAdmissionPolicy em CEL permite impor requisitos diretamente no API server, sem dependências externas. Com CEL é possível declarar condições objetivas para recusar objetos que não cumpram padrões mínimos de segurança, como exigir que cada imagem esteja fixada por digest, forçar runAsNonRoot verdadeiro, negar privileged e allowPrivilegeEscalation e garantir que todas as capabilities sejam removidas. Essa abordagem padroniza controles entre clusters, reduz a superfície operacional e integra naturalmente com fluxos GitOps.

ValidatingAdmissionPolicy nativa no Kubernetes com CEL

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: require-digest-and-min-privs
spec:
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["pods"]
  validations:
    - expression: "has(object.spec.containers) && object.spec.containers.all(c, c.image.matches('.*@sha256:.*'))"
      message: "imagem deve usar digest"
    - expression: "has(object.spec.securityContext) && object.spec.securityContext.runAsNonRoot == true"
      message: "pods devem rodar como não root"
    - expression: |
        object.spec.containers.all(c,
          has(c.securityContext) &&
          c.securityContext.privileged != true &&
          c.securityContext.allowPrivilegeEscalation != true &&
          ((has(c.securityContext.capabilities) && has(c.securityContext.capabilities.drop) &&
            c.securityContext.capabilities.drop.exists(cap, cap == 'ALL')) ||
           !has(c.securityContext.capabilities)))
      message: "containers não podem ser privilegiados, devem negar escalada e derrubar todas as capabilities"
---
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: require-digest-and-min-privs-binding
spec:
  policyName: require-digest-and-min-privs
  matchResources:
    namespaceSelector: {}
  validationActions: ["Deny"]

A solução direta com Quor.dev

Imagens de frameworks e aplicações chamam atenção, mas o ecossistema inteiro precisa do mesmo cuidado. Redis é infraestrutura crítica. Cada uma dessas camadas acumula CVEs rapidamente. Imagens Zero-CVE do quor.dev reduzem a superfície, trazem SBOM e provenance e facilitam auditoria contínua. Isso não substitui patch da aplicação, mas elimina ruído de base e acelera tempo para mitigar em incidentes. O ponto é simples. segurança não é só do framework que sua equipe escolhe. toda a pilha de ferramentas precisa de atenção, e Redis entra nessa lista com prioridade, e o quor.dev lhe dá isso com apenas um re-deploy.

Checklist final para o seu time

• Confirmar versão do Redis em todos os ambientes e atualizar para no mínimo 8.2.2, 8.0.4, 7.4.6, 7.2.11 ou 6.2.20 conforme a família

• Fixar imagens por digest. Evitar aliases como 8.2-alpine. Preferir tags exatas

• Aplicar ACL negando @scripting e removendo EVAL e EVALSHA de todo usuário que não precise

• Criar ou endurecer NetworkPolicies. Permitir somente pods autorizados

• Aplicar políticas de admissão. Digest obrigatório e privilégios mínimos

• Ativar alertas no Loki para EVAL, EVALSHA, SCRIPT LOAD e crashes de Lua

• Reforçar autenticação, habilitar protected-mode e limitar superfícies de rede

Compliance & controles

• CIS Kubernetes Benchmark. Controles de NetworkPolicy, políticas de admissão e privilégios mínimos em Pods

• NIST SSDF e NIST 800-53. Práticas de atualização contínua, inventário de software, SBOM e hardening

• PCI DSS. Redução de superfície e segmentação de rede. Imagens com SBOM e Zero-CVE facilitam evidências e resposta

Referências

• Advisory oficial do fornecedor com versões corrigidas, IoCs e mitigações

• Notas de versão com séries corrigidas, incluindo 6.2.20

• Análises técnicas independentes sobre a cadeia de exploração e a linha do tempo

• Páginas públicas de imagens oficiais para verificação de tags e digests

• DarkReading - https://www.darkreading.com/cloud-security/patch-now-redishell-redis-rce

Quer conhecer mais sobre como ter um ecossistema de containers sem CVE, acesse aqui: quor.dev