Firecracker corrige escape de VM; bypass do seccomp segue sem correção
Pesquisadores da Coinspect demonstraram uma cadeia que escapa da microVM do Firecracker a partir do espaço de usuário do convidado com root (CVE-2026-122192), com execução de código no processo do monitor no host, seguida por um contorno da política seccomp (FC-03). A fuga para o Firecracker está corrigida nas versões 1.16.2 e 1.17.0; o redesenho do seccomp para o FC-03 segue em revisão no PR #6287, sem CVE separado planejado pela AWS. Quem opera Firecracker próprio deve atualizar; a AWS afirma que seus serviços, incluindo Lambda, não são afetados.
O que aconteceu
Pesquisadores da empresa de segurança Coinspect demonstraram publicamente um ataque que sai da máquina virtual sandbox Firecracker e alcança o servidor host, com execução de código no processo do Firecracker e, em seguida, operações no host que a política de segurança bloqueava. A falha principal tem correção nas versões 1.16.2 e 1.17.0. A AWS afirma que seus serviços, incluindo Lambda, não são afetados.
Por que importa
O Firecracker roda cargas não confiáveis em larga escala: é a base do AWS Lambda e do Fargate e também isola agentes de IA em serviços como Amazon Bedrock AgentCore, DigitalOcean Managed Agents, Vercel Sandbox e E2B. Para quem executa cargas de vários clientes em Firecracker próprio, a falha quebra o isolamento entre convidado e host, com risco ao servidor subjacente. A AWS relatou em 2026 que o Firecracker suporta mais de 15 trilhões de invocações do Lambda por mês.
O que fazer
Atualizar instalações próprias do Firecracker para a versão 1.16.2 ou 1.17.0 e seguir o aviso de segurança do GitHub e o boletim da AWS. Acompanhar o PR #6287, que propõe a correção da segunda falha, sem CVE separado. Revisar a configuração do jailer: no teste dos pesquisadores, a etapa de rede do ataque falhou com namespace de rede dedicado (--netns).
Para o time técnico
- CVE
- CVE-2026-122192
- Afetados
- AWS Firecracker (monitor de máquinas virtuais) · Firecracker anterior a v1.16.2 e v1.17.0, com VM restaurada de snapshot usando backend de memória File e dispositivo balloon (PoC usou Full snapshot e virtio-balloon) ou virtio-mem.
- Exploração
- Prova de conceito pública demonstrada pela Coinspect (Juan Pablo Martinez Kuhn), blog atualizado em 4 de novembro de 2026 e divulgado no r/netsec. As fontes não relatam exploração na natureza.
- Correção
- CVE-2026-122192 corrigido no Firecracker v1.16.2 e v1.17.0. FC-03 (bypass do seccomp) sem correção final: redesenho do seccomp em revisão no PR #6287; a AWS não planeja CVE separado. Orientação oficial no aviso de segurança do GitHub e no boletim de segurança da AWS. Mitigação parcial observada: com namespace de rede dedicado (--netns no jailer), a conexão de rede retornou ENETUNREACH.
- Vetor
- Firecracker, caminho de descarte de memória (memory-discard) com backend File em VM restaurada de snapshot, com dispositivo balloon ou virtio-mem. Corrupção de memória: o código tenta substituir o mapeamento do snapshot por memória anônima com mmap MAP_FIXED; se o mmap falha depois de remover o mapeamento antigo, o slot de memória do KVM continua ativo e o endereço reutilizado pelo monitor (VMM) fica acessível ao convidado, que lê e altera a memória viva do VMM. Condições: root no espaço de usuário do convidado, sem código no kernel do convidado; pressão de memória gerada pelo convidado consome o headroom do limite por microVM e provoca a falha tardia. Segunda etapa (FC-03): a política seccomp do VMM permitia io_uring_setup, io_uring_register e io_uring_enter; código já em execução no VMM cria um novo ring e realiza operações de host bloqueadas, como socket de rede para o loopback do host.
- Mais detalhes
- Cadeia em dois estágios: FC-05 (CVE-2026-122192) dá execução controlada de código no EventManager do VMM; FC-03 usa io_uring para operações de host que o seccomp bloqueava; chamada direta de socket no mesmo contexto terminou com SIGSYS. As restrições de um ring do io_uring não são herdadas por um novo ring. O PoC rodou com o engine de bloco Sync padrão, sem ring criado pelo Firecracker em uso. O handler do balloon marcava a requisição como used antes do descarte e apenas logava o erro em caso de falha. A AWS afirma que seus serviços, incluindo Lambda, não são afetados e que clientes não precisam agir. A página de avisos de segurança do GitHub listava dois publicados até 21 de outubro de 2026. A Coinspect avaliou só o Firecracker, não as implantações dos serviços citados.
Linha do tempo
Incidente aberto.
