Qué ha ocurrido: dos vulnerabilidades críticas de ejecución remota de código en PHP
El 21 de octubre de 2026, el equipo de PHP publicó un aviso de seguridad sobre dos vulnerabilidades críticas en el intérprete. Ambas pueden desembocar en ejecución remota de código (RCE): un atacante podría conseguir que el servidor ejecute instrucciones con los permisos del proceso PHP, sin disponer de una cuenta de usuario.
Los avisos oficiales asignan una puntuación CVSS v4.0 de 9,2 sobre 10. La gravedad justifica priorizar la actualización, pero no significa que todas las instalaciones sean igual de fáciles de atacar ni que todas las webs con PHP ya estén comprometidas.
CVE-2026-109618: corrupción de memoria al agotarse la memoria disponible
El primer fallo está relacionado con la gestión de errores por falta de memoria, conocida como out of memory u OOM. En determinadas situaciones, una interrupción puede dejar datos internos de una petición a medio inicializar. El procesamiento posterior de ese estado puede permitir ejecutar código. El aviso técnico del proyecto PHP documenta el problema y su corrección.
CVE-2026-109619: estado global que conserva referencias a memoria liberada
El segundo fallo afecta a estado interno que puede sobrevivir entre peticiones dentro del mismo proceso trabajador. Si conserva referencias a memoria ya liberada y otra petición las utiliza, puede producirse un acceso indebido a memoria y, bajo condiciones específicas, RCE. El segundo aviso oficial explica que la exposición concreta depende de la configuración, la versión y las operaciones ejecutadas.
El comunicado incluye instalaciones que atienden peticiones web mediante PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El equipo considera mayor el riesgo en mod_php, donde ha demostrado una explotación sin autenticación que puede iniciarse antes de ejecutar el código de la aplicación. Usar PHP-FPM no debe interpretarse como una garantía de inmunidad.
Versiones de PHP afectadas y primeras versiones corregidas
Dentro de cada rama, las versiones anteriores a la indicada necesitan el parche correspondiente, salvo que el proveedor haya incorporado una corrección equivalente mediante un backport. Esta tabla recoge las primeras versiones upstream corregidas anunciadas el 21 de octubre, no una garantía sobre cuál será la última versión disponible cuando leas la noticia.
| Rama | Versiones upstream anteriores al parche | Primera versión corregida | Acción recomendada |
|---|---|---|---|
| PHP 8.2 | 8.2.x anteriores a 8.2.35 | 8.2.35 | Aplicar el parche y planificar la migración antes del fin de soporte de la rama. |
| PHP 8.3 | 8.3.x anteriores a 8.3.36 | 8.3.36 | Actualizar al paquete corregido del proveedor o a una versión posterior que incluya la corrección. |
| PHP 8.4 | 8.4.x anteriores a 8.4.27 | 8.4.27 | Aplicar la actualización de seguridad y verificar los procesos en ejecución. |
| PHP 8.5 | 8.5.x anteriores a 8.5.12 | 8.5.12 | Aplicar la actualización y comprobar la compatibilidad de extensiones y aplicaciones. |
| PHP 8.1 y anteriores | Ramas sin soporte ordinario del proyecto PHP | Consultar al proveedor | Confirmar backports o soporte LTS y preparar la migración a una rama soportada. |
Importante para servidores Linux y hosting gestionado: el número mostrado puede conservar una versión base antigua aunque la distribución haya aplicado los parches. Solicita el identificador del paquete y el aviso de seguridad del proveedor para ambos CVE; no decidas únicamente comparando números.
PHP ha facilitado además backports mínimos de código fuente para 7.4, 8.0 y 8.1 debido a la gravedad del caso. Eso no devuelve el soporte ordinario a esas ramas ni equivale a una actualización automática de tu hosting. La rama 8.2 alcanza su fin de soporte el 31 de diciembre de 2026, según el calendario oficial de versiones soportadas.
¿Afecta a WordPress, WooCommerce o Laravel?
Puede afectar al entorno donde se ejecutan, si utiliza una versión de PHP vulnerable. Esta noticia trata de fallos del intérprete PHP, no de una vulnerabilidad atribuida al código de WordPress, WooCommerce o Laravel. La revisión debe incluir el servidor que procesa las peticiones, no solo el CMS o el framework.
- WordPress y WooCommerce: actualizar temas, plugins y el núcleo sigue siendo necesario, pero no reemplaza la actualización de PHP del alojamiento.
- Laravel y aplicaciones a medida: actualizar dependencias con Composer no implica que se haya sustituido el binario PHP del servidor. Revisa también los servicios de ejecución y los workers persistentes.
- Hosting compartido o gestionado: pide confirmación de que el parche está aplicado en tu sitio y en todos sus entornos, no solo en una versión disponible para seleccionar.
- Contenedores y varios nodos: una imagen corregida no protege réplicas que siguen ejecutando la anterior. Comprueba el despliegue efectivo de todos los procesos.
Si mantienes una aplicación empresarial sobre este framework, nuestro servicio de desarrollo y evolución de aplicaciones Laravel permite abordar compatibilidad y cambios de versión junto con el mantenimiento del proyecto.
Cómo comprobar qué versión de PHP utiliza realmente tu web
La versión de la consola puede ser distinta de la del servidor web. La consulta php -v es útil para la CLI, pero no demuestra qué versión atiende las visitas. Un servidor puede tener varios binarios y pools de PHP-FPM funcionando a la vez.
- Consulta el panel de hosting y la configuración del dominio o del pool que ejecuta esa web.
- Confirma con el administrador la versión del servicio y el paquete instalado, incluyendo su revisión de seguridad.
- Comprueba, mediante herramientas internas o una comprobación temporal restringida, el entorno que procesa una petición real de la aplicación. No dejes una página pública de
phpinfo()expuesta. - Revisa todos los nodos, subdominios y entornos accesibles que ejecuten PHP. Conserva evidencia de la versión o del parche aplicado.
Una pregunta concreta al proveedor evita respuestas ambiguas: «¿El servicio PHP que ejecuta este dominio incorpora las correcciones de CVE-2026-109618 y CVE-2026-109619? ¿Qué paquete y revisión lo acreditan?»
Cómo actualizar PHP con seguridad: plan para empresas
La prioridad es reducir el tiempo de exposición sin introducir fallos evitables en la aplicación. Para corregir estas vulnerabilidades no siempre es necesario cambiar de rama mayor: un paquete de seguridad de la rama actual puede ser suficiente si sigue soportada e incorpora ambos parches.
- Inventaría los entornos. Identifica dominios, servicios PHP, extensiones, proveedores y responsables. Incluye las réplicas que atienden tráfico.
- Confirma el parche adecuado. Contrasta la tabla con el aviso de tu distribución o proveedor. Distingue actualización upstream de backports y evita cambiar de versión sin comprobar compatibilidad.
- Prepara una copia recuperable. Respalda código, configuración y datos, verifica cómo restaurarlos y define el procedimiento de recuperación. No asumas que una copia sin probar es suficiente.
- Prueba en un entorno controlado. Valida extensiones y dependencias, inicio de sesión, formularios, tareas, integraciones y, si procede, pedidos o pagos en modo de prueba.
- Aplica el parche y sustituye los procesos activos. Sigue el procedimiento del proveedor para reiniciar o recrear PHP-FPM, Apache y los workers persistentes que corresponda. Instalar un paquete no garantiza que todos los procesos hayan dejado de usar el código anterior.
- Comprueba después del cambio. Verifica la versión efectiva o revisión del paquete, la salud de todos los nodos, los flujos clave y los registros. Documenta la intervención y monitoriza errores.
Actualizar corrige los fallos, pero no elimina por sí solo una posible intrusión previa. Si observas archivos inesperados, procesos anómalos o indicios de acceso no autorizado, conserva evidencias y activa un proceso de respuesta a incidentes. El parche y la investigación son trabajos distintos.
¿Qué hacer si todavía no puedes actualizar PHP?
Contacta con el responsable de sistemas o el proveedor para reducir temporalmente la exposición y fijar una intervención prioritaria. Los avisos de PHP describen medidas parciales según cada fallo, pero advierten que no existe una mitigación de configuración que sustituya completamente la actualización.
No apliques cambios generales de memoria, sesiones o procesamiento de peticiones sin valorar sus efectos. Pueden afectar a la disponibilidad y no cubrir todas las vías del problema. Un WAF, ocultar errores o bloquear una ruta concreta tampoco acredita que la instalación esté protegida frente a ambos CVE.
Preguntas frecuentes sobre las vulnerabilidades PHP de octubre de 2026
¿Cuál es la solución para CVE-2026-109618 y CVE-2026-109619?
Actualizar a un PHP que incorpore ambos parches. Las primeras versiones corregidas publicadas son 8.2.35, 8.3.36, 8.4.27 y 8.5.12. Si utilizas paquetes de una distribución, confirma con su aviso de seguridad si incluyen las correcciones mediante backport.
¿Mi web está hackeada por usar una versión vulnerable?
No puede concluirse eso solo por la versión. Una vulnerabilidad indica una exposición potencial; una intrusión requiere evidencias. Aplica la corrección y revisa posibles indicios de compromiso sin confundir ambas situaciones.
¿Basta con actualizar WordPress o Laravel?
No. Estos fallos corresponden al intérprete PHP. Mantén actualizado el CMS o framework, pero comprueba por separado que el servicio PHP del alojamiento incorpora los parches.
¿PHP-FPM está libre de estos fallos?
No debe considerarse inmune. Los avisos describen condiciones distintas según el entorno y el comunicado incluye PHP-FPM entre las instalaciones a revisar. No extrapoles la ausencia de un exploit demostrado para una configuración a una garantía de seguridad.
¿Un hosting puede estar corregido aunque muestre una versión anterior?
Sí. Algunos proveedores incorporan parches manteniendo el número base. Solicita el paquete, su revisión y el aviso que confirme la corrección de los dos CVE en el servicio que ejecuta tu dominio.
¿Tengo que migrar obligatoriamente a PHP 8.5?
No necesariamente. Existen correcciones para las ramas 8.2, 8.3, 8.4 y 8.5. Elige una versión soportada y compatible; si tu rama está sin soporte o próxima a agotarlo, planifica también la migración.
¿Actualizar PHP garantiza que no habrá cortes?
No se puede garantizar sin revisar el entorno. Las pruebas de compatibilidad, las copias verificadas, la planificación y la validación posterior ayudan a reducir el riesgo. La duración depende de tu infraestructura y de la aplicación.
Fuentes oficiales y criterio de actualización
Noticia elaborada por 10Code a partir de fuentes primarias, consultadas el . Las condiciones de explotación y los paquetes de cada proveedor pueden evolucionar: contrasta el aviso vigente antes de intervenir.
La decisión práctica: no te quedes en saber si tu web «usa PHP». Confirma el parche del servicio real, documenta la actualización y comprueba que la aplicación sigue funcionando. Habla con 10Code para revisar tu caso o consulta más recursos técnicos para empresas.