PHP2Shell: causas y guía de solución

Fuentes verificadas al 22 de octubre de 2026. Audiencia: operadores de aplicaciones PHP, respondedores de seguridad e ingenieros que mantienen compilaciones personalizadas de PHP.

Este artículo resume la causa, el alcance del impacto, el proceso de reparación formal, las medidas de mitigación temporales y la implementación del parche oficial de la vulnerabilidad PHP2Shell. El texto principal se cita utilizando números como S1; Todos los enlaces de fuentes se enumeran en el apéndice al final del texto. El fragmento de configuración es una plantilla de implementación que debe ajustarse según la versión real, la capacidad comercial y la relación de herencia de configuración.

TL;DR: Pasos de reparación y sugerencias

Actualice el tiempo de ejecución de PHP: actualice la rama correspondiente al menos a 8.2.35, 8.3.36, 8.4.27 o 8.5.12. Para los paquetes de distribución, utilice la versión completa del paquete que el proveedor confirme que corrige ambos CVE. S1 S10
Reemplace todos los procesos antiguos: reinicie o reinicie cada PHP worker, servicio de alojamiento y contenedor después de la actualización, y confirme que las instancias antiguas hayan salido.
Verifique a través de la ruta de solicitud Web real: verifique Web SAPI, la versión completa del paquete y la instancia en ejecución. Verificar php -v por sí solo no establece que el servicio en vivo esté arreglado.
Ejecute comprobaciones de regresión empresarial y restaure presupuestos de recursos normales.: inicio de sesión de prueba, manejo de sesiones, cargas, importaciones y manejo de errores. Si el límite de memoria PHP se eliminó temporalmente, restaure un presupuesto finito apropiado después de aplicar el parche.
Si es imposible realizar una actualización inmediata: restrinja el tráfico que no sea de confianza antes de que llegue a PHP. Evalúe la desactivación del progreso de carga y los rastreos fatales de PHP 8.5 como se describe en la Sección 5. Las mitigaciones de configuración y las reglas de WAF tienen cobertura limitada y no pueden reemplazar una actualización. S1 S2 S3

1. Descripción general de la vulnerabilidad y juicio de riesgo

PHP2Shell en este artículo se refiere a dos vulnerabilidades de nivel Critical reveladas oficialmente por PHP el 21 de octubre de 2026. Ambas están relacionadas con la memoria y la gestión del ciclo de vida de solicitudes del motor PHP, lo que plantea el riesgo de ejecución remota de código no autenticado. S1 S2 S3

Proyecto	CVE-2026-109618	CVE-2026-109619
nombre oficial	RCE via OOM corruption	RCE via stale global state
cuestiones centrales	La memoria insuficiente provoca un salto anormal, lo que deja un estado que aún no ha completado la inicialización.	El estado global que permanece en el trabajador apunta a la memoria de solicitud liberada.
Tiempo típico de ocurrencia	El proceso de inicialización, ejecución o limpieza de la solicitud actual.	La solicitud anterior abandona el estado y las solicitudes posteriores lo consumen por adelantado.
¿Es OOM una condición necesaria?	Pertenece al mecanismo desencadenante central de la vulnerabilidad.	No; También pueden estar involucrados otros errores fatales y la limpieza posterior al diagnóstico.
Dirección de reparación fundamental	Maneje de forma segura las fallas de asignación y las cancelaciones de solicitudes	Arreglar la propiedad estatal, el momento de la limpieza y la inicialización temprana
Requisitos de eliminación	debe ser reparado	debe repararse al mismo tiempo

Base: Dos boletines de seguridad oficiales y envíos de correcciones. S2 S3 S4

1.1 Comprensión de las implementaciones afectadas

PHP considera oficialmente que todas las implementaciones de PHP que manejan solicitudes de Web están en riesgo, incluidas PHP-FPM, Apache mod_php, php-cgi, FrankenPHP y LiteSpeed. El ataque mod_php demostrado puede ocurrir antes de que se ejecute el código de la aplicación, por lo que las comprobaciones de inicio de sesión, el middleware del marco y la validación de la carga de la aplicación no pueden cubrir esa ruta. S1

Es necesario distinguir entre “es necesario arreglar la implementación” y “una determinada cadena de ataque ha sido completamente probada”. Anuncio de CVE-2026-109618: FPM saldrá del proceso secundario después de que falle el inicio de la solicitud, bloqueando la ruta de limpieza correspondiente de mod_php después del error de inicio; sin embargo, el camino OOM después de un inicio exitoso todavía está en riesgo. El anuncio también señala que aún no se ha demostrado el exploit FPM completo para este CVE. Esta restricción no se puede utilizar para deducir que FPM es seguro, especialmente CVE-2026-109619 no se puede ignorar. S2 S3

Los límites de permisos inmediatos para una explotación exitosa dependen de la identidad del proceso que aloja PHP y los recursos a los que tiene acceso. En general, se debe prestar atención al código del sitio web, el directorio de carga, las credenciales de la base de datos, los tokens de servicio y las capacidades de acceso a la red interna; La “ejecución remota de código” no significa obtener permisos de root de forma natural. El juicio de consecuencias aquí se basa en el modelo de permisos del proceso y el impacto real debe evaluarse junto con los permisos de implementación.

Los scripts CLI ordinarios y únicos no tienen la misma entrada HTTP; pero los procesos que manejan tareas externas durante mucho tiempo en CLI o en modo integrado aún deben incluirse en el inventario de tiempo de ejecución y ciclo de vida. Solo se actualizan las dependencias CMS, framework o Composer y el motor PHP subyacente no se reemplaza automáticamente.

2. Análisis de causa

2.1 Primero comprenda los dos ciclos de vida.

PHP worker suele gestionar varias solicitudes seguidas. La memoria asignada durante la solicitud se puede liberar de manera uniforme al final de la solicitud, mientras que el propio trabajador y algunos de sus campos globales continúan existiendo.

Por tanto, el motor debe mantener dos restricciones:

Restricción de inicialización: los datos visibles para otros códigos deben estar en un estado que pueda leerse, atravesarse y destruirse de forma segura.
Restricción del ciclo de vida: una vez que se ha liberado la memoria de solicitud, los campos de mayor duración no deben continuar tratando las direcciones dentro de esa memoria como estado válido.

Estas dos restricciones corresponden a los principales modos de falla de los dos grupos de vulnerabilidades. El siguiente proceso es una descripción del mecanismo que combina anuncios y compilación de parches. Esto no significa que cada implementación tenga exactamente el mismo camino accesible. S2 S3 S5

2.2 CVE-2026-109618: OOM interrumpió una actualización de estado inconclusa

La implementación anterior utiliza un salto no local de tipo longjmp() para manejar OOM, y la ruta asociada sale del contexto de ejecución actual a través de zend_bailout(). El peligro es que una parte del código C puede haber publicado un nuevo objeto, matriz o estado de solicitud en otro código, pero aún no ha completado toda la inicialización de los campos; en este momento, cualquier falla en la asignación en el momento relevante puede causar que se omitan los pasos de cierre normales. S2

El proceso de fracaso se puede dividir en cuatro pasos:

Cree o actualice la estructura interna de la solicitud y hágala accesible.
La asignación de memoria posterior falla y se activa OOM.
El flujo de ejecución se aleja de la función actual y el código utilizado originalmente para completar la inicialización o restaurar el estado no se ejecuta.
La limpieza de solicitudes continúa procesando estas estructuras y trata los contenidos no válidos como campos o direcciones válidos.

El problema no es que quedarse sin memoria siempre cause RCE. Más bien, el agotamiento de la memoria cambia el flujo de control y viola las suposiciones del motor sobre estructuras válidas. La asignación fallida no tiene por qué implicar directamente la estructura que finalmente se lee incorrectamente. S2

Por qué las solicitudes más pequeñas también pueden quedarse sin memoria

La cantidad de bytes en el cuerpo de la solicitud y el uso del montón después del análisis no son lo mismo. El campo A puede corresponder a múltiples cadenas, elementos de matriz y objetos de metadatos dentro de PHP; la complejidad estructural de la entrada afectará el grado de amplificación de la memoria.

Los problemas con varias partes enumerados en el anuncio oficial incluyen: espacio en la verificación del tamaño inicial cuando falta la longitud de la declaración disponible, la cantidad de encabezados para una sola parte no es lo suficientemente limitada y los controles de archivos vacíos aún producen metadatos, con nombres anidados que aumentan aún más la carga de trabajo de la matriz. La propia desenredación, decodificación o reasignación de entrada de la aplicación también puede ser una fuente de OOM. S2

De esto se pueden extraer dos conclusiones protectoras:

Las restricciones del cuerpo de la solicitud deben implementarse tanto como sea posible antes de ingresar a PHP, y se debe considerar la longitud de lectura real y la complejidad estructural.
Limitar individualmente el tamaño del archivo, la cantidad de archivos o cerrar solo un portal de carga no puede cubrir todas las fuentes OOM.

Por qué la autenticación de aplicaciones puede llegar demasiado tarde

En mod_php, el cuerpo de la solicitud se puede analizar automáticamente durante la fase de inicialización de la solicitud; Incluso si el inicio falla, se seguirá realizando la limpieza de solicitudes relacionadas. Por lo tanto, las rutas de ataque confirmadas pueden ocurrir antes del código de la aplicación. Para reducir la exposición en esta etapa, se deben colocar restricciones en el proxy inverso, el servidor Web u otro límite que precede al procesamiento de la solicitud PHP. S1 S2

2.3 CVE-2026-109619: La memoria de solicitud ha sido liberada, la referencia global aún está viva

Este problema implica estado de error, sesión, objeto o extensión: el campo se almacena en una ubicación de acceso a largo plazo del trabajador, pero los datos a los que hace referencia el campo pertenecen a una única solicitud. Siempre que la referencia no se limpie adecuadamente antes de que se libere el montón de solicitudes, las solicitudes posteriores pueden encontrar un estado colgante, formando uso después de la liberación. S3

El análisis oficial divide las condiciones de explotación en “productores” y “consumidores”:

rol o condición	significado	Implicaciones para la protección
productor estatal	Coloque el estado propiedad de esta solicitud en una ubicación a la que aún se pueda acceder más adelante.	Para comprobar si la limpieza correspondiente se completa después de una salida anormal
El estado permanece	No se eliminó, o se eliminó y luego se rellenó mediante una operación tardía.	Puede que no sea suficiente borrar una vez en la etapa de cierre anterior
reutilización de trabajadores	El mismo trabajador continúa procesando solicitudes posteriores.	Varios trabajadores son solo una diferencia de programación, no una garantía de seguridad de la memoria
consumidor anticipado	Lea, libere o determine el valor residual antes de que el estado correspondiente se inicialice normalmente.	Debe verificar INI, sesión y otras rutas antes de la inicialización.

Estas condiciones deben cumplirse en combinación; cualquier registro de errores por sí solo no prueba que la vulnerabilidad se haya aprovechado con éxito. S3

No requiere OOM como requisito previo necesario

Los errores fatales pueden interrumpir la publicación y restauración del estado emparejado. Los fallos de compilación o análisis, los errores no detectados, los fallos require y los tiempos de espera de ejecución pueden dejar atrás determinados estados. Los diagnósticos no fatales tardíos en la limpieza también pueden volver a completar la información de error que ya se eliminó. S3

Por lo tanto, cambiar memory_limit a ilimitado no cubre este conjunto de vulnerabilidades.

”Antes de la inicialización” debe tratarse por separado

El momento de los dos tipos de consumidores confirmados es diferente:

EDiagnóstico inicial de INI: algunas configuraciones aplicadas a solicitud emiten advertencias, avisos o desaprobaciones antes de la inicialización normal del ejecutor, y el procesamiento de diagnóstico puede acceder al estado de error anterior.
Progreso de carga de la sesión: la sesión puede procesarse por adelantado durante el proceso de análisis del cuerpo de la solicitud, pero el módulo normal RINIT aún no se ha completado; no se puede inferir que la ruta no existe porque la aplicación no llama explícitamente a session_start(). S3

No todas las configuraciones de INI tienen el mismo tiempo de riesgo. La configuración a nivel de directorio de mod_php y PHP_VALUE / PHP_ADMIN_VALUE pasada por el front-end FPM debe distinguirse de la configuración de inicio ordinaria de php.ini, FPM pool y FPM .user.ini. Estos últimos tienen diferentes tiempos de configuración y no pueden considerarse colectivamente los mismos primeros consumidores. S3

Apagar display_errors, log_errors, reducir error_reporting o usar @ solo afecta la visibilidad del diagnóstico; Es posible que se haya accedido al estado interno relevante antes de decidir si generar el registro. S3

3. Versión de reparación y selección de parches

3.1 Línea base oficial de corrección ascendente

Sucursal actual PHP	La primera versión que incluye esta solución oficial.	Sugerencias
8.2	8.2.35	Actualice a esta versión o a una versión posterior que contenga las mismas correcciones
8.3	8.3.36	Igual que arriba
8.4	8.4.27	Igual que arriba
8.5	8.5.12	Igual que arriba
8.1 y versiones anteriores	El soporte general ascendente ha finalizado	Priorizar la migración a sucursales admitidas; liberación de verificación a corto plazo o puerto posterior del fabricante LTS

La versión y el estado de soporte se basan en el anuncio oficial de PHP, y la fecha límite es el 22 de octubre de 2026. S1

Estos son los umbrales de corrección específicos de cada rama. No pueden ser reemplazados por una declaración de que todas las versiones inferiores a 8.5.12 son vulnerables: versiones como 8.2.35 y 8.4.27 en otras ramas ya contienen las correcciones.

3.2 Verifique la versión completa del paquete de distribución

Las distribuciones a menudo agregan correcciones de seguridad basadas en versiones anteriores. La aceptación también debe verificar la versión de lanzamiento, la fuente del repositorio, la versión completa del paquete y el boletín de seguridad.

Por ejemplo, la versión del paquete de arreglo Ubuntu 24.04 LTS listada para Ubuntu USN-8948-1 es:

8.3.6-0ubuntu0.24.04.13

Su parte ascendente sigue siendo 8.3.6, pero la versión del paquete completo de esa distribución se incluye en este anuncio de solución. Esta conclusión solo se aplica a la distribución correspondiente y al origen del paquete, y no se puede generalizar a ninguna compilación que también muestre 8.3.6. S10

3.3 Elegir el parche correcto

escena	plan prioritario	Puntos clave para la aceptación
Usando el paquete de distribución PHP	Instalar actualizaciones de seguridad publicadas por el fabricante.	El anuncio cubre tanto CVE; la versión completa del paquete es correcta
Utilice el contenedor oficial PHP o la imagen de creación propia	Actualice el tiempo de ejecución base, reconstruya e implemente	La instancia en ejecución usa la nueva imagen; todas las copias antiguas están salidas
Ramas compatibles autocompiladas	Utilice la versión de seguridad oficial de esta rama o el conjunto de parches oficial completo	Coincidencia de ramas, finalización de dependencias, compatibilidad de extensiones y paso de regresión
Sujeto a 7.4, 8.0, 8.1	Priorizar el backport del proveedor; evaluar la rama oficial del código fuente de emergencia si es necesario	Identifique cambios de comportamiento y programe la migración a versiones compatibles

Se han lanzado parches oficiales y las correcciones reales deberían comenzar a partir de estos parches. Los fragmentos de código de la Sección 6 tienen como objetivo ilustrar los aspectos más destacados del diseño y la revisión y no constituyen un parche completo que pueda aplicarse de forma independiente. S1 S4 S6

4. Proceso de reparación formal

4.1 Inventario del tiempo de ejecución que realmente maneja las solicitudes

Se recomienda formar un libro de contabilidad breve en el que conste al menos:

Nombre de dominio de entrada o servicio, servidor de proxy inverso, PHP SAPI.
Rama PHP, versión completa del paquete o resumen de imágenes, código fuente de compilación.
FPM pool, unidad de servicio real, contenedor o Pod, número de réplicas.
Se han cargado extensiones, configuración principal y archivos de configuración adicionales.
¿Existen otras versiones de PHP, copias de implementación antiguas o portales de origen a los que se pueda acceder directamente?

Estas son sugerencias de implementación para que “actualizado” pueda corresponder a cada entrada de tráfico real. Compruebe especialmente si las líneas de comando PHP y Web PHP usan versiones diferentes, la imagen está creada pero el contenedor antiguo aún se está ejecutando, parte del grupo o la copia no se reemplaza, etc.

4.2 Seleccione e implemente la actualización correcta

Confirme la versión de la solución según la Sección 3, preferiblemente utilizando una fuente de paquete confiable existente o una cadena de compilación controlada. El alcance de la actualización debe incluir el componente que realmente aloja la solicitud, como el paquete FPM, el módulo Apache PHP, el binario CGI o la compilación del servicio en el que está integrado PHP.

Antes de actualizar, mantenga la configuración y la lista de paquetes, y verifique el inicio y los servicios clave en un entorno similar al de producción. Para extensiones automantenidas, verifique la compatibilidad de compilación y ejecución correspondiente a la versión PHP. Simplemente elegir una confirmación aparentemente relevante de otra rama no garantiza que se haya implementado todo el conjunto de correcciones.

4.3 Reiniciar o transferir instancias en ejecución

Instalar un archivo y cargar código nuevo en un proceso son dos cosas diferentes. Se debe reiniciar el servicio correspondiente, o se debe completar el reemplazo continuo y se debe confirmar que el trabajador anterior y el contenedor anterior han salido.

Para mod_php, reinicie el proceso Apache que aloja el módulo. Los servicios que incorporan PHP necesitan que se reemplace su proceso de alojamiento. Para FPM, borrar OPcache no reemplaza la actualización del tiempo de ejecución ni la jubilación de trabajadores antiguos.

Cuando se utiliza una conmutación elegante, es necesario comprobar si el proceso de generación anterior todavía maneja conexiones largas o solicitudes pendientes. El registro de aceptación debe incluir el servicio real, la versión de implementación, el tiempo de finalización del cambio y los resultados de salida de la instancia anterior.

4.4 Verificar mediante solicitudes Web reales

Se recomienda combinar las siguientes pruebas en lugar de confiar únicamente en un único comando de versión:

evidencia	¿Qué se puede probar?	No puedo probar nada solo
Administrador de paquetes o metadatos de imágenes	Fuentes de instalación y compilaciones completas	El tráfico se ha cambiado a esta instancia.
Estado del proceso y de la implementación	trabajador o contenedor completa el reemplazo	La entrada exterior debe dirigirse hacia él.
Resultados de diagnóstico restringidos a los que se accede a través del portal real	Web SAPI real y configuración en ejecución	Si el puerto de lanzamiento cubre dos CVE
Anuncio del proveedor o registro de parche completo	Esta corrección de errores está incluida en esta compilación.	Todas las réplicas están implementadas.

PHP_VERSION, PHP_SAPI, los archivos de configuración cargados y las configuraciones de emergencia se pueden verificar a través de capacidades de diagnóstico internas existentes o portales de diagnóstico temporales y de acceso controlado. Asegúrese de que CDN o el caché de la página no devuelvan la solicitud directamente; elimine la entrada de diagnóstico temporal cuando esté completa.

php -v generalmente solo indica el binario CLI seleccionado actualmente por el shell; Los comandos como php-fpm -i no equivalen a verificar el trabajador existente que está recibiendo tráfico. No exponga la página phpinfo() completa a la red pública durante mucho tiempo.

4.5 Verificaciones de regresión empresarial y eliminación de configuraciones de emergencia

Verifique el inicio de sesión normal, la lectura y escritura de sesiones, los formularios y cargas, la importación, el manejo de errores y la estabilidad de los trabajadores en torno a las funciones afectadas por este cambio. Compruebe si la tasa de error, el retraso de respuesta, el pico de memoria, la salida del proceso y la frecuencia de reconstrucción son anormales.

Si se configura temporalmente memory_limit=-1, el presupuesto limitado que coincide con la capacidad comercial se restaurará después de que el parche oficial entre en vigor; Si se establece pm.max_requests=1, la configuración del ciclo de vida evaluado por capacidad se restaurará después de que se confirme la reparación. Los límites de tamaño de entrada y los controles de acceso a la fuente se pueden conservar según lo dicten las necesidades comerciales.

Si surgen problemas de compatibilidad durante la actualización, se debe dar prioridad a suspender el portal afectado, restringir su acceso externo o ajustar la aplicación antes de revertirla. Permitir directamente que el tiempo de ejecución no reparado vuelva a servir a la red pública reabrirá el riesgo original.

5. Medidas de mitigación cuando no es posible una actualización inmediata

Esta sección está destinada a reducir la exposición a corto plazo o mejorar la disponibilidad. Cada medida sólo cubre un camino específico, y una combinación de múltiples medidas no equivale a una reparación completa. S1 S2 S3

5.1 Priorizar controles de tráfico antes de PHP

Si el servicio lo permite, restrinja temporalmente los puntos finales sensibles a fuentes confiables o aplique el control de acceso antes de PHP. Para cargas de trabajo de carga, limite el tamaño del cuerpo de la solicitud, el recuento de campos, el recuento de piezas, los encabezados por parte y la profundidad de anidamiento. Los servicios que no necesitan multiparte pueden rechazarlo en el frontend. S2

Estas restricciones cubrirán todas las entradas a PHP. Solo al interceptar el URL llamado “cargar” se perderán otras entradas que aún son analizadas automáticamente por PHP en el cuerpo de la solicitud. Para casos como transferencias fragmentadas, falta de longitud declarada disponible, etc., el límite debe basarse en el tamaño de lectura real; la aplicación también debe tener su propio presupuesto de tamaño de salida al descomprimir o expandir el contenido nuevamente.

Plantilla de configuración 5.2 FPM pool

Coloque las siguientes configuraciones en la sección de configuración FPM pool que realmente atiende las solicitudes, no palabra por palabra en php.ini. Los valores de 8M y 4M son ejemplos para ajustarse a la carga de trabajo. Deje espacio para campos de formulario y límites de varias partes al limitar toda la solicitud POST. S11 S12

; Temporary mitigation: evaluate capacity before applying.
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 4M
php_admin_flag[session.upload_progress.enabled] = off

Solo PHP 8.5, más:

php_admin_flag[fatal_error_backtraces] = off

Las funciones y límites de cada uno son los siguientes:

Configuración	efecto esperado	Descripción de las restricciones que deben mantenerse
`memory_limit=-1`	Elimine la predecible condición de activación del límite superior de memoria de solicitud PHP	No previene el error de asignación subyacente; cancelar el presupuesto original puede aumentar el riesgo de agotamiento de la memoria e interrupción del servicio.
Más pequeño `post_max_size`	Reducir el tamaño de los datos que ingresan al proceso de análisis.	El analizador no reparado tiene una brecha conocida; La amplificación de la memoria no se puede prevenir de forma independiente.
`upload_max_filesize < post_max_size`	Limite el tamaño de un solo archivo y reserve el espacio superior de la solicitud	No restringe todos los campos, metadatos o asignaciones en la aplicación
Cerrar el progreso de la carga	Bloquear la ruta relacionada con la sesión confirmada	No cubre otras variantes de estado global.
PHP 8.5 cerrar rastro fatal	Bloquear productores de estado relacionados confirmados	No cubre otros caminos como sesión.

Los límites de la medida surgen del anuncio oficial; Para conocer la sintaxis del grupo y la semántica de configuración a nivel de administración, consulte el manual PHP. S1 S2 S3 S11

Las aplicaciones a través de ini_set() no pueden anular la configuración de nivel de administración php_admin_*. Todas las configuraciones entrantes de grupo, nivel de directorio y front-end aún deben revisarse para confirmar que los valores en las solicitudes reales sean los esperados. Después de la modificación, reconstruya todos los trabajadores para evitar que los procesos existentes sigan manteniendo el estado anterior.

Si elige modificar php.ini directamente, la sintaxis debe cambiarse a:

memory_limit = -1
post_max_size = 8M
upload_max_filesize = 4M
session.upload_progress.enabled = Off

A diferencia de php_admin_value en el grupo, simplemente configurar memory_limit=-1 en php.ini no evita que la aplicación lo modifique nuevamente. Se debe verificar el marco, el código de la aplicación y otras configuraciones para ver si han restablecido el valor limitado; cuando se requiera cumplimiento, utilice la configuración de nivel de administración adecuada para el SAPI actual y verifique el valor efectivo real. S11 S12

Agregue fatal_error_backtraces = Off solo para PHP 8.5. No utilice ini_set() a nivel de aplicación como solución alternativa para deshabilitar el progreso de carga y no confíe en FPM .user.ini para hacerlo efectivo antes del análisis de solicitudes. S1 S3

5.3 Administre el costo de eliminar los límites de memoria PHP

memory_limit=-1 es una mitigación de ruta temporal para entornos no reparados y no debe copiarse como configuración predeterminada a largo plazo. Cuando una aplicación o solicitud se sale de control, puede consumir más memoria del host. Por lo tanto, antes de su uso, debe evaluar la cantidad de concurrencias, el pico de trabajador único y la capacidad total del servicio, e implementar límites de entrada de front-end. S2

Los límites de memoria de contenedor o grupo c pueden proporcionar límites de disponibilidad, pero no garantizan que las asignaciones nunca fallen; todo el contenedor, el maestro y todos los trabajadores también pueden ser despedidos cuando se activa el límite. La granularidad del aislamiento y las estrategias de terminación deben evaluarse junto con la implementación y no se pueden considerar una protección completa para estos dos CVE. S2

No reemplace las estrategias anteriores con RLIMIT_AS, RLIMIT_DATA o las restricciones de espacio de direcciones de proceso correspondientes; pueden causar directamente que la asignación subyacente falle en la aún problemática ruta OOM. S2

Ejemplo de configuración de 5.4 Nginx

Aplicable a la implementación donde Nginx reenvía solicitudes a PHP-FPM. Se puede configurar en el nivel de configuración del servicio de hosting real:

client_max_body_size 8m;
fastcgi_request_buffering on;

client_max_body_size limita el tamaño del cuerpo de la solicitud; fastcgi_request_buffering on permite que Nginx lea primero el cuerpo completo de la solicitud y luego lo envíe al backend de FastCGI. Es necesario verificar si tiene efecto en un determinado server o location junto con las relaciones de herencia y cobertura existentes. S13 S14

Solo cuando el negocio no necesita multipart, puede agregar una regla de rechazo a la entrada de servicio correspondiente:

if ($http_content_type ~* "multipart/form-data") {
    return 403;
}

Esta es una plantilla de restricción de entrada simple que utiliza if y return, no una regla de filtrado general para vulnerabilidades del analizador. Verifique la sintaxis de configuración y las solicitudes normales antes de la implementación, y verifique si el error_page personalizado redirige las solicitudes 403 a PHP. La coincidencia de cadenas no ofrece garantías completas sobre todas las diferencias de análisis. S15

Además, estas configuraciones no limitan automáticamente la cantidad de datos, la cantidad de campos o la cantidad de objetos PHP que la aplicación puede descomprimir; las empresas que necesitan realizar cargas deben utilizar restricciones adicionales que comprendan la estructura de sus solicitudes.

5.5 Mitigación opcional: una solicitud por trabajador FPM

Para implementaciones FPM que pueden permitirse los gastos generales, se pueden evaluar configuraciones a corto plazo:

pm.max_requests = 1

Y reconstruir al trabajador existente. Bloquea la cadena de solicitudes cruzadas descrita en el nivel de reutilización de los trabajadores, pero aumentará la sobrecarga de creación e inicialización de procesos; al mismo tiempo, no puede reparar la misma solicitud OOM y los problemas de limpieza de CVE-2026-109618. Cuando el valor es menor pero mayor que 1, todavía hay una ventana de reutilización de solicitudes. S3 S11

Límites de cobertura de 5.6 WAF y Cloudflare

Cloudflare ha anunciado acuerdos de implementación para la protección contra PHP2Shell, incluido el plan Free. Al utilizar sus servicios, debe verificar si el tráfico real pasa a través del proxy, si las reglas de protección están vigentes y si el sitio de origen se puede omitir directamente; para planes pagos, también debe verificar la configuración y las excepciones de las Reglas Administradas correspondientes. S16

Algunas de las detecciones descritas por el proveedor utilizan señales de respuesta, por lo que todas las protecciones no pueden interpretarse como “cada ataque se bloquea antes de alcanzar PHP”. WAF puede ayudar a reducir la exposición y proporcionar información de observación, pero aún son necesarias actualizaciones continuas a PHP. S16

5.7 Por qué las medidas comunes son insuficientes

medidas o sentencias	deficiencias
Sólo cerrar `file_uploads`	No se puede cubrir todo el procesamiento multiparte y aplicar su propia ruta OOM
Configuración de `enable_post_data_reading=Off`	Cambie el comportamiento de llenar automáticamente POST/FILES; La aplicación aún puede leer el cuerpo de la solicitud y puede alterar el funcionamiento normal.
Desactive la visualización de errores, registre o use `@`	El procesamiento de diagnóstico interno aún puede acceder al estado colgante
Aumentar la cantidad de trabajadores.	No establecer un mecanismo de limpieza de estado seguro, ni eliminar la reutilización de un solo trabajador.
Configurar solo `disable_functions` o `open_basedir`	Estas limitaciones no solucionan la corrupción de memoria de la capa del motor C
Verifique una versión o una sola copia solo una vez	No se puede demostrar que se hayan reemplazado todas las entradas e instancias en ejecución.
No se ven registros de excepciones	No puede probar que la vulnerabilidad no existe o que no ha sido explotada antes.

Entre ellos, la configuración y el mecanismo de vulnerabilidad de PHP se pueden encontrar en S2 S3 S12; Los juicios sobre los límites de cobertura, aceptación y permiso se basan en las sugerencias de implementación presentadas por estos mecanismos.

6. Ideas de implementación y puntos de revisión del parche oficial.

6.1 Utilice correcciones completas para la rama correcta

La presentación oficial representativa de PHP 8.5 es:

31c0ea7d7ff1d1fccb6492e52dab544011628065
Avoid state corruption via bailout

La confirmación asocia explícitamente dos CVE, tanto para ajustar el mecanismo de salida OOM como para corregir el estado global al que se puede acceder durante la fase de inicialización. Envíe la página con la diferencia completa, consulte S4 S5. Otras sucursales deben usar sus propias versiones de seguridad oficiales o parches correspondientes, y no se puede asumir que los cambios en 8.5 se puedan aplicar directamente a cualquier versión anterior.

6.2 OOM Reparación: primero restaure el estado procesable y luego finalice la solicitud

La implementación formal introduce dos niveles de procesamiento OOM suave y duro: cuando se alcanza el límite suave, se registra el estado pendiente y se realiza una salida controlada en una ubicación segura como VM; la interfaz de asignación fallida permite a la persona que llama manejar explícitamente el error. Para las asignaciones que no pueden devolver fallas directamente, si se espera que se supere un umbral estricto más alto, el proceso finalizará directamente para evitar continuar procesando solicitudes en un estado intermedio inseguro. S2 S5

El siguiente es un extracto del código clave en 8.5 diff utilizado para marcar OOM pendiente:

EG(delayed_oom).state = ZEND_OOM_STATE_PENDING;
zend_atomic_bool_store_ex(&EG(vm_interrupt), true);

El manejo de interrupciones VM y otras ubicaciones seguras llaman posteriormente a zend_handle_delayed_oom(). Su contexto de ejecución de código de usuario utiliza una ruta de desenredado controlada; la ruta dura OOM llama a _exit(137). S5

Desde una perspectiva de diseño, los cambios importantes son: evita cruzar arbitrariamente la pila de llamadas C cuando la estructura está en un estado intermedio y coloca la salida en una ubicación que pueda mantener restricciones de estado. Una vez que se activa el límite suave, es posible que se requiera memoria adicional para completar el proceso, por lo que el nuevo umbral suave no puede entenderse como un límite superior absoluto para la memoria total del proceso.

Tampoco se puede resumir como “PHP ha eliminado todos los zend_bailout()”. El parche todavía utiliza mecanismos relevantes en contextos específicos; lo que está arreglado es el peligroso momento de salida y la gestión estatal que lo acompaña. S5

6.3 Actualizar las llamadas de asignación y el análisis multiparte juntos

Si solo cambia una función de asignación para “devolver NULL en caso de falla” y la persona que llama original aún asume que siempre se devuelve un puntero válido, introducirá nuevos accesos a puntero nulo o una limpieza incompleta. La interfaz de asignación de fallas en el parche debe revisarse junto con la verificación de llamadas y la propagación de excepciones. S5

Las correcciones relacionadas con varias partes también incluyen realizar comprobaciones acumulativas basadas en el volumen de lectura real, reducir el procesamiento de encabezados inútiles o duplicados y adoptar una lógica de salida y limpieza consistente cuando OOM está pendiente. Estos cambios reducen la amplificación de recursos y hacen que el analizador cumpla con el nuevo protocolo OOM. S5

Para los equipos que mantienen sus propias sucursales, se recomienda que los siguientes temas sean el foco de la revisión del código:

¿Es el estado visible para el mundo exterior antes de que esté completamente inicializado?
Después de un error de asignación o una excepción de devolución de llamada, ¿la propiedad sigue siendo única e inequívoca?
¿Podrás llegar a la salida de limpieza unificada si fallas a mitad del camino?
¿Puede la función de limpieza reconocer campos no inicializados o liberados?
¿El presupuesto de análisis se basa en el volumen de procesamiento real, no solo en las solicitudes de confianza?
¿Todas las personas que llaman han manejado el nuevo valor de retorno de falla?

Estas son preguntas de revisión resumidas según el mecanismo de corrección y no son la conclusión de una auditoría que se haya completado para una base de código no proporcionada.

6.4 Corrección de solicitudes cruzadas: inicialización antes, limpieza final más tarde

Correspondiente a CVE-2026-109619, el parche ajusta múltiples límites del ciclo de vida al mismo tiempo. Los archivos y operaciones que se enumeran a continuación toman como ejemplo la diferencia oficial PHP 8.5. S5

ubicación	cambiar de dirección	Problema resuelto
`Zend/zend_execute_API.c`, etc.	Restablecer el estado del ejecutor, como errores, excepciones, controladores, objetos, etc.	Una vez finalizada la solicitud, todavía quedan referencias antiguas a las que se puede acceder en la siguiente solicitud.
Ruta de inicio de `main/main.c`	Llame a `php_basic_early_rinit()` antes de que se active SAPI	Cuando ocurre un consumidor temprano, el estado subyacente relevante aún no se ha inicializado.
Cerrar ruta de `main/main.c`	Destruye HTTP globals y márcalo como indefinido	El valor liberado todavía se considera un objeto válido.
antes de que finalmente se libere el montón de solicitudes	Limpiar el último mensaje de error nuevamente	Los diagnósticos de limpieza tardíos vuelven a completar el estado de error
`ext/session/session.c`	progreso de carga La ruta inicial se inicializa globalmente en la primera sesión	Módulo normal RINIT al que se accedió anteriormente en estado antiguo
Código relacionado con la serialización	Limitar el análisis de clases y las devoluciones de llamadas de los usuarios en el procesamiento inicial	Ejecutar código de usuario adicional cuando la inicialización no esté completa

Por ejemplo, la secuencia de inicio incluye:

zend_activate();
php_basic_early_rinit();
sapi_activate();

Después de destruir HTTP globals, agregue la marca de error de estado:

zval_ptr_dtor(&PG(http_globals)[i]);
ZVAL_UNDEF(&PG(http_globals)[i]);

Estos extractos ilustran dos principios: inicializar antes del consumidor más temprano posible y realizar la limpieza final después de la última operación que podría recrear el estado. Restablecer un puntero solo durante RINIT normal o una etapa de apagado anterior puede perder accesos anteriores o posteriores. S5

6.5 ¿Por qué no se recomienda realizar su propia “reparación de una sola línea”?

Reemplazar todos los zend_bailout() con _exit(), o simplemente agregar una verificación de puntero nulo en una entrada determinada, abarcaría una gran cantidad de contextos de ejecución diferentes. Pueden omitir otros campos de estado o pueden cambiar la destrucción, las devoluciones de llamada extendidas, el alojamiento de procesos y la semántica de finalización de solicitudes.

Para las versiones compatibles, tienen prioridad las correcciones completas que ya se han publicado. La migración de las sucursales propias debe registrar el origen de los parches, las líneas de base aplicables, el manejo de conflictos y los cambios de comportamiento, y utilizar los casos de uso de regresión ascendente correspondientes y la verificación de este proceso comercial. Las sugerencias aquí provienen de un análisis del alcance del parche en los cambios del asignador, VM, sesión y ciclo de vida de la solicitud. S4 S5

7. Puerto trasero de emergencia de PHP 7.4, 8.0, 8.1

PHP proporciona oficialmente el backport de código fuente mínimo de tres ramas antiguas según la gravedad. Los nombres de las sucursales son:

PHP-7.4-CVE-2026-109618-109619
PHP-8.0-CVE-2026-109618-109619
PHP-8.1-CVE-2026-109618-109619

Para enlaces de sucursales, consulte S7 S8 S9. Estas son entregas de emergencia para esta vulnerabilidad y no representan un retorno al soporte inicial regular para la rama anterior, ni reemplazan otras actualizaciones de seguridad. S1

7.1 Tome el puerto trasero PHP 8.1 como ejemplo

Las presentaciones relevantes para PHP 8.1 son:

1d7dec178a094e6e75b229ce22754045f8c6070a

Su estrategia favorece la falla rápida: llamar a _exit(1) después de generar diagnósticos en la ruta OOM correspondiente, e incluir el estado global y otras correcciones relevantes; mientras se deshabilita internamente el procesamiento correspondiente del progreso de carga de la sesión. Para el envío de código fuente relevante, consulte S6.

Esta es una diferencia de comportamiento con respecto al diseño retrasado OOM más completo en la rama compatible. El hecho de que la configuración todavía muestre que el progreso de la carga está activado no significa que el comportamiento de procesamiento interno después de este backport permanecerá sin cambios.

7.2 El precio que debe aceptar al implementar

Salir del proceso directamente puede hacer que la solicitud actual falle, omitiendo las devoluciones de llamada de cierre normales de PHP y parte del cierre de la aplicación; si el host adopta un modelo de subproceso, también es necesario evaluar el impacto de la salida de todo el proceso del host en otros trabajos concurrentes. También se debe incluir en la verificación si el administrador del proceso puede iniciar el proceso de reemplazo a tiempo.

Por lo tanto, los usuarios de versiones anteriores deben considerar en orden:

Migre a la rama PHP compatible y su versión fija.
Utilice una versión que cubra explícitamente tanto la actualización del fabricante CVE como la LTS.
Si realmente está sujeto a la versión anterior del código fuente, utilice el backport oficial de emergencia de la versión coincidente para verificar los cambios completos y la compatibilidad, y organizar la migración posterior.

El “backport mínimo” aquí describe la compatibilidad y el alcance de implementación seleccionados por el funcionario y no debe interpretarse automáticamente como “correcciones de vulnerabilidades incompletas conocidas”. Debe juzgar según el código fuente de la rama correspondiente y el anuncio del fabricante, y no eliminar los cambios de soporte usted mismo. S1 S6

8. Criterios de aceptación e inspecciones de seguimiento

Se recomienda utilizar los siguientes resultados como base para completar esta reparación:

Artículos de aceptación	Estándares de finalización
cobertura de vulnerabilidad	El anuncio de compilación o proveedor corrige explícitamente CVE-2026-109618 y CVE-2026-109619
Cobertura de implementación	Todos los portales, grupos, servicios y réplicas utilizan el tiempo de ejecución reparado.
El proceso entra en vigor	El antiguo trabajador, el antiguo proceso de host y el antiguo contenedor salen
Verificación de solicitud auténtica	SAPI confirmado, creado y configurado con el enlace Web real para eliminar la dirección errónea del caché
disponibilidad de negocios	Las funciones clave como sesión, carga, importación y manejo de errores han regresado con normalidad.
Fin de las medidas temporales	Las configuraciones de memoria ilimitada y reciclaje de trabajadores extremos se han restaurado según el plan de capacidad o tienen un motivo claro para conservarlas.
Evidencia de cambio	Registre la versión del paquete o el resumen de la imagen, el alcance de la actualización, el tiempo de finalización y los resultados de la verificación.

Lo anterior son sugerencias para la implementación. Si necesita verificar el comportamiento de OOM, una salida anormal o parches personalizados, debe utilizar pruebas de regresión ascendentes o inyección de fallas controladas en un entorno aislado para evitar crear repetidamente un agotamiento de la memoria en el entorno de producción como método de aceptación.

Verifique también los eventos fatales PHP, falla del trabajador, reinicio anormal, tasa de error de solicitud y WAF antes y después de la actualización. Los registros sólo pueden proporcionar pistas de investigación: la aparición de OOM no significa que haya sido explotado y la falta de alarmas no prueba que no se haya producido ninguna explotación. La actualización corrige rutas de vulnerabilidad que se pueden alcanzar en el futuro; Si se encuentran anomalías como manipulación de archivos o fuga de credenciales, se deben llevar a cabo investigaciones de incidentes por separado.

Apéndice: fuentes citadas y enlaces

Todos los enlaces de origen se recopilan a continuación. Los avisos, parches y guías de proveedores reflejan comprobaciones a partir de O22 de octubre de 2026; Las implementaciones posteriores deben buscar actualizaciones del proveedor. Las citas numeradas en el texto se refieren a estas entradas.

S1 — PHP boletín de seguridad oficial y versión de reparación

Fuente: Proyecto PHP, 21 de octubre de 2026.
Propósito: Alcance del riesgo, cuatro versiones de reparación oficiales, medidas temporales oficiales e instrucciones de backport de emergencia para sucursales antiguas.
Enlace: PHP 2026 This security bulletin está en el archivo del boletín anual

S2 — CVE-2026-109618 Boletín Técnico Oficial

Fuente: php/php-src GitHub Security Advisory, 21 de octubre de 2026.
Identificación: GHSA-w8hw-w9fx-j79w.
Propósito: Límite de cobertura para OOM, amplificación multiparte, diferencia y mitigación de SAPI.
Enlace: RCE via OOM corruption

S3 — CVE-2026-109619 Boletín Técnico Oficial

Fuente: php/php-src GitHub Security Advisory, 21 de octubre de 2026.
Identificación: GHSA-6wmf-4rv5-p3rp.
Propósito: estado pendiente de solicitudes cruzadas, productores y consumidores, inicialización temprana, mitigación de configuración.
Enlace: RCE via stale global state

S4 — Envío de corrección oficial de PHP 8.5

Fuente: php/php-src.
Enviar: 31c0ea7d7ff1d1fccb6492e52dab544011628065.
Propósito: Confirmar el envío formal para corregir dos vulnerabilidades al mismo tiempo y explicar la dirección general del cambio.
Enlace: Avoid state corruption via bailout

S5 — PHP 8.5 Oficialmente restaurado y completo diferencial

Fuente: diferencia de la misma presentación oficial.
Propósito: Verificar la implementación específica del asignador, VM, HTTP globals, sesión, serialización y ciclo de vida de la solicitud.
Enlace: official complete diff

S6 — Envío oficial del backport de emergencia de PHP 8.1

Fuente: php/php-src.
Enviar: 1d7dec178a094e6e75b229ce22754045f8c6070a.
Propósito: Verificar la salida rápida de ramas antiguas y cargar cambios de comportamiento en progreso.
Enlace: PHP 8.1 Emergency backport submission
Enlace: corresponds to complete diff

S7 — PHP 7.4 sucursal oficial del backport de emergencia

Fuente: ramas del código fuente php/php-src, PHP enumeradas en el boletín de seguridad oficial.
Enlace: PHP-7.4-CVE-2026-109618-109619

S8 — PHP 8.0 sucursal oficial del backport de emergencia

Fuente: ramas del código fuente php/php-src, PHP enumeradas en el boletín de seguridad oficial.
Enlace: PHP-8.0-CVE-2026-109618-109619

S9 — PHP 8.1 sucursal oficial del backport de emergencia

Fuente: ramas del código fuente php/php-src, PHP enumeradas en el boletín de seguridad oficial.
Enlace: PHP-8.1-CVE-2026-109618-109619

S10 — Ubuntu Boletín de Seguridad USN-8948-1

Fuente: Canonical / Ubuntu, 21 de octubre de 2026.
Propósito: Lanzar ejemplos de backport y versiones completas de paquetes.
Enlace: USN-8948-1: PHP vulnerabilities

S11 — Manual de configuración de PHP-FPM

Fuente: Documento oficial PHP.
Propósito: Semántica de configuración como php_admin_value, php_admin_flag, pm.max_requests, etc.
Enlace: PHP-FPM Configuration

S12 — PHP Manual de configuración principal INI

Fuente: Documento oficial PHP.
Finalidad: Definición y alcance del cuerpo de la solicitud, carga, memoria y configuración de lectura automática de POST.
Enlace: Description of core php.ini directives

S13 — Nginx solicita límite de tamaño corporal

Fuente: Documento oficial Nginx.
Propósito: El significado de client_max_body_size y los niveles de configuración disponibles.
Enlace: ngx_http_core_module / client_max_body_size

S14 — Búfer de solicitud Nginx FastCGI

Fuente: Documento oficial Nginx.
Propósito: La secuencia de procesamiento y función de fastcgi_request_buffering.
Enlace: ngx_http_fastcgi_module / fastcgi_request_buffering

S15 — Nginx Condición e instrucciones de devolución

Fuente: Documento oficial Nginx.
Propósito: Sintaxis de configuración de if y return.
Enlace: ngx_http_rewrite_module

Instrucciones de protección S16 — Cloudflare PHP2Shell

Fuente: Blog oficial Cloudflare.
Propósito: Descripción de su alcance de implementación WAF, disposición del plan Free y mecanismo de detección.
Enlace: Cloudflare deploys protections against php2shell vulnerability