Vulnerabilidad PHP en WordPress: comprobar y corregir tu sitio

Entender qué es una vulnerabilidad PHP en WordPress

El término abarca tres realidades distintas, que no se corrigen del mismo modo.

Tres familias de vulnerabilidades, tres responsables

La primera familia afecta a la versión de PHP instalada en el servidor. Cada rama de PHP recibe parches de seguridad durante un tiempo limitado; pasado ese plazo, las vulnerabilidades descubiertas ya no se corrigen. Un sitio que aún funciona con PHP 7.4 u 8.0 se ejecuta sobre un motor que no recibe parches desde hace años, y el cambio de versión depende del proveedor de hosting o de un simple ajuste en el panel de alojamiento. La segunda familia, con diferencia la más frecuente, afecta al código PHP de los plugins y los temas: una inyección SQL en un formulario, una subida de archivos sin validar, una función accesible sin autenticación. Estas vulnerabilidades se publican cada semana en las bases de datos de vulnerabilidades, con el número de versión corregida, y son explotadas por bots en las horas siguientes. La corrección consiste en actualizar el plugin afectado, o eliminarlo si ya no se mantiene. La tercera familia agrupa los errores de configuración: edición de archivos permitida en la administración, ejecución de PHP posible en la carpeta de medios, visualización de errores activada en producción, permisos de archivos demasiado permisivos. No son fallos, pero convierten una pequeña vulnerabilidad en una toma de control completa. El propio núcleo de WordPress, auditado con regularidad, actualizado automáticamente y rara vez origen de una vulnerabilidad PHP en WordPress explotada, representa una parte marginal de los incidentes reales.

Vulnerabilidad PHP en WordPress: lo que los bots explotan de verdad

Los registros de acceso de un servidor cuentan la misma historia en todas partes: cientos de solicitudes diarias, procedentes de direcciones de todo el mundo, que comprueban la existencia de archivos concretos. /wp-content/plugins/nom-extension/readme.txt para leer el número de versión, y luego una solicitud POST al archivo vulnerable si la versión coincide. El bot no sabe nada de tu sitio; recorre una lista de millones de dominios con una lista de vulnerabilidades conocidas, y solo se detiene donde hay respuesta. Los objetivos preferidos son los plugins instalados en millones de sitios: constructores de páginas, formularios de contacto, galerías, herramientas de copia de seguridad, plugins de comercio electrónico. Una sola vulnerabilidad en uno de ellos abre cientos de miles de sitios de golpe, y las explotaciones masivas suelen empezar el mismo día en que se publica el parche, porque la comparación entre la versión corregida y la anterior revela exactamente dónde golpear. El plazo entre la publicación de una vulnerabilidad y su primera explotación automatizada ya se mide en horas. Un sitio actualizado una vez al mes queda expuesto, de media, dos semanas por vulnerabilidad, y eso es más que suficiente. Es ese desfase, y no una vulnerabilidad PHP en WordPress especialmente ingeniosa, lo que explica la mayoría de los sitios comprometidos.

Saber si una vulnerabilidad PHP en WordPress expone tu sitio

Tres comprobaciones, diez minutos, sin conocimientos de desarrollo.

Comprobar la versión de PHP y su soporte

En la administración de WordPress, el menú Herramientas y luego Salud del sitio muestra la versión de PHP utilizada e indica si está obsoleta. La misma información se encuentra en el panel del hosting, normalmente en una sección “Configuración de PHP” o “Selector de versión”. La tabla de abajo resume el estado de las ramas habituales. Una rama al final de su vida útil no es necesariamente explotable de inmediato, pero cada nueva vulnerabilidad descubierta en PHP quedará abierta para siempre. El cambio a una rama con soporte se hace con un clic en el panel de alojamiento y, en la gran mayoría de los casos, un sitio WordPress actualizado funciona sin cambios en PHP 8.2 u 8.3. Las excepciones son los temas y plugins antiguos, que usan funciones eliminadas; se detectan probando el cambio de versión en una copia del sitio o consultando la compatibilidad indicada en su página oficial. Si un plugin impide pasar a una versión de PHP con soporte, el que debe irse es el plugin, no la actualización.

Detectar plugins vulnerables o abandonados

La lista de plugins instalados, con su versión, es la segunda comprobación. Para cada uno, tres preguntas. ¿La versión instalada es la última? Ir con varias versiones de retraso en un plugin popular casi siempre significa que hay una vulnerabilidad conocida abierta. ¿El plugin sigue mantenido? En su página oficial, un aviso como “no se ha probado con las tres últimas versiones principales de WordPress” o una última actualización de hace más de dos años indica abandono; las vulnerabilidades descubiertas nunca se corregirán. ¿El plugin sigue siendo necesario? Un plugin desactivado sigue estando en el disco y su código sigue siendo accesible directamente por URL, por lo que es explotable. Las bases de datos públicas de vulnerabilidades, como las de Patchstack o Wordfence, permiten buscar el nombre de un plugin y ver las vulnerabilidades conocidas con la versión corregida. Para un sitio único, este control lleva un cuarto de hora al mes. Para una agencia que gestiona treinta sitios, es media jornada, lo que explica por qué nunca se hace a mano y por qué las herramientas de gestión de parque comparan automáticamente cada versión instalada con la lista de vulnerabilidades publicadas y señalan cada mañana los sitios afectados.

Controlar los ajustes que lo empeoran todo

La tercera comprobación se centra en la configuración. Estos ajustes no son vulnerabilidades propiamente dichas, pero determinan lo que un atacante puede hacer una vez que encuentra una pequeña brecha. Estos son los puntos a revisar, por orden de importancia.

• Ejecución de PHP en wp-content/uploads: si es posible, cualquier formulario de subida vulnerable se convierte en una toma de control completa. Un archivo .htaccess de tres líneas en esa carpeta lo impide.
• Editor de archivos en la administración: una cuenta de administrador robada permite entonces escribir PHP directamente. La constante DISALLOW_FILE_EDIT lo desactiva.
• Visualización de errores: en producción, WP_DEBUG debe estar en false, si no, los mensajes revelan rutas y consultas.
• Permisos de archivos: 644 para archivos, 755 para carpetas, y nunca 777; wp-config.php puede bajar a 600.
• XML-RPC: desactívalo si no se usa; es un canal de ataque por fuerza bruta y de amplificación.
• Prefijo de tablas y nombre de la cuenta: una cuenta “admin” y el prefijo wp_ por defecto facilitan los ataques automatizados.

Cada uno de estos ajustes se comprueba en un minuto y se corrige en cinco. En conjunto, convierten una vulnerabilidad menor, que habría permitido leer una tabla, en un incidente sin consecuencias.

Leer los registros para ver quién llama a la puerta

Los registros de acceso del servidor, disponibles en el panel de alojamiento o en la carpeta logs, muestran en pocos minutos lo que las comprobaciones anteriores no dicen: si alguien ya lo ha intentado, y por dónde. Filtra las solicitudes POST de los últimos siete días y luego localiza las que apuntan a archivos de plugins en lugar de a páginas normales: admin-ajax.php con una acción desconocida, un archivo en wp-content/plugins llamado directamente, xmlrpc.php por cientos, wp-login.php desde decenas de direcciones distintas. Los códigos de respuesta completan el panorama: una serie de 404 indica un bot que busca un plugin que no tienes; un 200 en un archivo de plugin llamado directamente indica que lo ha encontrado. Anota las direcciones y las fechas; si una solicitud sospechosa coincide con un archivo modificado o una cuenta creada, la vulnerabilidad PHP en WordPress se ha explotado y la limpieza es prioritaria frente a todo lo demás. Esta lectura no tiene por qué ser diaria para un sitio aislado; basta con un control mensual, pero se vuelve valiosa el día que aparece un síntoma, porque fecha el incidente y señala la puerta de entrada. Para un parque de sitios, debe automatizarse: una herramienta que cuente los intentos por sitio y por día detecta las anomalías antes de que se conviertan en incidentes.

Cerrar las puertas y mantenerlas cerradas

Corregir una vez no sirve de nada si no hay rutina: cada semana se publican nuevas vulnerabilidades.

Vulnerabilidad PHP en WordPress: la rutina de actualización que funciona

La medida más eficaz también es la más simple: actualizar cada semana, y automáticamente cuando sea posible. WordPress ofrece actualizaciones automáticas para el núcleo, los plugins y los temas, que se activan plugin por plugin. El freno habitual es el miedo a romper el sitio. Se gestiona con tres precauciones: una copia de seguridad automática antes de cada actualización, una prueba rápida de la página de inicio y de un formulario después, y un rollback inmediato si algo ha cambiado. Las actualizaciones de seguridad de los plugins son menores en la inmensa mayoría de los casos y no cambian nada visible; son los cambios de versión mayor, anunciados como tales, los que merecen una prueba en una copia. Más allá de actualizar, mantén un inventario: qué está instalado, por qué y desde cuándo. Todo lo que ya no tiene razón de ser se elimina, no solo se desactiva. Por último, suscríbete a las alertas de una base de datos de vulnerabilidades para los plugins que usas, o utiliza una herramienta que lo haga por ti. Una vulnerabilidad PHP en WordPress publicada un martes se explota el martes por la noche; la actualización del viernes llega tarde, la del martes al mediodía llega a tiempo.

Vulnerabilidad PHP en WordPress: qué hacer cuando no existe parche

A veces se publica una vulnerabilidad para un plugin abandonado, o el parche se retrasa varios días. Tres opciones, de la más limpia a la más temporal. La primera es sustituirlo: casi cualquier plugin tiene un equivalente mantenido, y migrar un formulario o una galería lleva una hora. La segunda es desactivarlo y eliminarlo de inmediato, aceptando perder la función mientras encuentras un sustituto; una galería ausente sale más barata que un sitio comprometido. La tercera es el parche virtual, ofrecido por algunos firewalls de aplicaciones y por servicios como Patchstack: una regla que bloquea la solicitud maliciosa antes de que llegue al código vulnerable, sin modificar el plugin. Gana tiempo, pero no sustituye la corrección real. En todos los casos, después de corregir, comprueba que la vulnerabilidad PHP en WordPress no se haya explotado ya: archivos PHP recientes en uploads, administradores desconocidos, modificaciones de wp-config.php y de .htaccess. Los bots pasan antes que los parches, y un sitio corregido pero ya comprometido sigue comprometido. Para un parque de sitios, este control diario es la única forma de dormir tranquilo: cada mañana señala los sitios en los que un plugin presenta una vulnerabilidad publicada, con la versión objetivo, y aquellos en los que un archivo ha cambiado sin motivo.

Preguntas frecuentes

¿Actualizar PHP puede romper mi sitio? Rara vez, si WordPress, el tema y los plugins están al día. Prueba en una copia y vuelve atrás desde el panel de alojamiento si aparece una página de error.

¿Un plugin desactivado sigue siendo peligroso? Sí. Su código sigue en el disco y es accesible directamente. Elimínalo.

¿Cómo saber si ya se ha explotado una vulnerabilidad? Busca archivos PHP recientes, administradores desconocidos y modificaciones de wp-config.php. Un escaneo externo complementa, sin sustituir, esta comprobación.

¿Basta con un firewall? No. Bloquea ataques conocidos, no los publicados ayer. La actualización sigue siendo la primera protección.