Hoy, 21 de octubre de 2026, el equipo de PHP ha publicado un aviso de seguridad que no conviene dejar para la semana que viene: una vulnerabilidad crítica en PHP (en realidad, dos) permite ejecutar código de forma remota en el servidor sin necesidad de iniciar sesión. Afecta a prácticamente cualquier web, tienda online, intranet o API que funcione con PHP, lo que incluye la mayoría de webs con WordPress, Laravel, Symfony, Drupal, PrestaShop o Magento.
Si tu negocio depende de una plataforma en PHP y no sabes con certeza qué versión tiene tu servidor, quién se encarga de actualizarlo o si tu proveedor ya ha reaccionado, este artículo es para ti. Te explicamos en lenguaje claro qué ha pasado con esta vulnerabilidad crítica en PHP, cómo saber si estás expuesto y qué puedes hacer hoy mismo, tanto si tienes equipo técnico propio como si no.
En resumen: PHP ha corregido dos fallos con puntuación 9,2 sobre 10 que permiten tomar el control de un servidor con una simple petición web. La única solución completa es actualizar a PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35. Si tu web usa PHP 8.1 o anterior, ya no recibe parches oficiales y el riesgo es todavía mayor. En MiTSoftware ofrecemos un diagnóstico gratuito para saber en minutos si tu plataforma está expuesta.
Qué es esta vulnerabilidad crítica en PHP y por qué es tan grave
El aviso oficial publicado en el archivo de noticias de PHP.net describe dos fallos distintos, identificados como CVE-2026-109618 y CVE-2026-109619. Un día antes, el propio equipo de seguridad de PHP ya había anunciado que ambos tenían una puntuación CVSS de 9,2, un nivel que se reserva para los problemas más serios.
Sin entrar en detalles técnicos, los dos fallos tienen algo en común: aprovechan situaciones en las que PHP gestiona mal la memoria entre una petición y la siguiente. Un atacante puede provocar esas situaciones desde fuera y, en el peor caso, conseguir que el servidor ejecute el código que él quiera. Eso significa acceso a la base de datos de clientes, a pedidos, a contraseñas, a la posibilidad de instalar malware o de usar tu servidor para atacar a otros.
Lo que hace especialmente delicada esta vulnerabilidad crítica en PHP es que no necesita usuario ni contraseña y, en algunas configuraciones, el ataque se produce antes de que llegue a ejecutarse el código de tu aplicación. Es decir, da igual lo bien programada que esté tu web: el problema está en la base sobre la que funciona.
A quién afecta (y por qué probablemente te incluye)
Según el aviso, están en riesgo todas las instalaciones de PHP que atienden peticiones web, sea cual sea la forma en que estén montadas: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP o LiteSpeed. El equipo de PHP considera que el riesgo es mayor en servidores con Apache y mod_php, una configuración muy habitual en hostings compartidos y en servidores antiguos.
En la práctica, deberías considerarte afectado si:
- Tu web corporativa o tu blog funcionan con WordPress, Drupal o Joomla.
- Tu tienda online usa WooCommerce, PrestaShop o Magento.
- Tu plataforma a medida, intranet o API está hecha con Laravel, Symfony, CodeIgniter o PHP sin framework.
- Tienes un panel de gestión, un CRM o un ERP interno desarrollado hace años en PHP.
Hay además un grupo que debe preocuparse el doble: quienes siguen en PHP 8.1, 8.0 o 7.4. Esas versiones ya no reciben actualizaciones oficiales del proyecto PHP. Por la gravedad del caso, el equipo de seguridad ha publicado parches mínimos para quienes compilan PHP por su cuenta, pero no habrá paquetes listos para instalar. Y PHP 8.2 deja de recibir parches de seguridad el 31 de diciembre de 2026, tal como recoge la tabla de versiones soportadas de PHP.net. Muchas empresas están justo en esa franja sin saberlo.
Qué hacer hoy: la checklist de 10 minutos
Antes de entrar en pánico, conviene ordenar las prioridades. Esta es la checklist que usamos con nuestros clientes el mismo día de un aviso así:
- Averigua qué versión de PHP usa tu servidor. Tu proveedor de hosting o tu equipo técnico deberían poder decírtelo en minutos. Si nadie lo sabe, eso ya es un hallazgo importante.
- Comprueba si existe una versión parcheada para tu caso. Las versiones seguras son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Las distribuciones de Linux y los proveedores de soporte extendido recibieron los parches por adelantado, así que muchos ya los tienen disponibles.
- Pide la actualización por escrito y con fecha. Si tienes un proveedor externo, solicita confirmación de que el servidor se ha actualizado y de que todos los procesos de PHP se han reiniciado.
- Verifica que la web sigue funcionando después de actualizar: formularios, pagos, áreas privadas y tareas programadas.
- Si no puedes actualizar hoy, aplica medidas temporales (más abajo) y fija una fecha cercana para hacerlo.
- Si estás en PHP 8.1 o anterior, planifica ya una migración. Seguir así es mantener la puerta abierta.
Si alguno de estos pasos no tiene una respuesta clara en tu empresa, no estás solo: es la situación más común que encontramos cuando hacemos una auditoría de seguridad preventiva.
Si no puedes actualizar hoy: medidas temporales
El propio equipo de PHP insiste en que actualizar es la única solución completa. Aun así, propone algunas medidas que reducen la exposición mientras se prepara la actualización, por ejemplo:
- Desactivar la función de progreso de subida de archivos de las sesiones (
session.upload_progress.enabled=0) y reiniciar todos los procesos de PHP. - Reducir el tamaño máximo de las peticiones que acepta el servidor (
post_max_size) y limitar en el servidor web o el proxy el número de campos, cabeceras y partes de cada petición. - En PHP 8.5, desactivar las trazas en errores fatales (
fatal_error_backtraces=0). - Corregir los errores fatales y los tiempos de espera que un atacante pueda provocar, por ejemplo en importaciones o subidas de archivos.
Estas medidas requieren tocar la configuración del servidor con cuidado: un cambio mal aplicado puede romper subidas de archivos, pasarelas de pago o integraciones. Son un parche de horas o días, no una solución.
El problema de fondo: plataformas PHP sin dueño técnico
Cada vez que aparece una vulnerabilidad crítica en PHP vemos el mismo patrón. El fallo en sí se corrige rápido; lo que tarda semanas es descubrir quién tiene acceso al servidor, qué depende de qué versión y si actualizar va a romper algo. Webs hechas hace años por un freelancer que ya no está, hostings que nadie revisa, plugins que nadie actualiza o aplicaciones que siguen en PHP 7.4 porque "funcionan".
Ese es el verdadero riesgo: no la noticia de hoy, sino no tener a nadie que pueda responder en horas. Con PHP 8.2 llegando al final de su soporte en diciembre y PHP 8.6 a punto de publicarse, los próximos meses van a exigir decisiones sobre versiones, compatibilidad y mantenimiento. Si tu plataforma arrastra código antiguo, quizá te interese ver cómo enfocamos la modernización de sistemas heredados sin frenar el negocio.
Cómo te ayuda MiTSoftware a resolverlo
Llevamos años trabajando con proyectos en PHP de todos los tamaños, desde webs corporativas hasta plataformas a medida con miles de usuarios. Ante un aviso como el de hoy, nuestro trabajo se organiza en tres fases:
- Diagnóstico de exposición: identificamos qué versión de PHP usa cada uno de tus servidores, cómo está configurado y qué riesgo real tienes frente a estos dos fallos.
- Actualización segura: aplicamos la versión parcheada o las medidas temporales adecuadas, probamos los flujos críticos de tu web y dejamos constancia de lo que se ha hecho.
- Plan a medio plazo: si estás en PHP 8.2 o anterior, te proponemos un plan de migración a una versión con soporte, por fases y sin parar tu operación, con nuestro equipo de desarrollo PHP.
Y si buscas algo más que apagar este fuego, nuestro servicio de ciberseguridad para empresas incluye revisiones periódicas, monitorización y respuesta ante incidentes para que el próximo aviso no te pille por sorpresa.
Preguntas frecuentes
¿Mi hosting no se encarga de esto automáticamente? Depende del tipo de servicio. En hostings compartidos gestionados suele actualizarse la versión de PHP, pero en servidores VPS, dedicados o en la nube la responsabilidad casi siempre es tuya o de tu proveedor de desarrollo. Conviene confirmarlo por escrito.
¿Actualizar PHP puede romper mi web? Pasar de una versión parcheada a otra de la misma rama (por ejemplo, de 8.3.35 a 8.3.36) rara vez causa problemas. Cambiar de rama (de 7.4 a 8.3, por ejemplo) sí exige revisar el código y los plugins antes.
Tengo WordPress actualizado, ¿estoy a salvo? No necesariamente. Este fallo está en PHP, no en WordPress. Puedes tener el último WordPress y los plugins al día y seguir expuesto si el servidor usa una versión de PHP sin parchear.
¿Cuánto tarda el diagnóstico? En la mayoría de los casos, una primera revisión de exposición se hace en pocas horas y ya permite saber si hay que actuar hoy o puede esperar a una ventana de mantenimiento.
Diagnóstico gratuito: ¿está tu plataforma PHP expuesta?
No hace falta esperar a tener un incidente para saber en qué punto estás. Te ofrecemos una sesión de diagnóstico gratuita de 30 minutos: revisamos contigo la versión de PHP de tu servidor, su configuración y el riesgo real frente a esta vulnerabilidad, y te decimos, sin compromiso, qué harías hoy y qué puede esperar.
