El 21 de octubre de 2026 el proyecto PHP publicó una actualización de emergencia para dos fallas críticas que permiten a un atacante ejecutar código en el servidor sin usuario, sin contraseña y sin que nadie haga clic en nada. Se las conoce como php2shell (CVE-2026-109618 y CVE-2026-109619). Las versiones corregidas son 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Si tu sitio corre PHP 8.1 o una versión más antigua, el proyecto PHP no publicó una versión corregida para ti.
Si tienes un WordPress, una tienda WooCommerce o cualquier sitio hecho en PHP, esto te toca. Te explicamos qué pasó, cómo saber si tu sitio está expuesto y qué hacer hoy, sin tecnicismos de más.
Qué pasó el 21 de octubre
PHP es el lenguaje en el que funcionan WordPress, Joomla, Drupal, Moodle, Magento y la gran mayoría de los sitios administrables que existen. Cuando la falla está en PHP mismo, y no en un plugin o un tema, no importa qué tan cuidado esté tu sitio: el problema está en el motor que lo hace funcionar.
Eso es lo que pasó esta vez. Las dos fallas están en la forma en que PHP maneja la memoria al recibir datos de un formulario. Un atacante puede enviar una petición preparada a cualquier página que procese PHP y, en las condiciones adecuadas, tomar el control de lo que el servidor ejecuta.
Los avisos oficiales las califican con 9,2 sobre 10 en la escala de gravedad CVSS. Y según la empresa de seguridad Sansec, el código vulnerable existe desde PHP 5.4, una versión de 2012: son catorce años de sitios web.
Por qué esta es más seria que las fallas de siempre
Todos los meses aparecen vulnerabilidades en plugins de WordPress. Casi siempre afectan a un plugin que quizás no tienes, o necesitan que el atacante ya tenga una cuenta en tu sitio. Esta no:
- No depende de tus plugins ni de tu tema. Está en PHP, debajo de todo lo demás.
- No necesita credenciales. El atacante no tiene que iniciar sesión ni robarle la clave a nadie.
- Funciona con la configuración por defecto. Los investigadores demostraron la ejecución remota de código en WordPress 7.1.2, Drupal, Joomla, Magento y otras aplicaciones conocidas.
- Los ataques empezaron antes que el parche. Según Sansec, Cloudflare detectó los primeros intentos a las 04:43 de la madrugada en Chile, más de seis horas antes de que PHP publicara la corrección, a las 11:00.
Un dato para no exagerar: al momento de publicarse los avisos, el equipo de seguridad de PHP revisó los códigos de ataque que circulaban y no encontró uno que funcionara de verdad. Eso puede cambiar en días, como pasó en julio con wp2shell y la actualización forzada de WordPress, así que el momento de actuar es ahora y no cuando aparezca en las noticias.
Qué versiones de PHP están corregidas y cuáles no
Esta es la tabla que conviene tener a mano para revisar tu sitio:
| Versión de PHP | ¿Hay versión corregida del proyecto PHP? | Qué hacer |
|---|---|---|
| 8.5 | Sí: 8.5.12 | Actualizar a 8.5.12 o superior |
| 8.4 | Sí: 8.4.27 | Actualizar a 8.4.27 o superior |
| 8.3 | Sí: 8.3.36 | Actualizar a 8.3.36 o superior |
| 8.2 | Sí: 8.2.35 | Actualizar, y planificar el salto a 8.3 o 8.4: la 8.2 deja de recibir parches el 31 de diciembre de 2026 |
| 8.1, 8.0 y 7.4 | No. Solo un parche de código fuente para quien compila PHP por su cuenta | Cambiar a una versión con soporte |
| 7.3 o anterior | No | Cambiar a una versión con soporte; si el sitio no lo resiste, hay que revisarlo |
Algunas distribuciones de Linux y empresas de soporte extendido entregan correcciones para versiones antiguas por su cuenta, pero llegan más tarde, no siempre cubren todas las versiones y no dependen de ti. Quedarse en una versión vieja confiando en que alguien la parche es apostar con tu sitio.
Cómo saber qué versión de PHP usa tu sitio
Hay dos caminos, y ninguno toma más de dos minutos.
Desde WordPress: entra al escritorio y ve a Herramientas → Salud del sitio → pestaña Información → sección Servidor. Ahí aparece la versión de PHP.
Desde cPanel: busca la herramienta para seleccionar la versión de PHP (según el servidor se llama «Seleccionar versión de PHP» o «MultiPHP Manager»). Ahí ves qué versión usa cada dominio y puedes cambiarla.
Un detalle importante: lo que eliges en el panel es la rama (8.3, 8.4…), no el número fino. Que la rama esté al día con la última corrección es trabajo del proveedor del servidor, no tuyo. Lo tuyo es no estar en una rama que ya nadie corrige. Si quieres profundizar en esto, tenemos una guía completa sobre qué versión de PHP corre tu sitio y por qué importa.
Qué hacer hoy, según tu caso
Si tu sitio está en PHP 8.2 o superior: la corrección depende del servidor. Si tienes hosting compartido, pregúntale a tu proveedor si ya instaló las versiones corregidas. Es una pregunta legítima y la respuesta debería ser clara. Si tienes un VPS o servidor propio, actualiza PHP hoy y reinicia los procesos de PHP para que el cambio tome efecto.
Si tu sitio está en PHP 8.1, 8.0, 7.4 o anterior: este es el caso que más preocupa, porque no hay versión corregida del proyecto PHP para tu rama. El camino es subir a 8.3 o 8.4. Antes de hacerlo, saca un respaldo completo, actualiza WordPress, los plugins y el tema, y recién después cambia la versión. Si algo se rompe, puedes volver a la versión anterior mientras se arregla, pero no te quedes ahí.
Si tienes una tienda o un sitio con formularios: después de cualquier cambio, prueba lo que de verdad usas: un pedido de prueba, el formulario de contacto, el inicio de sesión y la recuperación de contraseña. Los problemas aparecen en la parte que nadie mira todos los días.
Lo que la actualización no arregla
Actualizar PHP te protege desde ahora. No deshace lo que haya pasado antes.
Como los ataques empezaron antes del parche, vale la pena una revisión rápida: que no haya usuarios administradores que no reconozcas, que no aparezcan páginas o contenido que no escribiste y que Google no muestre páginas extrañas al buscar site:tudominio.cl. Si algo no cuadra, revisa nuestra guía de señales de un WordPress hackeado.
Y revisa tus respaldos: de qué fecha es el más antiguo que tienes y si alguna vez probaste restaurarlo. Un respaldo que nunca se probó es una esperanza, no un respaldo. Acá explicamos cómo hacer y verificar respaldos de tu sitio.
Preguntas frecuentes
¿Un plugin de seguridad me protege de php2shell?
No. La falla ocurre dentro de PHP antes de que WordPress y sus plugins empiecen a funcionar. La única corrección completa, según el propio aviso de PHP, es actualizar.
¿Afecta a sitios que no son WordPress?
Sí. Afecta a cualquier sitio que funcione con PHP: Joomla, Drupal, Moodle, Magento, PrestaShop, sistemas hechos a medida y sitios en PHP sin gestor de contenidos.
¿Mi sitio en HTML estático está en riesgo?
Un sitio que solo entrega archivos HTML, sin PHP, no ejecuta el código vulnerable. Pero si en la misma cuenta tienes un formulario en PHP, un blog o un instalador viejo olvidado, esa parte sí cuenta.
¿Cambiar la versión de PHP me puede romper el sitio?
Puede pasar si un plugin o el tema llevan años sin actualizarse. Por eso se respalda y se actualiza todo antes. Un plugin que no funciona con PHP 8.3 en 2026 es una señal de que hay que reemplazarlo.
En resumen
php2shell es una falla del motor, no de tu sitio, y se corrige actualizando PHP. Si estás en 8.2 o superior, asegúrate de que tu servidor ya tenga la versión corregida. Si estás en 8.1 o anterior, esta es la señal que faltaba para subir de versión.
En AltaHosting ya estamos actualizando nuestros servidores. Algunos ya funcionan con las versiones corregidas y en el resto nuestros ingenieros están en ese proceso.
¿No sabes qué versión de PHP usa tu sitio o te da miedo cambiarla? Escríbenos por WhatsApp o a ventas@altahosting.cl y lo revisamos contigo: la versión que usa, si tus plugins y tu tema aguantan el cambio, y en qué estado están tus respaldos.
