Seguridad web · PHP2Shell

PHP publicó el 21 de octubre de 2026 actualizaciones de emergencia para dos vulnerabilidades críticas: CVE-2026-109618 y CVE-2026-109619. Si tu empresa utiliza un sitio, portal o aplicación con PHP, la prioridad es confirmar qué motor atiende cada dominio y aplicar el parche, no solamente actualizar el CMS.

Los fallos, conocidos como PHP2Shell, pueden permitir ejecución remota de código sin autenticación con los permisos del proceso web. Ambos tienen una puntuación oficial CVSS v4.0 de 9.2. Esta guía distingue lo confirmado por PHP de los reportes de explotación y propone un procedimiento de actualización con evidencias, pensado para responsables de sistemas, proveedores de hosting y empresas.

Qué se confirmó y por qué importa

CVE-2026-109618: corrupción durante el agotamiento de memoria. Algunas salidas por falta de memoria dejan datos internos de una solicitud incompletos; al terminarla, PHP puede procesarlos como si fueran válidos. El aviso describe ejecución remota demostrada contra Apache con mod_php, incluso antes de que empiece el código de la aplicación.

CVE-2026-109619: estado global que sobrevive a una solicitud. Un proceso puede conservar referencias a memoria ya liberada y utilizarlas en una solicitud posterior. PHP confirma rutas de explotación relacionadas con el ciclo de sesiones tanto en mod_php como en PHP-FPM; las condiciones dependen de la aplicación y la configuración. No es correcto presentar FPM como inmune.

El aviso general incluye instalaciones que atienden solicitudes web mediante PHP-FPM, mod_php, php-cgi, FrankenPHP y LiteSpeed. Que un sitio no tenga un formulario de carga visible o que su CMS esté actualizado no demuestra que el runtime esté protegido. Tampoco significa que todas las instalaciones puedan explotarse de idéntica manera.

Versiones corregidas: comprueba la rama y el paquete

Estos son los mínimos corregidos publicados por el proyecto PHP para sus ramas soportadas en este aviso. Utiliza esa versión o una posterior que conserve las correcciones.

Hay una excepción importante a la comparación numérica: una distribución Linux o proveedor LTS puede incorporar el parche mediante un backport sin cambiar la versión base al número anterior. Pide el aviso del proveedor, la revisión exacta del paquete y la confirmación de que corrige ambas CVE. Una versión antigua en el encabezado HTTP no basta para declarar vulnerable —o protegido— un servicio.

PHP 8.1 y anteriores ya no reciben mantenimiento del proyecto. PHP publicó parches mínimos de código fuente para 7.4, 8.0 y 8.1 ante la gravedad del caso, pero eso no devuelve soporte general a esas ramas. Si dependes de un proveedor LTS, confirma su cobertura; en otro caso, planifica migrar a una rama soportada. El aviso recuerda además que PHP 8.2 llega al fin de soporte el 31 de diciembre de 2026. PHP 8.6 RC4 incorpora correcciones, pero es una versión de pruebas y no una recomendación para producción.

¿Ya existen ataques o solo una prueba de concepto?

La demostración técnica de ejecución remota está confirmada por los avisos de PHP. Además, Amazon Threat Intelligence reportó el 21 de octubre un intento contra su red de señuelos MadPot fechado el 17 de octubre de 2026, antes de la divulgación pública, y otros intentos posteriores. Amazon indica que el análisis continúa y que no está claro si aquellos intentos previos habrían tenido éxito contra sistemas reales; también informa explotación extendida tras publicarse los parches.

No hay que convertir esa observación en «todos los sitios PHP fueron comprometidos». Sí justifica tratar el caso como una actualización urgente y revisar actividad histórica, no esperar una ventana rutinaria de varias semanas. Unit 42 corroboró la disponibilidad de pruebas de concepto y la necesidad de parchear. La cobertura de The Hacker News del 21 de octubre también identifica los cuatro lanzamientos de emergencia y que actualizar es la solución completa.

Plan práctico: inventariar, actualizar y comprobar

Si una aplicación falla después de actualizar, no des por resuelto el incidente regresándola permanentemente a un motor vulnerable. Aísla el servicio afectado y revisa compatibilidad para recuperar operación con una versión corregida. Esta guía no implica que Tiser haya auditado o actualizado el servidor del lector.

Si todavía no puedes instalar el parche

El equipo de PHP es explícito: no hay una combinación genérica de ajustes que sustituya la actualización. Las medidas temporales reducen rutas concretas, no hacen segura una instalación vulnerable. Si no puedes mantener una exposición aceptable, restringe el acceso o retira temporalmente de internet el servicio hasta corregirlo.

• Limita solicitudes y cargas en el servidor frontal o proxy. Bloquear multipart puede reducir exposición cuando la aplicación no lo necesita, pero rompe funciones si se aplica sin evaluar su uso.
• El aviso propone desactivar session.upload_progress.enabled administrativamente y reiniciar todos los workers para cortar rutas de sesión confirmadas. No confíes en ini_set() ni en .user.ini de FPM para esta protección previa al procesamiento de la solicitud.
• En PHP 8.5, desactivar fatal_error_backtraces y reiniciar workers bloquea una ruta confirmada, no todas las variantes.
• PHP también describe memory_limit=-1 como mitigación parcial de la ruta OOM. No lo apliques a ciegas: elimina el límite de memoria por solicitud, puede agravar problemas de disponibilidad y no evita todos los fallos de asignación. Requiere diseño de límites externos y supervisión por el administrador. El aviso descarta usar RLIMIT_AS o RLIMIT_DATA como sustitutos.

Un WAF, ocultar mensajes de error o un reinicio sin parche tampoco acreditan corrección. Mantén las decisiones temporales documentadas y con fecha de retiro.

Qué revisar después: parchear no borra un posible compromiso

Conserva registros del servidor web, PHP-FPM, proxy y plataforma de seguridad. Según la referencia de Amazon, revisa desde al menos el 17 de octubre: errores anómalos, procesos inesperados lanzados por el usuario web, archivos modificados sin explicación y conexiones salientes inusuales. Una dirección IP o una petición aislada es una pista para investigar, no una prueba automática de intrusión.

La ausencia de errores tampoco demuestra seguridad: PHP advierte que ciertas rutas pueden no producir registros previsibles. Si encuentras indicios, separa la respuesta a incidentes del mantenimiento: preserva evidencias, contiene el sistema y evalúa integridad y credenciales expuestas. Instalar la versión corregida cierra la vulnerabilidad, pero no elimina por sí solo una persistencia ya instalada.