El 21 de octubre PHP publicó las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35 para corregir dos fallos críticos, CVE-2026-109618 y CVE-2026-109619, conocidos como php2shell. Los dos permiten ejecutar código en el servidor sin usuario ni contraseña, y el propio equipo de PHP avisa de que no hay ninguna medida temporal completa: actualizar es la única opción segura. Ese mismo día Node.js corrigió diez vulnerabilidades en sus tres versiones con soporte.
No es un aviso teórico. Amazon detectó intentos de explotación de php2shell el 17 de octubre, cuatro días antes del parche, y habla ya de intentos a gran escala.
Si tu empresa tiene una web, una tienda online o una aplicación interna, esto es lo que conviene revisar esta semana.
¿Me afecta? Probablemente sí, si tienes una web
WordPress, WooCommerce, PrestaShop, Moodle o Dolibarr están escritos en PHP. Según el equipo de PHP, cualquier instalación que sirva peticiones web está en riesgo, con independencia de cómo esté montado el servidor (PHP-FPM, Apache con mod_php, LiteSpeed…). El fallo está en PHP, no en los plugins ni en el tema.
Las versiones corregidas son estas:
- PHP 8.5: la 8.5.12 o posterior.
- PHP 8.4: la 8.4.27 o posterior.
- PHP 8.3: la 8.3.36 o posterior.
- PHP 8.2: la 8.2.35 o posterior. Ojo: la rama 8.2 deja de tener soporte el 31 de diciembre de 2026.
- PHP 8.1 o anterior: el proyecto PHP ya no publica actualizaciones. Algunos proveedores dan parches por su cuenta; si el tuyo no, toca migrar a una versión con soporte.
Cómo saber qué versión de PHP usa tu web
En WordPress, entra en Herramientas > Salud del sitio > Información y despliega el apartado Servidor: ahí aparece la versión de PHP (documentación de WordPress). En otras aplicaciones suele estar en el panel de tu hosting, en el apartado de configuración de PHP.
Si la versión que ves es anterior a las de la lista, tu web todavía no tiene el parche.
Si tu web está en un hosting gestionado
PHP adelantó los parches a las distribuciones de Linux y a los proveedores con soporte extendido, así que muchos hostings ya habrán actualizado. No lo des por hecho: pregúntalo por escrito. Tres preguntas bastan:
- ¿Qué versión exacta de PHP usa mi web y cuándo se actualizó?
- Si es una versión antigua (8.1 o anterior), ¿tenéis parche propio para php2shell o tengo que migrar?
- ¿Guardáis registros y copias de seguridad de antes del 21 de octubre, por si hay que comprobar que nadie entró antes del parche?
Si gestionáis vuestro propio servidor
- Actualiza el paquete de PHP y reinicia todos sus procesos (PHP-FPM, Apache). Un PHP actualizado en disco no protege nada mientras sigan vivos los procesos viejos.
- Si usas contenedores, reconstruye la imagen, no te limites a reiniciarla. Si la imagen usa una etiqueta como
latesty ya está descargada, el servidor puede seguir arrancando la versión antigua. Comprueba la versión dentro del contenedor después de desplegar. - Si no puedes actualizar hoy, PHP describe medidas que reducen el riesgo (por ejemplo, desactivar
session.upload_progress), pero insiste en que no son una solución completa. Úsalas solo como puente de unas horas.
Comprueba que nadie entró antes del parche
Como hubo intentos de explotación antes de que existiera el parche, actualizar no basta: hay que mirar si alguien llegó a entrar. En una web WordPress, lo mínimo es:
- Revisar la lista de usuarios con rol de administrador y buscar alguno que no reconozcas.
- Buscar ficheros
.phpen la carpeta de subidas (wp-content/uploads), donde no debería haber ninguno. - Comparar los ficheros del tema y los plugins con su versión original, y revisar las tareas programadas.
Si encuentras algo raro, no lo borres sin más: guarda una copia y pide ayuda, porque lo que se ve suele ser solo una parte.
Y Node.js: las aplicaciones a medida
Muchas herramientas internas, API y automatizaciones autoalojadas (n8n, por ejemplo) funcionan sobre Node.js. La corrección más grave de esta tanda (CVE-2026-111497) afecta a la descompresión de datos en formato Brotli y puede permitir ejecutar código. Las versiones corregidas son la 22.23.4, la 24.22.1 y la 26.12.1.
Para saber qué versión tienes, ejecuta node --version en el servidor o dentro del contenedor. Si sale una 20 o una 25, esas ramas ya no tienen soporte y no recibirán estos parches: hay que pasar a la 22, la 24 o la 26. Si la aplicación la mantiene un proveedor, pregúntale qué versión de Node usa y cuándo la va a actualizar.
Lo que deja esta semana
Las vulnerabilidades críticas van a seguir saliendo. Lo que marca la diferencia es poder responder en una hora a tres preguntas: qué aplicaciones tenemos, sobre qué versiones funcionan y quién las actualiza. Si hoy no sabes contestarlas, empieza por un inventario sencillo y por pedir a cada proveedor un compromiso de plazos para los parches de seguridad.
Es parte de lo que hacemos en consultoría IT: inventario de sistemas, plan de actualizaciones y revisión de proveedores, para que la próxima vez sepas en una mañana si te afecta.