CVE-2020-8816
Corrige ahora. Ella está bajo explotación confirmada por CISA y tiene exploit funcional público.
Apply updates per vendor instructions.
Resumen
Falha de injeção de comando (CWE-78) na interface web administrativa do Pi-hole (AdminLTE/Web) versão 4.3.2, explorável por um usuário já autenticado com acesso ao painel ao cadastrar um lease DHCP estático com um campo de endereço MAC malformado. O CVSS de 9.1 reflete o impacto (execução de código no sistema, potencialmente como root) e o escopo alterado (sai da aplicação web e afeta o SO subjacente), mas exige privilégios de administrador do dashboard — não é uma falha pré-autenticação, o que reduz bastante a superfície real de exposição.
Detalle técnico
O componente afetado é o formulário de configuração de leases DHCP estáticos do AdminLTE (o painel web do Pi-hole). O campo de endereço MAC não era validado/sanitizado corretamente antes de ser usado na composição de um comando de sistema executado no backend, permitindo que caracteres de controle de shell injetados nesse campo escapassem do contexto esperado e fossem interpretados pelo interpretador de comandos. Isso é classificado como CWE-78 (OS Command Injection).
A correção, feita no pull request #1165 do repositório pi-hole/web, foi descrita pelos próprios mantenedores como um "fix potential code injection on MAC address validator" — ou seja, o problema estava especificamente na rotina que valida o formato do MAC address antes de gravar o lease estático, não em todo o fluxo de DHCP. A falha já havia sido corrigida no ramo de desenvolvimento release/v5.0 antes de ser identificada como necessidade de release interino (4.3.3) para quem ainda estava no ramo 4.x.
O vetor CVSS (AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H) documenta bem o quadro: rede, baixa complexidade de ataque, nenhuma interação de usuário adicional necessária além de estar logado, mas privilégio alto (PR:H) é pré-requisito, e o escopo muda (S:C) porque o código injetado roda no contexto do processo que grava a configuração do dnsmasq/gravity, fora do sandbox da aplicação web.
Cómo se explota
O pré-requisito central, confirmado pelos próprios desenvolvedores do Pi-hole na discussão do PR de correção, é que o atacante precisa estar autenticado no painel administrativo do Pi-hole (usuário "privileged dashboard user"). Não há vetor pré-autenticação documentado. Na prática, isso significa: acesso de rede à interface web de administração (geralmente exposta na LAN, mas em configurações mal feitas pode estar acessível pela internet) e credenciais válidas de administrador, ou uma sessão de admin já estabelecida que o atacante consiga sequestrar (ex: via CSRF, se aplicável, ou rede local sem proteção).
Com acesso ao painel, o atacante cadastra ou edita um lease DHCP estático informando um endereço MAC contendo metacaracteres de shell em vez de um MAC válido. Esse valor, processado sem validação adequada pelo backend, resulta em execução de comando arbitrário no host que roda o Pi-hole — tipicamente um Raspberry Pi ou servidor Linux dedicado a resolução DNS, frequentemente executando os componentes de gerenciamento com privilégios elevados.
Existe PoC pública documentada (Packet Storm, blog do pesquisador nate-red que reportou a falha) e módulo Metasploit conhecido, o que baixa a barreira técnica para exploração. A CISA incluiu a CVE no catálogo KEV (adicionada em 10/12/2021, com prazo de correção de 10/06/2022 para agências federais dos EUA), confirmando exploração observada em ambiente real, não apenas teórica.
Versiones
Cómo protegerse
A correção oficial é atualizar o componente Web/AdminLTE do Pi-hole para a versão 4.3.3 (release interino específico para corrigir esta CVE no ramo 4.x) ou para a versão 5.0 em diante, onde o fix já estava presente antes mesmo do release 4.3.3. Quem está em qualquer versão do ramo 4.x anterior a 4.3.3 permanece vulnerável.
Como paliativo caso a atualização não seja imediata: restringir o acesso à interface administrativa do Pi-hole apenas a rede de gerência confiável (nunca exposta à internet), reduzir o número de contas com privilégio de administrador do dashboard e revisar/rotacionar credenciais de acesso — já que a exploração depende inteiramente de uma sessão autenticada com privilégio. Isso não elimina a falha, apenas reduz a chance de um atacante obter as credenciais necessárias.
Não funciona como mitigação: apenas trocar a senha do painel sem atualizar o software, pois qualquer conta administrativa legítima (incluindo a própria conta do operador, se comprometida por outro vetor) ainda pode ser usada para disparar a injeção. A vulnerabilidade está no código de validação do campo MAC, não em controle de acesso — só a atualização do AdminLTE remove a causa raiz.
Cómo detectar
Não há assinatura de exploração amplamente publicada pelo fornecedor ou por pesquisadores nas fontes analisadas. Como indício indireto, vale monitorar logs de acesso ao endpoint de gerenciamento de leases DHCP estáticos do painel web (requisições de criação/edição de lease) buscando valores anômalos no campo de endereço MAC — presença de caracteres como ponto e vírgula, pipe, crases, cifrão ou espaços fora do padrão XX:XX:XX:XX:XX:XX esperado é um forte indicador de tentativa de exploração, ainda que não haja um IOC oficial documentado pelo fornecedor ou pela CISA para esta CVE específica.