Nombre del complemento	addfreespace
Tipo de vulnerabilidad	CSRF
Número CVE	CVE-2026-6701
Urgencia	Bajo
Fecha de publicación de CVE	2026-05-04
URL de origen	CVE-2026-6701

Falsificación de Solicitudes entre Sitios (CSRF) encadenada a Cross‑Site Scripting (XSS) almacenado en addfreespace <= 0.1.3 — Lo que los propietarios de sitios de WordPress deben saber y hacer

Una vulnerabilidad recientemente divulgada que impacta el addfreespace plugin de WordPress (versiones <= 0.1.3) ha sido asignada CVE‑2026‑6701. La vulnerabilidad es un problema de CSRF (Falsificación de Solicitudes entre Sitios) que puede encadenarse a una condición de XSS (Cross‑Site Scripting) almacenado. Aunque la calificación general de CVSS es relativamente baja (4.3), el riesgo en el mundo real puede ser mayor de lo que sugiere el número — especialmente cuando los atacantes apuntan a sitios en campañas masivas o dependen de engañar a usuarios privilegiados para que interactúen con un enlace o página manipulada.

Como el equipo de seguridad de WP‑Firewall, queremos explicar, en lenguaje sencillo y con orientación específica, lo que significa este problema, cómo puede ser abusado, cómo detectar la explotación y — lo más importante — qué puedes hacer ahora mismo para proteger tus sitios. Esta guía está escrita para propietarios de sitios, administradores, desarrolladores y equipos de hosting.

---

Resumen ejecutivo (puntos clave)

• Una vulnerabilidad en addfreespace (<= 0.1.3) permite a un atacante enviar solicitudes que no están protegidas contra CSRF. Si un usuario privilegiado (administrador u otro rol de alto privilegio) es engañado para visitar una página maliciosa o hacer clic en un enlace malicioso, el atacante puede almacenar cargas útiles de JavaScript en el sitio (XSS almacenado).
• El XSS almacenado ejecutado en un contexto de administrador puede llevar a la toma de control de cuentas, escalada de privilegios, robo de datos o instalación de puertas traseras persistentes.
• No hay un parche oficial del plugin disponible en el momento de la publicación. Se aconsejan mitigaciones inmediatas.
• Acciones inmediatas recomendadas: desactivar o eliminar el plugin; restringir el acceso a las páginas de administración del plugin; aplicar reglas de WAF o parches virtuales; escanear en busca de scripts inyectados y modificaciones sospechosas; restablecer credenciales de administrador y rotar claves; e implementar un endurecimiento a largo plazo.
• Los usuarios de WP‑Firewall pueden aplicar parches virtuales, reglas de WAF gestionadas y escaneo activo para reducir el riesgo de inmediato.

---

Por qué CSRF encadenado con XSS almacenado es peligroso (en términos humanos)

CSRF y XSS son diferentes tipos de ataque, pero cuando se combinan se vuelven poderosos:

• CSRF: Un atacante engaña a un usuario que ha iniciado sesión (a menudo un administrador) para que realice una acción que no tenía intención de hacer — por ejemplo, haciéndole clic en un enlace o visitando una página web que hace una solicitud al sitio vulnerable. Las acciones de administración de WordPress correctamente codificadas incluyen verificaciones de nonce y verificaciones de capacidad para prevenir esto. En este caso, el plugin no validó correctamente el origen/nonce.
• XSS almacenado: Si un atacante puede hacer que JavaScript arbitrario se guarde en la base de datos del sitio web (por ejemplo, en una opción de plugin o campo personalizado), ese código se ejecutará cada vez que el contenido almacenado se muestre en el contexto de administración o frontend sin el escape adecuado.

Encadenamiento: Un atacante no autenticado crea una página que envía un POST/GET al endpoint del plugin vulnerable en segundo plano o cuando un administrador del sitio visita. Si el plugin almacena la carga útil de JavaScript del atacante (y luego la muestra sin escapar), la carga útil se ejecuta en el contexto del navegador del administrador. Desde allí, un atacante puede robar cookies de autenticación, realizar acciones como ese usuario (crear publicaciones, instalar plugins/temas, exportar datos) y establecer acceso persistente.

Incluso si un atacante necesita que el administrador realice una interacción (por ejemplo, hacer clic en un enlace), ese único clic puede ser todo lo que necesita para pivotar hacia un compromiso total.

---

Causas raíz técnicas (qué salió mal)

A partir de los detalles reportados y patrones de explotación típicos, la cadena generalmente indica las siguientes fallas en el código del plugin:

1. Falta de protección CSRF
   • No se utilizan nonces de WordPress (por ejemplo, wp_create_nonce / check_admin_referer) para acciones que cambian el estado.
   • No se valida el origen de la solicitud o el encabezado referer para asegurar que la solicitud provenga de una interfaz de administrador confiable.
2. Comprobación de capacidades insuficiente
   • Los puntos finales del plugin pueden no tener las comprobaciones de capacidad de usuario adecuadas (current_user_can) o hacer cumplir la capacidad apropiada para la tarea.
3. Falta o insuficiencia en la sanitización de datos y escape de salida
   • Datos peligrosos proporcionados por el usuario se guardan en la base de datos sin sanitizar (por ejemplo, usando sanitize_text_field, wp_kses_post) y se muestran más tarde sin escapar (por ejemplo, esc_html, esc_attr, o filtrado kses adecuado).
4. Interfaces de administrador que exponen puntos finales escribibles accesibles a través de métodos HTTP no autenticados
   • Ganchos de acción o puntos finales AJAX que aceptan solicitudes POST sin las protecciones adecuadas.

El resultado neto: un atacante puede provocar un cambio de estado (almacenar contenido) utilizando el navegador de una víctima, y el contenido almacenado puede ser renderizado y ejecutado más tarde.

---

Cómo se desarrollaría típicamente un ataque (a alto nivel)

1. El atacante identifica el punto final del plugin vulnerable (por ejemplo, una URL de acción de administrador utilizada por addfreespace).
2. El atacante crea una página web que realiza un POST (o GET) a ese punto final con una carga útil que contiene JavaScript (un vector XSS almacenado). La presentación del formulario incluye los parámetros esperados por el plugin.
3. Un administrador (u otro usuario privilegiado) visita la página maliciosa o hace clic en un enlace mientras está autenticado en el sitio de WordPress vulnerable.
4. Debido a que el plugin carece de protección CSRF, la solicitud es aceptada y el JavaScript malicioso se guarda en la base de datos (por ejemplo, en una opción, meta de publicación o campo controlado por el plugin).
5. Cuando el sitio (o la página de administración) muestra más tarde ese valor almacenado sin sanitización/escape, el JavaScript se ejecuta en el contexto del navegador del administrador.
6. El JavaScript puede entonces:
   • Leer cookies o almacenamiento local (y exfiltrarlas);
   • Hacer solicitudes autenticadas utilizando las credenciales del administrador (por ejemplo, crear nuevos usuarios administradores, instalar plugins);
   • Cargar scripts externos para ejecutar acciones adicionales o mantener la persistencia.

Nota: El paso clave es el usuario privilegiado realizando una acción (por ejemplo, visitar una página). Sin esa interacción, CSRF no puede ser activado normalmente. Dicho esto, muchos administradores hacen clic en enlaces o abren páginas, y los actores de amenazas explotan ese comportamiento a gran escala.

---

Impacto: lo que los atacantes pueden lograr

XSS almacenado ejecutado en una sesión de navegador administrativo puede habilitar:

• Toma de control de la cuenta (robar cookies de sesión o tokens de OAuth).
• Creación de nuevos usuarios administrativos.
• Instalación de puertas traseras (plugins/temas maliciosos) o tareas programadas que mantienen la persistencia.
• Exfiltración de datos: exportación de publicaciones, medios o datos de usuarios.
• Desfiguración del sitio o inyección de malware drive-by para infectar a los visitantes.
• Pivotar hacia el control de hosting o acceso a la base de datos a través de una explotación adicional.

Aunque el CVSS es bajo, el impacto comercial puede ser severo si el atacante logra persistencia o toma el control de un sitio de producción.

---

Acciones inmediatas que debes tomar (estilo de respuesta a incidentes)

Si ejecutas sitios de WordPress que usan addfreespace (<= 0.1.3), trata la situación como urgente:

1. Desactiva el plugin ahora
   • Inicia sesión en wp-admin y desactiva addfreespace. Si no puedes acceder a wp-admin, renombra la carpeta del plugin a través de SFTP/SSH (wp-content/plugins/addfreespace -> addfreespace.disabled).
2. Elimina el plugin
   • Si no lo necesitas estrictamente, elimínalo del código. A veces, eliminar el plugin es la opción más segura a corto plazo hasta que se publique una versión corregida.
3. Pon el sitio en modo de mantenimiento mientras investigas
   • Reduce la superficie de ataque mientras escaneas.
4. Aplica WAF/parcheo virtual de inmediato.
   • Bloquea las solicitudes a los puntos finales de administración del plugin y desautoriza los POST sospechosos que contengan cargas útiles similares a scripts.
   • Si usas WP‑Firewall, habilita el conjunto de reglas WAF gestionadas y el parcheo virtual para esta vulnerabilidad para bloquear intentos de explotación incluso mientras el plugin permanezca presente.
5. Escanea en busca de cargas útiles inyectadas y entradas de DB sospechosas.
   • Busca en publicaciones, opciones, usermeta y otros almacenamientos por <script, onerror=, al cargar=, o otros controladores de eventos JS que parezcan inesperados.
   • Ejemplo (defensivo, ejecuta como administrador a través de WP‑CLI o cliente de base de datos):
     • wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%'"
     • wp db query "SELECT option_name FROM wp_options WHERE option_value LIKE '%<script%'"
   • Nota: Las consultas exactas anteriores asumen prefijos de tabla estándar. Ajusta para prefijos personalizados y seguridad en producción.
6. Rotar credenciales y secretos
   • Restablece las contraseñas de todos los usuarios administradores.
   • Rota las claves API, credenciales de cuentas de servicio y claves en wp-config.php si sospecha de compromiso.
7. Revisar cuentas de usuario y roles
   • Busca cuentas de administrador inesperadas o usuarios con privilegios elevados.
8. Revise los registros del servidor y de acceso
   • Inspecciona los registros del servidor web y las auditorías en busca de POSTs sospechosos o solicitudes a puntos finales del plugin.
9. Restaura desde una copia de seguridad conocida y buena si detectas cambios que no puedes limpiar de forma segura.
   • Si encuentras puertas traseras o modificaciones inexplicables, una restauración limpia puede ser la remediación más rápida.
10. Asegurar el acceso de administrador
    • Aplica autenticación de 2 factores (2FA) para todas las cuentas privilegiadas.
    • Limita el acceso al área de administración por IP si es posible.
    • Usa contraseñas fuertes y únicas y una política de bloqueo de cuentas.

---

Cómo detectar un XSS almacenado a partir de esta vulnerabilidad (indicadores de compromiso)

Busca los siguientes signos:

• JavaScript inesperado en publicaciones, páginas, opciones o contenido de widgets.
• Nuevos usuarios administradores o cambios inesperados en los roles de usuario.
• Contenido de la interfaz de administración que muestra alertas extrañas, ventanas emergentes o redirecciones.
• Solicitudes salientes del sitio a dominios de terceros desconocidos (indicando exfiltración o callback).
• Registros del servidor que muestran POSTs a puntos finales de plugins desde referidores o agentes de usuario inusuales.
• Aumento inesperado de CPU o trabajos cron programados (indicando puertas traseras).

Comprobaciones defensivas útiles:

• Búsqueda de etiquetas de script en publicaciones y opciones con WP‑CLI:
  • wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%'" --limit=100
  • wp db query "SELECT option_id, option_name FROM wp_options WHERE option_value LIKE '%<script%'" --limit=100
• Escanear con un escáner de malware de confianza (del lado del sitio o a nivel de host) para detectar puertas traseras y webshells conocidos.
• Comparar archivos actuales con una instantánea limpia o los archivos originales distribuidos del plugin para encontrar archivos alterados.

Cuando encuentres contenido sospechoso, aísla y no lo ejecutes en un navegador en vivo. Trátalo como malicioso hasta que se demuestre lo contrario.

---

Orientación sobre remediación a nivel de código para desarrolladores

Si mantienes el plugin o desarrollas temas/plugins, estas son las prácticas de codificación defensiva esenciales a seguir para prevenir tanto CSRF como XSS almacenado:

1. Usa nonces y verifícalos en cada solicitud que cambie el estado
   • Al generar un formulario o un enlace que realice un cambio de estado:

     $nonce = wp_create_nonce( 'my_plugin_action' );

     Inclúyelo en formularios o AJAX:

     <input type="hidden" name="_wpnonce" value="" />

   • En el manejo de solicitudes:

     check_admin_referer( 'my_plugin_action' ); // o check_ajax_referer para AJAX

2. Verificar capacidades del usuario
   • Antes de realizar acciones, verifica:

     if ( ! current_user_can( 'manage_options' ) ) { wp_die( 'Permisos insuficientes' ); }

3. Limpia la entrada antes de guardar
   • Usa limpiadores apropiados:
     • sanitize_text_field(), sanitize_email(), intval(), floatval()
     • Para entrada HTML: wp_kses_post() o wp_kses() con una lista de permitidos segura
4. Escape en la salida
   • Siempre escapa los datos al imprimir:
     • esc_html(), esc_attr(), wp_kses_post() dependiendo del contexto.
5. Usa la API REST y verifica los callbacks de permisos
   • Para los endpoints REST, implementa permission_callback que verifica capacidades y nonces.
6. Valida los tipos de datos y longitudes esperadas
   • Aplica longitudes máximas y caracteres permitidos.

Ejemplo (código pseudo‑defensivo):

// En el formulario:
wp_nonce_field( 'my_plugin_save_settings', '_wpnonce', true );

// En el manejador de envío:
if ( ! current_user_can( 'manage_options' ) ) {;

Para entrada HTML que necesita permitir etiquetas limitadas:

$allowed = array(;

---

WAF y parches virtuales — reglas prácticas para implementar ahora

Si tienes un WAF (firewall de aplicación) como WP‑Firewall, puedes crear reglas defensivas que bloqueen intentos de explotación incluso antes de que se publique un parche oficial del plugin. Considera los siguientes enfoques de alto nivel:

1. Bloquear contenidos POST/GET sospechosos a los puntos finales del plugin
   • Crear una regla para inspeccionar solicitudes que apunten a acciones administrativas del plugin o archivos del plugin. Si el cuerpo de la solicitud contiene etiquetas de script o controladores de eventos XSS comunes (onerror, onload, javascript:), bloquea la solicitud.
2. Hacer cumplir la presencia de referer u origen para los POSTs administrativos
   • Bloquear o desafiar (CAPTCHA) los POSTs a wp-admin/admin-post.php, admin-ajax.php, o puntos finales específicos del plugin que no incluyan un referer válido o un parámetro _wpnonce.
3. Limitar la tasa y desafiar solicitudes anónimas a puntos finales administrativos
   • Muchos intentos de explotación son automatizados. La limitación de tasa reduce grandes ataques automatizados.
4. Patching virtual: interceptar patrones de explotación conocidos
   • Bloquear solicitudes que coincidan con los nombres de parámetros exactos o patrones de URL utilizados por el plugin vulnerable cuando contengan contenido sospechoso.
5. Bloquear solicitudes que intenten crear/modificar opciones con contenido de script
   • Si una solicitud intenta actualizar wp_options o campos comúnmente utilizados por el plugin con <script en la carga útil, bloquéala.

Ejemplo de una regla conceptual de firewall (pseudo):

SI request.path COINCIDE CON "/wp-admin/admin-post.php" O "/wp-admin/*addfreespace*" Y request.method EN (POST, GET) ENTONCES

Notas:

• Evita reglas demasiado amplias que puedan resultar en falsos positivos. Prueba primero en modo de monitor.
• Usa reglas combinadas con registro y alertas para que puedas adaptarte rápidamente.

Si eres usuario de WP‑Firewall, habilita el conjunto de reglas gestionadas que apunta a patrones de explotación CSRF/XSS y habilita el parcheo virtual para vulnerabilidades de addfreespace. Esto proporciona protección inmediata mientras sigues una remediación a largo plazo.

---

Lista de verificación posterior a la remediación (qué hacer después de eliminar el plugin o aplicar un parche)

1. Confirma que el plugin ha sido eliminado o actualizado a una versión parcheada cuando esté disponible.
2. Vuelve a escanear todo el sitio en busca de código malicioso, webshells y archivos modificados.
3. Revisa la base de datos en busca de cargas útiles almacenadas y elimínalas o sanealas.
4. Rota las credenciales: contraseñas de administrador, claves SSH, claves API.
5. Reemite cualquier token o clave filtrada que pueda haber sido expuesta.
6. Restaura una copia de seguridad limpia si no puedes asegurar completamente que el sitio está limpio.
7. Monitorea los registros y la detección de intrusiones para intentos repetidos.
8. Documenta el incidente, tus acciones y cualquier lección aprendida.

---

Cómo comunicar a los clientes y partes interesadas (si gestionas otros sitios)

• Breve y factual: explica el plugin afectado, las versiones, el nivel de riesgo y las acciones que has tomado (desactivado/eliminado, escaneado, implementadas reglas de WAF).
• Proporciona tranquilidad: enumera las mitigaciones exactas (reglas de WAF en su lugar, escaneo completado, credenciales rotadas, copias de seguridad utilizadas).
• Proporciona orientación: instruye a los usuarios finales a cambiar sus contraseñas si iniciaron sesión durante el período de exposición y a estar atentos a actividades sospechosas.
• Ofrece seguimiento: programa una revisión de seguridad completa si se encuentran indicadores de compromiso.

---

Lista de verificación de endurecimiento que debería ser práctica estándar (previniendo problemas similares)

• Aplica 2FA para cada cuenta administrativa.
• Limita el acceso al área de administración a través de una lista de permitidos de IP donde sea posible.
• Deshabilitar la edición de archivos en wp-admin:

  define( 'DISALLOW_FILE_EDIT', true );

• Aplica el principio de menor privilegio: da a los usuarios solo las capacidades que realmente necesitan.
• Mantener el núcleo de WordPress, temas y plugins actualizados.
• Instala y ejecuta un escáner de sitios de buena reputación y un WAF gestionado.
• Usa contraseñas fuertes y únicas y una política de gestión de secretos centralizada.
• Realiza copias de seguridad diarias (o más frecuentemente) con copias de seguridad inmutables almacenadas fuera del sitio.
• Revisa el código del plugin antes de instalar plugins de autores desconocidos o elementos de bajo número de descargas.

---

Si encuentras JavaScript sospechoso en tu base de datos — guía de limpieza segura.

• No visite páginas que muestren contenido sospechoso en una sesión de navegador de administrador antes de limpiar.
• Exporte la(s) fila(s) sospechosa(s) de la base de datos a un área de cuarentena segura y analícelas sin conexión o en una máquina aislada.
• Elimine o sanee las entradas utilizando funciones seguras (wp_update_post con contenido saneado, update_option con contenido saneado).
• Si no está seguro del alcance de la violación, restaure desde una copia de seguridad limpia verificada y vuelva a aplicar parches y endurecimiento.

---

Por qué un bajo CVSS no significa “no es gran cosa”

La explotación masiva automatizada y la ingeniería social dependen de pasos encadenados de baja complejidad. Una vulnerabilidad que requiere “solo” que un administrador haga clic en un enlace puede ser extremadamente poderosa cuando los atacantes envían decenas de miles de correos electrónicos de phishing o comprometen otros sitios web para incrustar la explotación. El XSS almacenado ejecutado en un contexto de administrador es particularmente sensible. Trate las vulnerabilidades con una evaluación de riesgo práctica: facilidad de explotación, número de sitios afectados y la ganancia potencial para el atacante. En muchos casos, el parcheo virtual inmediato y la eliminación de plugins son prudentes incluso para puntajes bajos de CVSS.

---

Guía rápida de respuesta a incidentes (una página)

1. Desactive el plugin (o cambie el nombre de la carpeta del plugin).
2. Active el modo de mantenimiento y bloquee el tráfico si es necesario.
3. Active las reglas de WAF/parche virtual para el plugin.
4. Escanee la base de datos en busca de etiquetas de script y entradas sospechosas; ponga en cuarentena los elementos encontrados.
5. Escanee el sistema de archivos en busca de archivos modificados y webshells.
6. Rota las contraseñas de administrador y las claves de API.
7. Revise los registros y las cuentas de usuario.
8. Restaurar desde copias de seguridad limpias si es necesario.
9. Endurezca el acceso de administrador (2FA, lista de permitidos de IP).
10. Reintroduzca el plugin solo cuando esté parcheado y después de una QA completa.

---

Pruebe el plan WP‑Firewall Basic (Gratis) — Protección esencial sin el costo

Si está buscando protección inmediata y práctica mientras sigue los pasos anteriores, considere registrarse en el plan WP‑Firewall Basic (Gratis). Incluye protecciones esenciales que ayudan a bloquear intentos de explotación y reducir rápidamente su exposición:

• Cortafuegos gestionado y WAF para bloquear patrones de explotación conocidos
• Ancho de banda ilimitado — el firewall no limita su tráfico
• Escáner de malware para detectar puertas traseras comunes y cargas maliciosas
• Mitigación para los riesgos del OWASP Top 10 para reducir vectores de ataque comunes

Puedes registrarte para el plan gratuito y desplegar estas protecciones rápidamente en: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

Palabras finales del equipo de seguridad de WP‑Firewall

Vulnerabilidades como la cadena addfreespace CSRF→stored‑XSS son un recordatorio de que incluso los plugins pequeños o de nicho pueden introducir un riesgo desproporcionado. La buena noticia: puedes tomar medidas efectivas de inmediato. Desactiva o elimina el plugin, aplica reglas de WAF y parches virtuales, escanea en busca de inyecciones, rota credenciales y endurece el acceso administrativo. Si gestionas múltiples sitios web (como una agencia o un host), automatiza el escaneo y el parcheo virtual para reducir la ventana de exposición en todos los sitios.

Estamos comprometidos a ayudar a los propietarios de sitios a reducir el riesgo de manera rápida y confiada. Si necesitas asistencia práctica, caza de amenazas o reglas de parcheo virtual personalizadas, WP‑Firewall está disponible para apoyar la limpieza y la defensa a largo plazo.

Mantente seguro y prioriza la mitigación rápida cuando se divulgue una vulnerabilidad: el tiempo entre la divulgación y la explotación activa suele ser más corto de lo que esperas.

— Equipo de seguridad de firewall de WP

---

Apéndice: Comandos de referencia rápida (defensivos)

• Busca etiquetas de script en las publicaciones (ajusta el prefijo de la tabla si es necesario):

  wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%';"

• Busca en wp_options contenido similar a scripts:

  wp db query "SELECT option_id, option_name FROM wp_options WHERE option_value LIKE '%<script%';"

• Lista los archivos modificados recientemente (últimos 7 días) en un host UNIX:

  find /path/to/wordpress -type f -mtime -7 -print

Recuerda: ejecuta estos comandos solo con el acceso y las copias de seguridad apropiadas, y evita exponer el sitio a un mayor riesgo mientras investigas.