Fallas de seguridad de octubre de 2026: PHP, Node.js, npm y Shopify, qué verificar

Tres ecosistemas que hacen funcionar una gran parte de la web fueron afectados al mismo tiempo: PHP, que impulsa WordPress y la mayoría de los sitios de empresa, Node.js, que sirve las aplicaciones modernas, y Shopify, en el lado del comercio electrónico. En cada caso, la explotación comenzó antes o justo después de la publicación de los parches. Esto es lo que ocurrió, y lo que debe verificar en su sitio, tanto si lo desarrolló usted mismo como si lo aloja un proveedor.

¿Quiere saber cómo está su sitio antes de seguir leyendo? Verifíquelo en un minuto con la herramienta gratuita: nota de A a F, protecciones que faltan y acción a tomar para cada una.

PHP: php2shell, dos fallas críticas explotadas antes del anuncio

El 21 de octubre de 2026, el equipo de PHP publicó una actualización de emergencia para dos fallas identificadas como CVE-2026-109618 y CVE-2026-109619, apodadas “php2shell”. Ambas tienen una puntuación de 9,2 sobre 10. Permiten a un atacante ejecutar código en el servidor sin ninguna cuenta, mediante una simple petición HTTP.

• La primera corrompe la memoria durante la gestión de un desbordamiento de memoria.
• La segunda explota un estado conservado entre dos peticiones (use-after-free).

Los detalles se filtraron en las redes sociales el 20 de octubre, un día antes de la fecha prevista. Amazon ya había observado un intento de explotación el 17 de octubre. El 26 de octubre, la agencia estadounidense CISA incluyó ambas fallas en su lista de vulnerabilidades explotadas.

Versiones corregidas: 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Las ramas 8.1 y anteriores no reciben versión oficial, solo parches de código fuente que debe aplicar usted mismo o a través de su distribución Linux.

Quién está afectado: toda instalación que sirva peticiones web, ya sea con PHP-FPM, mod_php, php-cgi, FrankenPHP o LiteSpeed. El riesgo es máximo con mod_php, donde la falla se activa antes incluso de que se ejecute su aplicación. Un sitio WordPress, PrestaShop o Laravel está afectado por definición.

Para verificar su versión y reiniciar los procesos tras la actualización:

# Muestra la versión de PHP en la línea de comandos
php -v

# En un servidor Debian o Ubuntu con PHP-FPM: el reinicio es obligatorio,
# la actualización del paquete no afecta a los procesos ya en memoria
sudo systemctl restart php8.3-fpm
sudo systemctl reload nginx

Punto de atención: las versiones 8.4.27 y 8.5.12 contienen una regresión que puede hacer fallar las aplicaciones que usan la extensión SimpleXML. La corrección está integrada en el código fuente pero aún no se había publicado a 26 de octubre. Pruebe antes de desplegar en producción.

Si la actualización es imposible de inmediato, PHP recomienda dos ajustes temporales, en un archivo que la aplicación no pueda sobrescribir:

; Neutraliza CVE-2026-109618 (gestión del desbordamiento de memoria)
memory_limit = -1

; Neutraliza CVE-2026-109619 (estado conservado entre peticiones)
session.upload_progress.enabled = 0

Después reinicie todos los procesos PHP. Estos ajustes no sustituyen a la actualización, ganan tiempo.

Si su sitio está en un alojamiento compartido, no tiene que instalar nada usted mismo. Pero compruebe en su panel de administración la versión de PHP seleccionada: muchos proveedores dejan la elección al cliente, y un sitio que sigue en 7.4 u 8.0 no dispone de ninguna versión corregida.

Node.js: Node2Shell, una falla en la descompresión Brotli

El mismo 21 de octubre, Node.js publicó correcciones para diez fallas, entre ellas CVE-2026-111497, apodada “Node2Shell”. Es una escritura fuera de límites en el decodificador Brotli integrado en el módulo node:zlib. Un flujo Brotli malformado basta para hacer caer el proceso, leer su memoria o ejecutar código.

Versiones corregidas: 22.23.4, 24.22.1 y 26.12.1. Las líneas 20, 23 y 25 están abandonadas y no recibirán ninguna corrección.

Lo que hace concreta esta falla son las vías de ataque ordinarias:

• Express 5 y body-parser 2 descomprimen por defecto los cuerpos de petición enviados con la cabecera Content-Encoding: br. Cualquier visitante puede por tanto enviar el flujo malicioso a su API.
• La función fetch() integrada descomprime automáticamente las respuestas Brotli. Un servidor de terceros comprometido puede atacar su aplicación cuando esta lo consulta.
• Todo código que pase datos no controlados a zlib.brotliDecompress().

Un servidor HTTP Node.js básico, sin middleware de análisis, no decodifica los cuerpos entrantes y no está expuesto por esta vía.

# Versión en ejecución
node -v

# En un Dockerfile, fije una versión corregida en lugar de una etiqueta flotante
# FROM node:22-alpine pasa a ser:
# FROM node:22.23.4-alpine

Si no puede actualizar de inmediato y su aplicación no necesita recibir peticiones comprimidas, desactive la descompresión en body-parser:

// Las peticiones comprimidas reciben una respuesta 415 en lugar de ser decodificadas
app.use(express.json({ inflate: false }));

Entre las otras nueve correcciones, dos se refieren a la elusión de la verificación del nombre de host TLS, y otra afecta a crypto.randomUUID() y crypto.randomInt(). Para esta última, el aviso recomienda reconstruir las aplicaciones, no solo actualizar el binario.

npm: gusanos que se propagan de paquete en paquete

El riesgo de Node.js no se limita al motor. El año 2026 ha visto una serie de ataques automatizados contra el registro npm, de la familia “Shai-Hulud”. El más amplio hasta la fecha, bautizado CHAINDROP, comenzó el 4 de agosto: la cuenta del mantenedor de keyv, una biblioteca descargada más de 600 millones de veces al mes, fue comprometida. En dos días, más de 400 paquetes fueron infectados, con más de mil millones de descargas mensuales combinadas.

El modo de operar es el mismo en cada oleada:

1. Un paquete infectado contiene un script preinstall que se ejecuta durante npm install, sin ninguna acción por su parte.
2. El script recopila los secretos de la máquina: tokens de npm y GitHub, claves SSH, credenciales cloud, claves de API de herramientas de IA.
3. Con los tokens npm robados, vuelve a publicar una versión infectada de cada paquete al que el mantenedor tiene acceso. Eso es lo que lo hace autónomo.

Las medidas que protegen realmente un proyecto:

• Bloquear los scripts de instalación. npm 12 lo hace por defecto para preinstall. En versiones anteriores, añada ignore-scripts=true a su archivo .npmrc y reactívelo caso por caso.
• Fijar las versiones con un archivo de bloqueo versionado e instalar con npm ci, nunca npm install en producción.
• Esperar antes de adoptar una versión. Una versión publicada hace unos días ha tenido tiempo de ser denunciada si es maliciosa. pnpm ofrece un ajuste de antigüedad mínima antes de que una nueva versión se tenga en cuenta.
• Activar la autenticación de dos factores en todas las cuentas npm y GitHub, y rechazar los tokens que la eluden.

Si una máquina de desarrollo instaló un paquete comprometido, considere robados todos sus secretos: revoque y regenere.

Shopify: el proceso de pago secuestrado por aplicaciones de terceros

El 10 de octubre, un desarrollador comprobó que una tienda Shopify redirigía a sus clientes a una página de pago falsa en el momento de pagar. El núcleo de Shopify no fue comprometido. El ataque pasó por aplicaciones instaladas en las tiendas, principalmente Hulk Product Options, y después Swym Wishlist Plus y Selleasy el 13 de octubre.

El mecanismo es instructivo para cualquiera que gestione un sitio con extensiones:

1. El script de la aplicación se carga normalmente desde el CDN de Shopify.
2. Al cargarse, consulta la API del editor de la aplicación, que devuelve un bloque de código personalizado.
3. Ese bloque, modificado por los atacantes, redirige al comprador a un proceso de pago falso alojado en dominios como checkout-confirm.top.
4. La página falsa recoge la tarjeta bancaria y después envía al comprador al pago real. El pedido se completa, el cliente no nota nada.

Shopify retiró las aplicaciones afectadas de su tienda de aplicaciones y, el 20 de octubre, desplegó un cambio: la tienda pide ahora confirmación al comprador antes de cualquier redirección a un sitio externo.

Si gestiona una tienda Shopify, la prueba lleva un minuto:

1. Abra una ventana de navegación privada.
2. Añada un artículo al carrito y haga clic en Pagar.
3. Compruebe que la dirección mostrada permanece en su dominio o en shopify.com.

Después: desinstale las aplicaciones que ya no usa, cambie la contraseña de Shopify y las de las cuentas de aplicaciones, active la autenticación de dos factores y revise las integraciones que tienen acceso a su tienda. Este tipo de intervención en Shopify se realiza en colaboración con Huggii, contácteme para saber más.

Lo que estos tres casos tienen en común

En los tres casos, el sitio en sí no era el objetivo inicial. El punto de entrada era una dependencia: el motor del lenguaje, una biblioteca instalada, una aplicación de terceros. Un sitio bien programado pero nunca actualizado sigue expuesto.

La respuesta se resume en tres hábitos: conocer sus versiones, actualizarlas en la semana siguiente a un parche crítico, y limitar lo que un script inyectado puede hacer gracias a las cabeceras de seguridad. Para este último punto, he publicado una herramienta de verificación que lee las cabeceras de su sitio y señala lo que falta.

Si su sitio funciona con PHP o Node.js y no sabe quién lo mantiene actualizado, es el momento de averiguarlo. Mi oferta de mantenimiento cubre exactamente eso. Hablemos.