Una tienda que deja de recibir pedidos, un portal de clientes fuera de servicio o un sistema interno detenido tienen un costo directo para tu empresa. La alerta PHP2Shell pone sobre la mesa una tarea concreta: identificar qué aplicaciones dependen de PHP, quién administra sus servidores y cómo corregirlas sin improvisar una interrupción.
Actualización al 21 de octubre de 2026: PHP ya publicó las versiones de seguridad. La noticia de The Hacker News que motivó este artículo se redactó antes de su lanzamiento; esta guía incorpora la información oficial posterior. La imagen principal pertenece a esa cobertura previa y conserva el aviso del parche pendiente.
Qué es PHP2Shell y por qué merece atención
PHP2Shell es el nombre utilizado para dos vulnerabilidades críticas: CVE-2026-109618 y CVE-2026-109619. Ambas pueden permitir la ejecución remota de código sin autenticación.
La primera involucra el manejo de fallos de memoria. El aviso técnico de PHP sobre CVE-2026-109618 documenta un ataque contra Apache con mod_php que puede ocurrir antes de ejecutar el código de la aplicación. También considera susceptibles otros entornos, con condiciones distintas.
La segunda afecta estado interno que puede permanecer entre solicitudes después de liberar la memoria correspondiente. El aviso sobre CVE-2026-109619 explica que las condiciones dependen de la aplicación, las extensiones y la configuración. Usar PHP-FPM no basta para descartar el riesgo.
Para el negocio, la pregunta útil es qué ventas, atención o procesos dependen de esos sistemas. Esa respuesta permite ordenar la intervención por impacto.
Qué servidores deben revisarse
El aviso oficial del 21 de octubre incluye PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. Destaca mod_php por un ataque demostrado que actúa antes del código de la aplicación. Por eso, revisar únicamente el framework o el CMS deja pendiente el componente que procesa las solicitudes.
En el inventario, conviene separar la versión de consola de la que atiende cada sitio. Un servidor puede alojar varias aplicaciones con distintas ramas o pools de PHP. Pide al administrador que compruebe cada servicio, incluidos contenedores y réplicas, y registre qué paquete lo proporciona.
Qué versiones corrigen las vulnerabilidades
El comunicado oficial de PHP identifica estas versiones corregidas:
| Rama instalada | Versión de seguridad publicada |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
PHP señala que actualizar es la solución completa. Para PHP 8.1 y anteriores, sin soporte oficial ordinario, corresponde consultar los parches del proveedor o planificar la migración a una rama soportada. Algunos proveedores distribuyen correcciones incorporadas a sus propios paquetes.
Pide evidencia del paquete corregido que ejecuta tu servicio web. No cierres la revisión con una captura del panel o con la confirmación de que se actualizó WordPress.
Un cambio de configuración no reemplaza el parche
La cobertura inicial de The Hacker News advertía que desactivar session.upload_progress.enabled no ofrecía protección completa.
El aviso técnico posterior de PHP precisa que esa medida bloquea rutas de ataque confirmadas relacionadas con sesiones, pero deja otras posibilidades. Requiere una configuración administrativa que se aplique antes del procesamiento de solicitudes y reiniciar todos los procesos PHP. Ocultar errores tampoco protege frente al problema de estado interno.
Nuestro criterio operativo es tratar cualquier medida temporal como una tarea con responsable y fecha de cierre. Debe acompañar la actualización y su verificación. Los ajustes de memoria y de procesamiento de solicitudes requieren evaluación técnica: copiar parámetros sin revisar la capacidad del servidor puede afectar la disponibilidad.
Medidas temporales y sus límites
El aviso oficial detalla medidas parciales para el equipo administrador:
- Sesiones: aplicar
session.upload_progress.enabled=0antes de procesar solicitudes y reiniciar todos los trabajadores.ini_set()y.user.inide FPM no sirven para este bloqueo. - PHP 8.5:
fatal_error_backtraces=0, seguido del reinicio de trabajadores, bloquea otra ruta confirmada. - Memoria:
memory_limit=-1elimina un disparador controlable, pero persisten fallos de asignación. Requiere límites externos mediante contenedores o cgroups;RLIMIT_ASyRLIMIT_DATApueden activar la condición vulnerable. - Solicitudes: revisar límites de tamaño y complejidad, incluso sin
Content-Lengthutilizable.
Estas medidas reducen exposición; ninguna sustituye la actualización. Cada cambio debe quedar documentado y revisarse tras instalar el parche.
Cómo organizar la actualización con control
Para una empresa peruana que depende de su web o de un sistema a medida, recomendamos coordinar estas acciones entre TI, el proveedor y el responsable del proceso:
- Inventariar los sistemas. Registrar aplicación, servidor, proveedor, versión de PHP y persona responsable. Incluir portales poco utilizados que sigan accesibles.
- Priorizar por impacto. Identificar dónde una interrupción detendría pedidos, atención o trabajo administrativo y acordar una ventana breve de intervención.
- Preparar la recuperación. Confirmar una copia reciente y el procedimiento para restaurar servicio y datos. Definir qué hacer si aparece una incompatibilidad.
- Aplicar y comprobar. Actualizar el entorno que atiende la web, reiniciar los procesos correspondientes y validar los flujos críticos: acceso, formularios, pedidos e integraciones.
- Registrar el cierre. Guardar la evidencia del paquete instalado, las verificaciones y cualquier incidencia pendiente.
Si dependes de hosting administrado, pide una respuesta concreta: qué servicio actualizaron, cuándo lo hicieron y cómo verificaron el resultado. Esa trazabilidad facilita tomar decisiones sin perseguir respuestas entre varios proveedores.
Qué evidencia pedir para cerrar la intervención
Solicita un registro breve que permita comprobar el trabajo sin depender de una confirmación verbal:
- Cobertura: dominios, aplicaciones, pools y réplicas revisados, con su responsable.
- Corrección: versión y revisión del paquete instalado; si el proveedor incorporó el parche a una versión anterior, enlace a su aviso de seguridad.
- Activación: confirmación de que los procesos que atienden solicitudes ya ejecutan el paquete corregido.
- Continuidad: resultado de las verificaciones de acceso, formularios, carga de archivos e integraciones que utiliza tu empresa.
Guarda esa evidencia en el registro interno de mantenimiento. Evita publicar páginas de diagnóstico con configuración del servidor para demostrar la versión.
Qué hacer si todavía no puedes actualizar
Como criterio de continuidad, evalúa restringir temporalmente los sistemas pendientes a los usuarios que realmente los necesitan. Revisa con tu equipo si el costo de limitar el acceso es menor que el de mantener la exposición durante la espera.
Conserva registros para la revisión técnica y acuerda quién investigará comportamientos inesperados. Si aparecen indicios de compromiso, activa la atención del incidente; instalar el parche no demuestra por sí solo que el entorno esté limpio.
Un servicio de soporte y operación TI debe ayudarte a convertir estas decisiones en tareas verificables, con responsables y seguimiento.
Protege la operación con una decisión verificable
La prioridad ante PHP2Shell es contar con PHP corregido y comprobar que los procesos del negocio siguen funcionando. Tener inventario, respaldo y responsables reduce el tiempo dedicado a resolver una emergencia y mejora el control sobre tus proveedores.
En OBSYSTEM podemos ayudarte a revisar tus sistemas y organizar la intervención según su impacto en tu empresa. HABLAR CON OBSYSTEM para definir el siguiente paso.
Imagen principal: The Hacker News, artículo de Swati Khandelwal del 21 de octubre de 2026. Copia local optimizada a WebP.