OrcaCyber Research - PHP2Shell: Cómo una solicitud fallida se convirtió en ejecución remota de código

La prueba de concepto de esta investigación se creó con los modelos OrcaCyber Zero y OrcaCyber Ultra. El paquete de investigación documenta el análisis a nivel de código fuente, una reproducción controlada mediante un exploit público adaptado, un artefacto de divulgación de memoria, caídas de procesos y evidencia de ejecución de comandos. Los archivos proporcionados no registran de forma independiente qué pasos realizó cada modelo; la atribución a cada modelo la proporciona el equipo de investigación.

Una condición fatal de falta de memoria debería finalizar una petición de forma segura. Aquí, podía interrumpir PHP mientras el estado nativo solo estaba parcialmente inicializado, dejando referencias que persistían en la siguiente petición. El resultado fue una violación de la vida útil de la memoria entre peticiones, con consecuencias que iban desde la divulgación hasta la ejecución remota de código en el entorno probado.

Evidencia clave de un vistazo

• Objetivo — PHP 8.4.26, Apache/mod_php, un único worker, laboratorio Docker aislado.

• Registros de fallos — Una salida por SIGABRT y tres salidas por SIGSEGV de workers en el extracto proporcionado.

• Respuesta HTTP — 819.200 bytes en el valor de PHPSESSID decodificado de la URL.

• Prueba de ejecución — code>uid=33(www-data) gid=33(www-data) groups=33(www-data)/code>.

• Regresión — El informe describe cuatro intentos fallidos en PHP 8.4.27 parcheado; las ejecuciones sin procesar no se incluyen.

Fuente: archivos cargados REPORT.md, crash_evidence.log, leak_attempt.resp y rce_proof_8426.txt. Los anexos descritos a continuación reproducen esos artefactos como paneles de evidencia compuestos tipográficamente; no son fotografías ni capturas de pantalla nativas de terminal.

1. La vulnerabilidad: fallo de propiedad en el límite de la solicitud

Los dos problemas relacionados tienen que ver con la inicialización de solicitudes interrumpida y los punteros globales del entorno de ejecución obsoletos. En la arquitectura de PHP correspondiente, el manejo de multipart/form-data y las devoluciones de llamada de progreso de carga de sesión pueden ejecutarse antes del código normal de la aplicación del usuario. Una transición excepcional del flujo de control, incluida code>zend_bailout()/code>, puede omitir la limpieza esperada y dejar el estado apuntando a memoria que posteriormente se libera o se reutiliza.

Invariante de seguridad: una referencia global del worker expuesta a la solicitud B nunca debe hacer referencia a memoria cuya propiedad y tiempo de vida terminaron con la solicitud A. El fallo reportado viola ese invariante.

El endpoint demostrado era una página PHP mínima que simplemente devolvía OK; la narrativa del exploit no dependía de endpoints de inyección SQL a nivel de aplicación, inclusión de archivos o deserialización.

2. Secuencia técnica

• A1 — interrupción. El manejo de multipart y del progreso de carga provoca OOM durante la limpieza, lo que deja estado de sesión obsoleto.

• B1 — fuga. Una solicitud posterior hace que la serialización de la cookie de sesión lea más allá de un ID de sesión válido.

• Recuperación de direcciones. Los valores de puntero filtrados se utilizan para inferir la disposición relevante de la biblioteca y el heap en esa compilación.

• A2/B2 — corrupción. Una secuencia adicional de dos solicitudes modela y redirige datos obsoletos utilizados al apagar.

• Resultado. El exploit público adaptado reporta ejecución de comandos como www-data.

Anexos de prueba: lo que realmente muestran los archivos proporcionados

Anexo A — terminación de worker a partir del registro de Apache

• code>[core:notice] [pid 1:tid 1] AH00051: el pid hijo 54 salió con la señal Abort (6), posible coredump en /etc/apache2/code>

• code>[core:notice] [pid 1:tid 1] AH00051: el hijo con pid 55, señal de salida fallo de segmentación (11), posible volcado de memoria en /etc/apache2/code>

• code>[core:notice] [pid 1:tid 1] AH00051: el proceso hijo con pid 58 finalizó con la señal Segmentation fault (11), posible coredump en /etc/apache2/code>

• code>[core:notice] [pid 1:tid 1] AH00051: el proceso hijo con pid 61 terminó con la señal Segmentation fault (11), posible volcado de memoria en /etc/apache2/code>

Extracto tipografiado de crash_evidence.log (23 de octubre de 2026). Múltiples salidas de trabajadores respaldan un fallo de seguridad de memoria; las caídas por sí solas no establecen RCE.

Anexo B — Respuesta HTTP con cookie de sesión anómala

• code>HTTP/1.1 200 OK/code>, con los datos binarios omitidos.

• code>Servidor: Apache/2.4.69 (Debian)/code>

• code>X-Powered-By: PHP/8.4.26/code>

• code>Set-Cookie: PHPSESSID=[datos binarios omitidos]/code>

• Longitud de la cookie codificada: 2,330,754 bytes.

• Valor decodificado de la URL: 819.200 bytes.

Medición calculada directamente a partir de leak_attempt.resp. El valor binario se omite intencionalmente para evitar reproducir cualquier contenido de proceso filtrado.

Anexo C — prueba de ejecución

code>uid=33(www-data) gid=33(www-data) groups=33(www-data)/code>

Contenido exacto de rce_proof_8426.txt, tal como se proporcionó. Respalda el resultado de ejecución reportado, pero no es una transcripción completa de comandos/sesión.

Anexo D — corrección del ciclo de vida de la sesión

• code>static inline void php_rinit_session_globals(void)/code>

• code>@@ -121,6 +120,7 @@ static inline void php_rinit_session_globals(void)/code>

• code>* vuelve a codificar la sesión durante el inicio de la solicitud, antes de RINIT, cuando no hay ningún usuario/code>

• code>/* Se ejecuta antes de RINIT: no se puede invocar código de usuario, véase php_session_unserialize_init() *//code>

• code>/* Esto se ejecuta antes de RINIT, así que debemos limpiarlos antes *//code>

• code>php_rinit_session_globals();/code>

Líneas seleccionadas del diff de código fuente de session.c.diff. Este cambio restablece explícitamente el estado global de la sesión antes de lo que lo hace RINIT normal.

3. Por qué importan las pruebas

La divulgación de memoria proporciona el puente entre la caída de un proceso y una cadena de explotación. Un valor de sesión con un tamaño anómalo y datos binarios incrustados es compatible con que el entorno de ejecución interprete memoria no válida como una cadena Zend. El informe de investigación describe además la extracción de direcciones de código y de montículo a partir de la ventana filtrada. El paquete de evidencias contiene la respuesta sin procesar, pero no un script independiente que demuestre cada dirección recuperada.

El artefacto de RCE muestra el contexto de seguridad de www-data. No establece acceso root, el compromiso de un entorno de producción ni una portabilidad completa a despliegues PHP arbitrarios. La configuración de laboratorio con un solo worker es importante porque la secuenciación de solicitudes y la afinidad de worker afectan al mecanismo.

4. Una corrección del ciclo de vida subyacente, no solo del síntoma

El diff del código fuente proporcionado para el commit de parche de PHP 01a40e89fbfc («Avoid state corruption via bailout») muestra la inicialización temprana de las globales de sesión, cambios en el manejo de OOM del asignador y una lógica de restablecimiento/limpieza más amplia. Estos cambios tienen como objetivo evitar que el estado nativo sobreviva a una solicitud interrumpida en un estado no válido. Corregir solo la ruta de codificación de cookies no restauraría, por sí solo, esta garantía de propiedad de la memoria.

El informe de investigación indica que los intentos contra PHP 8.4.27 no produjeron la cookie anómala, el bloqueo ni la prueba de RCE en cuatro ensayos. Las transcripciones reales de la versión parcheada no están en este paquete, por lo que esa comparación se reporta como una observación del investigador en lugar de como una prueba que pueda inspeccionarse de forma independiente.

5. Acciones defensivas

• Inmediato.Actualice la línea de PHP compatible afectada a su versión con la corrección de seguridad y utilice los avisos del proveedor para confirmar el estado exacto del paquete.

• Reducción de la exposición. Considere restringir las entradas multipart y deshabilitar code>session.upload_progress/code> si no se utiliza; estas medidas no sustituyen al parche.

• Detección. Revise los fallos durante la inicialización de solicitudes, los errores 500 inesperados y los encabezados de respuesta code>Set-Cookie/code> de tamaño excesivo.

• Garantía. Vuelva a probar con grupos de trabajadores representativos de producción y valide que el estado de sesión anterior no pueda persistir entre solicitudes.

6. Metodología de investigación de OrcaCyber

La valiosa tarea de investigación no consiste solo en detectar operaciones inseguras individuales; consiste en rastrear una violación completa de invariantes a través del análisis de solicitudes, el comportamiento del asignador, las variables globales nativas persistentes, la serialización y el apagado. OrcaCyber Zero y OrcaCyber Ultra se utilizaron para crear la PoC en esta investigación, según la atribución del equipo de investigación. El conjunto de artefactos públicos respalda la reproducción técnica, pero no proporciona trazas de ejecución modelo por modelo ni demuestra el descubrimiento autónomo de vulnerabilidades.

Escalera de evidencia: hipótesis sobre el código fuente → desencadenador alcanzable → fallo en tiempo de ejecución → divulgación de información → prueba de ejecución → regresión de la versión corregida. Esta secuencia genera mayor confianza que una descripción de vulnerabilidad o un resultado basado solo en un fallo. También fomenta informar claramente la incertidumbre cuando faltan archivos de código fuente o registros de ejecución sin procesar.

7. Alcance y limitaciones

Esta publicación describe un laboratorio Docker aislado autorizado. El exploit se basa en la investigación PHP2Shell publicada anteriormente, con una adaptación local documentada en el informe suministrado. El paquete incluye scripts, diffs, bytes de respuesta, registros y salida de prueba, pero omite el checkout completo del exploit upstream, las capturas de pantalla nativas y las transcripciones completas sin procesar de la regresión de parches. No se afirma que se haya comprometido a ninguna víctima ni cliente del mundo real.

Fuentes y artefactos

Principal: se proporcionó php2shell-report-bundle.tar.gz (REPORT.md; report-CVE-2026-109618.md; report-CVE-2026-109619.md; crash_evidence.log; leak_attempt.resp; rce_proof_8426.txt; diferencias del código fuente de PHP). Contexto público: avisos de seguridad de PHP GHSA-w8hw-w9fx-j79w y GHSA-6wmf-4rv5-p3rp; anuncios de versiones de seguridad de PHP. Atribución pública del exploit: 9bie/php2shell-bypass-aslr-exp. Repositorio de investigación: orcacyber-php2shell-research.

Conclusión: una solicitud falló; un puntero sobrevivió; la siguiente solicitud confió en él. La parte difícil de entender esta vulnerabilidad es establecer esa conexión con evidencia observable.