dinosn/cve-2026-75650-magento-validation-lab# Laboratoire Docker pour valider la primitive d'exécution PHP au niveau composant CVE-2026-75650 de Magento et le correctif Adobe VULN-39341.
Ce laboratoire autonome reproduit la primitive d'exécution PHP au niveau composant StyleSmuggler sur un checkout Magento Open Source 2.4.9 épinglé à une révision, puis prouve que le correctif VULN-39341 d'Adobe bloque l'entrée identique.
La preuve est non destructive : le PHP inclus ne peut écrire qu'un seul marqueur aléatoire dans /tmp. Il ne peut pas exécuter de commande, télécharger de fichier, ouvrir un callback ou accepter une charge utile fournie par un opérateur.
Le laboratoire fournit :
755e34dd689021c5165db9d35ecff74f7dc51527 ;Le laboratoire ne prétend pas disposer d'un exploit HTTP non authentifié standard. La sonde de composant démarre au niveau du modèle réel de modèle d'e-mail, prouvant ainsi le sink dangereux et la limite du correctif, et non le connecteur réseau-vers-modèle manquant. Aucune route HTTP synthétique n'est ajoutée.
À utiliser uniquement sur des systèmes que vous possédez ou pour lesquels vous êtes explicitement autorisé à tester. Ne placez pas la sonde PHP sous une racine web de production. Pour une installation réelle, utilisez le validateur en lecture seule ou validez un clone de staging jetable.
Exigences :
Seule la passerelle storefront en mode développeur est publiée, et uniquement sur loopback (127.0.0.1:8096 par défaut). Une seconde passerelle nginx non exposée sélectionne la gestion d'erreurs de production standard afin que le test de rapport reçoive l'identifiant de rapport normal de Magento. MariaDB, Redis, OpenSearch, PHP-FPM et cette passerelle de rapports ne sont pas exposés au réseau hôte.
cd docker-lab
cp .env.example .env
docker compose up -d --build
docker compose logs -f php
Le clonage initial de Magento, l'installation des dépendances et l'installation de l'application prennent normalement 15 à 40 minutes. Lorsque le journal PHP affiche Ready, exécutez :
docker compose exec -T php bash /lab/scripts/run-ab.sh
Ou utilisez les cibles pratiques :
make up
make wait
make ab
La commande A/B tente toujours de laisser la source dans l'état corrigé.
Le test ne réussit que lorsque les deux moitiés testées indépendamment se comportent comme prévu :
Rapport non corrigé : raw-tag=true, guard=false
Rapport corrigé : raw-tag=false, guard=true, neutralized=true
Composant non corrigé : marker=true
Composant corrigé : marker=false
[PASS] Le stockage des rapports et l'exécution des composants correspondent aux contrôles A/B requis.
Un HTTP 200, une notification rendue, un rapport d'erreur généré ou une exception levée ne sont pas acceptés comme preuve d'exécution. Les vérifications du rapport et de l'exécution restent séparées : leur succès conjoint n'invente pas le connecteur HTTP standard non prouvé.
make vulnerable
make report # attendu : balise brute préservée, aucune garde d'exécution
make probe # attendu : execution_observed=true et code de sortie 0
make patched
make report # attendu : garde de sortie présente, balise de charge utile neutralisée
make probe # attendu : execution_observed=false et code de sortie 2
make probe renvoyant 2 dans l'état corrigé est le résultat négatif attendu ; make ab gère les deux codes de sortie et ne renvoie 0 que lorsque l'A/B complet réussit.
Cette vérification ne démarre jamais Magento et n'exécute pas de code depuis l'arbre monté. Le conteneur n'a pas de réseau, pas de capacités Linux, un système de fichiers racine en lecture seule et un montage cible en lecture seule.
make validate TARGET=/chemin/absolu/vers/magento
Verdict attendu entièrement corrigé :
Summary: 9/9 contrôles présents
Verdict: FULL_CONTROL_SET_PRESENT
Tout résultat inférieur est signalé comme FULL_CONTROL_SET_NOT_CONFIRMED, et non automatiquement comme exploitable. Confirmez l'édition/version Commerce exacte et appliquez le correctif correspondant à la version d'Adobe via son processus de déploiement pris en charge.
Le nom plus exact est sonde d'exécution de code de composant à marqueur uniquement. Une RCE distante de bout en bout nécessite qu'une requête distante standard produise son propre marqueur ou callback indépendant sur la build testée.
Voir Notes techniques pour le flux de données, les neuf contrôles du correctif et le tableau de force de preuve. Les résultats exacts testés sont consignés dans VALIDATION.md.
Utilisez le bulletin officiel et le correctif correspondant à la version déployée :
Le correctif intégré ici est mappé par chemin uniquement pour le laboratoire public monorepo 2.4.9. Ne l'appliquez pas directement à une installation Composer de production. L'application du correctif ne supprime pas non plus un implant déjà présent ni ne restaure des identifiants exposés.
make down # préserver les volumes
make reset # supprimer la source, la base de données et les volumes OpenSearch de ce laboratoire