Tu web dice que está al día. ¿Has comprobado todo lo que toca?

Te llega una noticia sobre un fallo grave de seguridad. Hablan de PHP, de inteligencia artificial y de un montón de páginas que podrían estar afectadas. Como tu web funciona con WordPress, entras a comprobarlo.

WordPress está al día. Los plugins, también. En la sección de actualizaciones no queda nada pendiente.

Cierras el panel con bastante más tranquilidad.

La comprobación tiene sentido, pero puede haberse quedado a medias. Porque el componente afectado puede estar en el servidor y actualizarse por otro camino.

Eso es lo que hace interesante el caso de PHP2Shell: obliga a mirar qué estamos comprobando cuando decimos que una web está actualizada.

Qué ha pasado con PHP

El 21 de octubre de 2026 se publicaron correcciones para dos vulnerabilidades críticas de PHP, el lenguaje sobre el que funciona WordPress. Bajo determinadas condiciones, permitían que un atacante ejecutara código en el servidor sin iniciar sesión. El equipo de PHP pidió actualizar las instalaciones afectadas con urgencia. Aviso oficial de PHP.

Investigadores de Wiz demostraron ataques en entornos de prueba con WordPress, Drupal y Joomla. El problema estaba en PHP, por debajo del código de esas aplicaciones. Investigación de Wiz.

Aquí conviene separar tres cosas: tener un componente vulnerable, recibir un intento de ataque y haber sufrido una intrusión. Son situaciones distintas y requieren pruebas distintas.

También hay que poner en contexto el famoso 70 %. W3Techs sitúa PHP en aproximadamente siete de cada diez webs cuyo lenguaje de servidor puede identificar. Esa cifra explica su presencia; no cuenta páginas atacadas ni permite saber cuántas siguen pendientes de corregir. Estadísticas de W3Techs.

Una web tiene más de una lista de actualizaciones

En un WordPress hay varias piezas que conviene distinguir.

La primera es la propia aplicación: WordPress, el tema y los plugins. Buena parte de sus actualizaciones aparecen en el panel.

Después está PHP, que permite ejecutar esa aplicación. Su versión y sus correcciones se gestionan normalmente desde el alojamiento o por quien administra el servidor.

Y hay más: el servidor web, el sistema operativo y otros servicios también necesitan mantenimiento.

Cada pieza tiene su recorrido. Por eso puedes haber actualizado todos los plugins y seguir teniendo pendiente una corrección en PHP. El propio proyecto WordPress explica que PHP se instala en el servidor y que actualizarlo implica actuar sobre el alojamiento o pedir ayuda al proveedor. Guía de WordPress sobre PHP.

Qué ha hecho Hostinger en este caso

Hostinger nos ha enviado una comunicación explicando que, según sus pruebas, los ataques conocidos no conseguían aprovechar la vulnerabilidad en su plataforma de alojamiento gestionado. También ha detallado las protecciones aplicadas y confirmado la instalación del parche de PHP, sin que sus clientes tuvieran que intervenir. Explicación técnica de Hostinger.

Es un ejemplo concreto de trabajo que ocurre fuera del panel de WordPress: revisar la infraestructura, aplicar las correcciones y comunicar qué queda cubierto.

La distinción está en el servicio contratado. En el alojamiento gestionado, Hostinger se encarga de PHP. En sus VPS, esa responsabilidad corresponde a quien administra el servidor.

Además, hay un detalle útil: el parche puede estar incorporado a la versión que ya utiliza la web sin cambiar su número visible. Para comprobarlo en su alojamiento gestionado, Hostinger indica que debe revisarse la fecha de compilación —Build Date— en «PHP Info»: debe ser del 21 de octubre de 2026 o posterior. Cómo comprobarlo en Hostinger.

Por eso, al decidir qué tipo de hosting necesita tu web, también conviene valorar quién se ocupa de estas revisiones y cómo responde cuando aparece una alerta.

La inteligencia artificial también cambia los tiempos

La PHP Foundation explica que ya existían indicios de uno de los problemas desde 2024, aunque entonces no se había identificado una forma concreta de aprovecharlo. Las investigaciones de 2026, asistidas por IA, permitieron demostrar su alcance. La validación y los parches siguieron contando con trabajo y decisiones humanas. Explicación de la PHP Foundation.

Para quien lleva un negocio, la consecuencia práctica está en la capacidad de responder.

AWS documentó un intento relacionado con PHP2Shell el 17 de octubre en sus sistemas señuelo, antes de la publicación de las correcciones. También observó más intentos el día 21. Esa información no equivale a un recuento de webs comprometidas, pero muestra que la actividad puede empezar antes de que el aviso llegue a tu correo. Análisis de AWS.

Un procedimiento de mantenimiento tiene que poder atender una alerta crítica sin esperar a la siguiente revisión mensual.

Qué pedir para saber si tu web está cubierta

No necesitas aprender a administrar un servidor. Sí ayuda obtener respuestas concretas.

¿Qué PHP está atendiendo realmente mi web?

La información del sitio puede servir como punto de partida. Pero «tenemos PHP 8.3» resulta demasiado impreciso: dentro de una misma rama hay versiones anteriores y posteriores al parche.

Para los dos fallos iniciales, PHP publicó las versiones 8.2.35, 8.3.36, 8.4.27 y 8.5.12. Algunos proveedores distribuyen sus propias correcciones sobre paquetes existentes, como acabamos de ver con Hostinger. Versiones y paquetes corregidos.

¿Quién aplica la corrección y quién comprueba que está funcionando?

Conviene tener un responsable identificado y una confirmación referida a tu sitio o servicio. Si tienes varias webs, instalaciones de prueba o subdominios, la revisión debe contemplarlos.

Comprobar la página principal deja sin responder qué ocurre con el resto.

¿Cómo se hará el cambio sin dejar de comprobar el negocio?

Antes de cambiar de versión hay que revisar la compatibilidad del proyecto y contar con una copia recuperable. Un entorno de staging permite ensayar el cambio, especialmente cuando hay plugins o desarrollos propios.

La preparación debe acompañar la urgencia de la corrección. Si hace falta una medida temporal mientras se resuelve una incompatibilidad, tiene que decidirla quien conoce el entorno.

Después hay que comprobar lo que importa en esa web: enviar una consulta de prueba, entrar en el área privada o recorrer una compra en un entorno de pruebas, sin generar un cobro real.

Que la portada cargue bien es una comprobación útil. El resto de funciones necesita la suya.

¿Se ha revisado el último aviso disponible?

El 23 de octubre PHP añadió un aviso sobre otra vía de ejecución de código, limitada a una combinación poco habitual de configuración y comportamiento de la aplicación. Publicó una mitigación y anunció que la corrección seguiría el ciclo ordinario. El responsable debe revisar ese supuesto adicional y determinar si afecta a tu caso. Aviso actualizado de CERT-EU.

Este seguimiento también forma parte del mantenimiento: una alerta puede recibir información nueva después de su primera publicación.

Corregir el fallo y revisar lo ocurrido son trabajos diferentes

Aplicar el parche cierra las vías que corrige. Para saber si alguien las aprovechó antes hace falta revisar las evidencias disponibles.

Según la exposición y lo que se encuentre, el equipo técnico tendrá que valorar registros, archivos y posibles cambios en la instalación. Ver la web aparentemente normal no responde por sí solo a esa pregunta.

Y una copia de seguridad tampoco sustituye esa revisión. Si necesitas recuperar una instalación, habrá que elegir una copia adecuada y corregir la causa antes de volver a dejarla expuesta. Es parte de lo que tratamos al hablar de recuperar una web sin perder los pedidos.

Qué debería quedar claro después de una alerta

Una respuesta útil debería explicar qué componente se ha revisado, qué corrección se ha aplicado, qué funciones se han probado y si queda algo pendiente de investigar.

Eso permite cerrar la revisión con algo más concreto que una captura del panel sin actualizaciones.

La tranquilidad tiene una base mucho mejor cuando sabes qué se ha comprobado y quién se ha encargado.

Si en tu negocio no está claro hasta dónde llega el mantenimiento de la web, podemos revisar contigo qué cubre ahora y qué conviene completar. Cuéntanos tu caso.