Home / Legal / Vulnerability Disclosure Policy

Vulnerability Disclosure Policy

Version 1.1 · Effective date: October 14, 2026 · Last updated: October 11, 2026

We welcome reports from security researchers. If you believe you have found a vulnerability in LiKE, please let us know.

How to report

Email [email protected], one email per issue, in English or Russian, with:

  • a description of the issue and its impact;
  • steps to reproduce it (a short video or screenshots help);
  • the affected URL or endpoint;
  • your name or handle, if you would like to be listed on this page.

Please do not include other people's personal data in your report.

We review all reports we receive. We may contact you if we need more information.

What we care about most

  • access to data in another customer's workspace or organisation;
  • bypassing authentication or taking over another user's account;
  • authorisation flaws in our API;
  • getting our AI features to reveal data from a workspace you don't have access to.

Scope

In scope: lynkora.pro and its subdomains operated by Lynkora, including customer workspaces (*.lynkora.pro), and our API.

Out of scope: third-party services we use (for example, payment checkout and email delivery providers), and any system not operated by Lynkora.

Rules

  • Test only with accounts and workspaces you own. Register your own account at lynkora.pro for testing.
  • To help us tell your testing apart from real activity, please register with a +security tag in your email address if your provider supports it (for example, [email protected] — emails still arrive in your usual inbox) and include "test" in your workspace name. Please delete your test accounts when you are done.
  • Do not access, modify or delete data that belongs to others. If you reach someone else's data by accident, stop, do not keep a copy, and tell us.
  • Do not brute-force passwords, use leaked credentials, or create more than a few accounts.
  • When testing rate limits, send no more than 10 requests. That is enough to show the issue.
  • Do not run denial-of-service or load tests, automated scans at high volume, social engineering, phishing, or physical attacks.
  • Do not make real or fraudulent payments.
  • Do not disclose the issue publicly until we have released a fix (90-day non-disclosure period).

Not accepted

We do not accept reports of:

  • issues already known to us or previously reported;
  • theoretical issues without a proof of concept;
  • automated scanner output without a demonstrated impact;
  • missing security headers or cookie flags without a working attack;
  • clickjacking on pages without sensitive actions;
  • SPF, DKIM or DMARC configuration;
  • denial of service, load testing or rate limits on non-authentication endpoints;
  • social engineering or physical attacks;
  • account or email enumeration;
  • password policy (length or complexity);
  • software version disclosure, banner grabbing or verbose error pages without sensitive data;
  • issues that require a compromised device, man-in-the-middle position or unlikely user interaction;
  • self-XSS, logout CSRF, or CSRF on forms without sensitive actions;
  • ways to exceed plan limits (for example, AI token or seat limits) without access to other customers' data;
  • AI model behaviour, such as jailbreaks, prompt injection or inaccurate answers, unless it exposes data from a workspace you don't have access to.

Rewards

We do not run a paid bug bounty program and do not pay for reports. With your consent, we may list your name on this page for valid, in-scope findings once they are fixed.

Good faith

We consider research carried out in good faith and in line with these rules to be authorised.

Acknowledgments

We thank the following researchers for responsibly reporting issues:

(none yet)

---

We may update this policy from time to time.

Version 1.1, effective from 2026-10-13