Si la web o la tienda online de tu empresa funciona con WordPress, Magento, Laravel o cualquier otro sistema basado en PHP, pide hoy a tu proveedor de hosting o a tu equipo técnico que actualice PHP a la versión 8.5.12, 8.4.27, 8.3.36 o 8.2.35 y que luego reinicie el servidor. El proyecto PHP publicó estas versiones el 21 de octubre de 2026 para cerrar dos fallos críticos conocidos como PHP2Shell, cada uno con una nota de 9.2 sobre 10, que permiten a un atacante ejecutar comandos en tu servidor sin ninguna contraseña. La Autoridad Nacional de Ciberseguridad de Arabia Saudí (NCA) emitió ese mismo día una alerta «crítica» que recomienda la actualización, y varias empresas de seguridad vieron intentos de explotación horas antes de que se publicara la corrección.

¿Qué ha pasado exactamente?

Los dos fallos son CVE-2026-109618 y CVE-2026-109619, y están en el propio lenguaje PHP, no en un plugin ni en un tema. Esa es la diferencia clave: en nuestro artículo anterior sobre las correcciones de WordPress que se convirtieron en el mapa de los atacantes, el error estaba en un software que funciona por encima de PHP. Aquí el error está en la base sobre la que se apoya todo ese software. Por eso, tener WordPress al día o pocos plugins no te protege.

Según el primer aviso de seguridad de PHP, el primer fallo aparece cuando una petición se queda sin memoria mientras se prepara, y deja datos a medio inicializar que PHP trata después como válidos. Según el segundo aviso, el otro fallo deja colgados datos de una petición anterior después de liberarlos, y la siguiente petición del mismo proceso los usa. El resultado es el mismo en ambos casos: una sola petición web bien preparada basta para ejecutar comandos en el servidor.

Wiz Research encontró los fallos con ayuda de modelos de IA. Su informe dice que el equipo los descubrió el 19 de agosto de 2026, los comunicó al equipo de PHP el 24 de agosto, y que todas las versiones de PHP desde la 5.4 están afectadas por al menos uno de ellos. Wiz calcula que PHP mueve alrededor del 70% de los sitios web.

¿Está afectada mi web?

Lo más probable es que sí, si funciona con PHP y su versión es anterior a las indicadas arriba. Wiz demostró ejecución remota de código sin autenticación en WordPress, Drupal y Joomla con su configuración por defecto. Sansec amplió la lista en su análisis a 11 plataformas, entre ellas Magento 2.4.9, WordPress 7.1.2, Laravel 13.11, Symfony 8.1, phpMyAdmin, Nextcloud y WHMCS.

Para saber tu versión de PHP, abre el panel de tu hosting (cPanel, Plesk o similar) y busca «PHP Version», o pregunta a tu equipo. Ten en cuenta dos puntos:

  • La versión 8.1 y anteriores ya no tienen soporte y no recibirán ninguna corrección. Según la tabla de versiones con soporte de PHP, las únicas ramas con soporte ahora son 8.2, 8.3, 8.4 y 8.5.
  • La propia rama 8.2 pierde el soporte de seguridad el 31 de diciembre de 2026, dentro de dos meses y medio. Si vas a actualizar ahora, pasa a 8.4 u 8.5 y ahórrate una segunda actualización pronto.

Qué hacer hoy: cinco pasos

  1. Localiza todos los sitios donde funciona PHP. La web, la tienda, el panel de administración y cualquier sistema interno o portal de clientes. Muchas empresas olvidan una web antigua que sigue en línea.
  2. Actualiza a una versión corregida. 8.5.12, 8.4.27, 8.3.36 o 8.2.35. En un hosting compartido, pregunta por escrito a tu proveedor: ¿habéis aplicado la actualización del 21 de octubre?
  3. Reinicia PHP después de actualizar. El aviso de PHP indica que un proceso que no se ha reiniciado sigue con el código antiguo, así que descargar la actualización no basta.
  4. Si tu web está en 8.1 o anterior, planifica la actualización esta semana y pruébala antes en una copia de pruebas, porque algunos plugins antiguos pueden dejar de funcionar.
  5. Revisa los registros. Wiz recomienda buscar peticiones de subida inusuales seguidas de errores de falta de memoria, errores HTTP 500 repetidos o cookies de sesión (PHPSESSID) demasiado grandes o malformadas.

Si no puedes actualizar hoy

Los avisos de PHP proponen medidas temporales que reducen el riesgo pero no sustituyen la actualización: desactivar session.upload_progress.enabled poniéndolo a 0 y reiniciar todos los procesos, y en la versión 8.5 poner fatal_error_backtraces a 0. Si tu web nunca acepta subidas de archivos, también puedes bloquear las peticiones multipart en el servidor frontal.

Si tu web está detrás de Cloudflare, la empresa explica en su blog que desplegó reglas de cortafuegos para estos fallos desde las 3:02 UTC del 21 de octubre, unas 9 horas antes de la divulgación, en todos los planes, incluido el gratuito. Pero la propia Cloudflare aconseja actualizar PHP incluso con esta protección, porque los atacantes no dejan de cambiar sus cargas.

La visión de Origami

Este fallo recuerda que la seguridad de una web no termina al actualizar WordPress y sus plugins. Debajo de cada web hay un lenguaje de programación, un servidor y una configuración, y todos necesitan a alguien que los vigile. Lo que vemos a menudo en las empresas es una web creada hace años de la que nadie sabe ya qué versión de PHP usa ni quién tiene acceso para actualizarla. Si es tu caso, la pregunta ya no es «¿actualizamos?» sino «¿quién lo actualiza hoy?». En Origami creamos webs y sistemas y vigilamos sus actualizaciones desde el primer día. Si quieres revisar tu web o actualizar PHP sin cortes, contacta con nosotros.

Fuentes