Seguridad de WordPress: Por qué las actualizaciones y la protección son cruciales

#Qué corrigió WordPress 7.1.3 y por qué importa la fecha

WordPress 7.1.3 salió el 6 de octubre de 2026 con 7 correcciones de seguridad y 4 de errores. La nota de la versión enumera las clases de fallo:

• XSS almacenado en la pantalla de administración de comentarios, activado a través de comentarios pendientes
• un problema de denegación de servicio en WP_Http::make_absolute_url()
• una inyección SQL de segundo orden en la exportación WXR
• una debilidad que permitía a usuarios con rol Autor fijar entradas como destacadas
• divulgación sin autenticar de comentarios de entradas privadas y no publicadas
• XSS en los embeds de Imgur
• parámetros falsificables en el hook {status}_{type}, que provocaban una colisión de nombres de acción

Los créditos nombran a Thomas Chauchefoin de Trail of Bits, Ananda Dhakal de Patchstack y otros. Anthropic figura como autor de tres de los hallazgos: la denegación de servicio, la inyección SQL y la debilidad de las entradas destacadas.

Tres semanas antes, WordPress 7.1.1 (17 de septiembre de 2026) incluyó 11 correcciones de seguridad, entre ellas un XSS almacenado en wpautop(), un path traversal autenticado en el controlador de plantillas de la REST API y la sobrescritura arbitraria de entradas por parte de Colaboradores.

Léelo tal como es: casi todos son fallos que necesitan un rol con sesión iniciada, un comentario pendiente o una función concreta. Ninguno es “todo internet es dueño de tu sitio esta noche”. Justo por eso se aplazan. El argumento para parchear rápido no es el dramatismo, es aritmética. Una corrección es pública en cuanto sale, y con ella su diff. El hueco entre el día de la versión y el día de tu actualización es la ventana en la que un fallo conocido vive en tu sitio. El propio núcleo declara que “solo la versión más reciente de WordPress recibe soporte activo”, y las correcciones de seguridad se retroportan cuando hace falta a ramas anteriores (hoy hasta la 4.7).

#Cómo gestiona el equipo de seguridad de WordPress las vulnerabilidades del núcleo

Según wordpress.org/about/security, el equipo de seguridad de WordPress lo forman más de 50 expertos de confianza, entre ellos desarrolladores principales e investigadores de seguridad. El equipo desarrolla y prueba las correcciones y las publica en versiones de corrección de errores. La página describe también la colaboración con grandes proveedores de hosting y empresas de seguridad en el despliegue y en reglas de WAF que frenan los ataques antes de que todos hayan actualizado.

De ahí salen dos consecuencias para el mantenimiento. En el núcleo, la corrección llega de una fuente coordinada y la actualización automática en segundo plano es el canal de entrega. Si está activada, la mayor parte del trabajo en el núcleo está hecha. En plugins y temas es distinto: las vulnerabilidades se comunican al autor y al equipo de plugins o de temas, y la rapidez de la corrección depende de una sola persona. Por eso la mayor parte de tu trabajo de actualización está en la lista de plugins, no en el núcleo.

#Cómo funcionan las actualizaciones automáticas del núcleo de WordPress

La nota de 7.1.3 indica que los sitios con actualizaciones automáticas en segundo plano inician la actualización por sí mismos. La documentación de actualización describe el control: la constante WP_AUTO_UPDATE_CORE acepta true (versiones de desarrollo, menores y mayores), false (ninguna) o 'minor' (solo menores). Antes de WordPress 5.6, todos los sitios recibían por defecto las actualizaciones automáticas de versiones menores del núcleo y de archivos de traducción; las instalaciones nuevas desde la 5.6 reciben también las mayores, salvo que WordPress detecte un repositorio de control de versiones.

Revisa tres cosas en cada sitio que gestiones:

1. La constante no está en false en wp-config.php, dejada por un desarrollador que quiso congelar una versión hace años.
2. El sitio no es una copia de trabajo con control de versiones que se excluye en silencio.
3. El hosting entrega de verdad la actualización. Ejecuta wp core version en el servidor un día después de una versión y compáralo con el de la nota.

#Se actualizan solos los plugins y temas de WordPress

Por defecto, dice la documentación, las actualizaciones en segundo plano de plugins y temas ocurren solo en casos especiales, “según determine la respuesta de la API de WordPress.org, controlada por el equipo de seguridad de WordPress”. Desde WordPress 5.5 puedes activar o desactivar las actualizaciones automáticas de cada plugin y tema en las pantallas de siempre. Activarlas para todo no es una estrategia. Actívalas en plugins de superficie pequeña y buen historial de versiones, y mantén los de pago, formularios y membresías en un camino por fases.

El directorio de plugins tiene su propia válvula de seguridad. Las vulnerabilidades se comunican al equipo de plugins, que intenta contactar con el desarrollador, y según la guía de seguridad de plugins “la mayoría de los plugins se cierran para evitar nuevas descargas hasta que se resuelva el problema”. El cierre bloquea instalaciones nuevas. No entra en tu sitio, así que un plugin cerrado que instalaste el año pasado sigue funcionando. Una vez por trimestre, compara tus plugins activos con lo que el directorio aún lista y sustituye los cerrados o abandonados. La misma disciplina vale para los ataques a la cadena de suministro, donde un plugin de confianza cambia de manos y la siguiente actualización es el ataque.

#Cómo actualizar WordPress de forma segura en producción

Si una actualización merece el riesgo depende de si puedes deshacerla. La rutina que funciona:

1. Haz una copia de seguridad que hayas restaurado al menos una vez. Una copia sin probar es una esperanza.
2. Aplica las actualizaciones en staging y recorre las rutas que generan ingresos o recogen datos: pedido, formularios de contacto, acceso, búsqueda.
3. Actualiza producción en una franja de poco tráfico y repite el mismo recorrido.
4. Mira el log de errores de PHP en busca de avisos nuevos, porque un plugin puede romperse sin ruido.
5. Conoce la vuelta atrás antes de empezar. Si sale mal, la guía sobre cómo restaurar una versión anterior tras una actualización fallida lo explica paso a paso.

Dos comandos de WP-CLI hacen casi todo el inventario. wp plugin list --update=available muestra lo pendiente y wp core check-update el estado del núcleo. Las versiones de seguridad van primero y el resto sigue cada semana. Un plan de mantenimiento es sobre todo alguien haciendo exactamente esto, con calendario, y dejándolo por escrito.

Con un hosting que ofrece staging en un clic, la barrera es baja. En un VPS propio, usa wp-cli o un pipeline de despliegue y mantén el staging detrás de autenticación HTTP o una VPN. Un clon abierto de producción con datos reales de clientes ya es, por sí solo, un problema de protección de datos.

Evita también un «staging» que no es más que una subcarpeta sobre la misma base de datos. Tablas compartidas y cookies compartidas dan una falsa sensación de seguridad. Un staging de verdad tiene su propia base de datos y su propia URL.

#Cómo revierte WordPress una actualización de plugin fallida

Desde WordPress 6.3, el núcleo incluye una reversión para actualizaciones manuales de plugins y temas. Según la nota de desarrollo de 6.3, la versión instalada se mueve a wp-content/upgrade-temp-backup/plugins/ o wp-content/upgrade-temp-backup/themes/ antes de actualizar. Si la instalación falla, vuelve a su sitio. Si sale bien, la copia se borra. Salud del sitio incorporó a la vez dos comprobaciones: si la carpeta de copia tiene permisos de escritura y si hay espacio en disco suficiente para actualizar con seguridad.

El límite está en la misma nota. «Fallar» significa que la propia instalación devuelve un error, por ejemplo un paquete vacío o archivos que no se pueden mover. Una actualización que se instala bien pero rompe el checkout cuenta como correcta, y la versión antigua ya está borrada.

WordPress 6.6 fue más lejos con las actualizaciones automáticas de plugins. La propuesta de integración describe el proceso: durante las actualizaciones automáticas el sitio entra en modo mantenimiento, WordPress envía una petición loopback a la portada para detectar errores fatales de PHP y, si devuelve un error, restaura la versión anterior del plugin y envía un correo a la dirección de admin_email. La convocatoria de pruebas de 6.6 confirma que es el comportamiento por defecto desde 6.6.

El mecanismo detecta lo evidente: un error fatal que tumba la portada. No detecta un fallo que solo aparece en el checkout, en un formulario o en una tarea cron, y la propuesta solo habla de plugins, no de temas. La reversión integrada no sustituye ni al staging ni a una copia de seguridad que hayas restaurado al menos una vez.

#Cómo controlar las actualizaciones automáticas desde el código

La documentación de actualización describe más interruptores que WP_AUTO_UPDATE_CORE. Son útiles cuando un equipo mantiene muchos sitios con las mismas reglas:

• AUTOMATIC_UPDATER_DISABLED en wp-config.php desactiva todas las actualizaciones automáticas, del núcleo y de todo lo demás. La documentación lo desaconseja con firmeza. Si encuentras esta constante en un sitio, averigua quién la puso y por qué.
• Los filtros auto_update_plugin y auto_update_theme reciben el elemento que se va a actualizar, así que puedes comprobar $item->slug y activar la actualización automática solo para plugins elegidos. Si el filtro devuelve false para todo, bloquea también las actualizaciones de seguridad que WordPress.org envía en casos especiales.
• auto_update_translation controla los archivos de traducción, que se actualizan solos por defecto.
• auto_core_update_send_email controla los correos sobre actualizaciones del núcleo. El filtro recibe el tipo (success, fail o critical), de modo que puedes silenciar los avisos de éxito y conservar los de error.
• automatic_updates_is_vcs_checkout decide si una carpeta .git, .hg o .svn en el directorio de WordPress o en uno superior detiene las actualizaciones automáticas.

La documentación indica que estos filtros van en un plugin must-use y no en wp-config.php, porque ahí WordPress aún no está cargado del todo y pueden surgir conflictos, entre otros con WP-CLI. Un pequeño mu-plugin en el control de versiones deja además las reglas a la vista del siguiente desarrollador que herede el sitio.

#Cómo proteger plugins propios de una actualización equivocada

Un plugin a medida con el mismo slug que un plugin del directorio de WordPress.org podía quedar sobrescrito cuando la versión del directorio recibía una actualización. La nota de desarrollo de WordPress 5.8 introdujo la cabecera de plugin Update URI para evitarlo: si el valor apunta a algo distinto de WordPress.org, WordPress no intenta actualizar el plugin desde allí. Update URI: false detiene las actualizaciones por completo, y el filtro update_plugins_{$hostname} permite que un servidor de actualizaciones propio entregue nuevas versiones. Añade la cabecera a todos los plugins internos. Lleva un minuto y elimina toda una clase de accidentes en los que código ajeno llega a producción por el botón de actualizar.

#Cómo reforzar WordPress mientras el parche está pendiente

Ninguna rutina es instantánea. El refuerzo decide qué puede hacer un atacante mientras tanto.

• Sin editor de archivos. define('DISALLOW_FILE_EDIT', true); en wp-config.php quita el editor de temas y plugins del escritorio, de modo que una sesión de administrador robada no pueda escribir PHP desde el navegador.
• Sin PHP en uploads. Bloquea la ejecución en wp-content/uploads en el servidor web. Un fallo de subida acaba entonces en un archivo almacenado, no en una shell.
• Permisos ajustados. wp-config.php legible solo por el usuario del sitio y ningún directorio con escritura para todos.
• Pocos administradores. Varias correcciones de la serie 7.1.x dependen de un rol. Menos cuentas con privilegios significa menos caminos explotables. Da a los redactores el rol Editor, no Administrador.
• Acceso fuerte. Passkeys o 2FA para toda cuenta que pueda publicar o instalar.
• XML-RPC apagado si no se usa. add_filter('xmlrpc_enabled', '__return_false'); si ninguna app ni conexión de Jetpack lo necesita.

La lista completa, con ejemplos de servidor, está en la guía de refuerzo de WordPress.

#De qué protege un WAF a WordPress

Los cortafuegos de aplicaciones web (Cloudflare, Sucuri, el WAF del hosting o el parcheo virtual por plugin de proveedores como Patchstack) son útiles. No sustituyen a las actualizaciones.

Un WAF funciona bien para:

• limitar la tasa de peticiones contra la fuerza bruta en el login,
• bloquear firmas de exploits conocidas y user agents maliciosos,
• el parcheo virtual: bloquear temporalmente un patrón de ataque conocido mientras pruebas la actualización en staging,
• filtrar por país o ASN cuando aparecen patrones de escaneo evidentes.

Un WAF es débil o ciego ante:

• errores de lógica en un plugin propio («si ?token= coincide, da admin»),
• sesiones legítimas de administrador comprometidas (una cookie robada tras un phishing),
• permisos de archivo erróneos que dejan ejecutar un PHP subido,
• puertas traseras que ya están en wp-content/uploads desde una intrusión anterior,
• problemas de cadena de suministro en los que el propio plugin actualizado está comprometido (más raros, pero documentados en el ecosistema).

Por eso el orden es siempre el mismo: primero actualizar y endurecer, y el WAF como capa extra y como margen durante la ventana del parche. Poner Cloudflare delante y dar el trabajo por terminado es un error frecuente, sobre todo cuando el DNS está bien pero el servidor de origen sigue sirviendo wp-admin directamente por su IP.

#Por qué la versión de PHP forma parte de la rutina de actualización

Las actualizaciones de WordPress sirven de poco si el PHP que hay debajo ya no recibe correcciones de seguridad. La página de requisitos de wordpress.org recomienda PHP 8.3 o superior, MySQL 8.0 o superior o MariaDB 10.11 o superior, y HTTPS. También dice que WordPress funciona con PHP 7.4 y MySQL 5.5.5, pero que esas versiones han llegado al final de su vida y pueden exponer el sitio a vulnerabilidades.

La tabla de php.net muestra que, en octubre de 2026, PHP 8.2 solo recibe correcciones de seguridad y que terminan el 31 de diciembre de 2026. PHP 8.3 recibe correcciones de seguridad hasta el 31 de diciembre de 2027, y 8.4 y 8.5 siguen con soporte activo. Las ramas anteriores a 8.2 no reciben ninguna corrección. Comprueba la versión en Herramientas, Salud del sitio, pestaña Información, o con php -v en el servidor, y planifica el cambio en staging como una actualización mayor de WordPress. Un plugin antiguo que no soporta un PHP más reciente es un motivo para sustituir el plugin, no para quedarse en una rama de PHP sin correcciones.

#Qué exige el RGPD cuando se vulnera un sitio

El artículo 32 del RGPD exige “medidas técnicas y organizativas apropiadas” para proteger los datos personales. El artículo 33 exige notificar a la autoridad de control “sin dilación indebida y, de ser posible, a más tardar 72 horas” después de tener constancia de una brecha, salvo que sea improbable que suponga un riesgo para los derechos y libertades de las personas. Las infracciones de las obligaciones de los artículos 25 a 39 entran en el nivel inferior de multas del artículo 83, apartado 4: hasta 10 millones de euros o el 2 por ciento del volumen de negocio mundial anual, la cuantía que sea mayor.

En España la autoridad de control es la AEPD, que publica una Guía para la notificación de brechas de datos personales con las directrices generales de cuándo y cómo notificar.

El reglamento no dice “instala las actualizaciones”. Pero una tienda que recoge datos de clientes y mantuvo semanas un plugin con corrección publicada tendrá difícil defender esa medida. Guarda registros que muestren lo contrario: fechas de actualización, la prueba en staging, el plan de vuelta atrás. La misma evidencia ayuda en tu auditoría de cumplimiento UE.

#Cómo detectar una intrusión que el navegador no muestra

El spam SEO inyectado está hecho para que el propietario no lo note. Las páginas se muestran a Googlebot, no a los visitantes, así que una portada limpia no demuestra nada. Estas comprobaciones sí:

• wp core verify-checksums y wp plugin verify-checksums --all comparan los archivos con las versiones oficiales y señalan cambios.
• Busca archivos PHP más recientes que wp-config.php, empezando por el directorio del tema.
• wp user list --role=administrator debe mostrar solo personas que reconoces.
• Un cambio de archivo que nadie del equipo sabe explicar es un incidente, no una curiosidad. Pasa directamente a la contención.

Si quieres que las comprobaciones las haga alguien que no es dueño del sitio, una auditoría de seguridad de WordPress cubre componentes desactualizados, usuarios expuestos y configuración del servidor en una sola pasada.

#Errores de seguridad WordPress frecuentes en las empresas

Algunos patrones se repiten en pequeñas empresas y clientes de agencias:

Pasarela de pago y reservas sin responsable. Redsys, Bizum, Stripe, Easy Digital Downloads, Bookly o Amelia se actualizan «cuando hay tiempo». El plugin de pago es justo el lugar que buscan los atacantes, porque el beneficio es directo. Nombra un responsable que siga los avisos de seguridad de esos slugs concretos.

Datos de producción en staging sin anonimizar. Copias de listas de clientes, historial de pedidos y suscripciones en una URL de staging abierta son un problema de protección de datos antes de que nadie entre. Enmascara los datos o restringe el acceso. A la AEPD le importa la seguridad del tratamiento, no que el entorno se llame «dev».

Agencia y cliente sin responsabilidades claras. El cliente cree que la agencia aplica los parches. La agencia cree que el cliente hace clic en wp-admin. Déjalo por escrito: quién vigila las actualizaciones, quién aprueba el paso de staging a producción, quién tiene 2FA en el panel del hosting. Sin esa frase, el parche se queda para después del Black Friday o de la campaña de Navidad, justo cuando menos tiempo hay para apagar fuegos.

Un «plugin de seguridad» en lugar de hardening. Un plugin que escanea archivos es útil como señal. No sustituye a los permisos de archivo, a las actualizaciones ni al bloqueo de install.php tras la instalación. Repasa los puntos del hardening del manual para desarrolladores antes de comprar otra licencia.

Correo y claves SMTP. Un plugin SMTP comprometido o una clave de SendGrid o Mailgun filtrada sirven para hacer phishing en nombre de tu empresa. Rota las claves cuando alguien se va y limita los permisos de la API.

#Qué revisar esta semana en tus sitios WordPress

Confirma que 7.1.3 está instalada en todos tus sitios. Lista los plugins con actualizaciones pendientes y ordénalos por lo que cada uno puede alcanzar. Elimina lo abandonado. Cuenta las cuentas de administrador y recórtalas. Después pon la próxima revisión en el calendario, porque la siguiente versión de seguridad no esperará a tu siguiente idea.