Saltar al contenido principal

Ciberseguridad

PHP2Shell: qué deben saber los clientes de iDeo

Toni Tarazona4 min de lectura
Ilustración de un servidor web con un aviso de seguridad

El 21 de octubre el equipo de PHP publicó parches de urgencia para dos vulnerabilidades con nota de gravedad crítica (9,2 sobre 10). Les han puesto un nombre fácil de recordar, PHP2Shell, porque convierten un servidor con PHP en una «shell», es decir, en una consola que el atacante maneja a su gusto.

Te contamos qué es, si te afecta, qué estamos haciendo y qué tienes que hacer tú.

En este artículo

Qué es PHP2Shell

PHP es el lenguaje con el que funcionan muchas webs y tiendas online: WordPress, WooCommerce, PrestaShop, Joomla o Drupal, entre otras. El fallo no está en esas aplicaciones, sino en el propio PHP, en cómo gestiona la memoria cuando recibe ciertos envíos de formularios.

Aprovechándolo, un atacante:

Son dos fallos registrados con los identificadores CVE-2026-109618 y CVE-2026-109619. Afectan a PHP en Apache (mod_php), PHP-FPM y otros modos habituales. Los investigadores que los descubrieron señalan que versiones muy antiguas de PHP también están afectadas.

INCIBE informa de ataques anteriores a la publicación de las actualizaciones. CISA indicaba en su aviso del 21 de octubre que no había observado explotación. Son observaciones distintas: no permiten afirmar aquí si ha habido intrusiones con éxito. La actualización sigue siendo la medida necesaria.

  • no necesita usuario ni contraseña: le basta con enviar peticiones preparadas a la web;
  • puede ejecutar programas en el servidor, con los permisos de la web;
  • puede leer lo que hay en la memoria: contraseñas de la base de datos, claves de pasarelas de pago o datos de clientes.

¿Te afecta?

Comprueba primero si tu web, tu aplicación o el panel del equipo utilizan PHP. Estos son los sistemas que conviene revisar:

  • una web corporativa o tienda online hecha con WordPress, WooCommerce, PrestaShop, Joomla o Drupal;
  • una intranet o herramienta interna con acceso desde el navegador: gestor de incidencias, CRM, ERP web, aulas virtuales o gestor documental;
  • un programa de reservas, de gestión de socios o una carta digital con portal web alojado en un servidor;
  • un portal de WiFi para clientes o invitados;
  • equipos con panel web, como algunos Firewall o NAS. Aquí hay que esperar al aviso de cada fabricante.

¿Qué sistemas no están afectados directamente?

No se ven afectados por estos fallos los sistemas que no ejecutan ni exponen una instalación vulnerable de PHP.

  • Las webs estáticas o hechas con .NET o Node, si no dependen de PHP.
  • Los servicios en la nube cuyo proveedor confirme que no usan PHP.
  • Un ordenador, Microsoft 365, el correo o el TPV no están afectados directamente por estos fallos si no ejecutan ni exponen PHP vulnerable. Un servidor Windows que sí use PHP debe revisarse.

Qué estamos haciendo en iDeo

En las webs que alojamos (WordPress y otras):

  • Ya hemos aplicado medidas en todos nuestros servidores, desde PHP 5.6. Hemos desactivado el progreso de subida de sesiones (session.upload_progress.enabled = 0), que corta una de las vías demostradas, y activado el modo estricto (session.use_strict_mode = 1) como refuerzo general de las sesiones, no como solución completa de PHP2Shell.
  • Estamos aplicando progresivamente las actualizaciones para PHP 7.4 y posteriores distribuidas por Plesk y cPanel, servidor a servidor, según la situación operativa comunicada por iDeo el 22 de octubre. En ramas antiguas, un parche del proveedor no devuelve el soporte oficial a la versión.
  • Si tu web funciona con PHP 7.3 o anterior, no hay actualización oficial: te escribiremos para planificar la migración a una versión con soporte.

Cómo revisamos los sistemas que mantenemos

El Centro de Atención a Usuarios revisa los sistemas que gestionamos:

  • Revisando todo lo que tiene PHP: webs, servidores y equipos con panel web, empezando por lo que está abierto a Internet.
  • Actualizando PHP a la versión corregida y reiniciando el servicio. Sin reinicio, el parche no se aplica. El reinicio puede causar una interrupción, que coordinamos contigo antes de intervenir.
  • Pidiendo confirmación por escrito a los proveedores de alojamiento de las webs que no están en nuestros servidores.
  • Buscando indicios de intrusión desde mediados de octubre: envíos de formularios extraños, errores de memoria, archivos nuevos en la web.
  • Contándote qué sistemas tienes, cuáles están ya corregidos y cuáles quedan pendientes, con fecha y versión.

Qué tienes que hacer tú

  • Si tu web o tu tienda la lleva otra empresa (agencia, alojamiento o fabricante), pregúntale hoy por escrito: «¿Usáis PHP? ¿Ya estáis en 8.2.35, 8.3.36, 8.4.27 o 8.5.12, o tenéis el parche de vuestra distribución?». Si quieres, se lo preguntamos nosotros.
  • Actualizar WordPress y sus plugins no basta: el fallo está en PHP, que va por debajo.
  • Si tu servidor tiene PHP 8.1 o anterior, ya no tiene soporte regular. PHP ha publicado parches de código fuente excepcionales para 7.4, 8.0 y 8.1: comprueba el paquete de tu proveedor y planifica la migración. PHP 8.2 deja de tener soporte el 31 de diciembre de 2026: es buen momento para planificar el salto.
  • Si notas algo raro (la web ha cambiado, redirige a otra página, Google avisa de que no es segura o llegan pedidos o correos extraños), llámanos y no borres nada. Si se confirma una brecha de datos personales, debe valorarse la notificación a la AEPD: cuando sea obligatoria, el plazo general es de 72 horas desde que se tiene conocimiento, salvo que sea improbable que exista riesgo para los derechos y libertades de las personas.

Versiones que corrigen el fallo

Rama de PHPVersión corregida
8.58.5.12
8.48.4.27
8.38.3.36
8.28.2.35

8.1 y anteriores: sin soporte regular. Hay parches excepcionales de código fuente para 7.4, 8.0 y 8.1; consulta a tu proveedor y planifica la migración. PHP 8.2 recibe soporte de seguridad hasta el 31-12-2026.

Si no se puede actualizar ya

Hay ajustes que reducen determinadas vías de ataque mientras se prepara la actualización. Desactivar el progreso de subida ya está aplicado en nuestros servidores; el modo estricto de sesiones es un refuerzo adicional, no una corrección de estos fallos.

Ninguno lo corrige del todo. PHP exige aplicar la actualización completa. Los ajustes deben imponerse desde la administración del servidor y reiniciando los procesos PHP; no basta con añadirlos dentro de WordPress. Si no puedes actualizar, acuerda con el responsable técnico cómo limitar la exposición del sistema.

  • desactivar el progreso de subida de sesiones;
  • activar el modo estricto de sesiones;
  • limitar el tamaño de los envíos;
  • poner un Firewall de aplicaciones web (WAF) delante de la web.

Servicios relacionados

¿Hablamos?

Si no sabes si tu web o tus programas usan PHP, llama al Centro de Atención a Usuarios y lo miramos contigo. Si ya eres cliente, revisamos los sistemas que llevamos y te comunicaremos el resultado.

Fuentes