Security & Responsible Disclosure

Last updated: May 1, 2026

Vrge handles email, calendar, files, and banking data. We take security seriously and welcome reports from the research community. This page describes how to report a vulnerability, what's in scope, how quickly we'll respond, and the protections you have when acting in good faith.

TL;DR — Email security@getvrge.com. We'll acknowledge within 3 business days. No lawsuits for good-faith research that respects the scope and rules below.

1. How to report

Email security@getvrge.com with a clear description of the issue, steps to reproduce, affected component (e.g. desktop app, team server, managed-AI proxy, website), and the impact you believe it has.

Please do notfile public GitHub issues, post on social media, or share the vulnerability publicly until we've had a chance to investigate and ship a fix. We'll keep you posted on progress throughout.

A machine-readable contact record is published at /.well-known/security.txt per RFC 9116.

2. What you can expect from us

Acknowledgement within 3 business days of receipt. If you don't hear back, please send a gentle nudge — email routing can fail.
Triage within 7 days — we'll confirm we've reproduced the issue and share a provisional severity rating.
Resolution timelines (target): critical within 30 days, high within 60 days, medium / low on the next scheduled release cycle. We'll update you if something takes longer.
Credit— if you want, we'll credit you (by name or handle) in the release notes when the fix ships. Say so in your report and link to the profile you want credited.

3. What's in scope

Reports affecting any of the following are welcome:

The Vrge desktop app (Tauri macOS + Windows builds) — data-at-rest handling, license key verification, auto-update channel, OAuth flows for connected sources.
The Vrge team-mode server (the Node/Express Docker image we publish) — authentication, authorization, SQL injection, license enforcement, webhook verification, portal-token security.
The Vrge Managed AI proxy at ai.getvrge.com — quota enforcement, webhook signature verification, secret handling, rate limiting, tenancy isolation.
The getvrge.com marketing site — XSS, CSRF on checkout flows, any way an attacker could redirect a paying customer to a malicious destination.

4. What's out of scope

Customer-run deployments of our self-hosted team server — those are operated by the customer and are their responsibility. Report misconfigurations there directly to the operator.
Third-party services Vrge integrates with — Lemon Squeezy, Cloudflare, Anthropic, OpenAI, Google, Microsoft, Plaid. Please report those to their respective security teams.
Missing HTTP security headers, SPF/DKIM/DMARC edge cases, TLS configuration nitpicks — we're open to hearing these, but they're low priority unless paired with a concrete exploit scenario.
Social engineering against our team or our customers. Please don't.
Denial-of-service testing. Please don't — it will disrupt real customers.

5. Rules of engagement

When testing, please:

Use your own account, your own data, and your own subscriptions. Don't interact with other users' data under any circumstance — if you can demonstrate access, stop immediately and report it.
Keep testing volume reasonable. If something looks rate-limited, treat that as confirmation, not a challenge.
Don't exfiltrate data beyond the minimum needed to prove the issue. A screenshot of your own data through a vulnerable endpoint is plenty; a database dump is not.
Give us a fair chance to fix the issue before disclosing publicly. We'll keep you in the loop and ship as quickly as we reasonably can.

6. Safe harbor

If you make a good-faith effort to follow this policy during your security research, we consider your activity authorized under our terms of service and relevant computer-misuse statutes. We will not initiate or support legal action against you, and we will work with you if a third party attempts to.

Good-faith effort means: staying within the scope above, respecting the rules of engagement, reporting directly to us first, and giving us reasonable time to remediate before any public disclosure.

This safe harbor does not extend to actions that violate the privacy or rights of third parties (including our customers' end clients), nor to actions that intentionally degrade service for other users.

7. Rewards

Vrge is a solo-operated product and we don't run a formal bug- bounty program at this time. For significant, novel, and clearly reproducible issues we will happily:

Credit you publicly in our release notes
Send a complimentary lifetime license
Send a small cash reward at our discretion for severe vulnerabilities that led to a material fix

We appreciate your help. Security research is a public good and we don't want to pretend otherwise.

8. OAuth handling for connected services

For sources requiring confidential application secrets (Plaid, Stripe Connect, PayPal, QuickBooks Online, Xero), Vrge operates a dedicated token-exchange relay on Cloudflare's infrastructure. The relay handles only the OAuth handshake — it never logs, persists, or stores user data, access tokens, or transaction history. CORS is allowlisted to the desktop application's origins only, so a random website cannot pivot through the relay.

9. Encryption at rest

Your local CRM database is encrypted at rest via SQLCipher with a per-device 256-bit key protected by your operating system's keychain (macOS Keychain Services, Windows Credential Manager, or Linux Secret Service). Even with physical access to your device's storage, the database cannot be read without the OS-level authentication that protects the keychain. OAuth tokens for connected services are independently encrypted via the same keychain layer.

10. Vulnerability management

Vrge's source repositories run continuous vulnerability scanning: GitHub Dependabot for dependency CVE alerts and automated patches, Gitleaks for secret-leak detection on every commit, and Semgrep static analysis with security-focused rule packs. Findings are triaged on documented CVSS-calibrated SLAs (Critical: 7-day patch target; High: 30-day; Medium: 90-day; Low: next release cycle). Mitigating controls are deployed when an upstream patch is unavailable within the target window.

11. Changes to this policy

We may update this policy as Vrge evolves. Material changes (new scope, removed safe harbor) will be reflected here and the “last updated” date at the top will change to the current revision.

Questions about this policy, or anything else security-related: security@getvrge.com.