Causa raiz

O painel administrativo do emlog pro traz um assistente de IA que pode executar SQL em nome do administrador via POST /admin/ai.php?action=execute_tool. Diversos problemas se acumulam neste único endpoint:

1. Sem token CSRF. Todos os outros arquivos de ação destrutiva em admin/ chamam LoginAuth::checkToken() primeiro (ex.: admin/media.php:140). admin/ai.php nunca chama.
2. A autenticação é apenas por cookie de sessão (admin/ai.php:152, User::isAdmin()) — sem verificação de Origin/Referer.
3. A barreira de confirmação de gravação é uma string pública fixa no código. include/service/ai.php:594: if (trim($confirm_code) !== 'confirm'). Qualquer requisição forjada simplesmente envia confirm_code=confirm.
4. SQL somente leitura não exige confirmação alguma (include/service/ai.php:578,589) — uma requisição autenticada simples pode executar SELECT em qualquer tabela.
5. Somente a tabela blog é protegida contra gravação (include/service/ai.php:591) — user e todas as outras tabelas são totalmente graváveis.
6. O mascaramento de senha pode ser contornado via alias. O mascaramento só corresponde ao nome literal da coluna de saída password (include/service/ai.php:822-828) — SELECT password AS pwd_hash FROM user retorna o hash bruto.
7. O cookie de autenticação não tem atributo SameSite (include/lib/loginauth.php:99), deixando a janela de carência padrão "Lax+POST" do Chrome (aproximadamente os dois primeiros minutos após o login) como única barreira entre isso e uma entrega cross-site confiável.

Encadeados: uma única requisição forjada do navegador de um administrador lê todas as tabelas (incluindo hashes de senha) e grava em todas as tabelas, exceto blog, incluindo uma sobrescrita direta de user.password.

PoC

Parte 1 — cadeia de impacto bruta (poc_raw_impact.sh)

Isola a primitiva de bypass de SQL/auth da questão de entrega via CSRF. Execute contra uma instância local que você controla:

Ele faz login como admin, extrai os hashes de senha via bypass por alias de coluna, sobrescreve a senha do admin diretamente na tabela user e então faz login novamente com a senha escolhida pelo atacante a partir de um novo cookie jar — provando a assunção total da conta quando uma única requisição autenticada chega ao endpoint.

Parte 2 — entrega real de CSRF entre sites (poc_csrf.html)

Resolve a questão do SameSite com um navegador real, em vez de supor. Sirva o poc_csrf.html de qualquer origem distinta do alvo (um IP diferente já basta — o Chrome trata IPs literais distintos como sites separados) e faça um administrador autenticado abri-lo dentro de aproximadamente dois minutos após o login:

O formulário é enviado automaticamente ao carregar, fazendo POST de uma chamada query_database forjada com confirm_code=confirm entre sites.

Verificado ao vivo: o POST forjado entre sites carregou o cookie de autenticação real do administrador (sec-fetch-site: cross-site, cookie anexado), retornou 200 {"code":0,"msg":"ok",...}, e a linha injetada foi confirmada como presente por meio de uma leitura autenticada subsequente. Repetir a mesma requisição cerca de 48 minutos depois contra o mesmo cookie jar, agora envelhecido, falhou — nenhum cookie foi anexado e o servidor retornou um redirecionamento não autenticado, confirmando que a janela de aproximadamente dois minutos do Lax+POST é a restrição real (refletida em AC:H).

Impacto

• Leitura completa do banco de dados: todas as tabelas/colunas, incluindo hashes de senha e quaisquer segredos em emlog_options (credenciais SMTP, chaves de API, etc.).
• Gravação completa no banco de dados em todas as tabelas exceto blog, incluindo user — sobrescrita de papel/senha/email, demonstrada de ponta a ponta como assunção de conta.
• Limitado a contas com role=admin; writer/editor são bloqueados por User::checkRolePermission(). Não é escalada de privilégio a partir de um papel inferior — transforma um único clique em link malicioso por um admin autenticado em comprometimento total e silencioso do site.

Correção

Adicione LoginAuth::checkToken() ao execute_tool, defina SameSite=Strict no cookie de autenticação e substitua a string estática confirm_code por um token real de uso único por sessão. Detalhes completos de remediação no aviso.

Linha do tempo da divulgação

• 2026-07-31 — Relatado via GitHub Security Advisories, conforme o próprio SECURITY.md do emlog.
• 2026-08-01 — O mantenedor publicou o aviso e solicitou um CVE.
• 2026-08-16 — CVE-2026-73847 atribuído pelo GitHub (CNA).

Nota sobre o crédito: o GitHub como CNA publicou o registro do CVE sem uma entrada credits, apesar de o próprio GHSA creditar e aceitar o relator. Uma solicitação de correção foi enviada para [email protected] em 2026-08-16; este README será atualizado se o registro for corrigido.

Isenção de responsabilidade

Publicado depois que o aviso se tornou público e um CVE foi atribuído, para uso defensivo/educacional. Não execute isto contra uma instância do emlog que você não possua ou para a qual não esteja explicitamente autorizado a testar.