Transparency
Security review.
In August 2026 we ran an internal security review of the AkcaVPN backend. This page is a plain summary of what we tested, what held up, what we found, and what we fixed.
Reviewed: August 2026 · Scope: backend API and infrastructure
Most of the industry asks you to trust a "no-logs" banner and nothing else. We would rather show our work. This is a summary of an internal security review our own engineering team carried out against the AkcaVPN backend: the API that handles wallet authentication, VPN configuration delivery, sessions, and payments, along with the privacy design behind our no-logs promise.
To be precise about what this is and is not: this was a first party review by the people who build AkcaVPN, not a paid third party audit. It was a point in time exercise. It reduces risk, it does not prove that no issue exists anywhere. We are publishing it anyway, because privacy infrastructure should be accountable, and because the results are ones we are comfortable standing behind. The work was carried out by AkcaVPN's engineering team, including two security engineers, with AI assistance from Claude (Fable 5).
What we checked
The review combined a full read of the backend source with hands on testing against the live API, done carefully so that nothing in production was disrupted and no real user data was touched.
- Authentication: wallet signatures, account number login, token handling, and forgery attempts.
- Access control: whether one account can reach another account's data or sessions.
- VPN configuration delivery: how tunnel keys and configs are issued and cached.
- The no-logs design: what the database and code actually store for a session.
- Common web and API weaknesses: injection, cross origin policy, error handling, rate limiting.
- Payment and Solana flows, and the supporting infrastructure, reviewed in source.
What held up
The parts that matter most for your privacy were tested and behaved correctly. We are listing them because a fair report shows the strengths, not only the gaps.
- Token forgery is rejected. Attempts to forge or tamper with an authentication token were refused.
- Accounts are isolated. A valid session cannot end, read, or keep alive another user's session.
- Cross origin access is locked down. Only our own applications are allowed to call the API with credentials.
- Database queries are parameterized. The reviewed paths were not vulnerable to SQL injection.
- No secrets leaked in errors. Malformed input did not expose stack traces, queries, or file paths.
No-logs, verified in source
The central privacy claim is that we do not keep the things that could identify you. We checked this at the code and database level for new sessions.
| Data | Stored? | Why |
|---|---|---|
| Your real IP address | No | Replaced with a placeholder; not persisted for new sessions |
| Sites you visit / DNS queries | No | Not handled or stored by the API |
| Tunnel private key | No | Stored as null |
| Wallet / account number | Yes | Needed for access control |
| Session lifecycle timestamps | Yes | Needed to manage an active connection |
Some things live outside the application, such as edge access logs, backups, and node level settings. Those are operational controls we confirm separately. See our No-Logs Policy and Warrant Canary for the rest of the picture.
Findings we are disclosing
These are the application level findings from the review. Most were fixed in the code during the engagement; the rest are hardening items on our list. None of them exposed user traffic or the contents of your tunnel.
| Finding | Severity | Status |
|---|---|---|
| Payment verification did not check how old a transaction was | Medium | Open (flow paused) |
| VPN config response could be cached with a key in the body | Medium | Fixed |
| Signature login endpoints were not rate limited | Medium | Fixed |
| Transport security header (HSTS) was not set | Low | Fixed |
| Framework name advertised and default error page shown | Low | Fixed |
| Client RPC endpoint shared a single upstream key | Low | Open (devnet) |
| An unused, duplicate login handler in the code | Info | Fixed |
Ongoing hardening
Beyond the items above, the review produced a set of operational and infrastructure actions that we are working through as routine security hygiene, such as credential rotation and deployment of the fixes made during the engagement. Where a detail could help an attacker before an action is complete, we handle it privately under responsible disclosure rather than publishing it here.
What this is not
This was an internal review by our own team, not an independent third party audit, and it should not be read as one. A security review is a snapshot in time. It lowers risk; it does not guarantee that AkcaVPN is free of every vulnerability. We will update this page as our security work continues.
Found something? Tell us.
If you believe you have found a security issue in AkcaVPN, we want to hear from you. Email contact@akca.network. Please give us a reasonable window to fix an issue before disclosing it publicly. We do not take legal action against good faith security research.
AkcaVPN