Vulnerabilidad en PHP (PHP2Shell): qué hacer

Si tu sitio web o algún sistema de tu empresa corre en PHP, hay que actualizar PHP ya: a 8.5.12, 8.4.27, 8.3.36 u 8.2.35, según la rama que uses. Las fallas conocidas como PHP2Shell permiten que un atacante ejecute código en el servidor sin iniciar sesión, afectan a todas las versiones de PHP de la última década y desde el 26 de octubre hay explotación confirmada. Actualizar WordPress o sus plugins no sirve: la falla está en PHP, no en la aplicación.

Esta guía está escrita para quien dirige una empresa, no para quien administra el servidor, aunque al final hay una sección técnica para pasarle a tu equipo o a tu proveedor.

Qué pasó, en corto

21 de octubre de 2026. El proyecto PHP publicó parches para dos vulnerabilidades, CVE-2026-109618 y CVE-2026-109619, ambas con una severidad de 9.2 sobre 10 (CVSS v4.0). Las dos permiten ejecución remota de código.
Alcance. Según Wiz, una de las firmas que las encontró, todas las versiones de PHP publicadas en la última década tienen al menos una de las dos, desde la 5.4. No dependen del código de tu aplicación: demostraron el ataque contra instalaciones recién creadas de WordPress, Drupal y Joomla.
26 de octubre. Se confirmó un ataque exitoso contra un servidor señuelo (honeypot) con PHP 8.4.26, según Enter.co. Es decir: entre el parche y el primer ataque confirmado pasaron cinco días.
En Colombia. El ColCERT emitió la alerta AL-20261021-123 y contó 8.699 servicios con PHP expuestos a internet en el país. Esa cifra mide exposición, no servidores atacados.
Hay una tercera falla sin parche. El 23 de octubre PHP avisó de CVE-2026-115560. Según el propio proyecto, solo ocurre con una combinación poco habitual de configuración y código, y se corregirá en la próxima versión. Mientras tanto se mitiga con un ajuste que explicamos abajo.

Lo que hace distinto este caso es cómo se encontró. Los investigadores usaron modelos de inteligencia artificial para hallar las fallas y para adaptar los ataques a distintas versiones y configuraciones. Wiz cuenta que una sola persona hizo en una semana un trabajo que antes le tomaba meses a un equipo especializado.

¿Mi empresa está afectada?

Probablemente sí, si tienes cualquiera de estas cosas:

Un sitio en WordPress, Drupal o Joomla, que corren sobre PHP.
Un sistema hecho en Laravel, Symfony, CodeIgniter o PHP sin framework.
Una tienda en WooCommerce, Magento o PrestaShop.
Un software de un proveedor que lo instaló en tu servidor o te lo da como servicio, y que usa PHP por debajo. Si no sabes en qué está hecho, esa es la primera pregunta para tu proveedor.

Para saber qué versión de PHP corre tu sitio, la vía más rápida es preguntarle a quien lo administra. Si tienes acceso al panel del hosting, normalmente aparece en la sección de PHP. Estas son las versiones que corrigen el problema:

Rama de PHP que usas	Versión que debes tener	Comentario
8.5	8.5.12 o superior
8.4	8.4.27 o superior
8.3	8.3.36 o superior
8.2	8.2.35 o superior	La rama 8.2 deja de recibir soporte el 31 de diciembre de 2026
8.1 o anterior	No hay versión oficial corregida	Hay que migrar a 8.2 o superior. El equipo de PHP publicó parches mínimos para 7.4, 8.0 y 8.1 solo para quien compila desde el código fuente

Si tu sitio corre en PHP 7 o en 8.0, el problema no es solo esta falla: llevas tiempo usando una versión sin parches de seguridad. Este es el momento de planear la migración.

Qué hacer según dónde corre tu sitio

Hosting compartido (el típico plan con panel tipo cPanel). Quien parcha PHP es el proveedor del hosting, no tú. Escríbele hoy y pregunta qué versión exacta tiene tu cuenta y si ya aplicó la corrección. Si el panel te deja escoger la versión de PHP, escoge la rama más reciente que tu sitio soporte, pero pruébalo antes: un sitio viejo puede romperse al subir de versión.

Servidor propio o VPS. Actualiza PHP desde los paquetes de tu sistema operativo o desde el repositorio que uses. Después hay que reiniciar todos los procesos de PHP (PHP-FPM o Apache), porque los procesos que siguen vivos continúan con el código viejo.

Contenedores Docker. Actualizar la imagen base a una etiqueta corregida (por ejemplo, php:8.3.36-fpm), reconstruir la imagen y desplegarla de nuevo. Reiniciar el contenedor con la misma imagen no corrige nada. Si tienes varios servidores o un servidor por cliente, el parche hay que llevarlo a cada uno.

Software de un proveedor. No asumas que ya lo hizo. Pídele por escrito la versión de PHP en la que corre tu sistema y la fecha en que aplicó la corrección.

Preguntas para enviarle hoy a tu proveedor

Puedes copiarlas tal cual en un correo o un WhatsApp:

¿Qué versión exacta de PHP corre mi sitio o mi sistema?
¿Ya actualizaron a una versión corregida contra CVE-2026-109618 y CVE-2026-109619? ¿En qué fecha?
¿Reiniciaron todos los procesos de PHP después de actualizar?
¿Desactivaron session.upload_progress mientras sale la corrección de CVE-2026-115560?
¿Revisaron los registros del servidor en busca de intentos de ataque desde el 17 de octubre?
Normalmente, ¿cuánto tardan en aplicar un parche crítico, y cómo me avisan?

La última pregunta es la que más dice. Un proveedor que responde con un número y un procedimiento tiene esto bajo control. Uno que responde “tranquilo, todo está seguro” no te dijo nada.

Para quien administra el servidor

El aviso oficial de PHP es claro: no hay mitigación completa y actualizar es lo único seguro. Mientras actualizas, estas medidas reducen el riesgo:

Desactivar el progreso de carga de sesión con session.upload_progress.enabled = 0 en php.ini, en el pool de PHP-FPM o en la configuración del servidor, y reiniciar todos los procesos. No sirve hacerlo con ini_set() ni con .user.ini. Este ajuste también cubre CVE-2026-115560, así que conviene mantenerlo después de actualizar, hasta la próxima versión de PHP.
Limitar el tamaño de las peticiones: PHP recomienda post_max_size = 8M si la aplicación no recibe archivos, o 32M si los recibe, con upload_max_filesize por debajo de ese valor.
Poner límites también en el servidor web o en el proxy (tamaño de la petición, número de campos y de partes multipart) y activar las reglas del WAF de tu proveedor de CDN, si lo tienes.
En PHP 8.5, poner fatal_error_backtraces = 0.

La lista completa está en el aviso de seguridad publicado en php.net.

Señales de que alguien lo intentó, según Wiz y los equipos de respuesta: peticiones multipart inusuales seguidas de errores de límite de memoria, muchas respuestas 500 seguidas, cookies PHPSESSID demasiado grandes o malformadas, reinicios de procesos de PHP sin explicación, procesos de consola lanzados por el usuario del servidor web (por ejemplo www-data) y tráfico de salida que no reconoces.

Si encuentras algo de eso, actualizar ya no basta: el parche cierra la puerta, pero no saca a quien ya entró. Ahí hace falta una revisión forense hecha por especialistas en respuesta a incidentes.

Lo que esto anuncia

PHP2Shell no es un caso aislado. El mismo 21 de octubre, Node.js corrigió diez vulnerabilidades, entre ellas una en la librería de compresión Brotli que también afecta a Python y .NET, y que encontró un equipo de OpenAI. OpenAI dice que espera que este tipo de hallazgos aumente bruscamente en los próximos meses.

Para una empresa, la consecuencia práctica es una sola: el tiempo entre que sale un parche y que lo atacan bajó a días. La pregunta que conviene hacerse ya no es si tu software es seguro, sino esta: si mañana sale un parche crítico, ¿en cuántas horas lo tienes instalado en todos tus servidores?

Si la respuesta es “depende de quién esté disponible” o “hay que hacerlo servidor por servidor”, el riesgo no está en PHP. Está en cómo se opera tu software. Eso se resuelve con tres cosas que no requieren reescribir nada:

Un inventario de qué corre dónde y en qué versión.
Despliegues automáticos, para que un parche se construya una vez y llegue a todos los servidores.
Alguien responsable de vigilar los avisos de seguridad y de actuar el mismo día.

Cómo te podemos ayudar

En GeekCorp desarrollamos y operamos software para empresas en Colombia. Esta semana un cliente nos preguntó a quién acudir para esto, y es una pregunta que seguramente se están haciendo muchas empresas.

Podemos revisar contigo qué corre en tus servidores, actualizar PHP y las dependencias de tus sistemas, y dejar montado un proceso para que el próximo parche crítico se aplique en horas y no en semanas. Cuando hace falta una prueba de penetración formal o una revisión forense, trabajamos con especialistas en seguridad informática.

Si quieres que lo revisemos, escríbenos y cuéntanos qué tienes. La primera conversación no tiene costo.

Fuentes: aviso de seguridad y versiones en php.net · Wiz: PHP2Shell · Enter.co: explotación confirmada y versiones · ImpactoTIC: alerta en Colombia · OpenAI: Patch the Planet