Security journal.

Internal review before the program launch

On 15 July 2026 we began an internal security review of CreateYourVPN. The fixes we have completed and re-verified are published below; more will follow as they are deployed and confirmed.

Guardrail added against unsafe cross-origin configuration

The current production configuration did not allow arbitrary origins, but the code permitted a dangerous combination of parameters if an operator misconfigured it. That combination is now rejected at startup and covered by an automated test.

Reduced the public surface of the production API

Interactive API technical documentation was reachable without authentication. It gave no access to protected data, but it made studying the API's internal structure easier. In production the documentation is now disabled, while remaining available in an isolated environment for development.

Platform cryptographic keys separated by purpose

An internal review found that a single secret was used for two different cryptographic jobs. This created no direct bypass, but it widened the blast radius of a key compromise. The two purposes have been separated and each now rotates independently.

Guaranteed clearing of the management key after server deletion

Clearing of the encrypted management key ran after background network operations and could fail to repeat if those operations failed. We decoupled key clearing from the network cascade and added a guaranteed retry. The unreachable-server and interrupted-process scenarios are covered by tests.

Removed an unused partner-API authorization path

The API supported an extra cookie-based authorization path that the current server-side architecture did not need. No cross-site attack was found in production, but the extra path widened the surface for future mistakes. The API now uses a single, explicitly defined authorization method, covered by negative tests.

Access to the infrastructure management panel was restricted

An external researcher reported that an administrative interface for infrastructure management was responding from the public internet. The interface was protected by authentication and no signs of unauthorised access were found. The report was accepted and access was restricted.

The interface is now reachable only from approved addresses, authentication requirements were strengthened, and the components involved were updated. The result was verified from outside our network. We also reviewed our public surface and added a recurring check of it. The reward was paid at the top tier.

Storefront users' email addresses are no longer kept

A person types their email to sign in to a partner's storefront, but the address does not settle with us: the code email goes out and the address is deleted right away. The account is recognised by an irreversible fingerprint the address cannot be recovered from, and the account name itself contains no address.

Users can reset their own subscription link

A subscription link is a secret: whoever has it gets the same access as its owner. Users can reset it themselves from their account — the previous link stops working and the credentials behind it are reissued. A link closed this way stays closed, including when data is restored from a backup.

Security headers on storefront pages

Partner storefronts did not send the security headers the panel and the API already sent, including the one that stops other sites from framing a page. No account data or session could be read this way. Storefronts now send the full set, and SR-15 lists every frontend we host.

Session handling and login-code delivery

Following reports from an external researcher, we reviewed two adjacent areas: the lifecycle of a partner session and the path taken by the login-code email. Neither finding gave access to accounts, partner data or user traffic.

The changes to login-code delivery are deployed and verified. A separate sign-out-everywhere control is in preparation; until it ships, signing out ends the current session.