Saltar al contenido
Helix Nebula

Investigación de seguridad

Vulnerabilidades que hemos reportado

Auditamos el software que usamos y protegemos. Cuando encontramos un fallo, lo reproducimos, lo reportamos en privado al proyecto y proponemos el arreglo.

Vulnerabilidades corregidas
8
Proyectos
5
En divulgación coordinada
5

01 — Historial

Reportes publicados

Solo aparecen los fallos ya corregidos y publicados por cada proyecto. Los que siguen en revisión no se muestran hasta que haya un arreglo.

  1. mail-parser

    mail-parser

  2. mailsuite

    mailsuite

  3. parsedmarc

    parsedmarc

  4. parsedmarc

    parsedmarc

  5. parsedmarc

    parsedmarc

  6. parsedmarc

    parsedmarc

  7. Better Auth for Convex

    @convex-dev/better-auth

    Alta8.1Aviso de seguridadGHSA-j8qq-g9pm-v3c2

    El plugin cross-domain puede entregar el token de sesión de la víctima a un origen de confianza controlado por el atacante

    Los callbacks de OAuth no comprobaban la cookie de state y el token de un solo uso se añadía a cualquier redirección permitida por trustedOrigins, incluidos comodines como *.vercel.app. Permitía robar la sesión de otro usuario.

    Afectadas
    < 0.12.6
    Corregido en
    0.12.6
  8. Better Auth for Convex

    @convex-dev/better-auth

    Media6.8Aviso de seguridadGHSA-pgx2-m66h-x29f

    Los enlaces enviados por email pueden apuntar al host del atacante con un baseURL dinámico

    Las cabeceras x-better-auth-forwarded-* se restauraban para cualquier petición, así que un atacante podía elegir el host de los enlaces de restablecimiento de contraseña y verificación.

    Afectadas
    0.11.5 – 0.12.5
    Corregido en
    0.12.6
  9. RustDesk

    rustdesk

    Alta7.4Reporte independiente

    Reutilización de (clave, nonce) entre los dos sentidos del cifrado de sesión

    Los dos extremos de una sesión cifraban con la misma clave y el mismo contador de nonce, lo que expone el XOR de los textos en claro ante un relay o un atacante en la ruta. RustDesk ya tenía otro reporte del mismo fallo y nos trató como reportero independiente; el arreglo separa las claves por sentido.

    Corregido en
    1.5.0

02 — Método

Cómo reportamos

01
Reproducimos
Cada fallo se confirma con una prueba de concepto contra la última versión publicada y la rama principal.
02
Reportamos en privado
Seguimos la política de seguridad de cada proyecto: aviso privado de GitHub, email o el canal que indiquen.
03
Proponemos el arreglo
Siempre que podemos, enviamos el parche y ayudamos a revisar la corrección del mantenedor.
04
Esperamos al arreglo
No publicamos detalles hasta que el proyecto ha sacado una versión corregida.

Auditorías

¿Quieres que revisemos tu software?

Auditamos código, dependencias e infraestructura con el mismo método que usamos en estos reportes.

Contactar