¿Puedo publicar sobre vulnerabilidades sin parches?
Publicar vulnerabilidades sin parches en Meta es una mala idea, y no solo por razones éticas: podés quedar expuesto legalmente y, en el peor caso, convertirte vos mismo en el responsable de un ataque masivo. La política oficial de Meta establece un proceso claro de divulgación responsable con plazos definidos, canales específicos y un programa de recompensas que en 2024 distribuyó más de 2,3 millones de dólares a investigadores.
En 30 segundos
- Publicar una vulnerabilidad sin parche en Meta antes de que la empresa la corrija va contra su política de divulgación responsable y puede generar responsabilidad civil o penal.
- Meta tiene un programa Bug Bounty activo: pagó 2,3 millones de dólares a cerca de 200 investigadores en 2024, según el informe oficial de Facebook Engineering.
- El proceso correcto es: reportar en privado, esperar respuesta en 21 días, y dar 90 días para el parche antes de considerar cualquier divulgación pública.
- Publicar un exploit activo sin coordinar con el proveedor tiene nombre: divulgación no coordinada, y puede activar la Ley de Fraude y Abuso Informático (CFAA) en EE.UU. o equivalentes locales.
- Hay tres tipos de divulgación: responsable (privada, coordinada), pública (último recurso) y zero-day (máximo riesgo para todos).
¿Podés publicar vulnerabilidades sin parches en Meta?
La divulgación responsable es el proceso por el cual un investigador de seguridad comunica una vulnerabilidad directamente al proveedor afectado antes de hacerla pública, dándole tiempo para desarrollar y distribuir un parche. Es la práctica estándar en la industria de ciberseguridad y el único camino que Meta reconoce como legítimo dentro de su programa de Bug Bounty.
La respuesta corta es no. Y la respuesta larga también es no, pero con matices.
Si encontrás un bug de seguridad en Facebook, Instagram, WhatsApp o cualquier producto de Meta y lo publicás antes de que haya un parche disponible, estás exponiendo a millones de usuarios a un ataque que nadie puede prevenir todavía. Eso no es investigación de seguridad: es una bomba con mecha encendida.
Dicho esto, “publicar” no es una categoría única. Hay una diferencia enorme entre compartir detalles técnicos con el equipo de seguridad de Meta (lo correcto), publicar un post general sin el exploit funcional (zona gris), y subir un proof-of-concept que cualquiera puede ejecutar antes del parche (riesgo legal alto, daño real, sin justificación).
Política oficial de divulgación responsable de Meta
Según la política oficial de Meta, el proceso tiene plazos definidos que son bastante estándar en la industria:
- 21 días para recibir una respuesta inicial del equipo de seguridad.
- 90 días como plazo máximo para que Meta desarrolle y libere el parche.
- Durante ese período, el investigador no debe divulgar públicamente ningún detalle técnico de la vulnerabilidad.
- Meta puede pedir una extensión si el fix es particularmente complejo, pero debe justificarlo.
Si Meta no responde en 21 días o no parcheó en 90 días, el investigador tiene más margen para escalar hacia la divulgación pública. Pero incluso ahí, la recomendación de la industria es avisar antes de publicar. Complementá con regulaciones en diferentes jurisdicciones.
Hay excepciones. Si la vulnerabilidad está siendo explotada activamente en el momento del descubrimiento, los tiempos cambian. En ese caso, coordinar con Meta y, potencialmente, con organismos de ciberseguridad como CISA (en EE.UU.) o INCIBE (en España) tiene sentido para acelerar la respuesta.
Tres caminos de divulgación: cuál aplica en cada caso
Ponele que encontrás un bug crítico en la API de Instagram que permite acceder a mensajes privados sin autenticación. ¿Qué hacés?
| Tipo de divulgación | Qué implica | Riesgo legal | Recomendado para |
|---|---|---|---|
| Responsable (coordinada) | Reportás en privado, esperás el parche, después podés publicar | Bajo (con buena fe demostrable) | La mayoría de los casos |
| Pública no coordinada | Publicás sin avisar al proveedor, o antes del parche | Alto: responsabilidad civil y penal | Nunca, básicamente |
| Zero-day completo | Publicás exploit funcional antes del parche | Máximo: vulnerabilidad activa, actores maliciosos lo usan | Bajo ninguna circunstancia normal |
La divulgación pública como “último recurso” existe cuando un proveedor ignora repetidamente los reportes o directamente niega la vulnerabilidad. En ese caso, el investigador puede optar por publicar para forzar una respuesta. Pero incluso ahí, la práctica aceptada es dar un aviso final antes de hacerlo público.
Consecuencias legales: lo que se juega quien publica antes de tiempo
Las consecuencias no son hipotéticas.
En EE.UU., la Computer Fraud and Abuse Act (CFAA) penaliza el acceso no autorizado a sistemas informáticos, y “acceso no autorizado” se ha interpretado de forma muy amplia por los tribunales. Publicar un exploit funcional puede calificar, incluso si vos no lo usás: porque facilitás que otros lo hagan.
En Argentina, el artículo 153 bis del Código Penal tipifica el acceso ilegítimo a sistemas informáticos. En España, el artículo 197 bis del Código Penal cubre situaciones similares. La mayoría de los países latinoamericanos tienen equivalentes. Cubrimos ese tema en detalle en opciones de alojamiento seguro.
¿Y si lo publicás sin datos sensibles, solo describiendo el tipo de vulnerabilidad? Zona gris. Depende del nivel de detalle técnico y de si alguien puede replicar el ataque con esa información. La regla práctica: si un atacante puede armar un exploit con lo que publicás, es suficiente para que haya daño.
El daño financiero también puede ser tuyo. Si una empresa puede demostrar que tu divulgación prematura causó pérdidas, puede demandarte civilmente. Equifax perdió entre 500 y 700 millones de dólares en el breach de 2017 que expuso datos de 147,9 millones de personas. Nadie quiere estar en el lado equivocado de ese tipo de números.
Programa de Bug Bounty de Meta: la alternativa con recompensa
Meta tiene uno de los programas de Bug Bounty más activos del mundo. En 2024, según el reporte anual de Facebook Engineering, pagó 2,3 millones de dólares a cerca de 200 investigadores de seguridad de todo el mundo.
El alcance del programa cubre todos los productos principales: Facebook, Instagram, WhatsApp, Messenger, Oculus y los servicios de publicidad de Meta. Los detalles de scope están publicados en bugbounty.meta.com/scope/.
Las recompensas varían según el impacto:
- Vulnerabilidades críticas (ejecución remota de código, acceso a datos de millones de usuarios): pueden superar los 100.000 dólares.
- Bugs de impacto alto pero más acotado: entre 10.000 y 50.000 dólares.
- Vulnerabilidades de impacto medio: desde 500 dólares.
La condición principal para recibir el pago es la divulgación responsable: no publicar nada hasta que Meta libere el parche o dé autorización explícita. Los investigadores que participan del programa tienen protección legal: Meta se compromete a no iniciar acciones legales contra investigadores que actúen de buena fe siguiendo las reglas del programa.
Cómo reportar correctamente una vulnerabilidad a Meta
El canal oficial es HackerOne, plataforma que Meta usa para centralizar los reportes de su programa Bug Bounty. El proceso paso a paso:
- Paso 1: No publicás nada en redes, foros ni grupos antes de completar el proceso.
- Paso 2: Documentás la vulnerabilidad con todos los detalles técnicos: sistema afectado, pasos para reproducirla, impacto potencial, capturas de pantalla o video si aplica.
- Paso 3: Enviás el reporte a través de HackerOne al programa de Meta. También podés usar el formulario directo en el sitio de Bug Bounty.
- Paso 4: Esperás la respuesta inicial (plazo: 21 días según la política oficial).
- Paso 5: Colaborás con el equipo de seguridad de Meta durante el proceso de validación y fix.
- Paso 6: Una vez que Meta confirma el parche lanzado, podés publicar tu investigación si querés.
En el reporte incluí: URL afectada o superficie de ataque, descripción del bug, pasos exactos para reproducirlo, impacto estimado (cuántos usuarios, qué tipo de datos), y cualquier referencia técnica relevante (CVE si ya existe, CWE del tipo de vulnerabilidad). Más información, más fácil para el equipo de seguridad priorizarlo y más chances de que la recompensa sea alta. Esto se conecta con lo que analizamos en cumplimiento regulatorio en fintech.
Casos históricos: cuándo falló la divulgación responsable
El caso más reciente y claro viene de Windows. Un investigador que documentó vulnerabilidades bajo el nombre “Chaotic Eclipse” reportó fallos de seguridad en Windows a Microsoft. Tras meses sin respuesta satisfactoria, publicó los exploits. El resultado fue que cibercriminales tomaron esa información y la usaron en ataques reales antes de que Microsoft pudiera parchear. (Como dato curioso: el investigador luego admitió que publicó por frustración, no porque hubiera seguido un proceso coordinado de escalamiento.)
¿Y el impacto de no parchear a tiempo? WannaCry en 2017 lo muestra con números concretos: el ransomware explotó EternalBlue, una vulnerabilidad en SMBv1 de Windows que la NSA conocía y mantenía como zero-day. Cuando Shadow Brokers la filtró, Microsoft publicó el parche. Pero miles de organizaciones que no habían aplicado el parche quedaron expuestas. Más de 200.000 sistemas en 150 países infectados. Daños estimados entre 4.000 y 8.000 millones de dólares.
La lección de Equifax es igual de directa: una vulnerabilidad en Apache Struts (CVE-2017-5638) con parche disponible desde marzo de 2017 fue explotada en mayo del mismo año porque Equifax no lo aplicó. 147,9 millones de personas vieron sus datos comprometidos. La empresa pagó hasta 700 millones de dólares en multas y compensaciones.
Ninguno de estos casos hubiese pasado si el parche se hubiera aplicado a tiempo. La divulgación responsable existe precisamente para crear esa ventana de tiempo donde el parche puede llegar antes que los actores maliciosos.
Errores comunes al reportar vulnerabilidades
Publicar en redes antes de recibir respuesta
El error más frecuente. El investigador reporta, no recibe respuesta en 48 horas y publica en Twitter/X o en un foro técnico para “presionar”. Resultado: la vulnerabilidad queda expuesta, Meta puede argumentar que se violaron los términos del programa y la recompensa se cancela. Si alguien la usa antes del parche, el investigador puede quedar asociado al daño. En principios de contenido online profundizamos sobre esto.
Confundir “divulgación responsable” con “silencio indefinido”
El otro extremo: investigadores que reportan, esperan seis meses, no reciben update y siguen esperando. Los 90 días existen precisamente para eso. Si Meta no parcheó en ese plazo y no justificó la demora, tenés el derecho (y en algunos contextos, la obligación ética) de escalar. Primero avisando que vas a publicar, después publicando si no hay respuesta.
Reportar sin documentación suficiente
Un reporte que dice “encontré una vulnerabilidad en el login de Instagram” sin pasos reproducibles, sin capturas, sin descripción del impacto, va directo al archivo. Los equipos de seguridad de empresas del tamaño de Meta reciben cientos de reportes por semana. Los que priorizan son los que tienen suficiente información para validar rápido. Un buen reporte también es la diferencia entre una recompensa mínima y una significativa.
Podés ampliar esto leyendo Can I post about unpatched security vulnerabilities on Faceb, donde lo explicamos en detalle.
Preguntas Frecuentes
¿Puedo publicar sobre vulnerabilidades de seguridad sin parches en Meta?
No podés publicar detalles técnicos de una vulnerabilidad activa en Meta antes de que haya un parche disponible. La política oficial de Meta establece un proceso de divulgación responsable con 21 días para respuesta y 90 días para el fix. Publicar antes de ese plazo viola los términos del programa Bug Bounty y puede derivar en consecuencias legales.
¿Cuáles son las consecuencias legales de divulgar vulnerabilidades sin parches?
Depende del país y del nivel de detalle publicado. En EE.UU., la CFAA puede aplicar si la divulgación facilita acceso no autorizado a sistemas. En Argentina, el artículo 153 bis del Código Penal cubre accesos ilegítimos a sistemas. Si la empresa puede demostrar daños causados por la divulgación prematura, también puede ejercer acciones civiles por responsabilidad.
¿Cuál es la política oficial de Meta para reportar vulnerabilidades?
Meta tiene un programa Bug Bounty activo gestionado a través de HackerOne. El proceso requiere reportar en privado, sin divulgación pública durante el período de fix (máximo 90 días). Meta se compromete a responder en 21 días y a no iniciar acciones legales contra investigadores que actúen de buena fe siguiendo las reglas del programa.
¿Cómo reportar correctamente una vulnerabilidad a Meta?
El canal correcto es HackerOne, a través del programa Bug Bounty oficial de Meta. El reporte debe incluir descripción técnica detallada, pasos para reproducir la vulnerabilidad, impacto estimado y capturas o video demostrativo. No publicar nada en redes ni foros hasta que Meta confirme el parche lanzado.
¿Puedo ganar dinero reportando vulnerabilidades a Meta/Facebook?
Sí. Meta pagó 2,3 millones de dólares a cerca de 200 investigadores en 2024. Las recompensas van desde 500 dólares para vulnerabilidades de impacto medio hasta más de 100.000 dólares para bugs críticos como ejecución remota de código. La condición para recibir el pago es seguir el proceso de divulgación responsable completo.
Conclusión
Publicar vulnerabilidades sin parches en Meta no es una opción responsable, y en muchos casos tampoco es una opción legal. El proceso existe, está documentado, tiene plazos razonables y viene con un incentivo económico concreto: más de dos millones de dólares distribuidos solo en 2024.
Si encontrás un bug real en algún producto de Meta, el camino es claro: reportar en privado a través de HackerOne, documentar bien, esperar el plazo y recién publicar después del parche. Si Meta no responde o no parcheó en 90 días, ahí sí tenés margen para escalar, pero siempre avisando antes.
La divulgación responsable no es solo un protocolo burocrático. WannaCry y Equifax dejan claro lo que pasa cuando esa ventana de tiempo no existe o no se respeta. El beneficio de seguir el proceso es para todos, incluyendo para vos como investigador: protección legal, recompensa económica y la posibilidad de publicar tu trabajo con el crédito completo una vez que el fix está activo.
