ExploitFA is a desktop front end for a VPN/proxy core. Even in demo mode it handles material that must be treated as secret: server addresses, credentials, UUIDs, Reality public keys and short IDs, subscription URLs, and the local configuration files that contain them. This document explains what is in scope, how to report a problem privately, and what the project guarantees.

Only the latest release receives security fixes. Pre-release builds and local builds from main are supported on a best-effort basis.

Please do not open a public issue, pull request, or discussion for a security problem.

Use GitHub's private reporting flow:

1. Go to https://github.com/Largo-m/ExploitFA/security/advisories/new
2. Describe the issue, the affected version, and the impact.
3. Include reproduction steps and, if possible, a proof of concept.
4. Do not attach real credentials, keys, or subscription links. Replace them with obviously fake values of the same shape.

You can expect:

• an acknowledgement within 72 hours
• an assessment and a remediation plan within 7 days
• credit in the advisory and release notes if you want it

Please give us a reasonable window to ship a fix before any public disclosure.

• Disclosure of credentials or configuration data to other users, other processes, logs, crash reports, or the network.
• Command or argument injection through configuration values, share links, server names, or file paths (for example when starting a VPN core process).
• Path traversal or writes outside the application directory.
• Bypassing the checksum verification of VPN core binaries.
• Remote code execution, privilege escalation, and local privilege issues caused by the application.
• UI redressing that could mislead a user into believing traffic is protected when it is not.

• The security of third-party VPN cores (Xray, sing-box) — report those upstream.
• Vulnerabilities that require an attacker who already controls the user's account or has local administrator rights.
• The fact that demo mode does not create a tunnel. This is a documented, intentional limitation, clearly labelled in the interface.
• Denial of service through intentionally malformed local configuration files.
• Missing features listed in docs/ROADMAP.md (for example Kill Switch or credential encryption) — these are known gaps, not vulnerabilities. Please open a normal issue instead.

• No telemetry. The application does not send analytics, crash reports, or usage data anywhere. There is no account system.
• Local-only configuration. config/servers.json, config/app.json, config/subscriptions.json, logs/ and data/ stay on the local disk.
• No secrets in the repository. Real endpoints, UUIDs, and keys must never be committed. config/servers.json and cores/*.exe are git-ignored; only *.example.json files are tracked.
• Core binaries are verified. When a packaged core is present, build.py refuses to package it unless its SHA-256 matches cores/SHA256SUMS.json.
• Activity export is opt-in. The Activity view only writes a file when the user explicitly clicks Export.

• Configuration and credentials are stored as plain JSON on disk. OS-level encryption is on the roadmap.
• Demo mode simulates a session. The interface states this in the title area, status strip, dashboard and About page.
• A live core started by the app exposes a local SOCKS5/HTTP inbound. It does not automatically install a system-wide TUN adapter.

1. Download releases only from the official GitHub Releases page.
2. Verify the published SHA256SUMS.txt next to the release artifacts.
3. Keep config/servers.json out of cloud-synced folders and version control.
4. Treat a share link as a password: anyone with the link can use your server.
5. Rotate UUIDs and Reality keys if a device is lost or a config file leaks.

We are grateful to everyone who reports issues responsibly.