SYS::ONLINE
Wasteland.
Briefs1598
Issues21
SinceFeb 2026
LIVE
▣ Breach NO-LOGS-VPN 2026-07-29

SplitVPN: Altenen Forum Actor Leaks 58 Million Connection Logs From a No-Logs VPN

"A threat actor operating on the Altenen carding and data-leak forum is distributing a 17 GB SQL database allegedly stolen from SplitVPN, the Russian VPN service formerly branded NotVPN and marketed to users bypassing…"

A threat actor operating on the Altenen carding and data-leak forum is distributing a 17 GB SQL database allegedly stolen from SplitVPN, the Russian VPN service formerly branded NotVPN and marketed to users bypassing state internet blocks. The dump is dated 21 July 2026. Mysterium's research team says it obtained a copy, verified it against the raw dump, and confirmed the seller's headline figures: roughly 23.4 million user records, 13.6 million device records, 2.6 million payment records, and approximately 58 million connection logs. The service's own marketing copy reads "No logs or history: We never store your activity or connection logs. 100% privacy guaranteed." No statement from SplitVPN or NotVPN appears in any source reviewed here, and there is no regulator filing or CERT advisory covering the incident. Everything currently known about this breach comes from a single research team's verification work and the press coverage that followed it.

What Happened

A long-tenured Altenen user posting under the handle vhacker51 opened a thread titled "SplitVPN (NotVPN) 23.4M users, 58M logs, 13.6M devices," describing the target as a Russian VPN for bypassing blocks with users concentrated in Russia, Iran, India, and Myanmar, and offering a compressed SQL file for download. Mysterium reports the listing gives a dump date of 21 July 2026, and that breach-tracking accounts including Dark Web Informer subsequently amplified it. Security Affairs picked up and summarised the same verification work on 29 July, attributing the record counts to Mysterium rather than independently confirming them.

The central finding is a table named deviceProxy. Its structure is minimal: which device connected to which server, and exactly when. Mysterium's account states the timestamps run continuously from June 2025 through 21 July 2026, the day of the dump, meaning the service was still writing connection records while it was being breached. That is a connection log by any working definition, and the provider claimed to keep none.

Readers should note a significant discrepancy in the reporting. Security Affairs and Mysterium both give the user-record count as approximately 23.4 million. UNDERCODE NEWS headlines its coverage "234 Million Users Exposed," a figure ten times higher that does not appear anywhere in its own body text and is not corroborated by any other source. The 23.4 million figure is the one supported by the verification work; the 234 million figure appears to be a decimal error and should not be repeated. UNDERCODE also describes the exposed metadata as spanning "years," which sits uneasily against the June 2025 start date given by the primary researchers.

One further caveat: the material available describes verification of the seller's claims against the dump contents. It does not establish how the database was obtained, whether SplitVPN has acknowledged the incident, or whether the operator has notified affected users. Treat attribution of the intrusion itself as unresolved.

What Was Taken

Per the verified breakdown, the database contains roughly 23.4 million user records holding account emails and last-seen IP addresses; approximately 13.6 million device records holding hardware identifiers; around 2.6 million payment records; and approximately 58 million rows in the deviceProxy connection-log table.

Full credit-card numbers were not exposed. Card data is masked to BIN plus last four digits. What was exposed is arguably worse for this particular user base: email addresses, IP addresses, device identifiers, approximate location, subscription status, and recurring-billing tokens.

The sensitivity is not in any single table but in the joins between them. Cross-reference deviceProxy against the users table and the device table and those 58 million rows resolve into a reconstruction of who connected, from which IP, to which server, and at what time, for tens of millions of people. For a customer base that Mysterium describes as concentrated in Russia, Iran, India, and Myanmar, that is a censorship-circumvention user list with timestamps attached. The recurring-billing tokens are a separate concern, carrying direct fraud and account-takeover potential independent of the metadata exposure.

Why It Matters

The strategic point is not that a VPN got breached. It is that the breach falsified the product. A VPN's core security claim is that the records required to reconstruct a user's activity do not exist. Here they existed, at a scale of tens of millions, and they were being written up to the hour of compromise. A no-logs policy that is unaudited is a marketing assertion, and the only reliable test of one is a hostile event.

For threat intelligence teams, this dataset has real downstream utility for adversaries. Email plus IP plus device identifier plus timestamp is enough to correlate a pseudonymous account against other breach corpora, geolocate a user historically, and build targeting packages against activists, journalists, or dissidents in exactly the jurisdictions this service advertised to. The censorship-circumvention framing means the affected population is disproportionately at risk from state-level adversaries, not just criminal ones.

For enterprises, the lesson generalises beyond consumer VPNs. Any third-party service whose value proposition is "we do not retain X" is an unverified control until an audit or an incident proves otherwise. If employees route corporate traffic through consumer VPN services on unmanaged or BYOD endpoints, the retention policy of those services is now part of your exposure surface.

The Attack Technique

The intrusion vector is not established. None of the sources reviewed describe how the database was obtained, and there is no vendor advisory, forensic report, or victim statement to draw on. The forum listing describes what was taken, not how. Anyone stating a root cause for this breach today is speculating.

What the sources do establish is the exfiltration and distribution pattern, which is routine for this class of incident: a full SQL dump taken in a single pass, compressed to 17 GB, and listed for download on an established criminal forum by a seller with existing standing there, then amplified by breach-tracking accounts within days. The continuous timestamps up to the dump date indicate the service was operational and unaware, or at least still writing, at the point of extraction.

The Wider Context

Three of the eight sources supplied for this brief cover separate incidents that should not be conflated with the SplitVPN leak, but which sharpen its significance.

The first is FortiBleed. In June 2026, researcher Volodymyr "Bob" Diachenko discovered an exposed server holding what appeared to be valid Fortinet and FortiGate VPN credentials, including usernames, email addresses, and plaintext passwords. BleepingComputer reports the collection covered 73,932 firewall URLs; CISA, in its own advisory, described the exposure as covering "approximately 74,000 Fortinet devices." Diachenko's investigation, as reported, attributes the campaign to a Russian-speaking multi-operator group and claims roughly 1.16 billion credential attempts against 320,777 FortiGate targets plus 2.1 billion attempts against 163,650 Microsoft SQL Server systems, with SSL VPN authentication hashes cracked on a 45-GPU Hashtopolis cluster. Those campaign-scale figures are Diachenko's and are reported as claims rather than confirmed. Fortinet's PSIRT, the only PRIMARY-tier source in this set, pushes back on the framing directly: the company states this is not a new Fortinet vulnerability and assesses the activity as credential reuse from prior incidents FG-IR-26-060 and FG-IR-25-647 combined with brute-forcing against devices with weak password hygiene and no MFA. Fortinet says it has identified potentially compromised systems and is proactively contacting affected customers. Where the outlet framing and the vendor assessment diverge, the vendor's characterisation of root cause carries more weight.

The second is 1VPNS. On 13 July 2026, the US Treasury's OFAC designated First VPN Service, its Ukrainian administrator Dmytro Rashevskyi, and Belarusian cryptor vendor Yegeniy Vladimirovich Silayev. TechTimes reports this as the first formal OFAC sanctioning of a VPN service under the US cyber authority for facilitating ransomware, and notes the strict-liability standard means intent to facilitate crime is not required for legal exposure to attach. The sanctions followed Operation Saffron, the May 2026 French and Dutch led takedown supported by Europol, Eurojust, and the FBI, which seized 33 servers across 27 countries. TroyPoint reports that investigators accessed the infrastructure before the takedown and recovered the user database, with details on 506 subscribers passed to police overseas and 83 intelligence packages produced. 1VPNS had advertised no-logs and non-cooperation with law enforcement since 2014 on forums including Exploit[.]in and XSS[.]is. The subscriber-count and intelligence-package figures come from a single OTHER-tier source and should be treated as reported rather than confirmed.

The through-line across all three is that VPN infrastructure is currently under pressure from every direction at once: the provider's own retention practices, the credentials protecting enterprise gateways, and the legal status of the operator.

What Organizations Should Do

  1. Treat any SplitVPN or NotVPN account as fully compromised. Assume the email address and IP tied to the account are in adversary hands. Rotate the password on that account and anywhere the same password was reused, and enable MFA on the email address itself. If the account carried a recurring-billing token, contact the card issuer and request a card reissue rather than relying on the BIN-plus-last-four masking as protection.

  2. Assess exposure for high-risk users specifically. If your organisation supports staff, sources, or partners in Russia, Iran, India, or Myanmar, treat historical use of this service as a targeting risk rather than a fraud risk, and adjust operational security guidance accordingly. Metadata that resolves to who-connected-when is a personnel-safety issue, not just a data-protection one.

  3. Stop accepting unaudited retention claims as controls. Require independent, published audits for any third party whose contribution to your security posture is a promise not to retain data. Where no audit exists, model the service as though it retains everything and log the residual risk formally.

  4. Act on the FortiBleed guidance if you run FortiGate appliances. Both Fortinet and CISA advise terminating all administrative and SSL VPN sessions, resetting all VPN and administrative passwords, enforcing MFA on every administrator and VPN account, and upgrading to current 7.4, 7.6, or 8.0 builds that support PBKDF2 hashing of administrator credentials. Fortinet specifically directs customers to remove legacy password settings via set login-lockout-upon-weaker-encryption.

  5. Remove management interfaces from the public internet. CISA's advisory calls for restricting firewall management interfaces from internet exposure and deleting unauthorised accounts. Review firewall and VPN user lists against your authoritative identity source and reconcile the differences.

  6. Hunt for post-authentication activity, not just failed logins. The FortiBleed pattern is valid-credential access followed by lateral movement into Active Directory. Review VPN and administrative logs for successful authentications from unfamiliar geographies or at unusual hours, and correlate against subsequent directory activity.

  7. Add sanctions screening to your VPN and anonymisation vendor review. The 1VPNS designation establishes that infrastructure-layer anonymisation providers can be sanctioned under a strict-liability standard. Procurement and compliance teams should screen these vendors the same way they screen any other counterparty.

Sources: VPN Breach Exposes 58 Million Connection Logs Despite "No-Logs" Cla... | Analysis of Reported Credential Compromise of FortiGate Devices Fo... | FortiBleed leak exposes Fortinet VPN credentials for 73,000 devices | CISA warns Fortinet users to secure devices after FortiBleed leak | NotVPN/SplitVPN Breach: 58M "No-Logs" Logs Exposed | VPN Privacy Promise Shattered, 234 Million Users Exposed in Massive... | This 'No-Logs' VPN Gave Up 500+ Users to Police (Now Seized) | Treasury Targets VPN Provider That Shielded Ransomware Groups for 1...