Saltar al contenido

Web

PHP2Shell: las fallas críticas de PHP que exponen a los sitios en WordPress y qué hacer esta semana

Jesús Gireaud · Fundador & Director ·

Un auto deportivo verde lima recién lavado, con espuma escurriendo por las puertas y un balde con esponja junto a la rueda, mientras sale humo gris del motor bajo el capó abierto.

El 21 de octubre de 2026, el equipo de PHP publicó una actualización de emergencia para dos fallas críticas, conocidas como PHP2Shell, que permiten a un atacante ejecutar código en un servidor web sin usuario ni contraseña. WordPress funciona sobre PHP, así que la falla alcanza a casi cualquier sitio hecho en WordPress. Y tiene una particularidad que confunde a muchos dueños de negocio: no se arregla actualizando WordPress. Se arregla actualizando PHP, y en la mayoría de los casos eso lo hace el hosting.

Una forma simple de verlo: WordPress es la carrocería del auto y PHP es el motor. Puedes tener la carrocería impecable, con todos los plugins al día, y el motor con una falla de fábrica. Esto es un llamado a revisión del motor.

Qué pasó

Las dos fallas están registradas como CVE-2026-109618 y CVE-2026-109619, y PHP les asignó una gravedad de 9,2 sobre 10. En la práctica, alguien puede mandar una petición al servidor de tu sitio y terminar con el control de ese servidor. En la configuración más expuesta (Apache con mod_php), el aviso oficial de PHP describe un ataque que se activa antes de que el sitio alcance a cargar.

La cronología es corta y por eso preocupa:

  • El 17 de octubre, Amazon detectó un intento de explotación en sus sistemas trampa, cuatro días antes del anuncio público (Amazon Threat Intelligence, citado por Help Net Security el 21 de octubre).
  • El 20 de octubre los identificadores de las fallas circularon en redes antes de tiempo, y PHP adelantó un día la publicación del parche.
  • El 21 de octubre salieron las versiones corregidas: PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. El CSIRT Nacional emitió la alerta AVC26-00740, que recomienda actualizar de inmediato, y Cloudflare informó que ya veía los primeros ataques.

Los centros de ciberseguridad de Estados Unidos y Reino Unido fueron más lejos: recomendaron considerar sacar de línea los sistemas que no se puedan actualizar pronto.

Si tu sitio usa PHP 8.1 o una versión anterior, no hay actualización oficial. Esas versiones ya no tienen soporte, y PHP solo publicó parches mínimos de código para 7.4, 8.0 y 8.1, que un hosting puede aplicar pero que no reemplazan pasar a una versión vigente.

¿Y WP2Shell?

Es otra falla, y conviene no mezclarlas. WP2Shell estaba en el propio WordPress, no en PHP, y se corrigió en julio: el 17 de julio de 2026 salieron WordPress 7.0.2, 6.9.5 y 6.8.6, y WordPress.org forzó la actualización automática en los sitios afectados. El 21 de julio la agencia de ciberseguridad de Estados Unidos (CISA) la sumó a su catálogo de fallas explotadas activamente. Según Wiz y SANS, citados por BleepingComputer, los atacantes la usaron para instalar puertas traseras disfrazadas de plugins, crear administradores falsos y recolectar los nombres de usuario y correos de los administradores.

En tres meses aparecieron dos maneras de tomar un sitio WordPress sin contraseña. Un sitio con las actualizaciones automáticas apagadas y un hosting que no actualiza PHP puede estar expuesto a las dos.

Por qué le pega más fuerte a una pyme

PHP está detrás del 69,3% de los sitios web cuyo lenguaje de servidor se conoce (W3Techs, citado por Tenable en octubre de 2026). Unos dos de cada tres de esos sitios corren sobre el motor que hay que actualizar. Lo que cambia es quién se encarga.

Una empresa grande tiene a alguien cuyo trabajo es leer esa alerta y actualizar. En una pyme, el sitio lo hizo un proveedor hace años, vive en un hosting compartido que nadie revisa y nadie tiene asignado el trabajo de mantenerlo. La alerta pasa sin que nadie la lea.

Las estadísticas públicas de WordPress.org, consultadas el 22 de octubre de 2026, lo muestran: el 35,8% de los sitios WordPress corre PHP 8.1 o una versión anterior, es decir, versiones que ya no reciben actualizaciones oficiales. El 15,9% sigue en PHP 7.4, que perdió el soporte en noviembre de 2022.

Cuando el sitio de una pyme cae, la cuenta llega por el lado del negocio:

  • Google puede marcar el sitio como hackeado en sus resultados, y el navegador puede mostrar una pantalla roja de advertencia antes de entrar. Los contactos dejan de llegar.
  • El sitio puede redirigir a tus visitas a páginas de estafa o enviar spam desde tu dominio, y entonces tus propios correos empiezan a caer en la carpeta de spam de tus clientes.
  • Los datos que tus clientes dejaron en los formularios quedan expuestos, justo cuando la ley 21.719 de datos personales tiene fijada su entrada en vigencia para el 1 de diciembre de 2026.

Qué hacer esta semana

1. Averigua qué versión de PHP usa tu sitio

En el panel de WordPress entra a Herramientas, Salud del sitio, pestaña Información, sección Servidor. Ahí aparece la versión de PHP. Si dice 8.2.35, 8.3.36, 8.4.27, 8.5.12 o un número mayor dentro de esa misma serie, el parche ya está.

Algunos hostings aplican la corrección sin cambiar el número de versión. Si ves un número más antiguo, pregúntale al hosting antes de asumir lo peor.

2. Actualiza PHP, o pídele a tu hosting que lo haga hoy

Actualizar WordPress, el tema o los plugins no toca PHP. En un hosting compartido, PHP lo actualiza el proveedor. Escríbele y pregúntale si la versión de PHP de tu sitio ya incluye el parche de PHP2Shell (CVE-2026-109618 y CVE-2026-109619). Si tu panel tiene un selector de versión de PHP, como el de cPanel, confirma que la versión que elijas ya trae la corrección.

Si estás en PHP 8.1 o anterior, el salto es más grande y conviene hacerlo con cuidado: respaldo completo, prueba en una copia del sitio y paso a PHP 8.3 u 8.4. PHP 8.2 deja de recibir parches de seguridad el 31 de diciembre de 2026, así que subir a 8.2 hoy alcanza para dos meses.

Si tu hosting no puede actualizar pronto, lo que recomiendan las agencias de ciberseguridad es dejar el sitio fuera de línea hasta que esté parchado.

3. Mientras tanto, pon un firewall delante del sitio

Un firewall de aplicaciones web revisa las peticiones antes de que lleguen a tu sitio. Hay dos tipos y no protegen igual.

Un plugin de seguridad que vive dentro de WordPress es como un guardia dentro de la casa. En el escenario más grave de PHP2Shell, el ataque ocurre antes de que WordPress cargue, así que ese guardia no alcanza a verlo. Un firewall externo es el guardia de la reja: revisa todo lo que entra antes de que toque el servidor.

Para PHP2Shell, Sucuri sumó reglas a su firewall el 21 de octubre y Cloudflare activó reglas para todos sus clientes, incluido el plan gratuito. Muchos hostings tienen además su propio firewall: pregúntale al tuyo si está activo para tu sitio.

Sobre Sucuri, una precisión que evita malentendidos. El plugin gratuito Sucuri Security, con más de 600.000 instalaciones, sirve para escanear el sitio, registrar cambios y endurecer la configuración. El firewall es un servicio pagado aparte. Suman, pero hacen cosas distintas.

Los mismos proveedores lo advierten: el firewall te da tiempo mientras actualizas, no reemplaza la actualización y solo protege si todo el tráfico pasa por él.

4. Confirma que WordPress está al día

Para cerrar WP2Shell, WordPress tiene que estar como mínimo en 7.0.2, 6.9.5 o 6.8.6 dentro de su serie. Lo más simple es tenerlo en la última versión, y eso lo ves en Escritorio, Actualizaciones. Si tienes las actualizaciones automáticas desactivadas, puede que el parche de julio nunca se haya instalado.

5. Revisa si alguien ya entró

Actualizar cierra la puerta, pero no saca a quien ya está adentro. Amazon recomienda revisar desde el 17 de octubre, la fecha del primer intento detectado. Las señales que más se repiten son administradores que no creaste, plugins que no instalaste, archivos PHP nuevos en carpetas donde no deberían estar (como la de imágenes subidas o la de caché) y tareas programadas que nadie configuró. Si encuentras algo, pide una revisión completa antes de borrar a ciegas.

6. Cambia las contraseñas, después de actualizar y revisar

PHP2Shell también permite leer pedazos de la memoria del servidor, y ahí pueden quedar contraseñas, claves de acceso y llaves de conexión con otros sistemas (Qualys, 20 de octubre de 2026). Por eso el orden importa. Si cambias las contraseñas antes de parchar, las nuevas quedan igual de expuestas. Y si alguien dejó una puerta trasera instalada, las vuelve a leer apenas las cambies: primero se cierra la puerta, después se cambian las llaves.

Lo que hay que cambiar:

  • Las contraseñas de los usuarios administradores de WordPress.
  • El acceso al panel del hosting y al FTP.
  • La contraseña de la base de datos y las claves de seguridad del archivo wp-config.php. Pídeselo a quien administra el sitio, porque si se cambia en un lado y no en el otro, el sitio deja de funcionar.
  • Las llaves de conexión con otros servicios: pasarela de pago, CRM, correo y formularios.

Aprovecha de activar la verificación en dos pasos en WordPress y en el hosting, y de borrar cualquier administrador que no reconozcas.

7. Apaga XML-RPC si no lo usas

XML-RPC es una puerta de servicio que WordPress trae abierta para que otras aplicaciones se conecten al sitio y lo administren desde fuera. Piensa en la puerta trasera de un local: sirve si por ahí llegan los proveedores, pero si nadie la usa, conviene cerrarla con llave, porque es justo por donde prueban suerte los que no deberían entrar. Es una de las rutas más usadas para probar contraseñas a la fuerza.

Apagarla no corrige PHP2Shell. Cierra una vía para adivinar contraseñas, y eso pesa cuando WP2Shell ya sirvió para recolectar nombres de administradores. Muchos sitios no la necesitan. En el plugin Sucuri Security se apaga con un clic, en la sección de endurecimiento (Hardening). Una excepción: si usas Jetpack u otra herramienta que publique o administre el sitio desde fuera, consulta antes de cerrarla, porque puede depender de esa puerta.

Si quieres reforzar la seguridad de tu sitio

En Hitos diseñamos y mantenemos sitios web. Si quieres reforzar la seguridad de tu sitio, escríbenos directamente.

Fuentes

Preguntas frecuentes

Preguntas frecuentes

¿Qué es PHP2Shell?

Es el nombre de dos fallas críticas en PHP (CVE-2026-109618 y CVE-2026-109619), corregidas el 21 de octubre de 2026, que permiten a un atacante ejecutar código en un servidor web sin autenticarse. Afectan a toda instalación de PHP que atiende visitas web.

¿Actualizar WordPress protege mi sitio de PHP2Shell?

No. La falla está en PHP, el lenguaje sobre el que funciona WordPress. Hay que actualizar PHP a 8.2.35, 8.3.36, 8.4.27, 8.5.12 o una versión posterior de la misma serie, y en un hosting compartido eso lo hace el proveedor.

¿PHP2Shell y WP2Shell son lo mismo?

No. PHP2Shell está en PHP y se corrigió en octubre de 2026. WP2Shell estaba en el núcleo de WordPress y se corrigió en julio de 2026 con las versiones 7.0.2, 6.9.5 y 6.8.6. Un sitio puede estar expuesto a una, a la otra o a las dos.

¿Mi sitio está a salvo si no usa WordPress?

Depende de si funciona con PHP. Drupal, Joomla, Magento, PrestaShop y cualquier desarrollo a medida en PHP están en la misma situación. Un sitio estático alojado sin PHP, como hitosmedia.com, que está hecho en Astro, no tiene PHP que atacar. En plataformas cerradas como Shopify o Wix, la infraestructura la mantiene la plataforma.

¿Un firewall reemplaza la actualización?

No. Un firewall externo, como el de Sucuri o el de Cloudflare, bloquea los ataques conocidos mientras actualizas, pero PHP es explícito en que la única corrección completa es actualizar.

¿Qué hago si mi sitio usa PHP 7.4?

Planificar la migración a PHP 8.3 u 8.4, con respaldo y una prueba previa, porque 7.4 no recibe actualizaciones oficiales desde noviembre de 2022. Mientras tanto, pregúntale a tu hosting si aplicó el parche mínimo que PHP publicó para esa versión.

¿Hablamos de tu crecimiento?

Agenda una sesión estratégica: sales con un diagnóstico claro, contrates o no.

Conversemos Escríbenos por WhatsApp