dinosn/cve-2026-75650-magento-validation-labLaboratorio Docker para validar la primitiva de ejecución PHP a nivel de componente CVE-2026-75650 de Magento y el parche Adobe VULN-39341.
Este laboratorio independiente reproduce la primitiva de ejecución PHP a nivel de componente StyleSmuggler en un checkout de Magento Open Source 2.4.9 fijado a una revisión específica, y luego demuestra que el parche VULN-39341 de Adobe bloquea la misma entrada.
La prueba no es destructiva: el PHP incluido solo puede escribir un marcador aleatorio en /tmp. No puede ejecutar un comando, descargar un archivo, abrir un callback ni aceptar un payload suministrado por el operador.
El laboratorio proporciona:
755e34dd689021c5165db9d35ecff74f7dc51527;El laboratorio no afirma un exploit HTTP no autenticado estándar. La sonda de componente comienza en el modelo real de plantilla de correo electrónico, por lo que demuestra el sink peligroso y el límite del parche, no el conector faltante de red a plantilla. No se añade ninguna ruta HTTP sintética.
Úselo solo en sistemas que posea o para los que tenga autorización explícita de prueba. No coloque la sonda PHP bajo una raíz web de producción. Para una instalación real, use el validador de solo lectura o valide un clon de staging desechable.
Requisitos:
Solo se publica la puerta de enlace de la tienda en modo desarrollador, y únicamente en loopback (127.0.0.1:8096 por defecto). Una segunda puerta de enlace nginx no expuesta selecciona el manejo de errores estándar de producción para que la prueba de informe reciba el identificador de informe normal de Magento. MariaDB, Redis, OpenSearch, PHP-FPM y esa puerta de enlace de informes no están expuestos a la red del host.
cd docker-lab
cp .env.example .env
docker compose up -d --build
docker compose logs -f php
El clon inicial de Magento, la instalación de dependencias y la instalación de la aplicación normalmente tardan entre 15 y 40 minutos. Cuando el registro de PHP imprima Ready, ejecute:
docker compose exec -T php bash /lab/scripts/run-ab.sh
O use los objetivos de conveniencia:
make up
make wait
make ab
El comando A/B siempre intenta dejar el código fuente en el estado parcheado.
La prueba solo pasa cuando ambas mitades probadas de forma independiente se comportan como se espera:
Informe sin parche: raw-tag=true, guard=false
Informe parcheado: raw-tag=false, guard=true, neutralized=true
Componente sin parche: marker=true
Componente parcheado: marker=false
[PASS] El almacenamiento de informes y la ejecución de componentes coinciden con los controles A/B requeridos.
Un HTTP 200, una notificación renderizada, un informe de error generado o una excepción lanzada no se aceptan como prueba de ejecución. Las comprobaciones de informe y ejecución permanecen separadas: su éxito conjunto no inventa el conector HTTP estándar no probado.
make vulnerable
make report # esperado: etiqueta sin procesar conservada, sin guardia de ejecución
make probe # esperado: execution_observed=true y salida 0
make patched
make report # esperado: guardia de salida presente, etiqueta del payload neutralizada
make probe # esperado: execution_observed=false y salida 2
Que make probe devuelva 2 en el estado parcheado es el resultado negativo esperado; make ab maneja ambos estados de salida y devuelve 0 solo cuando el A/B completo pasa.
Esta comprobación nunca inicia Magento ni ejecuta código del árbol montado. El contenedor no tiene red, ni capacidades de Linux, un sistema de archivos raíz de solo lectura y un montaje de destino de solo lectura.
make validate TARGET=/ruta/absoluta/hacia/magento
Veredicto esperado completamente parcheado:
Summary: 9/9 controles presentes
Verdict: FULL_CONTROL_SET_PRESENT
Cualquier resultado inferior se informa como FULL_CONTROL_SET_NOT_CONFIRMED, no automáticamente como explotable. Confirme la edición/versión exacta de Commerce y aplique el parche de Adobe correspondiente a la versión mediante su proceso de implementación compatible.
El nombre más exacto es sonda de ejecución de código de componente solo con marcador. La RCE remota de extremo a extremo requiere que una solicitud remota estándar produzca su propio marcador o callback independiente en la compilación probada.
Consulte Notas técnicas para ver el flujo de datos, los nueve controles del parche y la tabla de solidez de la prueba. Los resultados exactos probados se registran en VALIDATION.md.
Use el boletín oficial y el parche que coincida con la versión implementada:
El parche incluido aquí está mapeado por rutas solo para el laboratorio público del monorepo 2.4.9. No lo aplique directamente a una instalación de Composer de producción. El parche tampoco elimina un implante ya presente ni restaura credenciales expuestas.
make down # conserva los volúmenes
make reset # elimina el código fuente, la base de datos y los volúmenes de OpenSearch de este laboratorio