Security journal.

Strengthened protection against DDoS attacks

The website and the partner panel are now more resilient to being overloaded with requests.

Fixed handling of non-existent pages

A report from Tsabita showed that some non-existent addresses on the site returned a server error instead of a “not found” page. The responses contained no internal data. The error has been fixed, and such addresses now respond correctly. Thank you for the report.

Linux kernel vulnerability CVE-2026-98432 closed

A vulnerability, CVE-2026-98432, was found in how the Linux kernel handles incoming TCP connections. It affects Linux servers regardless of the service they run.

Kernels on the platform's servers and on partners' active VPN servers running supported system versions have been updated to a fixed version.

Aligned limits on the public support form

A report from Parth Narula showed that using a different email address on our public support form made it possible to send additional requests. We aligned the form’s limits, so changing the address no longer gives extra requests. Thank you for the responsible report.

Access to the support desk interface was restricted

An external researcher pointed out that the support desk interface was reachable from the internet. The interface required authentication; no signs of unauthorized access or disclosure of user data were found.

We removed the support desk from the public surface: access is allowed only from trusted addresses and through an internal channel. The interface settings were aligned with the domain actually in use, and the restriction was verified from an external network.

Return address restricted to panel pages

A security researcher found that the technical return address used after a session was restored could be interpreted by the browser as navigation to an external site. The scenario required a valid session and gave no access to the account or data.

The return address is now chosen from a closed list of internal pages. Any other value leads to the panel home page. The fix is covered by automated negative tests.

DMARC enforcement enabled

A security researcher found that the DMARC policy for createyourvpn.com operated only in monitoring mode and did not require messages that failed validation to be rejected. We enabled p=reject for the main domain and sp=reject for its non-sending subdomains. Transactional mail remains isolated on separate sending subdomains with their own SPF, DKIM and DMARC policies.

MTA-STS and TLS reporting enabled

A security researcher found that MTA-STS and TLS reporting were not configured for inbound mail at createyourvpn.com. We published an MTA-STS policy and enabled TLS reporting. The policy starts in testing mode while we verify the third-party forwarding path; enforcement will follow after clean reports.

Account session controls added

A security researcher found that a copied partner-session token could remain active after logout if it had been refreshed separately. We moved sessions to a single server-side identity: logging out now revokes the entire current session, while “Sign out everywhere” ends every active session.

The panel now has an “Account sessions” section. It shows current sign-ins with the device, IP address, sign-in time and last activity, as well as the history of successful and failed sign-in attempts over the last 90 days. Any session can be ended individually, or all of them at once.

Enabled DNSSEC

A researcher found that DNSSEC was not enabled for createyourvpn.com. We signed the DNS zone, published the DS record in .com, and verified the chain of trust.

Stronger protection for the public support form

Security researcher 0xVicky found that our public support form could be abused to submit excessive requests. We added limits for each visitor and for overall traffic, protected the form’s internal submission channel, and strengthened attachment validation. Thank you for the responsible report.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.