O que foi demonstrado (confirmado) vs. o que não foi (não verificado)

Toda a verificação foi executada em um sandbox próprio, isolado de rede, contra um upstream mock. A API real da OpenAI nunca foi chamada. Os oráculos de vazamento foram apenas sintéticos.

Confirmado (demonstrado dinamicamente):

• Gatilho de não-admin → leitura no lado do servidor de um arquivo local escolhido pelo upstream (caminho arbitrário comprovado com um marcador único por execução; o corpo servido é byte-a-byte igual ao marcador; o marcador está presente apenas no contêiner do app, ausente no mock — descartando "o mock retornou o próprio arquivo").
• Leitura de settings.php confirmada por byte-match sha256 (35.182 B) — conteúdo nunca impresso; credenciais de banco de dados estão, portanto, em escopo.
• SSRF HTTP interna: recuperação de resposta de um serviço sem porta pública (token interno com byte-match).
• Limite de autorização: a mesma conta recebe 403 na rota admin de configuração (contraste 200-vs-403).
• Alcance de HTTP legítimo por meio de um fluxo realista de widget de campo "Generate" configurado por admin, por um editor sem permissões de IA.

Não verificado (explicitamente não reivindicado):

• Roubo de credenciais de metadata de nuvem (IMDS) — mecanicamente plausível a partir do mesmo sink, não tentado.
• Alcance dinâmico do gêmeo na classe base — sobrescrito neste provedor (código morto para este alvo); registrado como uma variante de mesma causa-raiz para portar a correção, não uma reivindicação separada.
• Disparo passivo do automator "apenas salvar" — testado, negativo. "Apenas salvar" não o aciona.
• XSS armazenado (confusão de content-type) e condição de corrida em speech-to-text — pistas separadas, não comprovadas.

Não afetado: o api.openai.com padrão via TLS. A configuração host é controlada por admin / config-sync / deploy — um atacante não-admin em tempo de execução não pode alterá-la.

Causa-raiz e direção da correção (resumo)

A URL da resposta era passada para um fetch de propósito geral que honra todos os stream wrappers registrados no PHP (file, php, http, data, phar, …). response_format tem como padrão url, então o branch vulnerável é o caminho padrão. file:// é o stream wrapper de filesystem padrão do PHP e não é controlado por allow_url_fopen (uma afirmação anterior de que "exige allow_url_fopen" estava errada e foi retratada).

Corrija a primitiva, não apenas o ponto de chamada:

1. Pare de usar um fetch de propósito geral para recuperação remota; use o cliente HTTP-only injetado.
2. Valide se o esquema é http/https antes da requisição; desabilite redirecionamentos (um 30x pode saltar para file://).
3. Defesa em profundidade: rejeite hosts resolvidos privados/link-local/loopback, ou restrinja ao(s) host(s) de CDN de imagens configurado(s); valide tamanho / content-type / decodificação de imagem.
4. Porte a mesma correção para a classe base para que provedores irmãos a herdem (caso contrário, correção incompleta).
5. Testes de regressão são primeiro os casos de negação: file://…, http://169.254.169.254/… e um redirecionamento 302→file:// devem ser todos recusados.

Direção completa: docs/fix-direction.md.

Estrutura de diretórios

A documentação está atualmente em japonês (.ja.md); traduções canônicas em inglês são um TODO. Retido deste repositório: payloads de armamento e qualquer PoC turnkey de leitura de arquivos. O reproducer/ público demonstra o mecanismo do defeito contra um mock usando um único oráculo benigno (/etc/hostname) — sem leitura de caminho arbitrário, sem captura de settings.php, sem IMDS. Não é uma arma contra sites ativos. Atualize para 1.1.1 / 1.2.2.

Reprodutor seguro

Objetivo: permitir que um pesquisador confirme a classe do defeito sem fornecer um exploit para alvo ativo ou expor segredos. Tudo roda offline.

• Isolamento: docker compose com o app e um upstream mock em uma rede isolada (--network none para as verificações de primitivas da linguagem). Nenhuma credencial montada. O mock nunca fala com a API real.
• Modelo fiel de upstream não confiável: o mock faz o papel de "um host apontando para um proxy/gateway auto-hospedado não confiável". Ele é armado fora de banda (não via prompt) para retornar uma URL alvo sintética — isso codifica o modelo de atacante corrigido (o upstream escolhe a URL, o usuário apenas dispara).
• Apenas oráculos benignos:
  • file:///etc/hostname e um marcador único por execução gravado apenas dentro do contêiner do app → prova que o app leu um caminho escolhido pelo upstream (marcador ausente no mock).
  • settings.php verificado por byte-match sha256, conteúdo nunca emitido → prova "credenciais de banco em escopo" sem divulgá-las.
  • Um serviço HTTP interno sem porta pública → prova a recuperação de resposta via SSRF interna com um token sintético.
• O veredito é por bytes brutos, não HTTP 200: sucesso = corpo servido byte-a-byte igual ao valor sintético esperado, mais um contraste de autorização 200-vs-403. Os códigos de saída são estritos (0 explorável / 1 pré-condição / 2 não reproduzido / 3 falha na limpeza / 99 erro). Veja reproducer/verdict.md.
• Nota de transparência: qualquer normalização de ambiente (por exemplo, corrigir o dono do diretório de arquivos do sandbox que uma execução anterior como root deixou sem permissão de escrita) é documentada e afeta apenas o trecho salvar/servir, não o sink de leitura de arquivos em si. Isso é divulgado para que revisores não interpretem mal como uma pré-condição manipulada.

Veja reproducer/README.md.

Linha do tempo da divulgação

Veja timeline.md. Resumo:

Orientações de detecção

As detecções para profissionais estão em detections/; a fundamentação em docs/detection-engineering.md. Em resumo:

• Correlacione quem disparou a geração de imagens (auditoria do app) com egress anômalo (proxy / EDR) para 169.254.169.254 / loopback / RFC1918 em uma janela de tempo curta após a chamada à API. Não alerte apenas por egress.
• Leituras file:// nunca passam pela rede — detecte aberturas de arquivos sensíveis por processos web via auditoria de host (auditd/EDR), com baseline para que apenas leituras fora do padrão dentro de uma requisição de geração de imagem disparem.
• Procure retrospectivamente por bytes declarados como image/* cujos magic bytes não são uma imagem.
• A maioria das integrações de IA não registra qual usuário buscou qual URL — adicione um registro de auditoria de fetch {request_id, actor, target_url, scheme, resolved_ip, content_type}. Apenas logs padrão não vão capturar isso.

Referências

• OWASP Top 10 A10:2021 — Server-Side Request Forgery
• CWE-918 SSRF · CWE-73 controle externo de nome/caminho de arquivo · CWE-441 proxy/relay não intencional · CWE-610 referência controlada externamente
• Stream wrappers do PHP (file:// é o stream wrapper de filesystem padrão; não controlado por allow_url_fopen)
• Equipe de Segurança do Drupal — divulgação coordenada via "Report a security vulnerability" do projeto
• Advisory: Drupal SA-CONTRIB-2026-053 — https://www.drupal.org/sa-contrib-2026-053
• CVE: CVE-2026-13233 (CNA: Drupal.org)

Aviso de segurança

• A divulgação está completa (CVE-2026-13233 / SA-CONTRIB-2026-053), portanto os detalhes de produto/versão/código são públicos. Atualize para 1.1.1 / 1.2.2 primeiro — sites sem patch ainda existem na natureza.
• O reproducer/ é apenas para sandbox e usa oráculos sintéticos. Não é um exploit para alvo ativo e não contém segredos. Não o execute contra sistemas que você não possui e para os quais não está autorizado a testar.
• Nenhum PoC funcional de leitura de arquivos e nenhuma evidência primária contendo segredos estão incluídos aqui — deliberadamente, mesmo após a correção, enquanto existirem implantações sem patch.

Aviso de divulgação responsável

Toda a pesquisa foi realizada pelo autor em um sandbox próprio, isolado de rede, contra um upstream mock — a API real do fornecedor nunca foi contatada, e nenhum sistema de terceiros foi testado. A descoberta foi reportada primeiro em privado à Equipe de Segurança do Drupal e publicada apenas em sincronia com a correção e o advisory (SA-CONTRIB-2026-053, CVE-2026-13233); a classificação do fornecedor é Moderadamente crítico. Os valores CVSS do autor são uma autoavaliação provisória, não uma pontuação oficial, e foram deliberadamente mantidos conservadores (sem CVSS Crítico/Alto) — consistentes com a classificação de faixa média do fornecedor. Este material tem fins defensivos e educacionais. Veja SECURITY.md.