El 21 de octubre de 2026, PHP publicó un aviso oficial de seguridad y actualizaciones urgentes. Si tu empresa utiliza aplicaciones PHP, conviene comprobar hoy qué versión ejecutan y quién se encarga de mantenerla.
Esta guía está revisada a 23 de octubre de 2026. El objetivo inmediato es aplicar el parche; después, corregir los bloqueos que impiden mantener la aplicación al día.
Qué ha pasado
Los fallos son CVE-2026-109618, relacionado con corrupción de memoria al manejar errores de falta de memoria, y CVE-2026-109619, relacionado con estado interno que persiste entre peticiones. Pueden permitir ejecución remota de código sin autenticación.
El problema está en el entorno PHP. Por eso, actualizar solamente el CMS o sus plugins no sustituye el parche del servidor. WordPress también lo aclara en su comunicado.
Cómo solucionarlo, paso a paso
1. Identifica dónde se ejecuta PHP
Haz una lista de webs, tiendas, portales, APIs, contenedores y herramientas internas. Anota proveedor, responsable, versión y exposición a Internet. Empieza por los sistemas públicos.
En un servidor administrado por tu equipo, php -v muestra la versión de consola. Puede ser distinta de la que utiliza la web: comprueba también el pool PHP-FPM, el módulo de Apache o la imagen del contenedor que atiende las peticiones. Evita publicar un archivo phpinfo() accesible desde Internet.
En hosting gestionado, solicita confirmación del parche aplicado a cada sitio. En WordPress puedes consultar la versión web en Herramientas → Salud del sitio → Información → Servidor, como explica su aviso oficial.
2. Confirma la actualización correspondiente
Estas son las versiones correctoras publicadas en el aviso de PHP:
| Rama | Versión correctora |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
Instala esa versión o una posterior de la misma rama que incluya los parches. Si tu distribución incorpora correcciones mediante backports, verifica en su boletín el número completo del paquete y la cobertura de ambos CVE; el número base por sí solo no demuestra que falte el parche.
PHP 8.1 y anteriores están fuera del soporte del proyecto. Consulta si tu proveedor ofrece una corrección mantenida y prepara la migración a una rama soportada.
3. Prepara una recuperación y comprueba compatibilidad
Antes del cambio, conserva una copia verificable de datos, archivos y configuración, con acceso restringido. Define quién recupera el servicio y cómo. Comprueba en un entorno de pruebas los procesos críticos: acceso, pedidos, pagos, formularios e integraciones.
Haz esta preparación con urgencia y sin prolongar la exposición. Si no puedes parchear a tiempo, CERT-EU recomienda considerar el aislamiento de las aplicaciones públicas. Una página de mantenimiento dentro de la propia aplicación PHP no equivale a aislar el servidor vulnerable.
4. Actualiza PHP en todos los entornos afectados
Utiliza los paquetes corregidos de tu distribución, el panel del proveedor o una imagen de contenedor actualizada y reconstruida. Incluye las extensiones necesarias y todas las réplicas que sirven tráfico. No hay un comando de actualización universal: depende del sistema operativo, del repositorio y de la versión instalada.
Coordina el reinicio o reemplazo de todos los procesos PHP que seguían cargando el código anterior. Actualizar un paquete en disco sin renovar los procesos puede dejar el cambio incompleto.
5. Verifica el servicio después del cambio
Confirma la versión o revisión corregida en el entorno web real y repite los flujos críticos. Revisa errores HTTP, registros de PHP y colas de trabajo. Documenta el paquete instalado, la fecha y el resultado por servidor o contenedor.
Si necesitas revertir por incompatibilidad, evita volver a exponer una versión vulnerable: mantén el servicio aislado mientras resuelves el problema.
6. Revisa posibles indicios de intrusión
Actualizar corrige el fallo, pero no revierte un compromiso anterior. Revisa archivos inesperados, accesos administrativos, procesos y conexiones anómalos. Si hay indicios, activa la respuesta a incidentes, conserva evidencias y rota las credenciales afectadas desde un entorno fiable.
Las medidas temporales y los filtros WAF no sustituyen la actualización. El aviso de PHP explica sus limitaciones; no conviene aplicar ajustes de memoria o configuración sin evaluar sus efectos en ese entorno.
Si actualizar PHP rompe la aplicación, hay que abordar el legacy
Una dependencia sin soporte puede convertir cada parche en un proyecto urgente. Nuestra recomendación es inventariar componentes, añadir pruebas sobre los procesos críticos y migrar por fases con criterios de aceptación y reversión.
En Codefuente ofrecemos modernización de aplicaciones: actualización de lenguajes y frameworks, refactorización, migración de datos e integraciones y mantenimiento posterior. Esto reduce la deuda técnica y facilita aplicar futuros parches; no garantiza que nunca aparezcan nuevas vulnerabilidades.
El servicio de ciberseguridad complementa ese trabajo con revisión de accesos, protección de sistemas y, como añadido, copias de seguridad y recuperación verificadas, con aislamiento, retención y pruebas de restauración.
Cuéntanos qué aplicación necesitas actualizar y definimos un plan según su versión, dependencias y criticidad.