Divulgación responsable de vulnerabilidades
Todo software tiene bugs. El nuestro preferimos que lo encuentres tú.
Este es el programa de divulgación de vulnerabilidades de diagnos. No pagamos en dinero — hoy por hoy no podemos. Pagamos en gratitud pública, con un lugar en el salón de la fama y con la certeza de que el examen de alguien quedó más seguro por tu contribución.
curl https://diagnos.health/.well-known/security.txt Contact: mailto:[email protected]Contact: mailto:[email protected]Policy: https://diagnos.health/en/bounty/Preferred-Languages: pt-BR, en, es, it, frExpires: 2027-09-16T00:00:00Z Acceso rápido
Las diez secciones de esta página, para abrir directamente la que buscas.
Salón de la fama
Toda vulnerabilidad válida entra en esta lista, con el nombre que elijas — tu nombre, tu apodo, tu @ o ninguno de ellos.
| # | Investigador | Qué encontró | Cuándo |
|---|---|---|---|
| 001 | TÚ | esta fila está reservada | cuando quieras |
| 002 | — | — | — |
| 003 | — | — | — |
| 004 | — | — | — |
| 005 | — | — | — |
TE QUIERO A TI
PARA LA SEGURIDAD DE DIAGNOS
Postura de seguridad
Controles activos en producción
-
Tu contraseña nunca llega hasta nosotros
El login corre sobre OPAQUE, un PAKE: el servidor nunca ve tu contraseña, ni siquiera durante el login. Solo guarda un registration_record, que por sí solo no abre nada.
-
El servidor no puede abrir tu bóveda
Las claves nacen en tu dispositivo. El servidor solo recibe texto cifrado — no existe una línea de código del otro lado que abra una KEK.
-
Repetir una solicitud no funciona
Cada solicitud sensible lleva nonce + timestamp, clave primaria (scope_id, ts, nonce) en D1, tolerancia de reloj de 120s y retención de 300s barrida por cron.
-
Cada solicitud relevante se vuelve registro
Escribimos un objeto por solicitud relevante en R2. La escritura se cobra y corre fuera del camino crítico de la respuesta — auditar no retrasa a nadie.
-
El dominio más sensible es el más cerrado
sign.diagnos.health tiene una CSP default-src 'none' de verdad — bloquea, no solo reporta — y SRI calculado en el build. La cookie de dispositivo es __Host-, HttpOnly, Secure, SameSite=Strict.
-
El dato clínico sabe dónde vive
Informes e imágenes están en un bucket R2 con jurisdicción UE amarrada directo al binding — no es una promesa en un contrato, es una configuración que aplica la infraestructura.
Brechas conocidas
- Nunca contratamos una prueba de penetración independiente. Nadie de afuera auditó esto.
- No tenemos SOC 2 ni ISO 27001.
- HIPAA: los requisitos técnicos están cubiertos, pero la cadena de contratos con subprocesadores (BAA) está incompleta — solo dos firmados, el resto en negociación.
- La CSP de la aplicación todavía está en modo report-only: reporta la violación, no bloquea nada.
- El escaneo automatizado de vulnerabilidades todavía ocurre de forma puntual, no como rutina continua.
- El disyuntor del rate limit es una estimación conservadora, nunca calibrada contra tráfico real.
La primera lista es lo que ya construimos. La segunda es por qué existe esta página. No te estamos pidiendo confianza — te estamos pidiendo desconfianza, documentada en un reporte.
Alcance del programa
Nueve objetivos posibles. La etiqueta junto a cada uno dice si está dentro, fuera, o dentro-pero-con-letra-pequeña — léela antes de apuntar cualquier herramienta hacia alguno.
| Objetivo | Estado | Qué es |
|---|---|---|
| vault.diagnos.health | Dentro del alcance | El servidor principal del producto — la "bóveda". Sesión, desbloqueo vía OPAQUE, el ledger, URLs firmadas de R2, Agentes de IA, MCP y OAuth pasan todos por aquí. |
| api.diagnos.health | Dentro del alcance | El mismo servidor, con el otro nombre que el producto usa para él. Hoy las dos entradas conviven en el código — las dos valen. |
| /api/internal/v1/* | Dentro, con matiz | Un prefijo dentro de la propia API, reservado a la app oficial — exige cabeceras que un curl suelto no produce solo. Lee el aviso de abajo antes de probar esta línea. |
| sign.diagnos.health | Dentro del alcance | La ceremonia de firma del informe — WebAuthn/passkey, alcanzada por enlace o código QR. El dominio más sensible del producto. |
| app.diagnos.health | Dentro del alcance | La aplicación web de diagnos. |
| diagnos.health | Dentro del alcance | Este sitio, el que estás leyendo ahora mismo. Está en el alcance aunque sea marketing estático — pero ajusta la expectativa: lo peor que hay por aquí es una redirección abierta. |
| SDK · CLI · API Apache-2.0 | Dentro del alcance | SDK, CLI y API en Python, licencia Apache-2.0. El código va a un repositorio público pronto — leerlo es bienvenido. |
| *.diagnos.health | Fuera del alcance | Cualquier *.diagnos.health que no esté en esta lista está fuera del alcance y fuera del puerto seguro. Es el estándar que popularizó GitHub: solo podemos autorizar investigación sobre sistemas que son nuestros. |
| cloudflare · google · modal · sentry · … | Fuera del alcance | Cloudflare, Google/Firebase, Modal, Sentry y similares. Repórtaselo a ellos, no a nosotros — salvo que el problema esté claramente en nuestra integración. |
Sobre la audiencia "internal" (y por qué el curl solo no llega ahí)
Cabeceras exigidas
La audiencia internal exige, todas a la vez:
Authorization: Bearer <Firebase ID token>X-AppCheck-TokenX-Signature-HmacX-Signature-NonceX-Signature-Timestamp
Lo que no existe
- No existe X-Device-Challenge. El nombre circuló internamente, pero nunca existió ni una línea de código con él.
- No existe bloqueo automático de workspace. Ninguna llamada errónea bloquea una cuenta por sí sola — esto también circuló, y también es falso.
Lo que existe de verdad
Lo que existe de verdad, y dice lo mismo:
- Límite de solicitudes por ruta, más un disyuntor por alcance: 600 solicitudes por ventana.
- Antirreplay real: clave primaria (scope_id, ts, nonce) — un nonce repetido devuelve 409, no 401.
- Freno de fuerza bruta en el login: 10 intentos en 15 minutos por cuenta, best-effort.
- Todo 4xx/5xx se convierte en una señal de seguridad anónima; las de severidad alta abren una excepción que una persona revisa antes de cualquier bloqueo.
Prueba la audiencia internal a través de la app web, con tu propia cuenta: las cabeceras nacen solas, y todo lo que hagas ahí está dentro del alcance y del puerto seguro. Golpear /api/internal/v1/* directo con curl no prueba nada más que una colección de 401 — y encima genera ruido que alguien va a tener que revisar a mano.
Datos de pacientes
Qué no hacer
- No abras el examen.
- No hagas scroll.
- No tomes una captura de pantalla.
- No copies el ID "para revisarlo después".
Qué hacer
- Repórtalo de inmediato, con el mínimo detalle necesario para demostrar que el problema existe.
- La prueba de concepto demuestra el acceso, nunca el contenido — por ejemplo: "pude listar registros de otros workspaces mediante el endpoint X cambiando el parámetro Y", sin pegar el informe.
- Borra toda copia local: caché, capturas de pantalla, historial de Burp, logs de proxy.
- Nunca exfiltres, descargues, compartas, publiques ni intentes monetizar datos de pacientes — ni siquiera para demostrar el impacto.
Fundamento legal
El dato de salud es un dato personal sensible bajo la LGPD, la ley brasileña de protección de datos (art. 5.º, II en relación con el art. 11).
Y el §4.º del art. 154-A del Código Penal brasileño aumenta la pena de 1/3 a 2/3 por divulgar, comercializar o transmitir a un tercero los datos obtenidos — incluso cuando el acceso inicial fue autorizado. Es decir: el puerto seguro de esta política cubre que hayas entrado; no cubre que te hayas llevado algo.
Tem uma consequência que é sua, não só nossa: quem decide o que fazer com o dado é, por definição, o controlador dele. Se você baixar, guardar ou compartilhar o que achou, você deixa de ser alguém testando o sistema e vira isso sozinho — respondendo direto perante o titular nos termos dos dois regimes, sem cobertura nenhuma desta política. E tirar esse dado do bucket europeu para qualquer outro lugar também é transferência internacional de dado pessoal, com regime próprio nos dois lados: LGPD, arts. 33 a 36; GDPR, Capítulo V, arts. 44 a 49.
E se o que você achou não é uma falha em potencial, mas exposição que já aconteceu, o seu relatório é o que dispara, para nós, o prazo legal de notificar a autoridade e o titular — até 72 horas pelo GDPR (Art. 33), até 3 dias úteis pela LGPD (Resolução CD/ANPD nº 15/2024). É por isso que pedimos para reportar na hora, em vez de continuar investigando atrás de um achado mais completo.
Esto no es burocracia. Es que al otro lado de ese JSON hay un resultado de biopsia con nombre y apellido.
Reglas de participación
Mientras pruebas
- Probar con tus propias cuentas de prueba, o cuentas que creaste tú mismo.
- Usar herramientas automatizadas — escáneres, fuzzers — con sentido común.
- Detenerte ante la primera señal de dato real de paciente y reportarlo.
- Acceder, o intentar acceder, a la cuenta de otra persona.
- Hacer DoS volumétrico, o apuntar un escáner que dispare miles de peticiones por minuto contra producción — volcar tráfico no es investigación, es abuso.
- Usar ingeniería social contra nuestro equipo, nuestros pacientes o nuestros socios.
- Realizar un ataque físico.
Detenerte no es una sugerencia — es la regla más importante de esta página. El detalle completo está en Datos de pacientes.
Uso de IA en los informes
- Puedes usar IA para explorar o escribir — no vamos a fingir que eso no existe. Pero tú respondes por cada palabra y cada afirmación técnica del informe, generada por IA o no.
- Di explícitamente si una herramienta de IA ayudó.
- Todo informe necesita una prueba de concepto que funcione de verdad, reproducida por ti. La salida de un escáner o de un LLM sin confirmación manual no es una vulnerabilidad — es una hipótesis, y una hipótesis sin verificar se cierra como inválida.
Un informe fabricado, exagerado o con una PoC que no reproduce el problema se cierra sin respuesta detallada. La reincidencia termina en expulsión del programa.
En enero de 2026, el proyecto curl cerró por completo su programa de bug bounty después de que los informes generados por IA llegaran a superar por mucho a los informes válidos. En años de seguimiento, ningún informe producido solo por IA, sin verificación humana, encontró jamás una vulnerabilidad real.
No queremos llegar a eso.
Plazos de atención
-
Confirmación
Confirmamos la recepción de tu informe en un plazo máximo de 5 días hábiles.
-
Triaje
Evaluamos la severidad y te decimos hacia dónde va.
-
Corrección
Trabajamos en la corrección con prioridad proporcional a la severidad.
-
Aviso
Te avisamos cuando la corrección se publique.
-
Reconocimiento
Ofrecemos crédito público opcional — y nunca tomamos represalias contra la investigación de buena fe.
La escala completa de severidad y prioridad está en la sección Clasificación de severidad.
Divulgación pública
Pedimos 90 días corridos contados desde la confirmación del problema — no desde el envío, que es una fecha que solo tú controlas — antes de cualquier publicación.
Si la corrección sale antes, podemos acordar una fecha conjunta más temprana.
Si el problema está siendo explotado activamente por terceros ahora mismo, ese plazo se acorta — avísanos de inmediato.
Y nunca publiques datos de pacientes, credenciales reales ni nada que aumente el riesgo, incluso después del plazo.
Puerto seguro legal
En la práctica, nos comprometemos a:
- No iniciar ni respaldar ninguna acción civil, denuncia penal o parte policial contra ti por la investigación hecha dentro de esta política — incluidas las medidas técnicas usadas para acceder a un sistema en alcance.
- Si un tercero te amenaza o inicia una acción legal por esa investigación, declarar pública y formalmente que tu conducta fue investigación de seguridad autorizada y de buena fe.
Y esto tiene límites, tan visibles como la promesa:
- Solo vale para los sistemas listados en Alcance. No podemos autorizar investigación sobre un sistema de un tercero, aunque se pueda llegar a él desde el nuestro.
- No cubre conductas fuera del alcance ni fuera de las reglas de esta política.
- No cubre llevarte datos. Acceder para probar es una cosa; extraer es otra — mira Datos de pacientes y el §4 del art. 154-A, que agrava la pena justamente por eso.
- No aplica a investigación hecha para extorsionar o coaccionar a nadie, ni a quien esté excluido en Reconocimiento.
¿Nos estás probando desde fuera de Brasil? Esta autorización sigue apoyándose en la ley brasileña — es la que rige los sistemas que tocarías. Como cortesía, también entendemos esta política como una autorización de acceso de buena fe bajo la ley de delitos informáticos que aplique en tu país.
¿No estás seguro de si una prueba concreta encaja en esta política? Pregunta antes, en [email protected].
Fundamento legal en Brasil
En Brasil no existe la "CFAA" ni la "DMCA". Son leyes estadounidenses, y pegar esa sigla en una política brasileña no protege a nadie aquí — solo delata que el texto se tradujo, no se pensó.
Lo que sí se aplica es el art. 154-A del Código Penal brasileño (Ley n.º 12.737/2012, modificada por la Ley n.º 14.155/2021). Convierte en delito invadir un dispositivo informático ajeno "sin autorización expresa o tácita" de quien lo usa.
Hay un detalle que lo cambia todo. La redacción de 2012 solo se aplicaba cuando la invasión ocurría "mediante violación indebida de un mecanismo de seguridad" — había que romper alguna traba. La Ley n.º 14.155/2021 eliminó esa exigencia. Hoy el delito ya no depende de romper nada: depende solo de actuar sin autorización. La autorización se convirtió en el único elemento que decide.
Por eso esta página es la autorización expresa de la que habla la ley. Y eso es más fuerte que prometer no denunciarte: con autorización, el delito ni siquiera llega a existir — no es una defensa posterior, es la ausencia de un elemento del propio tipo penal. Una conducta autorizada nunca se convierte en delito.
Hallazgos no elegibles
No es que no nos importe — es que sin impacto demostrado no hay forma de distinguirlo del ruido.
Configuración y cabeceras
- Cabecera de seguridad ausente (CSP, HSTS, X-Frame-Options) sin una PoC de explotación real.
- Registro SPF, DKIM o DMARC ausente o mal configurado.
- Divulgación de versión de software en un banner, header o changelog público, sin explotación asociada.
- Ausencia de certificate pinning en una app móvil.
Interfaz e interacción
- Clickjacking en una página que no ejecuta ninguna acción sensible.
- Self-XSS — la víctima tiene que pegar su propio payload.
- Redirección abierta sin impacto adicional demostrado.
Enumeración y límites de tasa
- Enumeración de usuario o correo — descubrir si existe una cuenta.
- Ausencia de rate limiting sin prueba de un brute-force viable.
- CSV injection sin ejecución comprobada en el entorno de la víctima.
Infraestructura y disponibilidad
- Denegación de servicio volumétrica, o cualquier cosa que dependa de generar tráfico masivo.
- Un ataque que exige interceptar el tráfico de otra persona, sin una falla nuestra que lo haga posible.
Terceros y dependencias
- Una falla en una biblioteca de terceros, sin una PoC de explotación específica en nuestro entorno.
- Una falla en un servicio o infraestructura que no operamos nosotros.
Calidad del informe
- Salida de un escáner sin PoC manual y sin confirmación de explotación real.
- Informe generado por IA sin verificación humana y sin PoC reproducible.
Fuera del modelo de amenaza
- Ingeniería social contra nuestro equipo, nuestros socios o nuestros pacientes.
- Ataques físicos contra una oficina, un empleado o un dispositivo.
- Un bug que solo aparece en un navegador o sistema operativo obsoleto, sin soporte del fabricante.
- Un ataque que depende de que la víctima siga las instrucciones del propio atacante — pegar un comando, instalar una extensión.
¿Crees que tu caso es la excepción? Envíalo de todas formas y explica por qué. Esta lista es un filtro, no un muro.
Clasificación de severidad
La severidad decide una cosa: el orden de la cola de corrección. Nada más.
| Severidad | Criterio general | Ejemplos en diagnos |
|---|---|---|
| Crítica | Compromete la confidencialidad de más de un paciente, o rompe la garantía central del cifrado de extremo a extremo — sin que la víctima tenga que hacer clic en nada. |
|
| Alta | Compromete datos de un solo workspace, o da privilegio de administrador dentro de él — todavía sin interacción de la víctima. |
|
| Media | Tiene impacto real, pero limitado: exige un clic de la víctima, o expone metadatos en vez del contenido del informe. |
|
| Baja | Impacto mínimo, exige condiciones poco probables juntas, o es solo información — sin un camino claro hasta un dato de paciente. |
|
La clasificación final es nuestra — pero explicamos el razonamiento. Si no estás de acuerdo, dilo: lo reevaluamos.
Reconocimiento y elegibilidad
Cuatro cosas, en este orden — la primera duele un poco.
-
Dinero: cero.
Sin "lo estamos evaluando". Cero, literal. Somos una empresa pequeña, y el dinero que hay paga servidor y personas. Si eso cambia algún día, esta página cambia con ello — y serás de los primeros en saberlo.
-
Crédito de producto, quizá.
Podemos — a nuestro criterio y sin ninguna obligación — ofrecer crédito de uso de la plataforma. Sin valor pactado, sin garantía, no es negociable. No es un pago: es gratitud con una factura alrededor.
-
Un lugar en el salón de la fama.
Toda vulnerabilidad válida entra — con el nombre que elijas: tu nombre real, un apodo, un @ de red social o anónimo.
Ver el salón de la fama -
La gratitud de gente que nunca vas a conocer.
Al otro lado de esto hay médicos y pacientes que nunca van a saber tu nombre. Es poco. Lo sabemos. Pero es verdad.
Y a cambio pedimos una cosa: permiso para citar tu informe — técnico, sin datos de pacientes — en nuestro changelog de seguridad, cuando publiquemos la corrección.
Quién puede participar
Cualquiera puede reportar, y lo corregimos de todas formas. Lo que cambia es el crédito — sin reconocimiento público ni crédito de producto para:
- Quien trabaja o trabajó en MedDeck en los últimos seis meses — incluidos los contratistas.
- Familiar directo de alguien con información privilegiada sobre el sistema probado.
- Persona o entidad en una lista de sanciones (OFAC/SDN, Unión Europea) o en un país bajo embargo integral.
- Quien llegó hasta el fallo por incumplimiento de contrato o filtración interna, y no por investigación independiente.
Cómo enviar un reporte
La mayoría de los reportes entran por el buzón estándar. El otro existe para cuando esperar realmente sale caro.
El canal estándar
Todo reporte entra por aquí — es el buzón que leemos primero, siempre.
Enviar reporteSolo cuando esperar sale caro
Explotación activa ocurriendo ahora mismo. Datos de un paciente ya expuestos públicamente. Una credencial filtrada. Este buzón es para eso — y solo para eso.
Esto no puede esperar Qué debe incluir el reporte
- Pasos de reproducción numerados, en el orden en que realmente los hiciste.
- El impacto real — qué puede HACER un atacante, no solo "conseguí X".
- Entorno, navegador y cuenta que usaste.
- Una prueba de concepto mínima y no destructiva.
No hace falta que esté en inglés ni con formato de CVE. La claridad vale más que la formalidad.
Mantén todo en el canal privado con nosotros hasta que acordemos juntos la divulgación pública.
El archivo que hace este trabajo por ti. Ya está publicado, y es por donde una herramienta automática nos encuentra antes de que cualquier humano lea esto: /.well-known/security.txt
Reportes cifrados
Todavía no publicamos una clave PGP. ¿Quieres cifrar igual? Pídenosla por correo y te mandamos cómo hacerlo.
Preguntas frecuentes
¿De verdad no pagan nada?
Nada. Ni dinero, ni cripto, ni una camiseta. Podemos ofrecer crédito de producto cuando tenga sentido, sin ninguna garantía — es gratitud con límite, no un precio disfrazado.
¿Puedo probar con mi cuenta real?
Puedes, y es el modo recomendado si eres de la audiencia interna — mira la sección "Alcance". Lo que nunca puedes hacer, bajo ninguna circunstancia, es probar con la cuenta de otra persona.
Encontré datos de un paciente. ¿Y ahora?
Detente. No abras el examen, no hagas scroll, no copies el ID "para confirmar después". Reporta el hallazgo sin pegar el contenido del informe — la sección "Datos de pacientes" trae el paso a paso, y no es burocracia: es la diferencia entre investigación de seguridad y delito.
¿Cuánto tardan en responder?
Confirmamos la recepción en un plazo de 5 días hábiles; después, te damos una posición sobre la severidad y los próximos pasos. Es una meta de atención que nos exigimos, no una cláusula de SLA contractual.
¿Puedo publicar lo que encontré?
Sí — 90 días corridos después de confirmado el problema, o antes si acordamos una fecha juntos. Nunca con datos de pacientes dentro, ni siquiera después del plazo.
Usé IA para encontrar esto. ¿Hay algún problema?
Ninguno, siempre que lo hayas verificado y reproducido tú mismo, en un entorno real. Una salida de IA sin esa comprobación no es una vulnerabilidad, es una hipótesis — la sección "Reglas" explica por qué.
¿Me van a demandar?
No, si seguiste esta política. La sección "Puerto seguro" es, en una frase, la autorización expresa que exige el art. 154-A del Código Penal brasileño para que lo que estás por hacer no sea delito — no es retórica, es el texto de la ley.
Ya reporté y no tuve respuesta.
Reenvía mencionando la fecha del primer envío — el correo se pierde. Si es realmente urgente, usa el buzón de urgencia. No es desdén: somos un equipo pequeño, no un centro de operaciones de seguridad 24 horas.
Eso es todo. Adelante.
Si llegaste hasta aquí, ya te importan los datos de estos pacientes más que a mucha gente que trabaja con ellos todos los días. Gracias — y buena caza.
Reportar una falla