Para quién es esto: para cualquier persona que gestione un sitio web con PHP (servidor propio, VPS, nube, Docker o hosting compartido) y para quienes construyan sitios con WordPress, Laravel, EC-CUBE y similares. Este artículo se basa en los anuncios oficiales del equipo de seguridad de PHP y en declaraciones de organismos públicos y proveedores. No explica cómo atacar nada.
En desarrollo: esta página se actualizará conforme se publique más información
A fecha de 25 de octubre de 2026 (JST); proveedores de hosting y paquetes de sistema operativo a fecha de 02:15 UTC del 23 de octubreAún no se sabe
- Versiones afectadas, puntuación CVSS y versión corregida del tercer problema, CVE-2026-115560 (previsto con la próxima versión regular)
- Explotación en la naturaleza (postura oficial) y si se han producido intrusiones
- Flujos de paquetes de sistema operativo pendientes (RHEL 9 php:8.4, Debian testing forky)
- Proveedores de hosting que no han anunciado la finalización (KAGOYA, CPI para versiones sin corrección publicada, Xserver para PHP 5.5 y anteriores, y otros)
El equipo de seguridad de PHP publicó las correcciones el 21 de octubre, y IPA y JPCERT/CC de Japón emitieron alertas el 22 de octubre. La mayoría de los principales proveedores de hosting compartido han anunciado que la corrección está aplicada. Varias empresas han observado intentos de explotación, pero no se ha anunciado ninguna intrusión confirmada. El 23 de octubre se divulgó un tercer problema (CVE-2026-115560) que las versiones corregidas no abordan. El equipo de PHP lo considera poco probable en la práctica, pero recomienda establecer session.upload_progress.enabled=0 hasta la próxima versión regular. Esta página se actualizará cuando se confirmen los paquetes de sistema operativo y los proveedores restantes.
Las versiones corregidas y las vulnerabilidades (según php.net)
El 21 de octubre de 2026, el equipo de seguridad de PHP publicó un aviso de seguridad en php.net («Critical remote code execution vulnerabilities, update now») y anunció la versión corregida de cada rama.
- Versiones corregidas
- PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35
- CVE-2026-109618
- El manejo de la falta de memoria puede interrumpir PHP mientras los datos internos de la solicitud solo están parcialmente inicializados, y la limpieza de la solicitud puede entonces tratar esos datos no válidos como válidos. Conduce a la ejecución remota de código (RCE)
- CVE-2026-109619
- El estado interno propiedad de la solicitud puede sobrevivir después de que su memoria de respaldo haya sido liberada, y una solicitud posterior atendida por el mismo worker puede usar ese estado obsoleto antes de que la inicialización lo restablezca. Conduce a la ejecución remota de código (RCE)
- Gravedad
- Ambas con CVSS v4.0 de 9.2
- Quién está en riesgo
- Todas las instalaciones de PHP que atienden solicitudes web (PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed). mod_php es el de mayor riesgo, con un exploit demostrado en el que una solicitud sin autenticar activa el ataque antes de que se ejecute cualquier código de la aplicación
- 8.1 y versiones anteriores
- Sin actualización por parte del proyecto PHP. Se proporcionaron backports mínimos de código fuente para 7.4, 8.0 y 8.1
- Distribuciones
- Las distribuciones Linux y los proveedores LTS recibieron los parches con antelación; consulte a su proveedor para obtener paquetes actualizados
- Mitigaciones
- No hay mitigación completa; actualizar es la única opción segura (las medidas temporales si aún no puede actualizar están en el recuadro siguiente)
Medidas temporales si aún no puede actualizar (según el aviso; no le dejan a salvo)
El equipo de PHP enumera ajustes que reducen rutas de ataque concretas hasta que pueda actualizar, pero indica que ninguno de ellos hace que una instalación sea segura. Las principales son revisar memory_limit y los límites de tamaño de solicitud como post_max_size, desactivar session.upload_progress.enabled y reiniciar los workers, y en PHP 8.5 desactivar fatal_error_backtraces. Las condiciones importan, así que lea el aviso oficial antes de cambiar nada, y priorice la actualización.
Un tercer problema que las versiones no corrigen (CVE-2026-115560, divulgado el 23 de octubre)
El 23 de octubre de 2026, el equipo de seguridad de PHP publicó en php.net «Informational advisory: Session upload progress», divulgando un problema que las versiones del 21 de octubre no corrigen. Es independiente de las dos vulnerabilidades críticas.
- CVE
- CVE-2026-115560. Se publicará un aviso completo con la próxima versión (a fecha de 25 de octubre, el registro CVE y NVD aún no tienen entrada)
- Condiciones
- Solo se ve afectada una combinación inusual de configuración y código de aplicación: la configuración establece session.serialize_handler en php_binary o php_serialize, la aplicación lo cambia a php en tiempo de ejecución con ini_set() antes de llamar a session_start(), y el progreso de subida de sesión (session.upload_progress) sigue habilitado. Las aplicaciones que nunca cambian el manejador de serialización en tiempo de ejecución pueden mantener activada la función
- Impacto
- Puede conducir a la ejecución remota de código (RCE). El equipo califica la configuración de «poco probable en la práctica»
- Mitigación
- Establecer session.upload_progress.enabled=0 hasta la próxima versión regular. Este mismo ajuste ya figuraba como mitigación en el aviso del 21 de octubre para CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp); si lo aplicó entonces, manténgalo y no necesita hacer nada más
- Corrección
- Como la configuración es poco probable, se tratará en el ciclo de versiones regular, con la corrección y un aviso completo en la próxima versión. No se dio ninguna fecha
- Aún no publicado
- Versiones afectadas y puntuación CVSS
- Explotación
- El anuncio del equipo de PHP no menciona explotación
Después de la publicación (a fecha de 02:15 UTC, 23 de octubre de 2026)
- Hora de publicación
- Los avisos de seguridad de GitHub se publicaron hacia las 13:34 UTC (22:34 JST), unos 30 minutos antes de lo previsto para las 14:00 UTC
- Versiones afectadas
- Según los avisos oficiales de GitHub, las versiones anteriores a 8.2.35, 8.3.36, 8.4.27 y 8.5.12. Los registros CVE indican 8.2 a 8.5 y no dicen nada sobre la 8.1 y anteriores (el equipo proporcionó correcciones de código fuente para 7.4, 8.0 y 8.1)
- Impacto confirmado (según los avisos)
- CVE-2026-109618: ejecución remota de código sin autenticación confirmada en mod_php; PHP-FPM podría verse afectado según el análisis del código fuente, pero no se ha demostrado un exploit completo. CVE-2026-109619: ejecución remota de código confirmada en mod_php; también validada en PHP-FPM mediante la ruta de progreso de subida de sesión, que depende de una operación de aplicación adecuada
- Organismos públicos japoneses
- El 22 de octubre, IPA publicó «Medidas frente a las vulnerabilidades de PHP (CVE-2026-109618, CVE-2026-109619: PHP2shell)» (en japonés), como seguimiento de su aviso previo del 21 de octubre. Pide a los usuarios que actualicen a las versiones corregidas (8.2.35, 8.3.36, 8.4.27, 8.5.12). Para la 8.1 y anteriores, que ya no tienen soporte, pide que pasen a una versión de PHP con soporte o a un producto o servicio que haya sido corregido. Si las medidas provisionales eficaces son difíciles, pide a las organizaciones que valoren si necesitan bloquear el acceso externo o detener temporalmente el servicio. También cita la opinión de una empresa de seguridad que participó en la investigación, según la cual PHP 5.4 y posteriores se ven afectados por al menos uno de los fallos (opinión de esa empresa, no una declaración del equipo de PHP). JVN publicó JVNVU#99905564 a las 10:30 JST (01:30 UTC) el mismo día, pidiendo aplicar los parches. JPCERT/CC emitió el mismo día una alerta (JPCERT-AT-2026-0033), instando a actualizar cuanto antes y a comprobar indicios de compromiso. También expone qué buscar al revisar si hay un compromiso
- CISA
- CISA emitió una alerta el 21 de octubre instando a las organizaciones a aplicar el parche de inmediato. Indica que «no ha observado la explotación de estas vulnerabilidades en el momento de la publicación». Dice a las organizaciones que no puedan actualizar de inmediato, o que todavía usen PHP 8.1 o anterior, que desconecten los sistemas basados en PHP hasta que puedan parcharse o actualizarse. Los fallos no figuran en el catálogo de Vulnerabilidades Explotadas Conocidas (edición del 21 de octubre)
- Explotación en la naturaleza
- Sin declaración del equipo de PHP, y CISA indica que no había observado explotación en el momento de su publicación. La calificación de explotación que CISA añade a los registros CVE seguía siendo «ninguna» tras su actualización del 22 de octubre. El equipo de inteligencia de amenazas de un importante proveedor de nube afirmó el 21 de octubre que sus honeypots registraron un intento de explotación el 17 de octubre, cuatro días antes de la divulgación (publicación). Afirma que los fallos están «ahora recibiendo intentos de explotación generalizados en la naturaleza», pero que «no está claro si alguno de estos intentos habría tenido éxito en sistemas reales». Recomienda investigar desde al menos el 17 de octubre. Un proveedor de CDN y varias empresas de seguridad también informan de tráfico de ataque o de sondeo (proveedor de CDN, resumen de noticias). Otra empresa de seguridad afirmó en una actualización del 22 de octubre que los exploits públicos no funcionan contra una instalación de PHP por defecto y que la explotación masiva es menos probable de lo que se pensó en un primer momento. En Japón, Lolipop y Heteml dijeron el 22 de octubre que detectaron accesos que parecían dirigirse a los fallos, pero hasta ahora no se ha confirmado ningún acceso no autorizado ni fuga de datos como resultado. No se había anunciado ninguna intrusión confirmada a las 02:15 UTC del 23 de octubre
- Paquetes del sistema operativo
- Ubuntu proporciona correcciones para las versiones 26.10, 26.04, 24.04 y 22.04 enumeradas. Las correcciones para 20.04 y 18.04 requieren Ubuntu Pro; 16.04 y 14.04 requieren su complemento Legacy Support (USN-8948-1, USN-8948-2). Debian ha corregido la 13 (DSA-6574-1) y la 12 (DLA-4848-1); sid ya tiene la 8.4.27-1 corregida, mientras que testing (forky) sigue en la 8.4.26-1 sin corregir. Red Hat ha corregido muchos flujos de RHEL 8–10 (clasificados como Important, access.redhat.com) y añadió RHEL 8 php:8.2 el 21 de octubre (RHSA-2026:87073). RHEL 9 php:8.4 aún no tiene corrección («Affected» en la actualización del 22 de octubre). RHEL 6 está marcada como «Out of support scope» (fuera del ámbito de soporte) sin corrección prevista, y RHEL 7 está afectada por CVE-2026-109619 sin corrección todavía. Alpine ha corregido las versiones 8.5, 8.4 y 8.3. Si PHP procede de paquetes del sistema operativo, aplique ahora la actualización de su proveedor
- Imágenes oficiales de Docker
- Las etiquetas latest, 8.5, 8.4, 8.3 y 8.2 (incluidas las variantes -apache y -fpm) apuntan todas a las versiones corregidas (8.5.12, 8.4.27, 8.3.36, 8.2.35) (hub.docker.com). Las etiquetas de la 8.1 y anteriores, sin soporte, no se han actualizado. La corrección solo surte efecto después de volver a descargar la imagen y recrear los contenedores
- NVD
- La puntuación propia de NVD para ambas es CVSS 3.1 9.8 (Critical); la puntuación del equipo de PHP es CVSS v4.0 9.2 (nvd.nist.gov)
- Afirmación de que la corrección está incompleta
- Una publicación en una lista de correo de vulnerabilidades decía que la corrección de 8.5.12 «puede estar incompleta». El desarrollador que publicó el anuncio del equipo de seguridad de PHP respondió en la misma lista el 22 de octubre (09:11 UTC) que se trata de un «problema no relacionado con impacto mínimo» (un fallo en un componente en un escenario poco probable) y que «no tiene nada que ver con el RCE» (respuesta). El aviso de php.net no ha cambiado
- Windows
- Hay compilaciones para Windows de las versiones corregidas
- remirepo
- El equipo de PHP indica que rpms.remirepo.net, mantenido por voluntarios, no tendrá actualizaciones hoy e insta a cambiar a los paquetes de la distribución o a compilar desde el código fuente
El aviso previo (20 de octubre)
Un día antes, el 20 de octubre de 2026, el equipo de seguridad de PHP publicó en php.net un aviso titulado «Upcoming Critical PHP Security Release». Decía lo siguiente.
- Hora de publicación
- Miércoles 21 de octubre de 2026, 14:00 UTC (23:00 en Japón)
- Alcance
- Dos vulnerabilidades críticas
- Gravedad
- Ambas calificadas con 9.2 según CVSS v4.0
- Solicitud
- Se anima a todos los usuarios de PHP a prepararse desde ahora para actualizar en cuanto esté disponible la versión
- Publicación anticipada
- El equipo puede publicar antes si se hacen públicos detalles de cualquiera de las vulnerabilidades o aparecen pruebas de explotación activa
- Aún no publicado
- Detalles completos, versiones afectadas y versiones corregidas, todos previstos para la publicación
- Últimas versiones en ese momento
- 8.5.11, 8.4.26, 8.3.35 y 8.2.34 (versiones de seguridad del 24 de septiembre de 2026)
CVSS califica la gravedad de una vulnerabilidad de 0 a 10, y 9.0 o superior corresponde a la banda superior «Critical» (véase Qué es CVSS). IPA de Japón también publicó el 21 de octubre un aviso de «preparación previa» pidiendo a las organizaciones que inventaríen los programas que usan PHP. IPA señala que PHP también puede ejecutarse dentro de productos de software y dispositivos de red, no solo en aplicaciones web.
Quién actualiza PHP: depende de su configuración
Cualquier sitio que funcione con PHP puede verse afectado, pero quién actualiza PHP realmente depende del entorno. Equivocarse en esto provoca huecos como «pensaba que lo hacía el proveedor» o «actualicé una versión de PHP distinta de la que sirve el sitio».
Servidor propio, VPS, nube
Lo actualiza usted (actualice los paquetes y luego reinicie)
Docker (imagen oficial)
Reconstruye la imagen cuando salgan las nuevas etiquetas
Paquetes de distribución (Debian, Ubuntu, RHEL …)
La distribución incorpora la corrección y usted la aplica. Los números de versión difieren de los del upstream
Hosting compartido
El proveedor actualiza PHP. Usted comprueba qué versión ha seleccionado
| Entorno | Quién actualiza PHP | Qué debe hacer usted |
|---|---|---|
| Servidor propio, VPS, servidor en la nube | Usted | Instale la versión corregida (o el paquete corregido de la distribución) y reinicie PHP-FPM o Apache |
Imagen oficial de Docker (php:8.4-fpm y similares) | Los mantenedores de la imagen y usted | Cuando se publique la etiqueta corregida, descárguela, reconstruya su imagen y reemplace los contenedores. No reutilice una imagen base antigua en caché |
| Paquetes de distribución (familia Debian, Ubuntu, RHEL) | La distribución y usted | Consulte los avisos de seguridad de la distribución para el paquete corregido y aplíquelo. Las distribuciones solo incorporan la corrección, por lo que sus números de versión no coincidirán con los números upstream de PHP |
| Hosting compartido | El proveedor | Compruebe la versión de PHP de cada sitio en el panel de control, planifique un cambio si es la 8.1 o anterior, y lea los avisos del proveedor en su sitio web oficial |
| PHP integrado en productos o dispositivos | El fabricante | Consulte los avisos de seguridad del fabricante (puede que no pueda ver el PHP que contiene) |
El botón de actualización de WordPress o Laravel no actualiza PHP en sí. Actualizar su aplicación y actualizar PHP son tareas separadas.
Cómo comprobar su versión de PHP de forma segura
Si puede iniciar sesión en el servidor, use la línea de comandos
Si tiene acceso por shell, este comando muestra la versión de PHP.
php -vNo obstante, esta es la versión de PHP de la línea de comandos (CLI). El PHP que sirve su sitio web (PHP-FPM o el módulo de Apache) puede ser otra versión. Es habitual que un mismo servidor tenga instaladas la 8.2 y la 8.4. Compruebe el lado web con los métodos siguientes o mediante el nombre del servicio PHP-FPM (por ejemplo php8.4-fpm).
En WordPress, use Salud del sitio
En el panel de WordPress, abra Herramientas, luego Salud del sitio, después la pestaña Información, y despliegue «Servidor». Muestra la versión de PHP que ejecuta realmente el sitio, de modo que cualquiera con acceso de administrador puede comprobarlo sin iniciar sesión en el servidor.
En hosting compartido, use el panel de control
En hosting compartido, los ajustes de versión de PHP del panel de control muestran la versión seleccionada para cada dominio. Muchos proveedores permiten elegir una versión distinta por dominio, así que compruebe cada dominio.
No deje una página phpinfo() en línea
Una forma de ver la versión es colocar en el directorio público un archivo que llame a phpinfo(), pero esa página muestra la versión de PHP, la configuración y los detalles internos del servidor. Ofrece a un atacante información útil para dirigir el ataque, así que bórrela en cuanto haya terminado. Si los tres métodos anteriores son suficientes, ni siquiera la cree. Cómo encontrar archivos olvidados se explica en Archivos secretos dejados en directorios públicos.
Antes de actualizar
Enumere sus sitios y servidores
Para cada sitio, anote en una sola tabla en qué servidor está, la versión de PHP (CLI y web), quién actualiza PHP (usted, el proveedor o un contratista) y los datos de contacto del responsable. Incluya los sitios de staging y los sitios olvidados que sigan públicos. Los sitios olvidados son los que se quedan sin actualizar. Un método se explica en la lista de comprobación de inventario de seguridad.
Haga copias de seguridad
Respalde archivos y bases de datos para poder revertir si la actualización rompe el sitio. Guarde la copia fuera del servidor y confirme que puede restaurarla (copias de seguridad y recuperación esenciales).
Establezca una ventana de mantenimiento y los pasos
Decida cuándo actualizará (incluidos horarios nocturnos), quién lo hará y cómo informará a las personas afectadas. En sus propios servidores, anote los comandos de actualización, los servicios que hay que reiniciar y cómo confirmar el resultado. Si un contratista o agencia gestiona el servidor, confirme hoy quién lo actualiza y cuándo.
En una rama sin soporte, planifique la migración
Según php.net, el soporte de PHP 8.1 terminó el 31 de diciembre de 2025, igual que para la 8.0 y anteriores. Con la política de soporte del proyecto PHP, las ramas sin soporte no reciben versiones de seguridad. Esta vez tampoco se publicó una versión oficial (solo backports mínimos de código fuente para 7.4, 8.0 y 8.1); planifique el paso a una versión con soporte, de la 8.2 a la 8.5. El soporte de seguridad de la 8.2 también termina el 31 de diciembre de 2026, así que si migra ahora, la 8.3 o posterior es el destino más seguro.
No se apresure con plugins de «corrección» no oficiales ni con soluciones de configuración
Antes de que se publique una corrección, suelen circular plugins no oficiales y cambios de configuración que dicen bloquear el problema. Los métodos que no figuran en el aviso oficial no pueden verificarse. La única solución real es la versión corregida de PHP (o el paquete corregido de su distribución). Las reglas de WAF (cortafuegos de aplicaciones web) pueden ganar tiempo, pero no sirven de nada para el tráfico que llega al servidor sin pasar por el WAF.
Actualizar a la versión corregida
Las versiones corregidas son 8.5.12, 8.4.27, 8.3.36 y 8.2.35 (publicadas el 21 de octubre de 2026). Si instaló PHP desde los paquetes de su sistema operativo, use los paquetes actualizados que ofrezca su distribución.
Actualice a la versión corregida de su rama
Consulte el anuncio de publicación y el ChangeLog de php.net para la versión corregida de su rama (8.2, 8.3, 8.4 u 8.5) y actualice a esa versión o posterior. Si usa paquetes de distribución, consulte los avisos de seguridad de su distribución (Debian, Ubuntu, Red Hat y otras) para la versión corregida del paquete. En Docker, descargue y reconstruya cuando se publiquen las etiquetas corregidas.
Reinicie PHP-FPM y Apache
Actualizar el paquete no cambia los procesos de PHP que ya están en ejecución. Reinicie PHP-FPM (por ejemplo php8.4-fpm), o Apache si usa su módulo de PHP, para que se cargue el nuevo PHP.
Revise sus ajustes de sesión para el tercer problema (CVE-2026-115560)
Este problema permanece incluso después de pasar a las versiones del 21 de octubre. Compruebe dos cosas.
- Si la configuración (php.ini y similares) establece session.serialize_handler en php_binary o php_serialize, y el código de la aplicación lo cambia a php con ini_set() (buscar
session.serialize_handleren su código es una forma rápida de encontrarlo) - Si session.upload_progress.enabled sigue activado (viene activado por defecto;
php -ien la CLI puede diferir del lado web, así que revise también el pool de PHP-FPM y la configuración del PHP que sirve el sitio)
Si se cumplen ambas condiciones, o no puede determinarlo, establezca session.upload_progress.enabled=0 hasta la próxima versión regular. Hágalo donde se lea al arrancar, como php.ini, el pool de PHP-FPM o la configuración del servidor web, y reinicie todos los workers (el aviso del 21 de octubre indica establecer session.upload_progress.enabled=0 de forma administrativa y reiniciar todos los workers). La función informa del progreso de las subidas de archivos; si su sitio muestra el progreso de subida, compruebe después que sigue funcionando. Si ya la desactivó como medida temporal según el aviso del 21 de octubre, déjela así. Entre los hosts compartidos japoneses, Heteml y Lolipop ya han desactivado esta función.
Confirme la versión tanto en CLI como en web
Además de php -v, use Salud del sitio de WordPress o el estado del servicio PHP-FPM para confirmar que el PHP que sirve el sitio web es ya la versión corregida. En servidores con varias versiones de PHP instaladas, compruebe todas.
Compruebe que el sitio funciona y que nada parece anómalo
Revise las páginas clave, el inicio de sesión, los formularios de contacto y los pagos. Si le preocupa que el sitio fuera atacado antes de la corrección, busque archivos desconocidos, cuentas de administrador adicionales y desfiguraciones. Un importante proveedor de nube detectó un intento de explotación el 17 de octubre, cuatro días antes de la divulgación, y recomienda investigar desde al menos esa fecha. La alerta de JPCERT/CC también enumera qué buscar. Cómo comprobarlo se explica en Cómo comprobar si su sitio web o servidor ha sido comprometido.
Para usuarios de hosting compartido
En hosting compartido, el proveedor instala y gestiona PHP en el servidor. Los usuarios no pueden instalar por sí mismos la versión corregida.
Lo que hace el proveedor
- Actualiza el PHP instalado en los servidores a la versión corregida
- Aplica protecciones temporales o mantenimiento de emergencia si es necesario
- Publica actualizaciones de estado en su sitio web oficial y en redes sociales
Lo que hace usted
- Comprueba la versión de PHP seleccionada para cada dominio en el panel de control
- Si es la 8.1 o anterior, pruebe y después cambie a una versión más reciente
- Lea los avisos del proveedor en su sitio web oficial, no a través de enlaces de correo
- Mantenga también actualizados el núcleo de WordPress, los plugins y los temas
El mantenimiento de emergencia del lado del proveedor puede dejar el panel de control no disponible durante un tiempo. Termine sus comprobaciones pronto para no quedarse sin poder cambiar la versión de PHP durante esa ventana.
Respuestas de los proveedores (confirmadas por este sitio a fecha de 02:15 UTC, 23 de octubre de 2026)
Muchos proveedores dicen haber terminado de aplicar la corrección. A fecha de 02:15 UTC del 23 de octubre (11:15 JST), KAGOYA no había anunciado su finalización. CPI pide a los clientes con versiones sin corrección publicada que apliquen mitigaciones o pasen a una versión parcheada. No se encontró ningún aviso sobre PHP para Rakko Server ni para WADAX. Las horas siguientes están en JST.
| Proveedor | Aviso oficial | Qué dice |
|---|---|---|
| Xserver (Japón) | Aviso de suspensión temporal de sitios oficiales y paneles de control como medida de seguridad preventiva (estado a las 20:10 del 22 de octubre, en japonés) | Aplicó correcciones oficiales o propias a cada versión de PHP que ofrece. Terminó de aplicarlas en todos los servidores objetivo para PHP 8.2–8.5 a las 06:45 del 22 de octubre, 7.4–8.1 a las 12:00 y 5.6–7.3 a las 14:00. Para PHP 5.5 y anteriores, los parches aún se están «creando y verificando». Desde las 20:10 reabrió por turnos sus sitios de servicio; los sitios oficiales, los paneles de control, el webmail, la API/MCP y el formulario de contacto han vuelto (algunas funciones, como el webmail antiguo, siguen en mantenimiento). Puede pedir a algunos clientes pasos adicionales según su uso. Indica que la acción no se debe a un acceso no autorizado |
| Sakura Rental Server (Japón) | Estado de la respuesta a las vulnerabilidades de PHP (22 de octubre, en japonés) | Corrección aplicada a todas las versiones de PHP seleccionables en el panel de control; no se necesita ninguna acción urgente del cliente. También sugiere pasar a la última versión de PHP con soporte. El webmail usado por algunos servicios se restauró a las 13:45 del 22 de octubre y phpMyAdmin a las 15:15 (aviso de mantenimiento). El mantenimiento de emergencia del 21 de octubre (n-2697) terminó a las 22:30 del 21 de octubre |
| mixhost (Japón) | [Completado] Respuesta a las vulnerabilidades críticas de PHP (22 de octubre, en japonés) | Paquetes de corrección aplicados en todos los servidores hacia las 10:18 del 22 de octubre, que cubren PHP 5.2–8.5. Los números de versión no cambian (por ejemplo, 8.4.26 sigue siendo 8.4.26). No se necesita ninguna acción del cliente. El mantenimiento de Mi Página desde las 22:10 del 21 de octubre también ha terminado |
| ColorfulBox (Japón) | Aviso (22 de octubre, en japonés) | Las protecciones previas y la actualización a las versiones corregidas se completaron en todos los servidores (compartidos, business, Tada Server y dedicados) por la mañana del 22 de octubre, incluidas las 7.4, 8.0 y 8.1. Actualizado en el mismo lugar, manteniendo la versión de PHP que usa; no se necesita ninguna acción del cliente |
| XREA, VALUESERVER, CORESERVER, One Rental Server (Japón) | XREA, VALUESERVER, CORESERVER V1 / V2, One (en japonés) | Los cinco completados. XREA, VALUESERVER y CORESERVER V1 terminaron a las 00:50 del 22 de octubre, y sus avisos actualizados indican que todas las versiones de PHP ofrecidas (5.3–8.5) están corregidas. One Rental Server terminó a las 10:20 (5.6–8.5) y CORESERVER V2 a las 11:13 (5.2–8.5). Los usuarios no necesitan cambiar de versión de PHP |
| Heteml (Japón) | El mantenimiento por las vulnerabilidades de PHP se completó, y cómo se desarrolló, [Completado] aviso de mantenimiento (18:05 del 22 de octubre, en japonés) | Los sitios de clientes volvieron a las 11:24 del 22 de octubre y todos los servicios se restauraron a las 18:05. PHP 8.2–8.5 recibieron las versiones oficiales corregidas, 7.4, 8.0 y 8.1 las correcciones del equipo de PHP para ramas sin soporte, y 5.6–7.3 las correcciones propias del proveedor basadas en las oficiales. En todas las versiones, esta medida desactiva una función (session.upload_progress), y se pide a los clientes que comprueben que sus sitios funcionan y que pasen a la 8.2 o posterior. Hasta que se aplicaron las correcciones, detuvo los sitios de algunos servidores desde aproximadamente las 03:05 del 22 de octubre |
| Lolipop (Japón) | El mantenimiento por las vulnerabilidades de PHP se completó, y cómo se desarrolló, [Completado] aviso de mantenimiento (actualizado a las 16:57 del 22 de octubre, en japonés) | Los sitios de clientes volvieron hacia las 13:00 del 22 de octubre y todo el mantenimiento terminó a las 16:57. PHP 8.2–8.5 recibieron las versiones oficiales corregidas, 7.4, 8.0 y 8.1 las correcciones del equipo de PHP para ramas sin soporte, y 5.3–7.3 las correcciones propias del proveedor basadas en las oficiales. Una función (session.upload_progress) está desactivada en todas las versiones, y se pide a los clientes que revisen sus sitios y pasen a la 8.2 o posterior. Hasta que se aplicaron las correcciones, detuvo los sitios de algunos servidores desde aproximadamente las 03:09 del 22 de octubre |
| KAGOYA (Japón) | Impacto de las vulnerabilidades de PHP en sus servicios (actualizado a las 18:15 del 22 de octubre, en japonés) | Para sus servidores de alquiler (PHP 7.4 y 8.1–8.5), indicó que las actualizaciones a las versiones corregidas estaban en curso y que se esperaba que terminaran a las 24:00 del 22 de octubre. A fecha de las 11:15 del 23 de octubre no se encontró ningún aviso de finalización. Para los planes de dedicado gestionado, compartido y WordPress, la corrección definitiva aún se está organizando, y pide a los clientes que valoren poner los sitios fuera de línea (cambiando a una página de mantenimiento) o restringir el acceso como medida provisional. Su actualización de las 10:35 indicaba que no se había confirmado ningún daño, como ataques o fugas de datos. Desde las 14:15 del 22 de octubre también realiza mantenimiento de seguridad en el webmail, el sitio de socios y sus paneles de control, sin fecha de fin indicada |
| ConoHa WING (Japón) | Respuesta a las vulnerabilidades de PHP completada (informe final) (22 de octubre, en japonés) | Los parches de seguridad se habían aplicado a todos los servidores a las 20:45 del 22 de octubre, momento en que también terminó el mantenimiento de emergencia. Los parches se aplicaron a todas las versiones de PHP ofrecidas incorporando solo la corrección, sin subir la versión, por lo que las pantallas como Salud del sitio de WordPress pueden seguir mostrando el número antiguo (por ejemplo 8.5.11). Los clientes no necesitan cambiar de versión. El webmail y el gestor de archivos volvieron hacia las 18:30, y phpMyAdmin también está de vuelta |
| Onamae.com Rental Server (Japón) | Respuesta a las vulnerabilidades de PHP completada (22 de octubre, en japonés) | Mismo contenido que ConoHa WING: los parches se habían aplicado a las 20:45 del 22 de octubre (planes Basic, RS y AI Homepage Pack). Solo se incorporó la corrección en todas las versiones de PHP ofrecidas, por lo que el número de versión mostrado puede no haber cambiado. Los clientes no necesitan cambiar de versión. El webmail y el gestor de archivos volvieron hacia las 18:30, y phpMyAdmin también está de vuelta |
| CPI (Japón) | Aviso sobre la suspensión de su sitio de servicio y de los paneles de control por las vulnerabilidades de PHP (actualizado a las 09:55 del 23 de octubre, en japonés) | Las versiones para las que existe el último parche están terminadas (por ejemplo 8.2 y 8.3 en SV-Basic, 8.2–8.4 en Business Standard). Para las demás versiones, pide a los clientes que valoren aplicar mitigaciones y pasar a una versión de PHP parcheada (en los planes antiguos, que valoren aplicar mitigaciones). El sitio de servicio se reabrió a las 21:00 del 22 de octubre y el panel de control hacia las 17:00; el gestor de archivos seguro y algunas otras herramientas se esperan después del 30 de octubre. Indica que no se ha confirmado ningún acceso no autorizado ni ataques que exploten los fallos |
| Rakko Server (Japón) | Sitio web oficial (en japonés) | Su sitio de servicio se detuvo desde las 19:00 del 21 de octubre como precaución (indicó que no se encontró ningún acceso no autorizado). El sitio ha vuelto, pero no se encontró ningún aviso sobre PHP a fecha de las 11:15 del 23 de octubre |
| WADAX (Japón) | Sitio web oficial (en japonés) | Al consultarlo el 22 de octubre, todo el sitio estaba suspendido por seguridad hasta que se garantizara la seguridad. A fecha de las 11:15 del 23 de octubre el sitio web ha vuelto, pero no se encontró ningún aviso sobre PHP |
Los proveedores redactan sus avisos de finalización de forma distinta. Compruebe en el aviso de su proveedor qué versiones de PHP están cubiertas y si tiene que hacer algo. Algunos proveedores, como ConoHa WING, Onamae.com y mixhost, solo incorporaron la corrección, por lo que el número de versión de PHP no cambia. No dé por no parcheado un sitio solo por el número; compruebe el aviso del proveedor. Los avisos de otros proveedores se añadirán cuando se confirmen.
Cuidado con los correos falsos que se hacen pasar por su proveedor
Cuando una vulnerabilidad o un mantenimiento de emergencia aparecen en las noticias, aumentan los correos falsos que dicen proceder de proveedores de hosting o de dominios («inicie sesión de nuevo por mantenimiento urgente», «su cuenta será suspendida»). No inicie sesión a través de enlaces de correo. Compruebe a través del sitio web oficial que usted mismo tenga guardado o de la cuenta oficial del proveedor en redes sociales. Cómo reconocerlos se explica en Qué es el phishing. Cómo prepararse ante una brecha en el propio proveedor se explica en Cuando su proveedor de hosting sufre una brecha.
Informes anteriores a la publicación
El anuncio oficial del 21 de octubre confirmó los identificadores CVE (CVE-2026-109618, CVE-2026-109619) y que ambas son vulnerabilidades de ejecución remota de código (RCE). La tabla siguiente muestra lo que se informó antes de la publicación; la explotación en la naturaleza todavía no está confirmada oficialmente.
Antes de la publicación, medios y empresas de seguridad difundieron varias afirmaciones. Ninguna fue una declaración oficial del equipo de seguridad de PHP. Este sitio no ha cambiado sus pasos recomendados a partir de ellas.
| Afirmación | Fuente | Estado |
|---|---|---|
| Los detalles de los fallos se filtraron antes de la publicación programada | Una empresa de seguridad (hablando con un medio de noticias) | No confirmado |
| Ambas son vulnerabilidades de ejecución remota de código (RCE) | Empresas de seguridad y CERT-EU (el CSIRT de las instituciones de la UE) | Confirmado por el anuncio del 21 de octubre |
| Identificadores CVE (CVE-2026-109618, CVE-2026-109619) | Empresas de seguridad, medios y CERT-EU | Confirmado por el anuncio del 21 de octubre |
| Afecta a un amplio rango desde PHP 5 en adelante | Empresas de seguridad, CERT-EU | No confirmado (los avisos de GitHub cubren las versiones anteriores a cada versión corregida sin límite inferior indicado; backports proporcionados para 7.4/8.0/8.1). El aviso de IPA del 22 de octubre cita a una empresa de seguridad que participó en la investigación y que afirma que PHP 5.4 y posteriores se ven afectados |
| No se ha observado explotación | Una empresa de seguridad (hablando con un medio de noticias) | Opinión de la propia fuente |
| Se han observado indicios de ataques | Un directivo de un proveedor de CDN, otra empresa de seguridad (citando informes de socios de hosting) y un importante proveedor de nube | Un proveedor de CDN dijo en su publicación de las 13:56 UTC que observó tráfico de ataque, y un importante proveedor de nube dijo que detectó intentos de explotación desde el 17 de octubre (véase «Después de la publicación»). Ningún organismo público lo ha confirmado |
Las opiniones sobre la explotación difieren según la fuente. En su aviso previo del 21 de octubre, IPA dijo que en ese momento no había confirmado ataques que explotaran los fallos. CISA también indicó en su alerta del 21 de octubre que no había observado explotación en el momento de la publicación. En cambio, un importante proveedor de nube dice que detectó un intento de explotación el 17 de octubre, antes de la divulgación. Haya comenzado o no la explotación, la acción es la misma: actualice ya a la versión corregida.
Postura de este sitio: lo que decide hoy es quién actualiza y cuándo
Las versiones corregidas ya están disponibles. Lo que queda pendiente es decidir quién actualiza y cuándo, y hacerlo. El hueco habitual no es técnico, sino de responsabilidad. Un sitio que construyó una agencia, un VPS que configuró alguien que ya no está, un servidor de pruebas que nadie recuerda: el PHP sin un responsable nombrado es lo que más tiempo se queda desactualizado. Cómo valorar la gravedad se explica en Cómo priorizar vulnerabilidades (CVSS, EPSS, KEV), y los pasos tras la divulgación en Qué hacer cuando se publica una vulnerabilidad.
Cronología
24 de septiembre de 2026
PHP 8.5.11, 8.4.26, 8.3.35 y 8.2.34 publicados como versiones de seguridad (las últimas versiones en ese momento del aviso).17 de octubre (anunciado el 21 de octubre)
Los honeypots de un importante proveedor de nube detectan un intento de explotación, cuatro días antes de la divulgación.20 de octubre
El equipo de seguridad de PHP anuncia en php.net una versión de seguridad para las 14:00 UTC del 21 de octubre. Ambas vulnerabilidades tienen una puntuación de 9.2 según CVSS v4.0. El mismo día, según se informa, una empresa de seguridad dijo a un medio que los detalles se habían filtrado.21 de octubre
IPA publica su aviso de «preparación previa». Xserver suspende el acceso a sus sitios oficiales y paneles de control desde las 16:00 JST.21 de octubre
El equipo de seguridad de PHP publica 8.5.12, 8.4.27, 8.3.36 y 8.2.35 y un aviso de seguridad. Indica que CVE-2026-109618 y CVE-2026-109619 pueden permitir ambas la ejecución remota de código sin autenticación e insta a todos a actualizar de inmediato.21 de octubre
CISA emite una alerta que insta a parchear de inmediato y dice que no ha observado explotación en el momento de la publicación.22 de octubre
Xserver (8.2–8.5), Sakura, mixhost, ColorfulBox, los servicios del grupo Value Domain, Heteml, Lolipop y otros anuncian que la corrección está aplicada. JVN publica JVNVU#99905564, IPA emite su alerta sobre medidas frente a las vulnerabilidades de PHP, y JPCERT/CC emite su alerta (JPCERT-AT-2026-0033).22 de octubre (tarde, JST)
ConoHa WING y Onamae.com dicen que los parches estaban aplicados a las 20:45 JST. Xserver ha terminado PHP 5.6–8.5 a las 14:00 JST y reabre sus sitios oficiales desde las 20:10 JST. KAGOYA dice que espera tener sus servidores de alquiler terminados a las 24:00 JST.23 de octubre
El equipo de seguridad de PHP divulga un tercer problema (CVE-2026-115560) no corregido por las versiones del 21 de octubre. Lo califica de poco probable en la práctica y recomienda establecer session.upload_progress.enabled=0 hasta la próxima versión regular.
Fuentes (registro público)
Los hechos de este artículo se basan en la siguiente información pública. Los elementos que PHP no ha publicado oficialmente (como la explotación en la naturaleza) se atribuyen a medios o empresas de seguridad y se marcan como no confirmados.
- Equipo de seguridad de PHP, «Security advisory: Critical remote code execution vulnerabilities, update now» (21 de octubre de 2026) — php.net
- Equipo de seguridad de PHP, «Informational advisory: Session upload progress» (CVE-2026-115560, 23 de octubre de 2026) — php.net
- Aviso de seguridad de GitHub para CVE-2026-109618 — github.com
- Aviso de seguridad de GitHub para CVE-2026-109619 — github.com
- ChangeLog (8.5.12, 8.4.27, 8.3.36, 8.2.35) — php.net
- PHP, «Upcoming Critical PHP Security Release» (20 de octubre de 2026) — php.net
- Página principal de PHP (últimas versiones en ese momento: 8.5.11, 8.4.26, 8.3.35, 8.2.34) — php.net
- PHP, «Supported Versions» — php.net
- PHP, «Unsupported Branches» (fin de vida de la 8.1: 31 de diciembre de 2025) — php.net
- Avisos de seguridad de php-src (GitHub) — github.com
- IPA, aviso pidiendo preparación previa para la versión de seguridad de PHP (21 de octubre de 2026, en japonés) — ipa.go.jp
- IPA, «Medidas frente a las vulnerabilidades de PHP (CVE-2026-109618, CVE-2026-109619: PHP2shell)» (22 de octubre de 2026, en japonés) — ipa.go.jp
- JVN, JVNVU#99905564 sobre múltiples vulnerabilidades de PHP que permiten la ejecución arbitraria de código (22 de octubre de 2026, en japonés) — jvn.jp
- JPCERT/CC, alerta sobre múltiples vulnerabilidades de PHP (CVE-2026-109618, CVE-2026-109619) (JPCERT-AT-2026-0033, 22 de octubre de 2026, en japonés) — jpcert.or.jp
- CISA, «Critical Vulnerabilities in PHP Require Immediate Patching» (21 de octubre de 2026) — cisa.gov
- Xserver Inc., aviso de suspensión temporal como medida de seguridad preventiva (22 de octubre de 2026; estado a las 20:10 JST, en japonés) — xserver.ne.jp
- Equipo de inteligencia de amenazas de un importante proveedor de nube: intentos de explotación desde el 17 de octubre, antes de la divulgación (21 de octubre de 2026) — aws.amazon.com
- Respuesta de un desarrollador del equipo de seguridad de PHP a la afirmación de que la corrección está incompleta (22 de octubre de 2026) — openwall.com
- Avisos de finalización de proveedores de hosting: ConoHa WING / Onamae.com / Lolipop / Heteml (todos del 22 de octubre de 2026, en japonés)
- CERT-EU, «Security Advisory 2026-018: Critical Vulnerabilities in PHP» (fuente de afirmaciones no confirmadas) — cert.europa.eu
- Informe de medios: relato de una empresa de seguridad sobre la filtración y su opinión de que no se observó explotación (BleepingComputer, 20 de octubre de 2026) — bleepingcomputer.com
- Informe de medios: mitigación del tercer problema (CVE-2026-115560) (BleepingComputer, 23 de octubre de 2026) — bleepingcomputer.com
- Alerta de una empresa de seguridad: informes de ataques desde socios de hosting (21 de octubre de 2026) — patchstack.com
- Publicación de un directivo de un proveedor de CDN: primeros ataques y reglas de WAF (21 de octubre de 2026; citada en la alerta anterior) — x.com
- Respuesta rápida de una empresa de seguridad: no se observó explotación en la naturaleza en sistemas de socios (a fecha del 21 de octubre de 2026) — huntress.com
- Análisis de empresas de seguridad (identificadores CVE, tipo y alcance informados) — sansec.io / tenable.com
- Avisos de seguridad de distribuciones: Debian security-tracker.debian.org / Ubuntu ubuntu.com / Red Hat access.redhat.com (RHEL 8 php:8.2: RHSA-2026:87073)
- Imagen oficial de Docker (php) — hub.docker.com
Historial de actualizaciones
2026-10-25: Se añade el tercer problema divulgado por el equipo de seguridad de PHP el 23 de octubre (CVE-2026-115560, no corregido por las versiones del 21 de octubre): sus condiciones, la mitigación (session.upload_progress.enabled=0) y la corrección prevista, además de un paso para que los administradores revisen sus ajustes. Se actualizan el resumen, el recuadro de estado, las preguntas frecuentes, la cronología y las fuentes.
2026-10-23 (02:15 UTC): Se añade el informe de un importante proveedor de nube sobre intentos de explotación desde el 17 de octubre (no está claro si alguno tuvo éxito), los informes de proveedores japoneses sobre accesos que parecían dirigirse a los fallos (sin daños confirmados), y que no se ha anunciado ninguna intrusión confirmada; se añade el consejo de revisar los registros desde el 17 de octubre en adelante. Se añade la respuesta del desarrollador del equipo de seguridad de PHP indicando que el informe de «corrección incompleta» no está relacionado. Se actualizan los paquetes del sistema operativo (Debian sid corregido, RHEL 9 php:8.4 aún sin corregir, sin corrección prevista para RHEL 6) y el estado de los proveedores de hosting (ConoHa WING, Onamae.com, Lolipop y Heteml completados; Xserver terminó PHP 5.6–7.3; versiones cubiertas por los servicios del grupo Value Domain; estado de KAGOYA y CPI).
2026-10-22 (04:45 UTC): Se cambia el título a formato de noticia de última hora y se añaden la alerta de IPA, la alerta de JPCERT/CC (JPCERT-AT-2026-0033), JVNVU#99905564 y la alerta de CISA. Se actualizan los informes de explotación (sigue sin haber intrusiones confirmadas), los paquetes del sistema operativo (se añade RHEL 8 php:8.2; RHEL 9 php:8.4 y las ramas de desarrollo de Debian pendientes), las imágenes oficiales de Docker y el estado de finalización en hosting compartido (Xserver, Sakura, mixhost, ColorfulBox, los servicios del grupo Value Domain, Heteml y otros).
2026-10-21 (21:30 UTC): Se actualizan los informes de explotación (intentos observados, sin intrusiones confirmadas), los paquetes corregidos de los proveedores de sistemas operativos, las imágenes oficiales de Docker ya corregidas, la puntuación de NVD, una afirmación no confirmada de que la corrección está incompleta y las novedades de hosting (Xserver empezó a aplicar correcciones, se añade WADAX).
2026-10-21 (14:30 UTC): Se añade el informe de un proveedor de CDN sobre tráfico de ataque observado, los paquetes corregidos de Ubuntu (USN-8948-1), las entradas de NVD y el estado de las imágenes oficiales de Docker.
2026-10-21 (14:10 UTC): Se añade el estado posterior a la publicación (hora de publicación, versiones afectadas, impacto confirmado en los avisos, sin pronunciamiento oficial sobre la explotación, paquetes del sistema operativo, imágenes oficiales de Docker, remirepo) y las novedades de hosting posteriores a las 21:00 JST (se añaden CPI y mixhost, preguntas frecuentes de Xserver, finalización de Sakura).
2026-10-21 (tras la publicación): Se incorpora el anuncio del equipo de seguridad de PHP del 21 de octubre (versiones corregidas, identificadores CVE, naturaleza de los fallos, quién está en riesgo, cómo se tratan la 8.1 y anteriores, medidas temporales) y se reescriben el título y el mensaje clave.
2026-10-21: Primera versión, basada en el aviso del equipo de seguridad de PHP del 20 de octubre, el aviso de preparación previa de IPA y el aviso de Xserver. Los identificadores CVE, las versiones afectadas y los números de versión corregidos se añadirán tras la publicación.
Lectura recomendada
- ¿Fue atacado su sitio?: Cómo comprobar si su sitio web o servidor ha sido comprometido
- Cuando el proveedor sufre una brecha: Cuando su proveedor de hosting sufre una brecha / Acceso no autorizado en ConoHa WING
- Ajustes de hosting compartido: Protección de .env en hosting compartido
- WordPress y Laravel: Seguridad de WordPress / Seguridad de Laravel
- Preparación: Copias de seguridad y recuperación esenciales / Lista de comprobación de inventario de seguridad
- Otra corrección crítica esa misma semana: GitLab CVE-2026-110264 (con las correcciones de expresiones regulares de Ruby)
- Términos: Qué es RCE (ejecución remota de código) / Qué es CVSS