Infraestructura · Seguridad

PHP2Shell: actualiza PHP ya

22 oct 2026 · 6 min de lectura · Infraestructura · José Areche

El 21 de octubre de 2026 el proyecto PHP publicó una alerta de seguridad que conviene leer con calma y aplicar con prisa: dos fallos críticos que, en las condiciones descritas por el equipo, pueden permitir ejecución remota de código sin autenticación en servidores que atienden peticiones web con PHP.

Los identifican como CVE-2026-109618 y CVE-2026-109619. En la conversación técnica ya se les conoce de forma informal como «PHP2Shell». Yo no voy a explicar cómo se explotan. Lo útil, desde el lado de quien opera, es otra cosa: qué versiones están parcheadas, cómo comprobar que tu servidor ya las corre y qué hacer mientras tanto.

La PHP Foundation lo resume sin rodeos: si corres PHP en internet, actualiza ahora.

01 / QUÉ SALIÓDos fallos, un solo mensaje: parchea

Las versiones que incluyen el arreglo son:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

En términos muy altos (sin entrar en la mecánica del ataque):

• CVE-2026-109618 se relaciona con corrupción de memoria cuando PHP corta una petición por límite de memoria (OOM).
• CVE-2026-109619 se relaciona con estado interno que puede quedar «viejo» entre peticiones del mismo worker tras ciertos errores fatales.

Afectan a cualquier instalación que sirva peticiones web con PHP: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP, LiteSpeed, etc. El propio aviso marca mod_php como el escenario de mayor riesgo. No hace falta que tu aplicación tenga un bug propio: el problema está en el motor.

Y ojo con esto: no es solo «las versiones recientes sin el último parche». Los avisos cubren también ramas viejas. Si tu servidor sigue en PHP 7.x, 8.0 u 8.1 —o incluso más atrás, desde la época de PHP 5.4— también está en el mapa de riesgo. La diferencia es que, para esas ramas, el proyecto PHP ya no publica un arreglo oficial.

02 / LA ÚNICA SOLUCIÓN COMPLETAActualizar y reiniciar workers

El aviso oficial es claro: no hay mitigación completa. Actualizar es la única opción segura.

1. Sube a una de las versiones parcheadas de tu rama (8.5.12, 8.4.27, 8.3.36 u 8.2.35), o al paquete equivalente de tu distribución / proveedor LTS.
2. Reinicia todos los workers de PHP (FPM, Apache, el servicio que sea). Un binario nuevo en disco no basta si siguen vivos procesos viejos.
3. Verifica la versión real que atiende la web: php -v en CLI y, mejor aún, la versión que reporta el pool o el módulo que sirve las peticiones. A veces CLI y FPM no coinciden.

Si tu PHP lo entrega el sistema operativo, revisa primero los paquetes del vendor: muchas distros recibieron el parche con anticipación. Si compilas desde fuente, baja las versiones nuevas desde php.net/downloads.

03 / PHP 5.4–8.1También vulnerables… y sin parche oficial

Esto conviene dejarlo sin ambigüedad, porque mucha gente lee «actualiza a 8.5.12 / 8.4.27 / …» y piensa: «yo estoy en 7.4 / 8.0 / 8.1, esto no me toca».

Sí te toca. Según los avisos públicos, el riesgo alcanza a las instalaciones que atienden la web con PHP desde hace mucho —en la práctica, el rango que se menciona va de PHP 5.4 hasta 8.1, además de las 8.2–8.5 sin el parche—. No es un bug «solo de la última rama».

Lo que cambia es la salida:

• PHP 8.2, 8.3, 8.4 y 8.5: hay arreglo oficial. Sube a 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 (o el paquete equivalente de tu vendor) y reinicia workers.
• PHP 8.1 y anteriores (incluida toda la línea 5.4–8.0): no hay arreglo oficial upstream del proyecto PHP. Algunas distros o proveedores LTS pueden publicar backports; eso hay que confirmarlo con tu vendor. El camino sano no es quedarse esperando: es migrar a una rama soportada ya parcheada.

Las mitigaciones temporales del aviso (ajustes de configuración) tampoco cierran el tema en esas versiones: reducen algunos caminos, pero no dejan el servidor seguro. En 8.1 o menos, el plan real es migración + verificación, no «afinar el php.ini y listo».

Si todavía estás en 7.4 u 8.0 «porque funciona», este es el tipo de aviso que convierte esa deuda en prioridad. Migrar duele un día; un servidor expuesto duele más.

04 / SI AÚN NO PUEDES ACTUALIZARMitigaciones temporales (y sus límites)

Solo mientras organizas el upgrade. El propio PHP dice que reducen exposición a caminos concretos, pero no dejan la instalación segura.

• Límite de memoria administrativo: configurar memory_limit=-1 de forma que la aplicación no pueda sobrescribirlo (por ejemplo con php_admin_value en el pool FPM o en la config de Apache). Esto evita el corte controlado por memory_limit, pero un fallo de asignación a otro nivel aún puede tocar el camino vulnerable.
• post_max_size conservador: mantenerlo bajo (el aviso sugiere valores acotados si no necesitas subidas grandes) y, cuando puedas, reforzar límites en el proxy o el servidor web (tamaño de petición, cantidad de campos, profundidad).
• Progreso de subida en sesión: desactivar session.upload_progress.enabled (en php.ini o config del pool antes del parseo de la petición; no basta con ini_set) y reiniciar workers. Cubre rutas confirmadas de uno de los fallos, no todas las variantes.
• En PHP 8.5: desactivar fatal_error_backtraces y reiniciar workers, según el aviso, solo bloquea un camino concreto.
• Si la aplicación no necesita multipart: puedes reducir superficie bloqueando ese tipo de peticiones en el frontend / reverse proxy. Solo tiene sentido si de verdad no usas subidas ni formularios multipart.

Ninguna de estas medidas reemplaza el parche. Son tiempo comprado, no un escudo.

05 / LISTA RÁPIDAQué haría yo hoy

1. Inventario: qué servidores / contenedores / hosts compartidos corren PHP expuesto a internet.
2. Versión actual vs. versión parcheada de la misma rama.
3. Plan de upgrade + ventana corta de reinicio de workers.
4. Comprobación post-cambio (php -v / versión del pool).
5. Si hay 8.1 o menos (incluye 7.x y 5.x): plan de migración a 8.2.35+ / 8.3.36 / 8.4.27 / 8.5.12; no alcanza con mitigaciones temporales ni con «esperar al LTS».
6. Mientras tanto: mitigaciones temporales del aviso oficial, sin confundirlas con «ya estamos bien».

06 / SI NECESITAS APOYOConversemos

Si administras sitios o plataformas en PHP y quieres una mano para evaluar el estado de tus servidores, aplicar el parche, planear un upgrade o migrar de una rama vieja, escríbeme por el contacto de joseareche.com (WhatsApp, correo o LinkedIn). Una conversación técnica suele ahorrar días de prueba y error.

Trabajo a diario con infraestructura, software y telefonía; no vengo a vender miedo, solo a dejar el checklist claro y, si hace falta, acompañar el cambio con criterio.

Fuentes: aviso de seguridad en php.net (21 oct 2026) · nota de la PHP Foundation. Las versiones y mitigaciones pueden actualizarse; prioriza siempre el aviso oficial.