Vulnerabilidades críticas de PHP: actualiza ahora

Si tu sitio, tienda o plataforma utiliza PHP para atender solicitudes web, esta actualización no debería esperar al próximo mantenimiento. El 21 de octubre de 2026, el proyecto PHP publicó correcciones para dos fallas críticas que pueden permitir ejecución remota de código sin autenticación.

Las vulnerabilidades críticas de PHP están identificadas como CVE-2026-109618 y CVE-2026-109619. El equipo de PHP recomienda actualizar de inmediato y advierte que las medidas de mitigación disponibles no sustituyen la instalación de una versión corregida.

¿Qué ocurrió?

Las dos vulnerabilidades afectan la manera en que PHP administra memoria y estado interno durante el procesamiento de solicitudes:

• CVE-2026-109618: una condición relacionada con errores por falta de memoria puede dejar datos internos de una solicitud en un estado inválido y abrir la puerta a ejecución remota de código.
• CVE-2026-109619: cierto estado interno puede sobrevivir después de liberar su memoria y ser utilizado por una solicitud posterior, lo que puede producir una condición de uso de memoria liberada.

Ambas vulnerabilidades recibieron una puntuación CVSS v4.0 de 9,2 sobre 10. No requieren que el atacante tenga una cuenta ni que una persona haga clic en un enlace.

¿Quién debe tomar precauciones?

El aviso oficial considera expuestas las instalaciones de PHP que atienden solicitudes web, incluidas configuraciones con PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El riesgo demostrado es especialmente alto en Apache con mod_php, porque un ataque puede activarse antes de que se ejecute el código de la aplicación.

Esto no significa que todos los sitios ya hayan sido comprometidos. Significa que la falla está en la capa que procesa las solicitudes y que esperar evidencia visible antes de actualizar aumenta innecesariamente el riesgo.

Versiones corregidas

La acción recomendada es actualizar a una de estas versiones, según la rama que utilice tu entorno:

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

PHP 8.1 y versiones anteriores ya no reciben actualizaciones oficiales del proyecto. Algunos proveedores de Linux o soporte extendido pueden ofrecer parches retroactivos, pero debes confirmarlo directamente con tu proveedor. PHP 8.2 alcanzará el final de su soporte de seguridad el 31 de diciembre de 2026, por lo que conviene planificar además una migración a una rama con mayor vigencia.

Lista de verificación para actuar hoy

1. Identifica la versión real de producción. No te quedes con la versión declarada en un documento: comprueba los servidores, contenedores, imágenes y procesos que atienden tráfico.
2. Confirma el modo de ejecución. Determina si utilizas PHP-FPM, mod_php, CGI, FrankenPHP o LiteSpeed.
3. Obtén el paquete del canal correcto. En Linux, revisa primero el repositorio oficial de tu distribución o proveedor LTS. En otros entornos, utiliza las descargas y binarios oficiales.
4. Prueba la actualización. Valida inicio de sesión, formularios, carga de archivos, sesiones, tareas programadas, integraciones y procesos de compra.
5. Despliega y reinicia todos los trabajadores. Actualizar archivos sin reiniciar los procesos puede dejar instancias antiguas atendiendo solicitudes.
6. Verifica después del despliegue. Confirma la versión activa desde el entorno de ejecución y revisa registros, errores, disponibilidad y comportamiento de las funciones críticas.
7. Documenta la evidencia. Registra qué sistemas se actualizaron, quién validó el cambio y qué activos siguen pendientes.

Si no puedes actualizar de inmediato

Las siguientes medidas solo reducen algunas rutas de ataque; no vuelven segura una instalación vulnerable. Deben aplicarse con personal técnico que entienda su impacto y con un plan de actualización inmediato.

• Aplicar límites conservadores al tamaño de las solicitudes en el servidor web o proxy y revisar post_max_size y upload_max_filesize.
• Desactivar session.upload_progress.enabled y reiniciar todos los trabajadores.
• En PHP 8.5, desactivar fatal_error_backtraces y reiniciar los trabajadores.
• Corregir configuraciones inválidas o deprecadas que produzcan diagnósticos antes de la inicialización.
• Revisar errores fatales y tiempos de espera alcanzables desde solicitudes externas.

El aviso oficial incluye otras recomendaciones específicas. No copies una configuración sin evaluar si tu aplicación necesita cargas de archivos, límites de memoria u otras capacidades relacionadas.

Precauciones adicionales después de actualizar

• Revisa accesos y cambios inesperados en archivos, cuentas, tareas programadas y credenciales.
• Rota secretos si encuentras indicios razonables de compromiso.
• Evita publicar versiones detalladas de PHP en encabezados o páginas de diagnóstico.
• Retira herramientas temporales como phpinfo() del entorno público.
• Incluye componentes del servidor, extensiones y dependencias en tu inventario de actualizaciones.

No es solo una tarea del desarrollador

Una vulnerabilidad de infraestructura puede afectar disponibilidad, información de clientes, formularios, ventas e integraciones. Por eso la respuesta necesita responsables, prioridades y evidencia, no solamente instalar un paquete.

Ainoa desarrolla administradores a la medida y soluciones conectadas con procesos reales. También explicamos por qué una operación tecnológica necesita indicadores verificables en Tu empresa no necesita más IA: necesita un proceso medible.

¿No sabes qué versión utiliza tu plataforma o qué componentes dependen de ella? Contacta a Ainoa. Podemos ayudarte a levantar el inventario, priorizar el riesgo y diseñar un plan de modernización sin perder el control de la operación.

Preguntas frecuentes

¿Un firewall reemplaza la actualización?

No. Puede reducir exposición a algunos patrones, pero PHP señala que actualizar a una versión corregida es la única solución completa.

¿PHP-FPM también está incluido?

Sí. El aviso considera en riesgo las instalaciones que sirven solicitudes web, incluido PHP-FPM, aunque el escenario demostrado más fuerte corresponde a mod_php.

¿Debo asumir que mi sitio fue atacado?

No automáticamente. Debes actualizar, verificar registros e indicadores de compromiso y escalar la investigación si encuentras actividad anómala.