Dimostrato (confermato) vs. non dimostrato (non verificato)

Tutte le verifiche sono state eseguite in una sandbox di proprietà, isolata dalla rete, contro un upstream mock. La vera API OpenAI non è mai stata chiamata. Gli oracoli di leak erano esclusivamente sintetici.

Confermato (dimostrato dinamicamente):

• Trigger non-admin → lettura lato server di un file locale scelto dall'upstream (percorso arbitrario dimostrato con un marcatore unico per esecuzione; il corpo servito è byte-per-byte uguale al marcatore; marcatore presente solo nel container dell'app, assente sul mock — escludendo che "il mock abbia restituito il proprio file").
• Lettura di settings.php confermata tramite byte-match sha256 (35.182 B) — contenuto mai stampato; le credenziali del DB sono quindi in scope.
• Recupero della risposta di una SSRF HTTP interna da un servizio senza porta pubblica (corrispondenza raw-byte del token interno).
• Confine di autorizzazione: lo stesso account riceve 403 sulla route di configurazione admin (contrasto 200-vs-403).
• Raggiungibilità via HTTP legittimo attraverso un flusso realistico del field-widget "Generate" configurato dall'admin, da parte di un editor senza permessi AI.

Non verificato (esplicitamente non rivendicato):

• Furto di credenziali dai metadati cloud (IMDS) — meccanicamente plausibile dallo stesso sink, non tentato.
• Raggiungibilità dinamica del gemello della classe base — sovrascritta su questo provider (codice morto per questo target); registrata come variante con la stessa causa radice per portare la correzione, non come rivendicazione separata.
• Attivazione passiva dell'automator "solo salvataggio" — testata, negativa. "Solo salvare" non lo attiva.
• XSS persistente (confusione di content-type) e race di concorrenza speech-to-text — piste separate, non provate.

Non interessato: api.openai.com predefinito su TLS. L'impostazione host è controllata da admin / config-sync / deploy — un attaccante non-admin in esecuzione non può modificarla.

Causa radice e direzione della correzione (riassunto)

L'URL della risposta veniva passato a un fetch generico che onora ogni stream wrapper PHP registrato (file, php, http, data, phar, …). response_format ha come default url, quindi il ramo vulnerabile è il percorso predefinito. file:// è il filesystem wrapper predefinito di PHP e non è limitato da allow_url_fopen (una precedente affermazione su "richiede allow_url_fopen" era sbagliata ed è stata ritrattata).

Correggi la primitiva, non solo il punto di chiamata:

1. Smetti di usare un fetch generico per il recupero remoto; usa il client solo-HTTP iniettato.
2. Valida che lo schema sia http/https prima della richiesta; disabilita i redirect (un 30x può rimbalzare su file://).
3. Difesa in profondità: rifiuta gli host risolti privati/link-local/loopback, oppure limita agli host CDN immagini configurati; valida dimensione / content-type / decodifica dell'immagine.
4. Porta la stessa correzione alla classe base così i provider fratelli la ereditano (altrimenti correzione incompleta).
5. I test di regressione sono prima i casi di rifiuto: file://…, http://169.254.169.254/… e un redirect 302→file:// devono essere tutti rifiutati.

Direzione completa: docs/fix-direction.md.

Struttura della directory

La documentazione è attualmente in giapponese (.ja.md); le traduzioni canoniche in inglese sono un TODO. Non inclusi in questo repo: payload armati e qualsiasi PoC pronto all'uso di lettura file. Il reproducer/ pubblico dimostra il meccanismo del difetto contro un mock usando un singolo oracolo benigno (/etc/hostname) — nessuna lettura a percorso arbitrario, nessun recupero di settings.php, nessun IMDS. Non è un'arma contro i siti live. Aggiorna a 1.1.1 / 1.2.2.

Reproducer sicuro

Obiettivo: consentire a un ricercatore di confermare la classe del difetto senza fornire un exploit per target live o esporre segreti. Tutto viene eseguito offline.

• Isolamento: docker compose con l'app e un upstream mock su una rete isolata (--network none per i controlli delle primitive del linguaggio). Nessuna credenziale montata. Il mock non parla mai con la vera API.
• Modello fedele di upstream non affidabile: il mock interpreta "un host che punta a un proxy / gateway self-hosted non affidabile." Viene predisposto out-of-band (non tramite il prompt) per restituire un URL target sintetico — questo codifica il modello di attaccante corretto (l'upstream sceglie l'URL, l'utente si limita a triggerare).
• Solo oracoli benigni:
  • file:///etc/hostname e un marcatore unico per esecuzione scritto solo all'interno del container dell'app → dimostra che l'app ha letto un percorso scelto dall'upstream (marcatore assente sul mock).
  • settings.php verificato tramite byte-match sha256, contenuto mai emesso → dimostra "credenziali DB in scope" senza divulgarle.
  • Un servizio HTTP interno senza porta pubblica → dimostra il recupero di una risposta SSRF interna con un token sintetico.
• Il verdetto è sui byte grezzi, non sull'HTTP 200: successo = corpo servito byte-per-byte uguale al valore sintetico atteso, più un contrasto di autorizzazione 200-vs-403. I codici di uscita sono rigorosi (0 sfruttabile / 1 precondizione / 2 non riprodotto / 3 pulizia fallita / 99 errore). Vedi reproducer/verdict.md.
• Nota di trasparenza: qualsiasi normalizzazione dell'ambiente (es. correzione del proprietario della directory files della sandbox che una precedente esecuzione da root ha lasciato non scrivibile) è documentata e riguarda solo la parte save/serve, non il sink di lettura file stesso. Questo viene dichiarato affinché i revisori non lo leggano come una precondizione truccata.

Vedi reproducer/README.md.

Cronologia della divulgazione

Vedi timeline.md. Riepilogo:

Guida alla rilevazione

Le rilevazioni per i practitioner sono in detections/; la logica in docs/detection-engineering.md. In breve:

• Correla chi ha attivato la generazione di immagini (audit dell'app) con egress anomalo (proxy / EDR) verso 169.254.169.254 / loopback / RFC1918 in una finestra temporale ristretta dopo la chiamata API. Non fare alert sul solo egress.
• Le letture file:// non toccano mai la rete — rileva aperture di file sensibili da parte dei processi web tramite auditing dell'host (auditd/EDR), con baseline così che scattino solo letture fuori pattern all'interno di una richiesta di generazione immagini.
• Caccia retrospettiva ai byte dichiarati image/* i cui magic bytes non sono un'immagine.
• La maggior parte delle integrazioni AI non registra quale utente ha recuperato quale URL — aggiungi un record di audit del fetch {request_id, actor, target_url, scheme, resolved_ip, content_type}. I log standard da soli non lo catturano.

Riferimenti

• OWASP Top 10 A10:2021 — Server-Side Request Forgery
• CWE-918 SSRF · CWE-73 controllo esterno del nome/percorso del file · CWE-441 proxy/relay non intenzionale · CWE-610 riferimento controllato esternamente
• Stream wrapper PHP (file:// è il filesystem wrapper predefinito; non limitato da allow_url_fopen)
• Drupal Security Team — divulgazione coordinata tramite "Report a security vulnerability" del progetto
• Advisory: Drupal SA-CONTRIB-2026-053 — https://www.drupal.org/sa-contrib-2026-053
• CVE: CVE-2026-13233 (CNA: Drupal.org)

Avviso di sicurezza

• La divulgazione è completa (CVE-2026-13233 / SA-CONTRIB-2026-053), quindi i dettagli di prodotto/versione/codice sono pubblici. Aggiorna prima a 1.1.1 / 1.2.2 — i siti non patchati sono ancora in circolazione.
• Il reproducer/ è solo sandbox e usa oracoli sintetici. Non è un exploit per target live e non contiene segreti. Non eseguirlo contro sistemi che non possiedi e che non sei autorizzato a testare.
• Nessun PoC funzionante di lettura file e nessuna evidenza primaria contenente segreti è inclusa qui — deliberatamente, anche post-fix, finché esistono distribuzioni non patchate.

Disclaimer sulla divulgazione responsabile

Tutta la ricerca è stata eseguita dall'autore in una sandbox di propria proprietà, isolata dalla rete, contro un upstream mock — la vera API del vendor non è mai stata contattata e nessun sistema di terze parti è mai stato testato. Il finding è stato segnalato privatamente al Drupal Security Team e pubblicato solo in sincronia con la correzione e l'advisory (SA-CONTRIB-2026-053, CVE-2026-13233); la valutazione del vendor è Moderately critical. I valori CVSS dell'autore sono una autovalutazione provvisoria, non un punteggio ufficiale, e sono stati deliberatamente mantenuti conservativi (nessun CVSS Critical/High) — coerenti con la valutazione media del vendor. Questo materiale ha scopi difensivi ed educativi. Vedi SECURITY.md.