Inicio / Aviso legal / Política de divulgación de vulnerabilidades

Política de divulgación de vulnerabilidades

Versión 1.1 · Fecha de entrada en vigor: 14 de octubre de 2026 · Última actualización: 11 de octubre de 2026

Traducción facilitada a título informativo y para su comodidad. Únicamente la versión en inglés de este documento tiene validez jurídica; en caso de discrepancia, ambigüedad o contradicción, prevalecerá el texto en inglés.

Agradecemos los informes de los investigadores de seguridad. Si cree haber encontrado una vulnerabilidad en LiKE, le rogamos que nos lo comunique.

Cómo informar

Envíe un correo electrónico a [email protected], un correo por cada problema, en inglés o en ruso, que incluya:

  • una descripción del problema y de su impacto;
  • los pasos para reproducirlo (un vídeo breve o capturas de pantalla son de ayuda);
  • la URL o el endpoint afectados;
  • su nombre o alias, si desea figurar en esta página.

Le rogamos que no incluya datos personales de otras personas en su informe.

Revisamos todos los informes que recibimos. Podemos ponernos en contacto con usted si necesitamos más información.

Lo que más nos importa

  • el acceso a datos del espacio de trabajo o de la organización de otro cliente;
  • la elusión de la autenticación o la toma de control de la cuenta de otro usuario;
  • los fallos de autorización en nuestra API;
  • conseguir que nuestras funciones de IA revelen datos de un espacio de trabajo al que usted no tiene acceso.

Alcance

Dentro del alcance: lynkora.pro y sus subdominios operados por Lynkora, incluidos los espacios de trabajo de los clientes (*.lynkora.pro), y nuestra API.

Fuera del alcance: los servicios de terceros que utilizamos (por ejemplo, los proveedores de pasarela de pago y de envío de correo electrónico) y cualquier sistema no operado por Lynkora.

Reglas

  • Realice pruebas únicamente con cuentas y espacios de trabajo de su propiedad. Registre su propia cuenta en lynkora.pro para realizar las pruebas.
  • Para ayudarnos a distinguir sus pruebas de la actividad real, le rogamos que se registre con la etiqueta +security en su dirección de correo electrónico, si su proveedor lo admite (por ejemplo, [email protected] — los correos siguen llegando a su bandeja de entrada habitual), e incluya "test" en el nombre de su espacio de trabajo. Le rogamos que elimine sus cuentas de prueba cuando haya terminado.
  • No acceda a datos que pertenezcan a otras personas, ni los modifique o elimine. Si accede por accidente a datos de otra persona, deténgase, no conserve ninguna copia e infórmenos.
  • No realice ataques de fuerza bruta contra contraseñas, no utilice credenciales filtradas ni cree más de unas pocas cuentas.
  • Al probar los límites de frecuencia (rate limits), no envíe más de 10 solicitudes. Es suficiente para demostrar el problema.
  • No realice pruebas de denegación de servicio o de carga, escaneos automatizados de gran volumen, ingeniería social, phishing ni ataques físicos.
  • No realice pagos reales ni fraudulentos.
  • No divulgue públicamente el problema hasta que hayamos publicado una corrección (período de no divulgación de 90 días).

Informes no aceptados

No aceptamos informes sobre:

  • problemas que ya conocemos o que se han comunicado anteriormente;
  • problemas teóricos sin prueba de concepto;
  • resultados de escáneres automatizados sin un impacto demostrado;
  • la ausencia de cabeceras de seguridad o de atributos (flags) de cookies sin un ataque funcional;
  • clickjacking en páginas sin acciones sensibles;
  • la configuración de SPF, DKIM o DMARC;
  • la denegación de servicio, las pruebas de carga o los límites de frecuencia en endpoints que no sean de autenticación;
  • la ingeniería social o los ataques físicos;
  • la enumeración de cuentas o de direcciones de correo electrónico;
  • la política de contraseñas (longitud o complejidad);
  • la divulgación de versiones de software, el banner grabbing o las páginas de error detalladas sin datos sensibles;
  • problemas que requieran un dispositivo comprometido, una posición de man-in-the-middle o una interacción improbable del usuario;
  • self-XSS, CSRF en el cierre de sesión (logout CSRF) o CSRF en formularios sin acciones sensibles;
  • formas de superar los límites del plan (por ejemplo, los límites de tokens de IA o de plazas) sin acceso a datos de otros clientes;
  • el comportamiento del modelo de IA, como jailbreaks, prompt injection o respuestas inexactas, salvo que exponga datos de un espacio de trabajo al que usted no tiene acceso.

Recompensas

No gestionamos ningún programa de bug bounty remunerado y no pagamos por los informes. Con su consentimiento, podemos incluir su nombre en esta página por hallazgos válidos y dentro del alcance, una vez corregidos.

Buena fe

Consideramos autorizada la investigación realizada de buena fe y de conformidad con estas reglas.

Agradecimientos

Agradecemos a los siguientes investigadores que hayan comunicado problemas de forma responsable:

(todavía ninguno)

---

Podemos actualizar esta política de vez en cuando.

Versión 1.1, en vigor desde el 2026-10-13