Novedades

Rate limiting real en /api/ingest

Límite de envíos por IP, además del límite por sitio, para que nadie agote la cuota de telemetría de otra cuenta usando su token público.

Error tracking (Sentry)

Integramos Sentry en la app y en el worker para detectar errores reales, en vez de enterarnos por un reporte de un cliente.

Proxies salientes para escaneo (Webshare)

En planes pagos, el escaneo puede salir a través de proxies para no quedar bloqueado por el firewall del sitio que estás monitoreando.

Reporte PDF verificado con test de regresión

Cada cambio se valida generando un PDF de reporte real en cada corrida de CI, no solo compilando el código.

Tema claro e informe más ejecutivo

El reporte PDF ahora tiene un tema claro además del oscuro, con un resumen ejecutivo en lenguaje simple y un plan de acción priorizado al inicio.

Rate limiter distribuido (Redis) en vez de Map en memoria

El límite de requests ahora usa Redis con fallback en memoria, en vez de un contador que se perdía en cada reinicio del servidor.

Verificar dominio de envío en Resend

Verificamos el dominio de envío de emails, así las notificaciones de Vigilantte llegan de forma confiable.

Plugin de WordPress

Hecho (2026-10-03, v1.1.0): wordpress-plugin/vigilantte-security/, descargable como .zip desde /api/downloads/wordpress-plugin (landing pública en /wordpress y tarjeta en la página de cada sitio WordPress).

Feed de vulnerabilidades por plugin/tema

Hecho (2026-10-03).

WPScan API para CVEs de plugins individuales

Activo desde 2026-10-03 (plan gratis: 25 consultas/día).

Plugin inventory vía WP REST API

Hecho: si el sitio expone /wp-json/wp/v2/plugins se listan los plugins instalados con su versión (worker/lib/cms.ts → fetchWpPluginInventory) para cruzarlos contra WPScan.

Escáner de formularios web

Analiza los formularios del HTML de la home y hasta 50 páginas del sitemap (worker/lib/forms.ts + worker/scanners/forms.ts).

Detección de CMS y análisis de vulnerabilidades

Detecta la plataforma (WordPress, WooCommerce, Shopify, Drupal, Joomla, Magento, PrestaShop, Wix, Squarespace, Webflow) solo por firmas técnicas —cabeceras, assets, meta generator—, nunca por la mención del nombre en …

Agente servidor multi-token y multi-sitio

Hecho 2026-10-02: SKUDO_SITE_TOKENS acepta varios tokens separados por coma; el agente recolecta una vez y reporta lo mismo a cada sitio del servidor.

Auto-verificación de hallazgos resueltos (RESOLVED → VERIFIED)

Si marcas un hallazgo como resuelto y no vuelve a aparecer en el siguiente escaneo, se confirma solo como verificado; si reaparece, se reabre automáticamente.

Diff de findings entre escaneos

Hecho: el detalle de cada escaneo compara contra el anterior (nuevos, resueltos, reabiertos) y, desde 2026-10-02, cada hallazgo muestra su historial en los últimos 10 escaneos (desde cuándo aparece y su estado en cada…

Alertas en tiempo real (Slack/Teams/webhooks)

Hecho: la organización configura un webhook entrante (Slack, Teams o Discord aceptan el mismo POST JSON) en Equipo, y el worker envía cada hallazgo CRITICAL nuevo con el mismo cooldown que el email (worker/lib/webhook…

Deduplicación y cooldown de alertas CRITICAL

Los avisos de hallazgos críticos se deduplican: te avisamos si es nuevo, o si sigue sin resolverse después de 7 días — antes se repetía en cada escaneo.

CSP permite unsafe-inline y unsafe-eval

Reforzamos la Content-Security-Policy con nonces en vez de permitir scripts inline sin restricciones.

Rate limiting en memoria se pierde al reiniciar

El límite de requests dejó de depender de un contador en memoria de un solo proceso, así resiste reinicios y funciona con varias instancias.

Token de verificación público cualquiera puede floodear /api/ingest

El token que viaja en el script instalable de tu sitio ahora está firmado, para que no cualquiera pueda mandar eventos falsos a tu cuenta.

Inyección HTML en emails vía nombre de organización

El nombre de tu organización se escapa antes de insertarse en los emails, para evitar que se inyecte HTML o JS en una invitación.

Dev server escucha en 0.0.0.0 exponiendo source maps

El servidor de desarrollo dejó de exponerse por default a toda la red local.

Contraseña temporal viaja en response HTTP plano

Las contraseñas temporales ya no viajan en la respuesta HTTP — se envían solo por email al dueño de la cuenta.

Falta CSRF protection en endpoints con sesión

Los endpoints que dependen de tu sesión ahora validan el origen del request para prevenir ataques CSRF.

User enumeration en endpoint de registro

El registro ya no revela si un email ya está en uso, para dificultar que alguien liste cuentas existentes.

Stripe webhook sin protección contra eventos duplicados

Los webhooks de Stripe ahora son idempotentes: un reintento del mismo evento no vuelve a disparar emails de facturación duplicados.

Sin límite de tamaño en request bodies

Los requests a la plataforma ahora tienen un límite de tamaño, para evitar abuso con payloads gigantes.

Sin logging de intentos de autenticación fallidos

Registramos los intentos de login fallidos (captcha, contraseña incorrecta, cuenta suspendida) para poder detectar ataques de fuerza bruta.

Sin 2FA / MFA

Hecho: TOTP (apps de autenticación) configurable desde Cuenta; si está activo, el login exige el código (src/lib/totp.ts, src/lib/auth.ts, /api/user/totp/*).

User-Agent personalizado en verificaciones de sitio

La verificación de dominio ahora usa un User-Agent genérico de navegador, en vez de uno identificable que un sitio podría usar para evadirla.

Chromium en producción 300-500MB RAM por PDF

Resuelto 2026-09-28: el PDF se genera en una cola (src/lib/report-pdf-queue.ts), un Chromium a la vez y solo con ≥800 MB de memoria libre; si no hay, espera y reintenta.

Deploy script con git reset --hard sin validación

El script de deploy ahora hace una verificación previa y muestra los cambios antes de aplicarlos, en vez de forzarlos sin revisión.

Escaneo profundo de scripts externos (frontend)

Hecho (2026-10-03).

Verificación SRI (Subresource Integrity)

Hecho (2026-10-03, worker/lib/sri.ts).

Inventario y legitimidad de tags de analytics/marketing

Hecho (2026-10-03).

Detección de defacement y phishing intra-página

Hecho (2026-10-03).

Análisis de integridad de assets estáticos (checksum remoto)

Hecho (2026-10-03, worker/lib/asset-integrity.ts + tabla site_asset_hashes).

Librerías JavaScript con vulnerabilidades conocidas

Hecho 2026-10-02: se detectan jQuery, jQuery UI/Migrate, Bootstrap, Lodash, Moment, AngularJS, Vue, Handlebars y DOMPurify con su versión (archivo, ?ver=, cdnjs/jsDelivr/unpkg) y se cruzan contra OSV.dev (base pública…

Verificación de checksums contra fuentes oficiales

Hecho (2026-10-03).

Monitoreo de cambios en DNS y WHOIS

Implementado: tabla SiteInfraBaseline (1 fila por sitio) guarda la última IP resuelta, nameservers, registrador y estado de DNSSEC.

Fuentes de reputación adicionales (URLhaus, AlienVault OTX, PhishTank)

Implementado en worker/lib/urlhaus.ts (sin API key, base comunitaria de URLs con malware activo), worker/lib/otx.ts (con OTX_API_KEY opcional, reportes de threat intel) y worker/lib/phishtank.ts (con PHISHTANK_API_KEY…

Sistema de falsos positivos (ignore rules)

Puedes marcar un hallazgo como falso positivo por sitio para que no vuelva a reportarse en los próximos escaneos.

Ignore rule desde el finding (1-click)

Desde el detalle de cualquier hallazgo puedes crear la regla de ignorado en un click, sin armarla a mano.

Expiración automática de ignore rules

Las reglas de ignorado pueden tener fecha de expiración, para que un falso positivo silenciado no quede olvidado para siempre.

Bulk ignore

Hecho: en el detalle de un escaneo se seleccionan varios hallazgos y se crean sus reglas de ignorado en una sola acción (POST /api/sites/[siteId]/ignore-rules/bulk), con motivo obligatorio.