seguridad

En los últimos días seguramente hayas leído titulares como «el fallo de PHP que pone en jaque al 70 % de Internet» o que gobiernos de media Europa han apagado sus webs por precaución. No es exageración: se llama PHP2Shell y es una de las vulnerabilidades más graves que ha tenido PHP en años.

Si tienes una web, lo más probable es que te afecte, porque WordPress, WooCommerce, Prestashop, Joomla, Drupal y la mayoría de webs hechas a medida funcionan con PHP. Según INCIBE, de los cerca de dos millones de dominios .es activos, alrededor de 1,5 millones usan PHP.

En este artículo te voy a explicar, sin tecnicismos, qué ha pasado, cómo saber si tu web está en riesgo y qué tienes que hacer, tanto si tu web está hecha en WordPress como si es una web a medida.

1. ¿Qué es PHP2Shell?

PHP es el lenguaje de programación que funciona «por detrás» en el servidor donde está alojada tu web. Cada vez que alguien visita una página, rellena un formulario o compra en tu tienda online, es PHP quien procesa esa petición antes de que WordPress (o el código de tu web) llegue a hacer nada.

PHP2Shell es el nombre con el que se conoce a dos fallos de seguridad críticos descubiertos en el propio núcleo de PHP:

• CVE-2026-109618: un fallo de corrupción de memoria cuando PHP se queda sin memoria al procesar una petición.
• CVE-2026-109619: un fallo de tipo use-after-free relacionado con la función que muestra el progreso de subida de archivos (session.upload_progress).

Los dos tienen una puntuación de gravedad de 9,2 sobre 10 (crítica) y llevaban escondidos más de una década. Lo curioso es que se descubrieron con ayuda de herramientas de inteligencia artificial, algo que ha acelerado muchísimo tanto su hallazgo como la aparición de ataques.

2. ¿Por qué es tan grave?

Un atacante puede tomar el control sin contraseña

Ambos fallos permiten lo que se conoce como ejecución remota de código sin autenticación. Traducido: alguien desde cualquier parte del mundo, sin usuario ni contraseña, podría ejecutar sus propias órdenes en el servidor de tu web. Desde ahí puede robar datos de clientes, instalar malware, meter enlaces de spam que hunden tu SEO o usar tu servidor para atacar a otros.

Ya se está explotando

No es un riesgo teórico. Amazon detectó intentos de ataque el 17 de octubre, cuatro días antes de que se publicara el aviso oficial. Cloudflare habló de millones de intentos tras hacerse público, y a finales de octubre la agencia de ciberseguridad de EE. UU. (CISA) confirmó ataques reales. Algunos intentan, por ejemplo, convertir los servidores en parte de una botnet.

Gobiernos y grandes webs se desconectaron

La reacción fue inédita: webs gubernamentales de Países Bajos, Finlandia, Francia, Bélgica o Dinamarca, además de la BBC o Wikimedia, se desconectaron por precaución. En España, INCIBE elevó el aviso a nivel crítico y muchas administraciones locales y universidades hicieron paradas de mantenimiento para actualizar.

Y hay un tercer fallo que todavía no tiene parche

El 23 de octubre, PHP avisó de un tercer fallo, el CVE-2026-115560, que no queda corregido con las versiones publicadas el 21 de octubre. PHP lo considera poco probable porque solo afecta a configuraciones poco habituales, pero recomienda desactivar el progreso de subida de archivos hasta la próxima actualización. A la hora de escribir este artículo, todavía no ha salido el parche definitivo. Más abajo te explico cómo aplicar esa medida.

3. ¿A qué webs afecta y quién tiene que solucionarlo?

Afecta a cualquier web que funcione con una versión de PHP sin parchear, da igual que sea un blog pequeño o una tienda online grande. Las versiones afectadas van desde PHP 5.4 hasta PHP 8.5.

Aquí está la clave que mucha gente no tiene clara: el problema no está en WordPress ni en tus plugins, sino en el servidor. Por eso, actualizar WordPress, los plugins o el tema no lo soluciona. De hecho, WordPress.org ya ha confirmado que no publicará ninguna actualización para esto, porque la solución tiene que llegar por PHP.

Quién tiene que actualizar depende de dónde esté alojada tu web:

• Hosting compartido (el típico de Raiola, SiteGround, Hostinger, IONOS, etc.): el proveedor actualiza PHP para todos sus clientes. Tú tienes que comprobar que lo ha hecho y que tu web usa una versión con soporte.
• Hosting WordPress gestionado: igual, el proveedor se encarga del parche, pero conviene confirmarlo.
• VPS o servidor propio: aquí nadie lo hace por ti. Lo tienes que actualizar tú o la persona que te lleva el servidor.

4. Cómo comprobar si tu web es vulnerable

Lo primero es saber qué versión de PHP usa tu web y compararla con esta tabla. Tu web está protegida frente a PHP2Shell si tiene, como mínimo, estas versiones:

• PHP 8.5 → 8.5.12 o superior
• PHP 8.4 → 8.4.27 o superior
• PHP 8.3 → 8.3.36 o superior
• PHP 8.2 → 8.2.35 o superior (ojo: deja de tener soporte el 31 de diciembre de 2026)
• PHP 8.1, 7.4 o anteriores → no hay versión oficial corregida. Hay que migrar a una versión actual.

Si tu web está hecha en WordPress

Es muy fácil y no necesitas tocar nada del servidor:

1. Entra en el escritorio de WordPress.
2. Ve a Herramientas → Salud del sitio.
3. Pulsa en la pestaña Información.
4. Despliega el apartado Servidor y mira la línea Versión de PHP.

Si tu web está hecha a medida

Puedes subir este pequeño archivo a la raíz de tu web (por FTP o desde el administrador de archivos del hosting), abrirlo en el navegador (tudominio.com/comprobar-php.php) y ver el resultado. Bórralo en cuanto termines, no es buena idea dejarlo publicado.

<?php
// comprobar-php.php · Comprobación rápida de PHP2Shell (oben.es)
// ⚠️ BORRA ESTE ARCHIVO EN CUANTO VEAS EL RESULTADO
header('Content-Type: text/plain; charset=utf-8');

$seguras = ['8.2' => '8.2.35', '8.3' => '8.3.36', '8.4' => '8.4.27', '8.5' => '8.5.12'];
$rama = PHP_MAJOR_VERSION . '.' . PHP_MINOR_VERSION;

echo "Versión de PHP: " . PHP_VERSION . "\n\n";

if (version_compare($rama, '8.5', '>')) {
    echo "✅ Rama más nueva que 8.5: no afectada por PHP2Shell.\n";
} elseif (!isset($seguras[$rama])) {
    echo "❌ PHP $rama no tiene parche oficial: hay que migrar a PHP 8.3 o superior.\n";
} elseif (version_compare(PHP_VERSION, $seguras[$rama], '>=')) {
    echo "✅ Versión parcheada (mínimo {$seguras[$rama]}).\n";
} else {
    echo "❌ Por número de versión NO está parcheada (necesitas {$seguras[$rama]}).\n";
    echo "   Si el servidor usa paquetes de Ubuntu, Debian o AlmaLinux, confírmalo con tu hosting.\n";
}

echo "\nProgreso de subida (session.upload_progress): ";
echo ini_get('session.upload_progress.enabled') ? "ACTIVADO ⚠️ (conviene desactivarlo)\n" : "desactivado ✅\n";

Cuidado: el número de versión puede engañar

Si tu web está en un servidor con Ubuntu, Debian, Red Hat o AlmaLinux, estos sistemas aplican el parche sin cambiar el número de versión. Por ejemplo, un Ubuntu 24.04 totalmente actualizado sigue mostrando «PHP 8.3.6» aunque esté protegido. Por eso, si ves un número «antiguo», no te asustes todavía: pregunta a tu hosting por escrito si el servidor tiene aplicado el parche de PHP2Shell.

5. Cómo solucionarlo

La única solución completa es actualizar PHP a una versión corregida. Las medidas temporales ayudan, pero el propio equipo de PHP las considera incompletas. Vamos por casos.

Caso 1: Webs en WordPress

1. Haz una copia de seguridad completa (archivos y base de datos) antes de tocar nada.
2. Comprueba tu versión de PHP en Salud del sitio, como te he explicado arriba.
3. Si estás en hosting compartido o gestionado: entra en tu panel (cPanel, Plesk o el panel propio del proveedor) y busca la opción «Versión de PHP», «Selector de PHP» o «MultiPHP Manager». Elige PHP 8.3 o 8.4. Después, escribe a soporte y pide que te confirmen que el parche de PHP2Shell está aplicado.
4. Si vienes de PHP 7.4 u 8.0/8.1: el salto puede romper plugins o temas antiguos. Lo ideal es probarlo antes en una copia de la web (staging) y revisar que todos los plugins sean compatibles.
5. Si tu WordPress está en un VPS: sigue los pasos del caso 2, porque el procedimiento es el mismo.
6. Revisa que no te hayan colado nada (te lo explico en el apartado 6).

Un apunte importante: los plugins de seguridad no sustituyen el parche. Un firewall a nivel de servidor o de red (como el WAF de Cloudflare, que activó reglas específicas para todos sus planes, incluido el gratuito) ayuda a frenar ataques, pero no arregla el fallo.

Caso 2: Webs hechas a medida (PHP, Laravel, Symfony, CodeIgniter…)

Aquí da igual el framework: el fallo está en PHP, así que todas las webs que corran sobre un PHP vulnerable están expuestas. Si tu web está en un hosting compartido, aplica los pasos 1 a 3 del caso anterior. Si está en un VPS o servidor propio, el técnico que lo administre tiene que hacer algo así (ejemplo para Ubuntu/Debian):

# 1. Ver la versión actual
php -v

# 2. Actualizar los paquetes de PHP
sudo apt update && sudo apt upgrade

# 3. Confirmar que el parche está aplicado (cambia 8.3 por tu versión)
zgrep -E 'CVE-2026-10961[89]' /usr/share/doc/php8.3-cli/changelog.Debian.gz

# 4. Reiniciar PHP para que cargue la versión nueva
sudo systemctl restart php8.3-fpm      # si usas PHP-FPM
sudo systemctl restart apache2         # si usas Apache con mod_php

Si el paso 3 devuelve líneas que mencionan los CVE, el parche está aplicado. No olvides el reinicio: si PHP no se reinicia, sigue funcionando la versión vieja en memoria.

Y si tu aplicación funciona con PHP 8.1 o anterior, toca planificar la migración del código a una versión actual. Es el momento de hacerlo: la próxima vulnerabilidad volverá a pillarte sin parche.

Medida temporal si hoy no puedes actualizar

Mientras se actualiza (y también para protegerte del tercer fallo, el CVE-2026-115560, que aún no tiene parche), PHP recomienda desactivar el progreso de subida de archivos. Es una función que casi ninguna web utiliza. Se añade esta línea en el php.ini del servidor o en la configuración del pool de PHP-FPM:

; php.ini · Protección temporal PHP2Shell / CVE-2026-115560
session.upload_progress.enabled = 0

Dos detalles importantes:

• No sirve ponerlo con ini_set() desde el código ni en un archivo .user.ini. Tiene que estar en la configuración principal de PHP, y después hay que reiniciar PHP.
• Mantenla aunque ya hayas actualizado, hasta que salga el parche del CVE-2026-115560.

Si tu servidor está expuesto y no se puede parchear de ninguna forma, la recomendación de INCIBE y de agencias como la NSA o el FBI coincide: desconectarlo de Internet hasta que esté actualizado.

6. ¿Y si ya me han atacado?

Como los ataques empezaron antes de que hubiera parche, conviene revisar la web desde el 17 de octubre aunque ya estés actualizado. Señales de alarma:

• Usuarios administradores en WordPress que no reconoces (Usuarios → filtrar por «Administrador»).
• Archivos .php dentro de la carpeta de subidas (wp-content/uploads), donde solo debería haber imágenes y documentos.
• Redirecciones raras, páginas de spam indexadas en Google o avisos de Google Search Console.
• El servidor va lento sin motivo o el hosting te avisa de un consumo anormal de recursos.

Si tienes acceso por SSH, este comando busca archivos PHP dentro de las subidas de WordPress, que nunca deberían estar ahí:

# Archivos PHP en la carpeta de subidas (en una web limpia no debería salir nada)
find wp-content/uploads -type f -name "*.php"

# Archivos PHP modificados desde el 17 de octubre de 2026
# (saldrán también los de plugins actualizados: revisa los que no te cuadren)
find . -type f -name "*.php" -newermt "2026-10-17"

Si encuentras algo sospechoso, cambia todas las contraseñas (WordPress, hosting, FTP, base de datos), restaura una copia de seguridad limpia anterior al 17 de octubre si la tienes y pide ayuda profesional para limpiar la web.

7. Preguntas frecuentes sobre PHP2Shell

¿Actualizar WordPress soluciona PHP2Shell?

No. El fallo está en PHP, el software del servidor. Ni WordPress, ni los plugins, ni las actualizaciones automáticas lo corrigen. Tienes que actualizar la versión de PHP o comprobar que tu hosting lo ha hecho.

¿Mi hosting lo habrá solucionado ya?

Muchos proveedores aplicaron el parche entre el 21 y el 22 de octubre, pero no todos, y en algunos casos depende de la versión de PHP que tengas seleccionada. Si tu web sigue en PHP 7.4 o 8.0, por ejemplo, puede que siga expuesta. Compruébalo siempre.

¿Afecta a webs hechas con Wix, Shopify o Squarespace?

Esas plataformas no te dejan gestionar el servidor y se encargan ellas de la seguridad, así que no tienes que hacer nada. PHP2Shell afecta a webs que funcionan sobre PHP en un hosting o servidor, como WordPress, Prestashop, Joomla, Drupal o desarrollos a medida.

¿Qué versión de PHP debería usar ahora?

Lo más recomendable hoy es PHP 8.3 o 8.4 en sus versiones parcheadas. PHP 8.2 sigue siendo válida, pero deja de tener soporte de seguridad a finales de 2026.

8. Conclusión

PHP2Shell es un fallo serio, se está explotando y afecta a la mayoría de webs. La buena noticia es que la solución suele ser sencilla: comprobar tu versión de PHP, actualizarla a una versión corregida, desactivar el progreso de subida de archivos y revisar que nadie haya entrado.

Lo que no puedes hacer es dar por hecho que estás protegido porque tienes WordPress actualizado o un plugin de seguridad. Aquí el problema está un nivel por debajo.

👉 Consejo final: dedica hoy cinco minutos a mirar la versión de PHP de tu web. Si no sabes dónde mirarlo, no tienes claro qué te dice tu hosting o tu web lleva años sin revisarse, apóyate en un profesional antes de que el problema lo encuentre otro por ti.

Fuentes oficiales: php.net (avisos de seguridad y descargas) · CERT-EU, aviso 2026-018. Información actualizada a 7 de noviembre de 2026.