La Agencia Nacional Checa de Seguridad Cibernética y de la Información (NÚKIB) advirtió el 21 de octubre de 2026 de dos vulnerabilidades críticas en PHP, el lenguaje de programación en el que funciona la mayoría de las webs del mundo. Los expertos las llaman php2shell (CVE-2026-109618 y CVE-2026-109619). A través de ellas, un atacante puede ejecutar su propio programa en el servidor, y además sin ninguna contraseña. Los detalles se filtraron antes de que se publicaran las correcciones y las instrucciones para explotarlas están disponibles públicamente.

La solución existe y es única: actualizar PHP. A continuación le explicamos cómo saber si le afecta y qué hacer según dónde funcione su web.

¿Me afecta?

Probablemente sí, si su web o aplicación funciona con:

  • WordPress, Joomla, Drupal u otro gestor de contenidos al que se accede a través de /wp-admin o /administrator,
  • una tienda online en un alojamiento propio (PrestaShop, WooCommerce, Magento),
  • un sistema de pedidos o reservas, una intranet, un control de asistencia u otra aplicación web a medida, si está escrita en PHP.

No le afecta si tiene la web o la tienda online en un servicio ya hecho en el que no se ocupa del servidor (Shoptet, Webnode, Wix y similares). Ahí la actualización corre a cargo del operador del servicio.

Lo importante es que no importa lo segura que sea su contraseña de administración. El fallo está en el propio PHP y el atacante lo explota antes de que la web llegue siquiera a comprobar el inicio de sesión.

Qué hacer según dónde funcione la web

Web en un alojamiento compartido (Wedos, Websupport, Active24 y otros)

La mayoría de los grandes proveedores de alojamiento actualizan PHP por su cuenta y con rapidez. Aun así, compruébelo:

  1. Inicie sesión en el panel de administración del alojamiento y busque la configuración de PHP de su web.
  2. Las versiones corregidas son la 8.2.35, 8.3.36, 8.4.27 y 8.5.12 y posteriores. Si tiene seleccionada una rama más antigua (7.4, 8.0, 8.1), cambie a una más reciente. Antes del cambio, haga una copia de seguridad de la web y, justo después, revísela página por página.
  3. Si no está seguro, escriba una consulta a su proveedor de alojamiento. Deberían tener preparada la respuesta «corregido».

Servidor propio o servidor virtual

Aquí la actualización depende de usted o de su administrador:

  • Actualice solo los paquetes de PHP, no todo el sistema de una vez. Si algo falla, sabrá enseguida qué lo ha causado.
  • Antes de actualizar, haga una copia de seguridad o una instantánea (snapshot) del servidor. Si la web no funciona tras la actualización, la restaurará en un minuto.
  • Después de actualizar, reinicie el servidor web (Apache, PHP-FPM). Mientras sigan funcionando los procesos antiguos, la corrección no se aplica.
  • Aproveche la ocasión e instale también los demás parches de seguridad del sistema. A menudo descubrirá que nadie ha tocado el servidor en meses.
Un técnico actualiza un servidor de noche y por la mañana revisa la web en una tableta con la propietaria de la empresa
Copia de seguridad, actualización de PHP, reinicio y comprobación de la web. En cada servidor por separado.

Una web antigua que no funcionará con el nuevo PHP

Este es el caso más difícil. Una aplicación escrita hace años para PHP 7 o anterior a menudo no funciona con la nueva versión, y sus creadores no han publicado corrección para las ramas antiguas de PHP. En ese caso tiene tres opciones:

  1. Migrar la aplicación a la nueva versión de PHP. Es la solución definitiva, pero lleva de días a semanas según el tamaño de la aplicación.
  2. Restringir el acceso mientras tanto. Si la aplicación solo la usan unas pocas sedes o empleados, configure el servidor para que solo puedan acceder sus direcciones IP. Los demás reciben «acceso denegado» antes de que la petición llegue a PHP. También funciona una contraseña a nivel de servidor, que se introduce antes de la propia página.
  3. Convertir una web sencilla en estática. Una web corporativa en la que solo cambia de vez en cuando un texto o la carta del restaurante no necesita PHP en absoluto. Una copia estática funciona sin gestor de contenidos y esta vulnerabilidad no le afecta.

Atención: PHP 8.2 dejará de recibir correcciones el 31 de diciembre de 2026. Si ahora actualiza dentro de la rama 8.2, planifique para el próximo año el paso a la 8.3 o posterior.

Cómo saber si alguien ya ha entrado

La vulnerabilidad se estuvo explotando antes de que se publicara la corrección. La actualización cierra la puerta, pero no echa a quien ya está dentro. Por eso, después de actualizar, revise:

  • procesos desconocidos ejecutados con el usuario del servidor web, normalmente programas que consumen mucha CPU (minería de criptomonedas),
  • archivos .php nuevos o modificados en las carpetas de la web, sobre todo en los directorios de imágenes subidas,
  • una carga inusualmente alta del servidor o tráfico saliente sin motivo aparente,
  • usuarios nuevos en la administración de la web.

Si encuentra alguna de estas cosas, no basta con borrar el archivo. Hay que revisar todo el servidor, cambiar todas las contraseñas (de la base de datos, FTP y administración) y, en el peor de los casos, restaurarlo a partir de una copia de seguridad anterior al ataque.

Cómo lo resolvimos nosotros

El NÚKIB envió la advertencia la tarde del 21 de octubre y esa misma noche revisamos todas las webs y servidores que gestionamos:

  • La mayoría de nuestras webs no usan PHP en absoluto, así que la vulnerabilidad no les afectaba.
  • Los servidores web con PHP los actualizamos esa misma noche, uno tras otro y siempre con una copia de seguridad previa. De paso instalamos también los demás parches de seguridad pendientes. Los sistemas internos, como el correo, siguen en ventanas de mantenimiento separadas.
  • Una aplicación más antigua que no funcionará con el nuevo PHP la hemos restringido, hasta su migración, a las direcciones IP de las sedes que la usan.
  • Una web corporativa sencilla con gestor de contenidos la estamos convirtiendo en estática para que PHP y sus actualizaciones dejen de ser necesarios.

Las webs en producción estuvieron fuera de servicio durante la actualización solo unos segundos, lo que tardó en reiniciarse el servidor web. Pero algo nos sorprendió: en el servidor de pruebas, tras los parches de seguridad, la base de datos no arrancó debido a un cambio en la nueva versión. Por eso siempre actualizamos primero el entorno de pruebas y solo después la producción.

Resumen

  • ¿Tiene una web en WordPress, Joomla o una aplicación propia en PHP? Compruebe la versión de PHP hoy mismo y actualice a la 8.2.35, 8.3.36, 8.4.27, 8.5.12 o posterior.
  • En un alojamiento compartido basta con revisar la configuración. En un servidor propio: copia de seguridad, actualización, reinicio y comprobación de la web.
  • Una aplicación antigua que no se puede actualizar, protéjala con una restricción de direcciones IP hasta su migración.
  • Si es una organización regulada por la ley checa de ciberseguridad, esta intervención debe constar también en su registro. Más información en el artículo ¿Le afecta NIS2?

¿No sabe con qué funciona su web o no tiene a nadie que haga la actualización? Lo averiguamos por usted y en un día le decimos si la vulnerabilidad le afecta y qué hacer. Solicite una revisión gratuita.