WISECHECKER / SEGURIDAD
Comprueba las correcciones de octubre de 2026, el PHP que ejecuta tu sitio, las versiones con soporte y un procedimiento de actualización seguro.
Fuentes revisadas:
Revisiones de fuentes programadas cada 6 horas. No es un escáner en tiempo real ni una lista completa de incidentes. Para decisiones urgentes, consulta el aviso oficial enlazado.
Ha pasado el plazo de revisión de seis horas. La información que depende de su actualidad espera una nueva comprobación.
Comprueba el PHP que atiende tu sitio, no solo WordPress, una opción del panel o la versión de la línea de comandos. Aplica la corrección adecuada y verifica el servicio en ejecución y las funciones que utilizan tus visitas.
Identifica la corrección de la rama de PHP que utilizas
| Rama | Versiones anteriores de la rama | Primera versión corregida |
|---|---|---|
| 8.2 | Anteriores a 8.2.35 | 8.2.35 |
| 8.3 | Anteriores a 8.3.36 | 8.3.36 |
| 8.4 | Anteriores a 8.4.27 | 8.4.27 |
| 8.5 | Anteriores a 8.5.12 | 8.5.12 |
Son las primeras versiones que corrigen estas dos vulnerabilidades, no una recomendación de permanecer en ellas indefinidamente. Aplica también las actualizaciones de seguridad posteriores. Si el sistema operativo o el alojamiento incorpora un backport, solicita el aviso del paquete y la confirmación de que corrige ambas CVE.
El comunicado oficial abarca instalaciones que atienden solicitudes web, incluidos PHP-FPM, Apache mod_php, php-cgi, FrankenPHP y LiteSpeed. El riesgo demostrado es especialmente alto en mod_php, pero también deben revisarse los demás entornos. Las ramas antiguas sin soporte requieren una migración o una corrección específica documentada por el proveedor; un parche excepcional del código fuente no renueva el soporte oficial.
Fuentes: aviso de seguridad de PHP, aviso de CVE-2026-109618 y aviso de CVE-2026-109619.
Localiza el PHP que procesa cada sitio
- Consulta la información del servidor desde el sitio. En WordPress, abre Herramientas → Salud del sitio → Información → Servidor y busca la versión de PHP. Los nombres pueden variar según la traducción y el panel del alojamiento.
- Relaciona el dominio y el modo de ejecución. Pregunta al alojamiento qué paquete y qué controlador de PHP atienden ese dominio, incluidos grupos de procesos, subdominios y entornos de pruebas separados. Un servidor puede tener varias versiones instaladas.
- Revisa las tareas en segundo plano. Las tareas programadas, colas y scripts de consola pueden usar otro ejecutable. Una versión comprobada en el terminal no demuestra qué PHP atiende la web.
- Confirma la corrección y su activación. Obtén la versión o paquete corregido, el resultado de instalación y los reinicios necesarios. Pide al administrador que compruebe que las nuevas solicitudes usan el entorno actualizado.
No dejes una página pública de phpinfo(): puede exponer detalles de configuración. Usa un diagnóstico autenticado, herramientas del alojamiento o una comprobación controlada que se elimine al terminar. No publiques configuraciones, variables de entorno ni secretos en un foro de soporte.
Preguntas para enviar al alojamiento
¿Qué entorno de ejecución, origen del paquete y controlador de PHP atienden este dominio? ¿Están corregidas CVE-2026-109618 y CVE-2026-109619, también mediante un posible backport? ¿Cuándo se activó la corrección y se reiniciaron los procesos pertinentes? Comprueben subdominios, pruebas, tareas programadas e instalaciones antiguas y comuniquen los resultados de las pruebas de funcionamiento.
Separa la corrección actual del plan de migración
Una rama con soporte puede pasar a recibir únicamente correcciones de seguridad. Planifica la migración antes de que termine ese plazo, sin esperar al siguiente aviso crítico.
| Rama | Correcciones generales hasta | Correcciones de seguridad hasta |
|---|---|---|
| 8.2 | 31 dic. 2024 — finalizado | 31 dic. 2026 |
| 8.3 | 31 dic. 2025 — finalizado | 31 dic. 2027 |
| 8.4 | 31 dic. 2026 | 31 dic. 2028 |
| 8.5 | 31 dic. 2027 | 31 dic. 2029 |
El soporte del proyecto PHP es distinto de un contrato comercial del distribuidor. Comprueba el paquete y el contrato concretos. La versión mínima compatible con un CMS no demuestra que esa rama sea segura o siga teniendo soporte. Algunas guías antiguas todavía mencionan PHP 7.4, que ya no recibe soporte del proyecto PHP. Consulta la tabla de soporte actual y el aviso de seguridad del proveedor al elegir una versión.
Fuente: versiones de PHP con soporte.
Actualiza con un plan de recuperación y pruebas reales
Identifica al responsable del entorno, la corrección, los requisitos de compatibilidad y la ventana de mantenimiento. Copia archivos, base de datos y configuración y comprueba cómo restaurarlos.
Utiliza un entorno restringido con datos de prueba protegidos. Aplica el paquete oficial o del proveedor con soporte mediante el procedimiento aprobado del alojamiento o servidor.
Confirma el entorno activo y el reinicio necesario. Prueba acceso, formularios, subidas, pagos, correo, tareas y API autorizadas; revisa errores de la aplicación y el servidor.
Prueba también los componentes de publicidad y consentimiento si forman parte del servicio. Que una página se abra no demuestra que funcionen los pagos, el correo o las tareas en segundo plano. Anota paquete o versión, hora, resultados y responsable.
Si una actualización urgente provoca incompatibilidades, coordina la contención y una recuperación con soporte con el alojamiento o el equipo de desarrollo. No vuelvas a exponer silenciosamente un servicio con una vulnerabilidad conocida. El plan de reversión debe considerar tanto la seguridad como la disponibilidad.
Una regla WAF o una versión oculta no sustituyen la corrección
El WAF puede bloquear algunas solicitudes, pero no corrige PHP ni elimina a un atacante ya presente. Cambiar la visualización de errores, ocultar la versión o usar muchos procesos tampoco demuestra que estas vulnerabilidades estén corregidas.
Algunas medidas provisionales oficiales afectan a los recursos del servidor y al comportamiento de sus procesos. No copies un cambio de límite de memoria ni un comando de reinicio en producción sin entender sus efectos. Si no puedes aplicar pronto la corrección, pide al responsable que evalúe restricciones de acceso, suspensión temporal o migración, con un plan y un plazo definidos.
Corregir PHP no cierra una investigación de intrusión
Si encuentras administradores desconocidos, redirecciones inesperadas, archivos modificados o tráfico de salida sospechoso, conserva registros y pruebas e involucra al alojamiento o al equipo de respuesta. Deben evaluar cuentas, tokens, persistencia, archivos e información afectada, además de PHP.
No borres archivos sospechosos de forma masiva ni sobrescribas la única prueba con una restauración. Antes de reabrir el servicio hacen falta contención, reconstrucción o restauración fiable, cierre de la vía de entrada y medidas apropiadas sobre credenciales y sesiones. Consulta los pasos de respuesta a incidentes.
Preguntas frecuentes sobre seguridad de PHP
¿Actualizar WordPress también actualiza PHP?
Normalmente no. WordPress, temas y plugins son componentes de la aplicación. El alojamiento o el administrador gestiona PHP por separado.
¿Hay que revisar PHP en una web estática?
Un sitio que nunca ejecuta PHP es distinto de uno que parece estático pero tiene un formulario, herramienta administrativa o instalación antigua en PHP. Comprueba esos servicios y los subdominios sin uso antes de concluir que PHP no está presente.
¿Debo instalar un escáner desconocido o probar un exploit público?
No. Empieza por el paquete instalado, el entorno activo y el aviso oficial del proveedor. Utiliza únicamente evaluaciones autorizadas y controladas con el administrador; no ejecutes un exploit desconocido contra un servicio en producción.
Más información: preparación de la actualización de PHP en WordPress y seguridad de WordPress. Ante un fallo actual o un error tras actualizar, consulta fallos de servicios y problemas de actualización.