WordPress impulsa aproximadamente el 40% de todos los sitios web en internet, y cada uno de ellos funciona con PHP. Esa popularidad es exactamente lo que convierte a WordPress en un objetivo tan atractivo. Un atacante que encuentra una debilidad en PHP, en el núcleo de WordPress o en un plugin popular no obtiene acceso a un solo sitio web: obtiene una llave que potencialmente abre millones de ellos.

Ese riesgo se volvió muy real en octubre de 2026, cuando el proyecto PHP publicó parches de emergencia para dos fallas críticas apodadas PHP2Shell. Estos errores están en PHP mismo, no en WordPress, lo que significa que mantener WordPress y tus plugins actualizados no era suficiente para protegerte. La solución tenía que aplicarse una capa más abajo.

Esta guía explica cómo funcionan realmente las vulnerabilidades de PHP, repasa los tipos más comunes que afectan a los sitios de WordPress, explica qué significa PHP2Shell para los dueños de sitios y te da una lista práctica para proteger tu sitio web.

Por Qué los Sitios de WordPress Son un Objetivo Favorito

Los atacantes rara vez eligen un sitio de WordPress porque te pertenece a ti específicamente. La mayoría de los ataques son automatizados: bots escanean internet las 24 horas buscando sitios que ejecuten una versión con vulnerabilidades conocidas y luego atacan cada coincidencia que encuentran. El sitio web de una pequeña panadería y el de una gran tienda en línea se ven iguales para un escáner.

Algunas cosas hacen que WordPress sea especialmente atractivo para esos bots:

  • Su enorme escala. Un solo exploit que funcione puede reutilizarse contra una gran cantidad de sitios.
  • Un gran ecosistema de plugins. Existen decenas de miles de plugins de WordPress, escritos por desarrolladores con niveles muy distintos de experiencia en seguridad. La mayoría de los sitios de WordPress comprometidos empiezan con un plugin o tema vulnerable.
  • Sitios que se crean y se olvidan. Muchos sitios de pequeñas empresas se construyen una vez y nunca se vuelven a actualizar, lo que deja vulnerabilidades conocidas abiertas durante años.
  • Hosting compartido. En un hosting compartido económico, muchas veces no controlas la versión de PHP: la controla tu proveedor.

Las Capas de un Sitio de WordPress

Para entender de dónde vienen las vulnerabilidades, ayuda imaginar un sitio de WordPress como una pila de capas, donde cada una depende de la capa que tiene debajo:

  1. El servidor y el sistema operativo: normalmente Linux, administrado por ti o por tu proveedor de hosting.
  2. El servidor web: Apache, Nginx o LiteSpeed, que recibe las solicitudes de los visitantes.
  3. El entorno de ejecución de PHP: el intérprete que realmente ejecuta el código PHP (mediante PHP-FPM, mod_php de Apache o algo similar).
  4. El núcleo de WordPress: el software de WordPress en sí.
  5. Plugins y temas: el código adicional que agregaste encima.

Una vulnerabilidad en cualquier capa puede comprometer todo lo que está por encima. Actualizar WordPress desde tu panel solo actualiza las capas 4 y 5. Si el agujero está en la capa 3, el entorno de ejecución de PHP, hacer clic en “Actualizar” en WordPress no hace nada para solucionarlo.

Cómo Funcionan las Vulnerabilidades de PHP

En el fondo, casi todas las vulnerabilidades web se reducen al mismo error: la aplicación confía en datos en los que no debería confiar. Cada campo de formulario, parámetro de URL, cookie, archivo subido y encabezado HTTP está controlado por quien envía la solicitud, incluidos los atacantes. Cuando el código trata esos datos como seguros, un atacante puede hacer que el código haga algo que su autor nunca pretendió.

Estas son las formas más comunes en que esto ocurre en PHP y WordPress.

Inyección SQL

La inyección SQL ocurre cuando los datos del usuario se insertan directamente en una consulta a la base de datos. Este código vulnerable toma un ID de la URL y lo coloca directamente en SQL:

// Vulnerable: los datos del usuario van directo a la consulta
$id = $_GET['id'];
$results = $wpdb->get_results("SELECT * FROM wp_orders WHERE id = $id");

Un atacante puede cambiar el parámetro id para reescribir la consulta y leer datos que no debería ver. En WordPress, la solución es usar $wpdb->prepare(), que mantiene los datos separados de la consulta:

// Seguro: el valor se pasa como parámetro, nunca como SQL
$results = $wpdb->get_results(
    $wpdb->prepare("SELECT * FROM wp_orders WHERE id = %d", $_GET['id'])
);

Explico este ataque a fondo en Inyección SQL: Cómo Funciona y Cómo Prevenirla.

Cross-Site Scripting (XSS)

El cross-site scripting ocurre cuando un sitio muestra en la página datos del usuario sin escaparlos. Si un plugin muestra un término de búsqueda así:

// Vulnerable: imprime los datos sin procesar en la página
echo "Buscaste: " . $_GET['s'];

un atacante puede crear un enlace que inyecta JavaScript en la página. Cuando un administrador con la sesión iniciada hace clic en él, ese script se ejecuta con sus permisos y puede crear silenciosamente una nueva cuenta de administrador para el atacante. WordPress ofrece funciones de escape exactamente por esta razón:

// Seguro: los caracteres especiales se escapan antes de mostrarse
echo "Buscaste: " . esc_html($_GET['s']);

Subida de Archivos sin Restricciones

Muchos plugins permiten a los usuarios subir imágenes, currículums u otros archivos. Si un plugin no verifica qué se está subiendo realmente, un atacante puede subir un archivo PHP en lugar de una imagen. Una vez que ese archivo está en una carpeta pública como wp-content/uploads/, el atacante simplemente visita su URL y el servidor lo ejecuta. Ese archivo subido, conocido a menudo como web shell, le da al atacante control total del sitio.

Inclusión de Archivos

Los errores de inclusión de archivos ocurren cuando el código PHP construye la ruta de un archivo a partir de datos del usuario:

// Vulnerable: el visitante elige qué archivo se carga
include($_GET['page'] . '.php');

Un atacante puede manipular la ruta para cargar archivos que el desarrollador nunca pretendió, como archivos de configuración del servidor o código que el atacante logró colocar en el servidor.

Inyección de Objetos PHP

La función unserialize() de PHP reconstruye objetos a partir de texto. Si alguna vez se usa con datos que controla un visitante, un atacante puede crear datos que generen objetos inesperados y activen código que ya existe en WordPress o en sus plugins. Es un error más sutil, pero aparece con frecuencia en los avisos de seguridad de plugins y puede llevar a la ejecución remota de código.

Corrupción de Memoria en PHP Mismo

Todas las vulnerabilidades anteriores están en el código PHP: WordPress, un plugin o un tema. La categoría más rara y peligrosa está en el intérprete de PHP, que está escrito en C. Errores como desbordamientos de búfer (buffer overflows) y de uso después de liberar memoria (use-after-free) permiten a un atacante corromper la memoria del intérprete con una solicitud cuidadosamente diseñada y, en el peor de los casos, ejecutar su propio código en el servidor.

Estos errores son peligrosos por dos razones. Primero, afectan a todas las aplicaciones PHP del servidor a la vez, sin importar qué tan cuidadosamente se haya escrito cada aplicación. Segundo, pueden activarse mientras PHP todavía está leyendo la solicitud, antes de que WordPress siquiera cargue, así que las páginas de inicio de sesión, los plugins de seguridad y otras protecciones de la aplicación nunca tienen la oportunidad de detenerlos.

Eso es exactamente lo que pasó con PHP2Shell.

PHP2Shell: Las Vulnerabilidades de PHP de Octubre de 2026

El 21 de octubre de 2026, el proyecto PHP publicó correcciones de emergencia para dos vulnerabilidades críticas, CVE-2026-109618 y CVE-2026-109619, conocidas en conjunto como PHP2Shell. La publicación se adelantó un día después de que los detalles de las fallas se filtraran antes de la divulgación planeada.

Esto es lo que los dueños de sitios necesitan saber:

  • Ambas fallas tienen una calificación de 9.2 sobre 10 (CVSS v4.0) y pueden permitir que un atacante sin cuenta ejecute código en el servidor web.
  • Están en el entorno de ejecución de PHP, no en WordPress. Cualquier instalación de PHP que atienda solicitudes web está expuesta, ya sea que funcione con mod_php de Apache, PHP-FPM, php-cgi, FrankenPHP o LiteSpeed. El riesgo es mayor en configuraciones con mod_php.
  • Casi todas las versiones de PHP están afectadas, hasta PHP 5.4.
  • Las versiones corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. PHP 8.1 y anteriores ya no reciben soporte del proyecto PHP, aunque se publicaron parches mínimos de código fuente para 7.4, 8.0 y 8.1.
  • Los atacantes actuaron rápido. Investigadores de seguridad reportaron intentos de explotación y escaneos masivos en internet alrededor del momento de la divulgación, y algunos reportes de intentos días antes de que el parche fuera público.

Una de las fallas es un error de corrupción de memoria en la forma en que PHP maneja quedarse sin memoria mientras procesa una solicitud. La otra es un error de uso después de liberar memoria relacionado con un estado que se conserva entre solicitudes atendidas por el mismo proceso de PHP. No necesitas entender los detalles internos para protegerte: lo importante es que la única solución completa es actualizar PHP.

Cómo Revisar tu Versión de PHP

Antes de poder arreglar algo, necesitas saber qué estás ejecutando. Hay algunas formas sencillas de revisarlo.

Desde el panel de WordPress: ve a Herramientas → Salud del sitio → Información y despliega la sección Servidor. Ahí aparece tu versión de PHP.

Desde el panel de control de tu hosting: la mayoría de los proveedores (cPanel, Plesk y paneles propios) muestran la versión de PHP y te permiten cambiarla en una sección llamada algo como “Configuración de PHP” o “Seleccionar versión de PHP”.

Desde la línea de comandos, si administras tu propio servidor por SSH:

php -v

Ten en cuenta que el PHP de la línea de comandos y el PHP que sirve tu sitio web no siempre son la misma instalación, especialmente en servidores con varias versiones instaladas. La pantalla de Salud del sitio de WordPress muestra la versión que realmente sirve tu sitio.

Además, las distribuciones de Linux suelen incorporar correcciones de seguridad sin cambiar el número de versión principal. Si el PHP de tu servidor viene de paquetes de Ubuntu, Debian o Red Hat, revisa el aviso de seguridad de tu distribución buscando los números CVE en lugar de confiar solo en el número de versión.

Cómo Proteger tu Sitio de WordPress

PHP2Shell es un buen recordatorio de que la seguridad no es una sola configuración: es un conjunto de hábitos en cada capa de tu sitio. Aquí tienes una lista práctica, empezando por lo más importante.

1. Mantén PHP Actualizado

Si administras tu propio servidor, actualiza PHP con tu gestor de paquetes y reinicia el servicio de PHP para que la nueva versión realmente se cargue:

sudo apt update && sudo apt upgrade
sudo systemctl restart php8.3-fpm   # ajústalo a tu versión de PHP

Si usas un hosting compartido o administrado, verifica si tu proveedor ya aplicó el parche y, si tu sitio todavía usa PHP 8.1 o una versión anterior, cámbialo a una versión con soporte. La mayoría de los proveedores confiables te permiten cambiar la versión de PHP desde el panel de control con un par de clics. Prueba tu sitio después del cambio, ya que los plugins muy antiguos pueden no ser compatibles con versiones más nuevas de PHP.

2. Mantén Actualizados el Núcleo de WordPress, los Plugins y los Temas

Los plugins siguen siendo la forma más común de entrar a un sitio de WordPress. Activa las actualizaciones automáticas para los plugins en los que confías y revisa tu panel con regularidad. Las actualizaciones suelen incluir correcciones de seguridad documentadas públicamente, lo que significa que los atacantes saben exactamente qué buscar en los sitios que no se han actualizado.

3. Elimina lo que No Usas

Cada plugin y tema instalado es código que puede contener una vulnerabilidad, incluso si está desactivado. Elimina los plugins y temas que no uses, y desconfía de los plugins que no se han actualizado en un año o más.

4. Protege los Inicios de Sesión

  • Usa contraseñas fuertes y únicas para cada cuenta de administrador.
  • Activa la autenticación de dos factores para todos los administradores.
  • Limita los intentos de inicio de sesión para frenar los ataques de fuerza bruta.
  • No uses admin como nombre de usuario, y dale a cada persona su propia cuenta con solo el rol que necesita.

5. Usa un Firewall de Aplicaciones Web

Un firewall de aplicaciones web (WAF) inspecciona las solicitudes entrantes y bloquea patrones de ataque conocidos antes de que lleguen a tu sitio. Servicios como Cloudflare se colocan delante de tu servidor, mientras que plugins de seguridad como Wordfence funcionan dentro de WordPress. Un firewall en el borde de la red es especialmente valioso contra errores del entorno de ejecución como PHP2Shell, porque puede detener una solicitud maliciosa antes de que PHP la procese.

6. Refuerza tu Configuración

Algunos pequeños cambios de configuración hacen una gran diferencia:

  • Desactiva la edición de archivos desde el panel agregando esta línea a wp-config.php, para que un atacante que entre a una cuenta de administrador no pueda editar archivos PHP directamente:

    define('DISALLOW_FILE_EDIT', true);

  • Bloquea la ejecución de PHP en tu carpeta de subidas, para que un web shell subido no pueda ejecutarse. En Apache, agrega un archivo .htaccess dentro de wp-content/uploads/:

    <Files *.php>
    Require all denied
</Files>

  • Configura los permisos de archivos correctamente: normalmente 644 para archivos y 755 para directorios, con wp-config.php aún más restringido.

  • Usa siempre HTTPS.

7. Haz Copias de Seguridad con Regularidad y Pruébalas

Las copias de seguridad son tu última línea de defensa. Si tu sitio llega a ser comprometido, una copia limpia y reciente puede marcar la diferencia entre una recuperación rápida y empezar de cero. Guarda las copias en un lugar distinto a tu servidor web, conserva varias versiones y, de vez en cuando, prueba restaurar una para saber que funciona cuando la necesites.

8. Vigila las Señales de un Ataque

Presta atención a señales como cuentas de administrador desconocidas, archivos nuevos inesperados (especialmente archivos .php en wp-content/uploads/), redirecciones extrañas, páginas de spam que aparecen en los resultados de Google o una lentitud repentina. Un plugin de seguridad con monitoreo de integridad de archivos puede avisarte cuando los archivos del núcleo cambian de forma inesperada.

Qué Hacer si tu Sitio Ya Fue Comprometido

Si sospechas que hackearon tu sitio:

  1. Desconecta el sitio o ponlo en modo de mantenimiento para proteger a tus visitantes.
  2. Cambia todas las contraseñas: administradores de WordPress, cuenta de hosting, base de datos y SFTP/SSH.
  3. Actualiza PHP, WordPress, los plugins y los temas para cerrar el agujero por donde entró el atacante.
  4. Restaura una copia de seguridad limpia de antes del ataque, o haz que un profesional limpie el sitio.
  5. Busca accesos persistentes: los atacantes suelen dejar cuentas de administrador adicionales, tareas programadas o web shells ocultos para poder volver a entrar después.
  6. Contacta a tu proveedor de hosting. Muchos proveedores pueden ayudarte a identificar el punto de entrada y a buscar malware restante.

Conclusión

WordPress en sí no es inseguro, pero se ejecuta sobre una pila de software, y a un atacante le basta con una capa débil para entrar. La mayoría de los ataques todavía llegan por plugins desactualizados y contraseñas débiles, pero PHP2Shell demostró que incluso el entorno de ejecución de PHP debajo de tu sitio necesita atención. Una instalación de WordPress completamente actualizada que funciona sobre una versión de PHP sin parchear sigue siendo un sitio vulnerable.

La buena noticia es que lo básico cubre la mayor parte del riesgo: mantén cada capa actualizada, elimina lo que no usas, protege tus inicios de sesión, coloca un firewall delante de tu sitio y mantén copias de seguridad confiables. Si todavía no has revisado qué versión de PHP usa tu sitio, hoy es un buen día para hacerlo.