dinosn/cve-2026-75650-magento-validation-labDocker lab per validare la primitiva di esecuzione PHP a livello di componente Magento CVE-2026-75650 e la patch Adobe VULN-39341.
Questo laboratorio autonomo riproduce la primitiva di esecuzione PHP a livello di componente StyleSmuggler su un checkout di Magento Open Source 2.4.9 bloccato a una revisione specifica, e poi dimostra che la patch VULN-39341 di Adobe blocca l'input identico.
La prova è non distruttiva: il PHP incluso può solo scrivere un singolo marcatore casuale in /tmp. Non può eseguire un comando, scaricare un file, aprire un callback o accettare un payload fornito dall'operatore.
Il laboratorio fornisce:
755e34dd689021c5165db9d35ecff74f7dc51527;Il laboratorio non dichiara un exploit HTTP non autenticato standard. La sonda del componente parte dal modello reale dei template email, quindi dimostra il sink pericoloso e il confine della patch, non il connettore mancante da rete a template. Non viene aggiunta alcuna rotta HTTP sintetica.
Utilizzare solo su sistemi di tua proprietà o per i quali sei esplicitamente autorizzato a testare. Non posizionare la sonda PHP sotto una web root di produzione. Per un'installazione reale, utilizzare il validatore in sola lettura o validare un clone di staging usa e getta.
Requisiti:
Solo il gateway storefront in modalità sviluppatore viene pubblicato, e solo su loopback (127.0.0.1:8096 di default). Un secondo gateway nginx non esposto seleziona la gestione degli errori di produzione standard, così il test del report riceve l'identificatore di report normale di Magento. MariaDB, Redis, OpenSearch, PHP-FPM e quel gateway dei report non sono esposti alla rete host.
cd docker-lab
cp .env.example .env
docker compose up -d --build
docker compose logs -f php
Il clone iniziale di Magento, l'installazione delle dipendenze e l'installazione dell'applicazione richiedono normalmente 15–40 minuti. Quando il log PHP stampa Ready, esegui:
docker compose exec -T php bash /lab/scripts/run-ab.sh
Oppure usa i target di comodità:
make up
make wait
make ab
Il comando A/B tenta sempre di lasciare la sorgente nello stato patchato.
Il test passa solo quando entrambe le metà testate indipendentemente si comportano come previsto:
Report non patchato: raw-tag=true, guard=false
Report patchato: raw-tag=false, guard=true, neutralized=true
Componente non patchato: marker=true
Componente patchato: marker=false
[PASS] L'archiviazione dei report e l'esecuzione dei componenti corrispondono ai controlli A/B richiesti.
Un HTTP 200, una notifica renderizzata, un report di errore generato o un'eccezione lanciata non sono accettati come prova di esecuzione. I controlli del report e dell'esecuzione rimangono separati: il loro successo congiunto non inventa il connettore HTTP standard non dimostrato.
make vulnerable
make report # atteso: tag raw preservato, nessun guard di esecuzione
make probe # atteso: execution_observed=true e exit 0
make patched
make report # atteso: guard di uscita presente, tag del payload neutralizzato
make probe # atteso: execution_observed=false e exit 2
make probe che restituisce 2 nello stato patchato è il risultato negativo atteso; make ab gestisce entrambi gli stati di uscita e restituisce 0 solo quando l'A/B completo passa.
Questo controllo non avvia mai Magento né esegue codice dall'albero montato. Il container non ha rete, nessuna capability Linux, un filesystem root in sola lettura e un mount di destinazione in sola lettura.
make validate TARGET=/absolute/path/to/magento
Verdetto atteso per patch completa:
Summary: 9/9 controlli presenti
Verdict: FULL_CONTROL_SET_PRESENT
Qualsiasi cosa inferiore viene segnalata come FULL_CONTROL_SET_NOT_CONFIRMED, non automaticamente come sfruttabile. Conferma l'edizione/versione Commerce esatta e applica la patch corrispondente alla versione di Adobe tramite il suo processo di distribuzione supportato.
Il nome più preciso è sonda di esecuzione codice componente solo-marcatore. Una RCE remota end-to-end richiede che una richiesta remota standard produca il proprio marcatore o callback indipendente sulla build testata.
Vedi Note tecniche per il flusso dei dati, i nove controlli della patch e la tabella della forza delle prove. I risultati esatti testati sono registrati in VALIDATION.md.
Usa il bollettino ufficiale e la patch corrispondente alla release distribuita:
La patch incorporata qui è mappata per percorso solo per il laboratorio monorepo pubblico 2.4.9. Non applicarla direttamente a un'installazione Composer di produzione. La patch inoltre non rimuove un impianto già presente né ripristina credenziali esposte.
make down # preserva i volumi
make reset # elimina i volumi di sorgente, database e OpenSearch di questo laboratorio