Break it, and we’ll pay you
LunoVPN runs a paid bug bounty for security issues in our client applications, VPN infrastructure and backend. Rewards run from $25 for low-impact client issues to $300 for anything that decrypts traffic or de-anonymises users. Eleven reports were fixed under the programme in August 2026. No report is marked closed until the researcher who found it has been invited to retest the fix, and every closed report is published on this page 90 days later. Researchers who follow the rules here have safe harbour, can publish their own findings, and can be paid in Monero without telling us who they are.
Eleven fewer ways to break LunoVPN
In August 2026, eleven reports were triaged, fixed and closed under this programme. Every one of them came from someone outside the company who had no obligation to tell us anything.
August 2026
first response
per report
is published here
anything is closed
Thank you to the people
who broke it first
We are trying to build the best and safest VPN there is — for everyone, not only for the people who already know what a DNS leak is. We cannot do that from the inside alone.
A VPN is a promise that something is safe. The only honest way to keep a promise like that is to invite people who are good at breaking things, let them try properly, and then fix what they find — quickly, and in public. Eleven researchers did exactly that last month.
None of them had to. They could have sold what they found, published it without warning, or simply moved on. Instead they wrote it up, waited for a patch, and made the product safer for people they will never meet — people who will never know their names and never thank them. Every LunoVPN user is running a better VPN because of it.
That is also why the researcher retest stage below exists, and why every closed report ends up on this page. A fix nobody checked is a hope. A problem nobody published is a problem the next provider gets to repeat.
If that is you: thank you. If it could be, the scope and the rules are below — and the safe harbour is real.
What we pay
Bands rather than fixed prices, because impact varies. We would rather err upward on a report that genuinely protects users.
| Severity | Reward | Examples |
|---|---|---|
| Critical | $200 – $300 | Remote code execution on a VPN node, key compromise, traffic decryption, or anything that de-anonymises users at scale. |
| High | $100 – $200 | Authentication bypass, cross-account access, leaking one user's traffic metadata to another, kill-switch bypass. |
| Medium | $50 – $100 | DNS or WebRTC leaks in a shipped client, privilege escalation on the local device, stored data that should not persist. |
| Low | $25 – $50 | Client-side issues with limited impact, verbose error output, weak defaults that reduce protection. |
Follow the rules below and we will not pursue legal action, will not ask you to stay silent, and will not require you to sign anything to receive a bounty. If you need that in writing before you start, email us and we will send it.
A patch is not a fix until someone tries to get past it
A fix can close the exact path you reported and leave a neighbouring one wide open. The proof of concept stops working, the ticket gets closed, and the underlying weakness is still there. So we added a stage: nothing is marked closed until the person who found it has had the chance to attack the fix.
Reported
You email [email protected]. We acknowledge within two business days and tell you who is handling it.
Triaged
We reproduce it, assign a severity band and confirm the reward — within seven days. The band is fixed at triage, not at close, so a slow fix never costs you money.
Remediated
We build and ship the fix, then tell you what changed and where. Not “resolved” — what we actually altered, so you have something concrete to test against.
Researcher retest New
Before anything is closed, you are invited to retest. Specifically: check whether the original attack path is gone, and whether the remediation can be bypassed — alternative paths, edge cases, a variant of the same class. The same safe harbour and the same scope rules apply to the retest.
It is voluntary and there is no penalty for declining. If you are unavailable or would rather not, we route the retest to another researcher who works in that vulnerability class. If the retest turns up a bypass, that is a new report and it pays like one — at its own severity band, not as a footnote to the old one.
The retest window is 14 days from the moment we tell you the fix is live. If we hear nothing, the report moves on without it; we do not hold a fix hostage to a reply that may never come.
Closed
The retest passed, or the window elapsed. The bounty is paid at this point if it has not been already, and the 90-day publication clock starts.
Published
Ninety days after close, the report appears in the ledger below with what it was, what it affected and what we changed. You can publish your own account whenever you like, as soon as the fix ships.
The retest step was proposed in September 2026 by someone taking part in the programme, who pointed out that we were treating “the proof of concept no longer works” as if it meant “the vulnerability is gone”. They were right, and they offered to retest their own findings for free. We would rather adopt the idea for everyone than accept the favour once. If you have a suggestion about how this programme runs, the same address works for that.
Every report, published 90 days later
Ninety days after a report is closed it is published here, whether it makes us look careful or careless. No editorial discretion, no quiet exceptions for the embarrassing ones. Two tables: what is in the pipeline right now, and what has come out the other side.
In the pipeline
updated 12 September 2026Open reports appear here as soon as they are triaged, but without technical detail — a reference, when it arrived, roughly what it touches, its severity band and the stage it has reached. That is deliberate: a live list of unpatched issues with reproduction steps would be a map for whoever reads it fastest.
| Ref | Received | Area | Severity | Stage |
|---|---|---|---|---|
| Nothing open at the moment.No reports are currently awaiting triage, remediation or retest. When one arrives it will be listed here within two business days of being triaged. | ||||
Published
90 days after closeOnce the clock runs out, the full entry goes up: what the issue was, which component it affected, the dates at each stage, whether a retest was carried out, and what we changed. Credit to the reporter if they want it, and nothing about them if they do not.
| Ref | Area | Severity | Reported | Fixed | Retested | Published |
|---|---|---|---|---|---|---|
| Empty, and that is the honest state of it.Nothing has passed its 90 days yet. The eleven reports fixed in August 2026 predate both this ledger and the retest stage — they were triaged, patched and closed before either existed — so we are writing them up retrospectively, and each appears above as it reaches its own 90-day mark. The first of them is due on 30 October 2026. Reports arriving from now on go through the full pipeline, retest included; the earliest of those becomes publishable in December. | ||||||
What a published entry will look like
simulationThe tables above are empty, so here is the format instead. Step through a report and watch what the public can see at each stage — and what stays back until the 90 days are up.
What the public sees
A report sits unlisted until it has been triaged. We will not publish a severity band we have not verified, and a row that says “something, somewhere, unknown” helps nobody.
Held back
- That a report exists at all
- Component, severity, everything
What the public sees
The row appears within two business days of triage. “Android client” is as specific as it gets while the issue is live — enough for you to see we are working, not enough to go looking.
Held back
- What the vulnerability actually is
- Reproduction steps and proof of concept
- Which code path or component
- Who reported it
- Reference, date, area, severity, stage
What the public sees
The fix is live, so the stage moves — but the detail stays back. Users on old app versions are still exposed until they update, and a description now would tell an attacker exactly who to look for.
Held back
- What the vulnerability was
- What the fix changed
- Reproduction steps
- Who reported it
- That a fix has shipped
What the public sees
In this simulated case the retest found a bypass: the same leak returned when the device was toggled through airplane mode. It was logged as a separate report, paid at its own band, and fixed in four days. Without this stage the original would have been closed on day 11 with the bug still reachable.
Held back
- Technical detail, still
- The bypass found during retest
- That a retest is under way, and its deadline
What the public sees
The publication date becomes public the moment the report closes. It is a commitment with a date on it, which is the only kind that means anything.
Held back
- Full write-up — for 90 more days
- That it is closed, and that a retest happened
- The exact date the full entry goes public
What the public sees
This is the shape of every published entry: what it was, what it cost users, what we changed, and whether a retest caught anything the first fix missed. Including when the answer is embarrassing.
Held back
- Everything above
- The reporter’s identity — their choice, permanently
Why publish at all, and why wait: a fixed vulnerability that nobody hears about teaches nobody anything, and a provider with no public list of past problems has either been extraordinarily lucky or is not telling you. Ninety days is long enough for users to update and for fleet-wide changes to land everywhere, and short enough that the disclosure still matters. If a fix cannot be deployed everywhere within 90 days we will say so here and give the new date, rather than letting the entry disappear.
What counts, and what doesn’t
In scope
Client applications on every platform, VPN node software and configuration, the account and billing backend, and the API used by the apps. Anything that could expose user traffic, identity or account access.
Out of scope
Scanner output with no demonstrated impact, missing headers on static marketing pages, denial of service, social engineering, physical attacks, and third-party services we do not operate.
Rules of engagement
- Test against your own account only. Never access, modify or retain another user’s data.
- Stop as soon as you have proof. Do not exfiltrate more than the minimum needed to demonstrate the issue.
- Do not degrade the service for other people. No load testing, no automated scanning of the node fleet.
- Give us 90 days, or until a fix ships, before publishing.
- Report through the address below rather than social media, so we can start fixing rather than firefighting.
- If you retest a fix, stay inside the same scope and rules. A retest is not a wider licence — it is the same engagement, aimed at the patch.
How to send it
Where
[email protected]. Include the affected component, reproduction steps, and what an attacker gains. A short video helps more than a long document.
When you’ll hear back
Acknowledgement within two business days, initial assessment within seven. If a fix will take longer we tell you why instead of going quiet.
How you get paid
Monero if you want to stay anonymous, bank transfer if you prefer. Public credit is optional and entirely your call.
What we publish
Every closed report goes into the public ledger 90 days later — flattering or not. Open reports are listed without technical detail until the fix is out.
Before we close it
You get 14 days to attack the fix. Find a bypass and it counts as a new report at its own severity band. Details in the remediation process.