Saltar al contenido

Business systems & own stackCapacidad

Vulnerabilidades críticas de PHP CVE-2026-109618 y CVE-2026-109619: actualización urgente de PHP en tu web

PHP corrigió dos fallos críticos el 21 de octubre de 2026. Averiguo qué PHP sirve tu web, lo actualizo a 8.2.35, 8.3.36, 8.4.27 u 8.5.12 y lo compruebo.

Para
Propietarios de webs en WordPress, WooCommerce, Magento, PrestaShop, Laravel y otras webs en PHP
Revisado

¿Te suena?

Marca lo que se aplica a ti

La situación Business systems & own stack
Tu hosting o php.net dice que actualices PHP ya, y nadie se ocupa del servidor.

Cómo lo resuelvo

Qué construyo

Averiguo qué PHP sirve de verdad cada uno de tus dominios y lo llevo a una versión con las dos correcciones: 8.2.35, 8.3.36, 8.4.27 u 8.5.12, o a una compilación del proveedor que incluya los parches. Después reinicio todos los procesos de PHP, porque un paquete corregido no sirve de nada mientras sigan vivos los procesos antiguos, y compruebo que la web sigue funcionando: páginas, acceso al panel, formularios y checkout. Si hoy no se puede actualizar, aplico los ajustes provisionales del aviso y dejo por escrito que no son una solución.

Qué se anunció el 21 de octubre de 2026

El proyecto PHP publicó un aviso de seguridad crítico con dos vulnerabilidades en el propio PHP: CVE-2026-109618, ejecución remota de código por corrupción en falta de memoria (OOM), y CVE-2026-109619, ejecución remota de código por estado global obsoleto. Las dos tienen una puntuación CVSS 4.0 de 9.2. Según php.net afectan a todas las instalaciones de PHP que sirven peticiones web, incluidas PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed, y solo actualizar es una solución completa.

Versiones de PHP corregidas

Rama de PHPPrimera versión con las dos correcciones
8.58.5.12
8.48.4.27
8.38.3.36
8.28.2.35, fin de soporte el 31 de diciembre de 2026
8.1, 8.0, 7.4Sin versión del proyecto PHP. Hay parches de código fuente publicados; revisa la compilación de tu proveedor.

Dónde está confirmado el riesgo

  • Apache con mod_php: ejecución remota de código confirmada para las dos CVE. En CVE-2026-109618 el ataque se produce antes de que arranque el código de la web.
  • PHP-FPM, también detrás de Nginx: para CVE-2026-109619 se validó la ejecución remota de código en condiciones concretas; para CVE-2026-109618 el riesgo sale del análisis del código fuente.
  • FrankenPHP y LiteSpeed: php.net los incluye entre los afectados; los ataques ahí se describen como probables, pero no demostrados.
  • Las webs estáticas y las aplicaciones en Node.js, Python o Go sin PHP no están afectadas directamente por estas dos CVE.

El proceso

Cómo funciona

6 pasos. El alcance y un precio fijo se acuerdan antes del primero.

  1. Mapear los dominios

    Para cada dominio localizo el servidor o el contenedor, cómo se ejecuta PHP (mod_php, FPM, CGI, FrankenPHP o LiteSpeed) y la versión exacta que responde a las peticiones.

  2. Elegir cómo actualizar

    Paquetes de seguridad de la distribución, el panel del hosting, una imagen de Docker reconstruida o una compilación del proveedor para PHP 8.1 y anteriores.

  3. Copia primero

    Una copia de la configuración de PHP y una forma de volver atrás antes de cambiar nada.

  4. Actualizar y reiniciar

    Instalo la versión corregida y reinicio todos los pools de FPM, Apache o contenedores que ejecutan PHP.

  5. Comprobar la web

    Versión confirmada por dominio y después páginas, acceso al panel, formularios y checkout.

  6. Dejarlo por escrito

    Qué funcionaba antes, qué funciona ahora y lo que aún requiere una decisión, como una rama de PHP sin soporte.

Entrega

Qué recibes

  • Cada dominio relacionado con el PHP que lo sirve de verdad, antes y después.
  • PHP en una versión con las dos correcciones, o el motivo por escrito de por qué aún no y el plan para hacerlo.
  • Todos los procesos de PHP reiniciados, para que la corrección esté realmente en marcha.
  • Una comprobación breve de la web después de actualizar.
  • Un resumen por escrito que puedes reenviar a tu hosting, tu agencia o tu aseguradora.
Hecho con10 piezas
  1. PHP-FPM
  2. Apache mod_php
  3. Nginx
  4. LiteSpeed
  5. FrankenPHP
  6. imágenes de Docker
  7. paquetes de seguridad de Debian y Ubuntu
  8. cPanel y Plesk
  9. Salud del sitio de WordPress
  10. Composer

Pruebas

Hecho antes, con fechas y cifras

Capacidad Trabajo que hago; la prueba de abajo viene de proyectos relacionados.

Antes → después

Antes, un correo de «actualiza ya» y nadie a cargo del servidor. Después, cada dominio funciona con una versión de PHP con las dos correcciones, los procesos antiguos ya no están y la web está comprobada. Esta página describe el servicio; no afirma un caso de cliente terminado para estas dos CVE.

Lo que puedes ver

Una hoja por dominio: dominio, servidor o contenedor, modo de PHP, versión antes, versión después, procesos reiniciados y resultado de la comprobación. Aquí se muestra como ejemplo sintético; los datos de clientes nunca se publican.

Página de capacidad escrita el 21 de octubre de 2026 a partir del aviso de seguridad de php.net y de los dos avisos de PHP en GitHub. No se afirma ninguna corrección de estas dos CVE ya terminada para un cliente. Gestiono mi propia infraestructura con Docker y Nginx y he trabajado con webs en WordPress, WooCommerce, Magento, PrestaShop, OpenCart y Drupal.

Precio y plazo

Cuánto cuesta y cómo funciona

Una Technical Working Session cuesta EUR 185: un servidor o una cuenta de hosting revisados en directo y actualizados en la sesión si el acceso lo permite, con un breve resumen por escrito. Varios servidores, contenedores, compilaciones propias o PHP 8.1 y anteriores necesitan un Focused Fix desde EUR 425, con el alcance y la fecha por escrito antes de empezar. Hablar de la tarea es gratis.

PresupuestoFijado antes de empezar

Precio
Technical Working Session EUR 185: un servidor o una cuenta de hosting revisados en directo y, si el acceso lo permite, actualizados en la misma sesión, con un breve resumen por escrito. Focused Fix desde EUR 425 para varios servidores o contenedores, compilaciones propias de PHP o PHP 8.1 y anteriores que necesitan un plan de migración. Hablar de la tarea es gratis.
Plazo
Empiezo en cuanto el acceso está confirmado, el mismo día laborable siempre que sea posible, hora de Europe/Madrid. Una Working Session dura hasta 60 minutos más un breve resumen por escrito; un Focused Fix lleva fecha por escrito antes de empezar.
Primer paso
Describe la tarea. Respondo en un día laborable, gratis, y te digo qué opción encaja, o que puedes resolverlo por tu cuenta.
Describe una tarea como esta

Una nota de Daniilantes de decidir

Cuándo no lo necesitas

Si tu web es estática o funciona con Node.js, Python o Go sin PHP, estas dos CVE no le afectan. Si tu hosting gestionado ya ha confirmado por escrito que tu plan funciona con una versión corregida y que los procesos se han reiniciado, solo tienes que comprobar la versión que aparece para tu web.

— Daniil

Preguntas

Lo que se pregunta sobre esto

¿Está afectada mi web en WordPress o WooCommerce?

Si el PHP que la sirve es anterior a 8.2.35, 8.3.36, 8.4.27 u 8.5.12 y no tiene un parche del proveedor para las dos CVE, sí, entra en el alcance. Actualizar WordPress, el tema o los plugins no lo soluciona: el fallo está en el propio PHP. WordPress muestra la versión de PHP en Herramientas → Salud del sitio → Información → Servidor.

Usamos Nginx con PHP-FPM, no Apache. ¿Estamos a salvo?

No. PHP-FPM entra en el alcance. El riesgo es mayor con Apache y mod_php, donde se demostró un ataque antes de que se ejecute el código de la web, pero para CVE-2026-109619 también se validó la ejecución remota de código en PHP-FPM en condiciones concretas. Tener Nginx delante no lo evita.

php -v en nuestro servidor ya muestra una versión nueva. ¿Ya está?

No necesariamente. La web puede estar servida por otro PHP: un contenedor, un pool de FPM aparte o la versión elegida en el panel del hosting. Y un paquete corregido solo protege cuando se han reiniciado todos los procesos de PHP en marcha.

Estamos en PHP 7.4, 8.0 u 8.1. ¿Y ahora?

El proyecto PHP ya no publica versiones para 8.1 y anteriores. Su equipo de seguridad publicó parches de código fuente para 7.4, 8.0 y 8.1, y algunas distribuciones de Linux y proveedores LTS ofrecen compilaciones parcheadas. Compruebo si la de tu proveedor incluye las dos correcciones; si no, planifico el paso a una rama con soporte.

¿Se puede arreglar cambiando la configuración, sin actualizar?

No. Los avisos dicen que solo actualizar es una solución completa. Ajustes como session.upload_progress.enabled=0, un post_max_size más bajo o, en PHP 8.5, fatal_error_backtraces=0 reducen el riesgo durante un tiempo. Los uso solo como medida provisional y lo dejo por escrito.

¿Afecta a mi tienda Shopify?

La tienda funciona en Shopify, así que ahí no hay un PHP tuyo que parchear. Sí entra en el alcance una app propia, una integración o un receptor de webhooks escrito en PHP que alojes tú.

¿Qué acceso necesitas?

Hosting compartido: el panel del hosting, donde se elige la versión de PHP. VPS o servidor dedicado: SSH con sudo. Contenedores: el repositorio o el registro y el pipeline de despliegue. No necesito contraseñas por chat; primero configuramos el acceso de forma segura.

Situaciones parecidas

Todas las situaciones (en inglés)
Daniil Maximkin

Hola, soy Daniil.

Trabajo contigo desde la definición del problema hasta la implementación y la entrega. Hablas con quien hace el trabajo. Trabajo en inglés y ruso; correspondencia en español con apoyo de traducción.

Mi historia Mi trabajo

¿Tienes una tarea parecida?

Describe tu tarea

La primera respuesta es gratis, en un día laborable. O escribe directamente: next@taskfordaniel.com

Habla de tu tarea

Describe qué necesitas crear, arreglar o conectar.

Escribir tu tarea next@taskfordaniel.com