Legal · English text prevails · all documents

Vulnerability Disclosure Policy

We want to hear about security problems in Vilkax before anyone else does. This policy tells you how to report one, what you may and may not do while looking, and what we commit to in return. It is the policy referred to in our security.txt.

How to report

Email security@vilkax.com. Include what you found, where, how to reproduce it, and what impact you believe it has. Screenshots and proof-of-concept requests help; a working exploit is not needed. If you want to encrypt, ask for our current key in your first message. You may report anonymously.

We acknowledge within one business day, tell you within five business days whether we can reproduce the issue and how we rate it, and keep you informed until it is fixed.

Scope

In scope: vilkax.com and its subdomains, the Vilkax API, the mobile apps, the desktop apps, the browser extension, the VPN app, and the infrastructure we operate.

Named explicitly, because they are where phishing-resistant authentication actually fails: the passkey enrolment and recovery flows, and the account-reset path. Published research through 2026 is consistent that FIDO2 cryptography holds while accounts still fall, because the ceremony runs through a browser, an operating system, a password manager, a sync service and a recovery route, and an attacker needs only one of them. Concretely, we want to hear about:

• any way to register a passkey on an account without satisfying the freshness gate, or to keep a credential alive after the account has revoked it;
• any assertion accepted with a user-verification flag weaker than the one the ceremony requested, or a challenge from one account or origin accepted for another;
• any recovery, device-migration or "verify your new phone" route that reaches a working session with less assurance than signing in normally does;
• any way to make an operator action grant authentication rather than start the same delayed, notified flow the account holder could start themselves.

Test these against your own account. That is the line: the flows are in scope, the humans are not - we do not want anyone phoning our support team, and a report obtained that way cannot be accepted however real the underlying weakness. If you believe a weakness is only reachable by deceiving a person, describe the path and we will reproduce it ourselves.

Out of scope, please do not test:

• the systems of our providers and partners (Cloudflare, Stripe, Mailgun, the VPN providers, the app stores, the mailbox providers), which have their own programmes;
• social engineering of our staff or users, physical attacks, and denial of service of any kind;
• reports from automated scanners with no demonstrated impact, missing best-practice headers with no exploit, rate-limit findings on endpoints that are rate-limited by design, and "self" issues that affect only your own account or device.

Rules for good-faith research

While researching you must:

• use only accounts and devices you own or have permission to test, and only test data you created;
• stop and report as soon as you can demonstrate the problem; do not go further to prove impact;
• not access, copy, modify or delete other people's data, and delete any you obtained unintentionally, telling us what it was;
• not disrupt the service, degrade it for other users, or run automated attacks at volume;
• not publish the vulnerability before we have fixed it or 90 days have passed, whichever is first, and coordinate the wording of any publication with us.

What we promise

If you follow these rules, we treat your research as authorised. We will not pursue or support legal action against you under computer-misuse, copyright or contract law for research that keeps to this policy, and we will say so to any third party who asks. Where a third party brings a claim, we will make clear that your actions were conducted in accordance with this policy. Lithuanian and Spanish criminal law both recognise authorisation as a defence to unauthorised-access offences; this policy is that authorisation, within its terms.

We fix confirmed vulnerabilities as quickly as their severity warrants, we tell you when the fix ships, and we credit you by the name you choose in the Credit section below unless you prefer not to be named. We do not currently pay bounties; if that changes, this page will say so.

Credit

We credit researchers here, on this page, by the name you choose, once the fix has shipped - or not at all if you would rather stay anonymous, which is equally fine and needs no explanation. This section is also the Acknowledgments target in our security.txt.

No reports have been credited yet. That is a statement of fact rather than a claim about our security, and this line will be replaced by names as they are earned.

Handling your data

We use your report and contact details only to handle the report and to credit you. They are kept for as long as the issue and its fix are relevant, and are not shared except with a provider whose system is affected, and then only what they need.

Data breaches

If a report shows that personal data has been accessed, we treat it as a personal data breach under Article 33 GDPR from the moment we confirm it, assess it under our breach procedure, and notify the supervisory authority within 72 hours and affected people without undue delay where the law requires it.

Changes

We update this policy as our programme develops. The version and date are at the foot of the page, and every version is kept on the legal hub.

Last updated: 2026-09-06 · Version v1