Un sistema publicado sigue siendo una responsabilidad
Un sistema puede funcionar, atender clientes y generar ingresos mientras un componente de su infraestructura necesita una corrección urgente. La ausencia de un error visible no demuestra que el entorno esté protegido.
Por eso insisto en mirar el software más allá del desarrollo. El despliegue inicia una operación que debe seguir siendo confiable. Alguien necesita seguir los componentes utilizados, evaluar alertas y aplicar cambios con rapidez. Cuando esa responsabilidad queda indefinida, la empresa convierte el mantenimiento en improvisación.
Qué ocurrió con PHP
El 21 de octubre de 2026 se publicaron correcciones para dos vulnerabilidades críticas de PHP, identificadas como CVE-2026-109618 y CVE-2026-109619 y conocidas en conjunto como PHP2Shell. Ambas recibieron una puntuación oficial de 9,2 en CVSS v4.0. (PHP — anuncio de lanzamiento, PHP — aviso previo)
Una implica corrupción de estado durante fallos por agotamiento de memoria. La otra afecta a referencias internas a memoria ya liberada, que una solicitud posterior puede utilizar. Los avisos describen condiciones que pueden permitir ejecución remota de código sin autenticación. Es un impacto potencial grave; no significa que todas las aplicaciones PHP estén siendo explotadas de la misma manera. (Aviso sobre memoria, aviso sobre estado interno)
El problema alcanza la infraestructura de la aplicación
La orientación oficial abarca instalaciones PHP que atienden solicitudes web, incluyendo PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El proyecto considera mayor el riesgo en mod_php, donde se demostró una vía de ataque anterior a la ejecución del código de la aplicación. La configuración y las rutas de ejecución importan. (PHP — alcance del aviso)
Para una empresa, la pregunta práctica es dónde está presente ese runtime. Puede sostener el sitio institucional, una tienda en línea, un portal interno o un servicio de terceros. Identificarlo exige conocer el entorno que sostiene la operación.
La consecuencia técnica se convierte en una consecuencia de negocio
Una ejecución indebida en el servidor puede afectar a los datos, la disponibilidad y la confianza. Su alcance depende de los permisos del proceso y de las conexiones disponibles. Un componente con acceso a otra información puede ampliar el impacto de un fallo inicialmente localizado.
Eso cambia la evaluación del mantenimiento. El coste de actualizar debe considerarse junto al de interrumpir ventas, perder acceso a un proceso o investigar una posible exposición. Incluso cuando nada de eso ocurre, una empresa sin inventario ni responsables pierde tiempo descubriendo quién debería actuar.
El tamaño del equipo no resuelve esa ausencia de decisión. Una operación pequeña necesita conocer sus límites y contar con responsables claros para desarrollo, alojamiento y mantenimiento.
Actualizar exige una decisión y una entrega verificable
Las correcciones upstream se lanzaron en las versiones 8.2.35, 8.3.36, 8.4.27 y 8.5.12. La Fundación PHP reforzó la necesidad de actualizar. Para paquetes mantenidos por distribuciones o proveedores, es necesario consultar el aviso correspondiente y la existencia de una corrección mediante backport. (PHP Foundation — correcciones y contexto)
La dirección debe establecer una prioridad, un responsable y un criterio de finalización. Informar de que se ha solicitado una actualización no demuestra que producción ya utilice el componente corregido.
La corrección también debe alcanzar imágenes, réplicas y productos que incorporan PHP. El NCSC de los Países Bajos recomienda comprobar esos entornos por separado. Después, el equipo debe confirmar la versión efectiva y validar los flujos importantes del negocio. (NCSC-NL — orientación operativa)
Una actualización importante del 23 de octubre
El 23/10/2026, PHP recomendó desactivar session.upload_progress.enabled hasta el próximo bugfix para un escenario de sesión poco habitual. Incluye esta orientación adicional al actualizar. (PHP — aviso del 23 de octubre)
Seguir el aviso después de aplicar el primer parche forma parte del mantenimiento. La seguridad depende de información actualizada y de alguien capaz de convertirla en acción.
El vídeo y la responsabilidad después de la entrega
El vídeo sobre las vulnerabilidades críticas de PHP aborda precisamente lo que este tipo de alerta representa para quienes mantienen aplicaciones en línea. Poner un sistema en producción incluye asumir la continuidad de su mantenimiento. (Ver el vídeo en Instagram)