Black October y PHP2Shell: qué revisar hoy en el sitio de tu empresa

Quién escribe esto: Stratus, un estudio de diseño y desarrollo web de Antofagasta. Hoy hacemos los sitios sin PHP, así que tenemos un punto de vista y lo decimos arriba. Cada dato va con su fuente y su fecha.

Respuesta corta: si el sitio de tu empresa funciona con PHP (todo WordPress, y casi todo lo que está en un hosting compartido con cPanel), confirma que la versión sea 8.2.35, 8.3.36, 8.4.27, 8.5.12 o una posterior. Si tu sitio está en PHP 8.1 o en una versión más antigua, no hay corrección para esa versión: hay que subir de versión.

Qué es Black October

Así se le llamó a una seguidilla de fallas de seguridad graves publicadas en la segunda mitad de octubre de 2026, en productos muy distintos: PHP, GitLab, Node.js y certificados digitales, entre otros. La que afecta a la mayor cantidad de sitios de empresas es PHP2Shell, dos fallas en el motor de PHP registradas como CVE-2026-109618 y CVE-2026-109619.

Qué es PHP2Shell y por qué importa

• La encontró Wiz, una empresa de seguridad en la nube, y la publicó el 21 de octubre de 2026, el mismo día de las actualizaciones de PHP. Según su informe, permite que alguien sin usuario ni clave ejecute código en el servidor.
• Está en el motor de PHP, no en tu sitio. Wiz dice que el código vulnerable viene desde PHP 5.4 (2012) y que hasta una aplicación mínima, un “Hello World”, puede quedar expuesta. Lo demostraron contra WordPress, Drupal y Joomla, pero no hace falta ninguno de ellos para que funcione.
• Ya se está usando. La agencia de ciberseguridad de Estados Unidos, CISA, agregó las dos fallas a su catálogo de vulnerabilidades explotadas el 26 de octubre, con un puntaje de gravedad de 9,2 sobre 10 (The Record, The Hacker News).
• La única solución completa es actualizar PHP. Lo dice el mismo informe de Wiz. Un plugin de seguridad o un firewall pueden ayudar mientras tanto, pero no reemplazan la actualización.

PHP publicó las versiones corregidas 8.4.27 y 8.5.12 el 22 de octubre (registro de cambios de PHP), y las ramas 8.2 y 8.3 recibieron las suyas (8.2.35 y 8.3.36).

Cómo saber qué versión de PHP tiene tu sitio

Necesitas el número completo, por ejemplo 8.4.27. Decir “PHP 8.4” no basta, porque 8.4.26 sigue vulnerable.

1. Si tu sitio es WordPress: entra al panel de administración y abre Herramientas, Salud del sitio, pestaña Información, sección Servidor. Ahí aparece la versión de PHP.
2. Si tienes acceso al panel del hosting (cPanel u otro): busca la sección de versión de PHP. El nombre cambia según el proveedor.
3. Si no tienes acceso a nada: pregúntale por escrito a quien administra tu sitio o a tu proveedor de hosting. Abajo va un texto para copiar.

Qué hacer según tu versión

Tu versión de PHP	Qué hacer
8.2.35, 8.3.36, 8.4.27, 8.5.12 o posterior	Está corregida. Revisa igual que el proveedor no la haya cambiado después.
8.2, 8.3, 8.4 u 8.5 con un número menor	Actualizar a la versión corregida de la misma rama. En un hosting compartido normalmente lo hace el proveedor: pídeselo y que te confirme la fecha.
8.1, 8.0, 7.4 o anterior	Esas versiones ya no tienen soporte de seguridad de PHP y no recibieron corrección. Hay que subir a 8.3 u 8.4, probando antes que el sitio siga funcionando: los temas y plugins antiguos a veces fallan con versiones nuevas.

Un dato para planificar: según la tabla oficial de PHP, la rama 8.2 deja de recibir correcciones de seguridad el 31 de diciembre de 2026. Si vas a mover el sitio, conviene ir directo a 8.3 u 8.4.

Si tu sitio estuvo expuesto

Que un sitio haya estado en una versión vulnerable no significa que lo hayan atacado. Pero si estuvo así después de mediados de octubre, vale la pena pedirle a tu proveedor que revise los registros del servidor y los archivos modificados en esas semanas, y tener a mano un respaldo de antes. En WordPress, revisa también la lista de usuarios administradores: un administrador que nadie reconoce es una mala señal.

El mensaje para tu proveedor

Hola, por la vulnerabilidad de PHP publicada el 21 de octubre (PHP2Shell, CVE-2026-109618 y CVE-2026-109619), ¿me pueden confirmar la versión exacta de PHP en la que corre nuestro sitio, desde qué fecha está en una versión corregida (8.2.35, 8.3.36, 8.4.27, 8.5.12 o posterior) y si revisaron los registros del servidor desde mediados de octubre? Gracias.

Si te contesta solo “estamos en PHP 8”, insiste por el número completo.

Cómo hacemos los sitios hoy, y por qué esta falla no los toca

Los sitios que hacemos hoy se publican como archivos ya armados en la red de Cloudflare. No hay PHP ni base de datos en el servidor que atiende a las visitas, así que esta falla no tiene dónde entrar. Eso no hace a un sitio invulnerable a todo, pero sí lo saca de las fallas que dependen de un motor corriendo en el servidor. Los sitios que mantenemos y que todavía usan PHP los revisamos el 3 de noviembre: ya están en una versión corregida.

Resumen

1. Averigua la versión exacta de PHP de tu sitio. Tres números, no dos.
2. 8.2.35, 8.3.36, 8.4.27, 8.5.12 o posterior: corregido. Menor que eso, pide la actualización.
3. 8.1 o anterior: no hay parche. Hay que subir de versión, con pruebas.
4. Pide por escrito la fecha de la actualización y una revisión de registros.

Si no sabes quién administra tu sitio o no te responden, escríbenos por WhatsApp y lo revisamos contigo.

Fuentes

• Wiz, “PHP2Shell”, 21-10-2026: wiz.io/blog/php2shell-php-rce
• PHP, registro de cambios de la rama 8 (8.4.27 y 8.5.12, 22-10-2026): php.net/ChangeLog-8.php
• PHP, versiones con soporte (consultado el 03-11-2026): php.net/supported-versions.php
• CISA agrega las fallas a su catálogo de vulnerabilidades explotadas: The Record y The Hacker News