Report a Security Vulnerability

Security help

What we want reported

If you find a way to weaken the security of vpn.now or its users, we want to hear about it before anyone else does. We care most about:

• Authentication and authorization bypasses. Logging in as someone else, reaching another user's dashboard, devices, or invoices, or escalating to admin access.
• Key handling flaws. Anything that exposes tunnel keys, lets one user obtain another user's config, or weakens how keys are generated or delivered.
• Injection vulnerabilities. SQL injection, command injection, cross site scripting, server side request forgery, or template injection anywhere on the site or API.
• Credential and secret leaks. Exposed API tokens, leaked session secrets, password reset flaws, or any path to account takeover.
• Tunnel and server issues. Weaknesses in how our VPN servers are configured, traffic that escapes the tunnel when it should not, or DNS handling flaws.

If your finding does not fit these buckets but you believe it has real security impact, report it anyway. We would rather read one report too many than miss one.

How to report

Email [email protected]. This inbox goes straight to the engineering team. Please use it only for security issues. For account or billing help, the regular contact form is much faster for you.

A good report includes:

• Steps to reproduce. Exact, numbered steps from a clean state. A working proof of concept beats ten paragraphs of theory.
• The affected URL or endpoint. The page, API route, or server involved, plus any parameters that matter.
• Your impact assessment. What an attacker could actually do with this. Be honest about limits and preconditions.
• Your contact details. So we can follow up with questions and credit you if you want credit.

Plain email is fine. Screenshots and request logs help. One issue per report keeps triage fast.

Our commitments to you

• Acknowledgment within 72 hours. A human confirms we received your report, usually faster.
• Regular status updates. We tell you when we have confirmed the issue, when a fix is in progress, and when it ships. If things go quiet, nudge us.
• Credit if you want it. Once the fix ships, we name reporters who want to be named. If you prefer to stay anonymous, we respect that too.
• No legal action for good faith research. If you follow the safe harbor rules below, we will not pursue or support any legal action against you for your research, and we consider it authorized.

Safe harbor rules

Our no legal action promise depends on you testing responsibly. The rules:

• Stay within your own accounts. Test against accounts and devices you created. Do not access, modify, or delete other users' data. If you need a second account to prove an issue, create one yourself or ask us for a test account at the same address.
• No data exfiltration beyond proof of concept. If you can read data you should not see, capture the minimum needed to prove it and stop. Do not download, store, or share it.
• No denial of service. Do not run load tests, resource exhaustion attacks, or anything designed to degrade the service for real users.
• No social engineering. Do not phish, pressure, or deceive our staff or users. This policy covers technical research only.
• No physical attacks. Do not attempt physical access to servers, offices, or hardware.
• Stop immediately if you reach user data. If a test unexpectedly exposes someone else's information, stop right there, do not explore further, and report what happened at once. We will treat an honest report of an accidental exposure as good faith.

Out of scope

These findings are almost never accepted on their own, because they carry little or no real risk:

• Clickjacking on static pages with no sensitive actions.
• Missing security headers without a demonstrated impact.
• Rate limiting observations without a working exploit, such as "this endpoint has no rate limit" with nothing achieved through it.
• Version disclosure, such as a server banner or framework version, without a path to exploitation.
• Raw output from automated scanners without manual verification. Run the tool if you like, but confirm the finding yourself before reporting it.

If you can chain an out of scope item into something with real impact, that chain is in scope. Show the impact and we will treat it seriously.

Severity and triage

We triage by real world impact, not by tool score. Roughly:

• Critical. Access to other users' data or keys, authentication bypass, remote code execution. We start work immediately, including out of hours.
• High. Privilege escalation, significant data exposure with preconditions, flaws in tunnel or key handling. Fix work starts within days.
• Medium. Issues needing user interaction or unusual conditions, such as reflected XSS behind specific input. Scheduled into the next releases.
• Low. Real but minor weaknesses. Fixed as part of normal maintenance.

We use CVSS as a reference point, not a verdict. If you disagree with our severity call, say so and explain why. We have changed our minds before.

Disclosure timeline

We follow coordinated disclosure. That means we fix the issue before details become public, and we agree on the publication timing together with you.

• We aim to fix confirmed vulnerabilities within 90 days of your report, and much faster for critical issues.
• Once the fix ships, you are free to publish your findings. We are glad to review a draft for accuracy if you want, but the writeup is yours.
• If we need more than 90 days, we will explain why and propose a new date rather than going silent.
• If an issue is being exploited in the wild, we may publish a warning to users before the full fix, and we will coordinate that with you.

Details about our infrastructure and how we handle data are on the transparency page and the security overview.