Quando foi a última vez que você olhou sob o capô das imagens Docker Container que você usa? Porque aqui está a dura verdade: cada instrução FROM, cada binário copiado e cada pacote instalado que forma seu Container é um vetor de ataque potencial.
Isso significa que, se você não estiver inspecionando regularmente as camadas das suas imagens de Container e as dependências de tempo de build, provavelmente estará herdando muito mais risco do que imagina.
CVEs (Common Vulnerabilities and Exposures), imagens base inseguras, Secrets hardcoded e privilégios excessivos são apenas algumas das formas pelas quais os atacantes conseguem se infiltrar. E isso deve ser uma preocupação para organizações como a sua.
Na verdade, o relatório State of Container Security 2024 da Red Hat, que entrevistou 600 profissionais de DevOps, engenharia e segurança, descobriu que quase metade das equipes (42%) admite que a segurança de contêineres tira o sono.
Desde vulnerabilidades de runtime de Container até CVEs que afetam cargas de trabalho de GPU críticas, este artigo detalha nove das vulnerabilidades de Container Docker mais vitais e comumente negligenciadas.
O que são Vulnerabilidades de Container Docker?
Uma vulnerabilidade de Container Docker é qualquer fraqueza, configuração incorreta ou falha em uma imagem de Container, runtime ou sua infraestrutura subjacente que atacantes podem explorar para comprometer a segurança. Isso inclui tanto CVEs conhecidas quanto problemas negligenciados, como configurações padrão inseguras, Secrets expostos ou privilégios excessivos.
A velocidade e a portabilidade que tornam os Containers Docker tão poderosos para desenvolvedores também podem transformá-los em um pesadelo para as equipes de segurança. Por exemplo, puxar uma imagem com a tag latest ou executar Containers como root pode parecer inofensivo à primeira vista. Mas, na prática, são exatamente esses os tipos de brechas que os atacantes procuram.
Uma vulnerabilidade, em termos simples, é qualquer coisa na sua configuração de Container que facilita a vida de alguém tentando invadir.
Com isso em mente, vamos detalhar as nove vulnerabilidades de Container Docker mais comuns e perigosas às quais você precisa ficar atento.
As 9 Principais Vulnerabilidades em Containers Docker
As nove vulnerabilidades a seguir são CVEs ativas e configurações incorretas disseminadas observadas em ambientes de produção. Cada uma representa um caminho de ameaça prático que pode levar ao comprometimento do Container, acesso ao host ou movimento lateral em sua infraestrutura.
Vamos detalhá-las.
1. Vulnerabilidades de Escape de Container runC e Docker
runC é um runtime de Container "de baixo nível" usado principalmente por runtimes de Container "de alto nível", como o Docker, para criar e executar Containers. Ao longo dos anos, vimos várias vulnerabilidades de escape de Container runC e Docker, que resultaram em ataques.
Uma das principais, CVE-2019-5736, foi descoberta em fevereiro de 2019. Essa vulnerabilidade permitiu que um atacante explorasse uma implantação runC executando uma versão do Docker anterior a 18.09.2 ao sobrescrever o binário runC do host, comprometendo assim o acesso root do host.
Embora seja uma vulnerabilidade antiga (6 anos em 2025), muitas equipes ainda estão expostas a ela, especialmente em ambientes com versões Docker/runC não corrigidas ou legadas, runtimes personalizados ou bifurcados, etc.
Uma nuance crítica na vulnerabilidade CVE-2019-5736 é que ela exige que o processo do Container esteja executando como usuário root. Suponha que os Containers estivessem executando como Containers não-root (por exemplo, com USER 1000 no Dockerfile ou securityContext.runAsNonRoot: true no Kubernetes). Nesse caso, os atacantes não podem acionar o caminho de sobrescrita porque não possuem os privilégios necessários, e é por isso que é importante não executar seus Containers como usuário root.
Desde 2019, mais vulnerabilidades de escape de Container runC e Docker surgiram, algumas com baixa gravidade e outras críticas:
- CVE-2024-21626: Escape de Container através de runC process.cwd & fds vazados
- CVE-2024-45310: Escape de Container para criar arquivos ou diretórios vazios
- CVE-2024-23651: Race no cache de montagem do Buildkit
- CVE-2024-23652: Exclusão arbitrária no teardown de Container em tempo de build do Buildkit
- CVE-2024-23653: Verificação de privilégio do SecurityMode GRPC do Buildkit
Corrigir essas vulnerabilidades de segurança exige a atualização dos Containers Docker afetados para uma versão corrigida.
NOTA: Se você não tem certeza de qual versão do runC você tem em seu ambiente, executar docker version deve retornar a versão como parte da saída:
Gravidade: Baixa → Crítica
2. CVE-2025-9074: Acesso Não Autenticado ao Docker Engine API do Docker Desktop a partir de containers
O Docker Engine API fornece uma interface programática para interagir com o daemon do Docker e gerenciar objetos Docker. Ele está presente em todas as ferramentas Docker, incluindo o Docker Desktop.
CVE-2025-9074 é uma vulnerabilidade crítica, semelhante a server-side request forgery (SSRF), no Docker Desktop. Com esta vulnerabilidade, containers podem acessar o Docker Engine API via a sub-rede Docker configurada em 192.168.65.7:2375 por padrão, mesmo com a “Enhanced Container Isolation” ativada. Além disso, com ou sem a opção "Expose daemon on tcp://localhost:2375 without TLS" ativada.
A CVE-2025-9074 afeta apenas máquinas macOS e Windows. Embora a maioria dos sistemas de produção execute em Linux, como o Docker, alguns utilizam Windows Server (especialmente se exigirem o uso de containers Windows).
Atacantes podem explorar esta CVE com apenas estas três linhas de código Python abaixo:
The code above connects to the Docker daemon via TCP socket and runs a new Alpine container that creates a file exploit and mounts it to the host directory /Users/<username>. With that, when the container writes to the /mnt/exploit file, it writes to host /Users/<username>/exploit.
Um atacante pode modificar o script para fazer qualquer coisa que o Docker engine possa fazer, incluindo controlar outros containers, criar novos, gerenciar imagens, etc.
Se você usa Docker Desktop em macOS ou Windows, certifique-se de atualizar para a versão mais recente, pois esta vulnerabilidade foi corrigida na versão 4.44.3.
Gravidade: Crítica
3. CVE-2022-0847: Dirty pipe (Escape do Kernel Linux)
A CVE-2022-0847, vulnerabilidade do kernel Linux, decorre de uma falha na lógica pipe_buffer.flags do código de pipe do kernel, que permite a um ator malicioso escrever em arquivos somente leitura, ignorando proteções como O_RDONLY e immutable. Em seguida, eles podem escalar seus privilégios.
Embora não seja uma vulnerabilidade específica de container, ela pode ser usada de dentro de um container Linux sem privilégios para sobrescrever binários como /usr/bin/sudo no host, injetar backdoors e pode ser usada para encadear exploits.
A única correção conhecida para esta vulnerabilidade é atualizar seus hosts Linux para versões de Kernel corrigidas.
Gravidade: Alta
4. Imagens Base Inseguras
Imagens base são a fundação de cada container que você constrói, e se elas são vulneráveis, sua aplicação também é. Infelizmente, ao criar containers, muitas equipes ainda usam tags de imagem como ubuntu:latest ou node:alpine sem perceber que essas tags são alvos móveis.
A imagem mais recente que seu container usa hoje pode ser diferente da que ele usa amanhã. Isso pode introduzir vulnerabilidades de segurança inesperadas.
Para mitigar esta vulnerabilidade, aponte para versões específicas e confiáveis (por exemplo, FROM debian:bullseye-20230912) em vez de usar tags como latest. E enquanto você usa versões confiáveis de uma imagem específica, lembre-se de escanear consistentemente usando ferramentas como Aikido Security para detectar CVEs e vulnerabilidades AutoFix.
Você também deve escanear imagens em seu registro de containers para corrigir vulnerabilidades antes que elas cheguem ao seu ambiente. Aikido também pode integrar e escanear imagens em seu registro de containers, seja Docker Hub ou Harbor.
Gravidade: Baixa → Crítica (Dependendo das imagens de container e do uso)
5. Acesso Irrestrito ao Socket Docker
Montar o Socket Docker, geralmente localizado em (/var/run/docker.sock), em um container, é uma das mais perigosas configurações incorretas em ambientes conteinerizados. Fazer isso concede ao container acesso total ao Docker Engine API, permitindo-lhe controlar todo o host. O que não é inerentemente ruim; no entanto, um único container malicioso pode significar que um atacante agora tem controle de todo o seu host.
As equipes às vezes montam o Socket Docker para permitir builds "Docker-in-Docker" ou ferramentas de monitoramento para gerenciar containers, mas é quase sempre um atalho perigoso.
Para mitigar esta vulnerabilidade, você nunca deve montar o Socket Docker em containers. Se você precisa da funcionalidade Docker-in-Docker, ela deve ser isolada em ambientes de build rigidamente controlados usando rootless Docker, gVisor, ou Kata Containers.
Se você usa Kubernetes, você deve aplicar Padrões de Segurança de Pod ou políticas de admissão para bloquear containers de acessar recursos em nível de host como o Socket Docker.
Gravidade: Crítica
6. CVE-2025-23266: Vulnerabilidade de IA da NVIDIA (Falha de Acesso à GPU)
IA e ML são tudo o que temos falado no último ano. Isso porque mudou a forma como trabalhamos e vivemos em geral.
CVE-2025-23266 é uma vulnerabilidade de Escape de Container que afeta o NVIDIA Container Toolkit e o GPU Operator, que nos permite construir e executar Containers acelerados por GPU.
O NVIDIA Container Toolkit utiliza hooks OCI (Open Container Initiative) (scripts ou binários personalizados) para configurar Containers para acesso à GPU. Um desses hooks, enable-cuda-compat, herda variáveis de ambiente do Container. Isso abre a porta para um atacante criar uma imagem maliciosa que define LD_PRELOAD para referenciar uma biblioteca compartilhada maliciosa.
Quando o hook privilegiado é executado, a biblioteca é carregada no host, fora do sandbox do Container, concedendo efetivamente ao atacante acesso root no nó.
Em clusters de GPU multi-tenant, isso cria um sério risco de vazamento de dados entre tenants e comprometimento do nó.
A NVIDIA lançou versões corrigidas de ambos os componentes. A atualização para o Toolkit v1.17.8 e o GPU Operator 25.3.1 ou a desativação de um hook opcional mitiga a vulnerabilidade.
Gravidade: Importante
7. Secrets Expostos
O Relatório IBM Cost of a Data Breach de 2025 revela que as violações de dados causadas por credenciais comprometidas levaram mais tempo para serem identificadas e contidas. Com o custo médio de uma violação de dados sendo de US$ 4,4 milhões, as organizações não podem se dar ao luxo de ter Secrets expostos.
No entanto, eles ainda são um dos erros mais comuns que os desenvolvedores cometem. Esses Secrets incluem credenciais sensíveis como chaves de API, senhas, chaves de criptografia, chaves privadas e muito mais, que poderiam permitir que atacantes acessassem ou roubassem dados confidenciais.
Desenvolvedores podem vazar Secrets em Docker Containers via:
- Dockerfiles (instruções ENV ou ARG)
- arquivos .env copiados para camadas de imagem, etc.
A parte assustadora é que, mesmo depois que um Container é excluído, se a imagem ainda estiver presente (ou enviada para um registro), os Secrets podem permanecer acessíveis.
As chances de sua organização ter vazado Secrets são altas. Mas o que você pode fazer a respeito agora?
Bem, você pode e deve:
- Encontrar quaisquer Secrets ativos e então
- Impedir que qualquer novo chegue à produção.
Existem também algumas soluções que oferecem um recurso de detecção de Secrets em tempo real que pode ajudar você a avaliar os riscos potenciais de Secrets expostos.
Gravidade: Alta
8. Vulnerabilidades de Privilégios de Container
Como mencionado anteriormente, você não deve executar Containeres como usuários root. Embora isso não dê acesso automático ao host, como você viu, aumenta significativamente o risco de fuga quando combinado com outras vulnerabilidades como CVE-2022-0492 ou configurações incorretas em montagens de volume e capacidades.
Além de executar Containeres como usuários root, existem outras maneiras pelas quais um Container pode ser vulnerável por meio de privilégios. Isso é particularmente verdadeiro ao usar um orquestrador de Containeres como Kubernetes, que cria, modifica e exclui Containeres automaticamente.
Com CVE-2023-2640 e CVE-2023-32629, um atacante pode usar um Container privilegiado não-root com montagem de volume para escalar privilégios.
No Kubernetes, você usaria o Security Context para definir configurações de privilégio e controle de acesso para um Container.
No Security Context acima:
- runAsNonRoot: true: Garante que o Container não iniciará como UID 0
- runAsUser: 1000: Executa explicitamente o Container como um usuário não-root
- allowPrivilegeEscalation: false: Bloqueia setuid ou outras escaladas
- capabilities.drop: [ALL]: Remove todas as capacidades Linux por padrão
Gerenciar privilégios e acesso de Containeres requer entender como sua aplicação se comporta. Por exemplo, se você não realiza nenhuma gravação em disco, então você deve montar quaisquer volumes associados como somente leitura, reduzindo ainda mais a superfície de ataque.
Leia nosso guia sobre vulnerabilidades de escalada de privilégios de Container e como se proteger contra elas.
Severidade: Alta → Crítica
9. gh0stEdit: Vulnerabilidade de Acesso Baseada em Camadas
Imagens Docker são projetadas para garantir que seus usuários finais possam avaliar e ver claramente o conteúdo de uma imagem antes de executá-la.
Mas no caso de gh0stEdit, essa visibilidade não importa.
Embora não seja um CVE formal, gh0stEdit (nome dado por seus pesquisadores) descreve uma nova vulnerabilidade onde um atacante pode manipular imagens Docker (mesmo aquelas assinadas com Docker Content Trust) sem quebrar a assinatura da imagem ou ser detectado por varreduras estáticas/dinâmicas.
Figura 1: Bypass de Integridade de Imagem Docker: Camadas Alteradas, Manifesto Inalterado. Fonte (Hackernoon)
Essa manipulação é possível porque o Docker foca no manifesto (a "receita" que lista as camadas da imagem e seus digests), e não em cada arquivo dentro de cada camada.
Se um atacante injetar um script malicioso em uma camada, o Container é executado, ignorando o Dockerfile, o processo de build e as verificações do registro. Ele pode se espalhar silenciosamente por todo o seu sistema.
Corrigir e defender-se contra gh0stEdit envolve várias etapas, incluindo:
- Sempre reconstruir imagens de Container a partir de fontes confiáveis
- Assinatura e verificação de imagens de Container com ferramentas como cosign
- O scanning de vulnerabilidades e conteúdo com ferramentas como Aikido complementa scanners de código aberto com regras personalizadas, preenchendo lacunas e revelando falhas de segurança.
- Usar um admission controller para impedir que imagens não assinadas ou não escaneadas sejam executadas dentro do seu cluster.
Severidade: Baixa → Crítica (Dependendo das imagens de Container e da superfície de ataque)
Construindo uma Postura de Segurança Docker Resiliente
Como exploramos neste artigo, vulnerabilidades como escapes de Container runC, imagens base não escaneadas, Secrets expostos e privilégios excessivos podem comprometer silenciosamente todo o seu ambiente.
Implementar uma postura de segurança Docker resiliente significa ir além de varreduras superficiais, buscando defesas contextuais, cientes do tempo de execução e orientadas por políticas que encontram e corrigem vulnerabilidades automaticamente.
Na Aikido, adoramos projetos open-source estabelecidos como Trivy, Syft e Grype. Mas também sabemos por experiência que usá-los isoladamente não proporciona uma boa experiência para o desenvolvedor.
A Aikido aprimora esses projetos com regras personalizadas para preencher lacunas e revelar falhas de segurança que você não conseguiria encontrar de outra forma. Ao contrário de encadear várias ferramentas open-source, a Aikido te liberta da necessidade de construir um script de varredura ou criar um job personalizado em seu CI/CD.
Sempre há mais a aprender sobre segurança Docker. Para responder a mais perguntas sobre como manter o Docker seguro, confira nosso checklist de segurança Docker sem rodeios para o desenvolvedor focado em vulnerabilidades.
Continue lendo:
As 7 principais vulnerabilidades de segurança na Cloud
As 10 principais vulnerabilidades de segurança de aplicações web que toda equipe deve conhecer
As 9 principais vulnerabilidades e configurações incorretas de segurança Kubernetes
As principais vulnerabilidades de segurança de código encontradas em aplicações modernas
As 10 principais vulnerabilidades de segurança Python que os desenvolvedores devem evitar
As principais vulnerabilidades de segurança JavaScript em aplicações web modernas
As 9 principais vulnerabilidades de segurança da supply chain de software explicadas
