Sicherheitsjournal.

Linux-Kernel-Schwachstelle CVE-2026-98432 geschlossen

Es wurde eine Schwachstelle, CVE-2026-98432, in der Verarbeitung eingehender TCP-Verbindungen durch den Linux-Kernel gefunden. Sie betrifft Linux-Server unabhängig davon, welcher Dienst auf ihnen läuft.

Die Kernel der Plattformserver und der aktiven VPN-Server von Partnern mit unterstützten Systemversionen wurden auf eine Version mit der Korrektur aktualisiert.

Aufeinander abgestimmte Beschränkungen im öffentlichen Supportformular

Ein Bericht von Parth Narula zeigte, dass sich über unser öffentliches Supportformular mit einer anderen E-Mail-Adresse zusätzliche Anfragen senden ließen. Wir haben die Beschränkungen des Formulars aufeinander abgestimmt, sodass ein Adresswechsel keine zusätzlichen Anfragen mehr ermöglicht. Vielen Dank für die verantwortungsvolle Meldung.

Der Zugriff auf die Oberfläche des Supportdienstes wurde eingeschränkt

Ein externer Forscher wies darauf hin, dass die Oberfläche des Supportdienstes aus dem Internet erreichbar war. Die Oberfläche erforderte eine Authentifizierung; Hinweise auf unbefugten Zugriff oder eine Offenlegung von Nutzerdaten wurden nicht festgestellt.

Wir haben den Supportdienst aus der öffentlich erreichbaren Angriffsfläche herausgenommen: Der Zugriff ist nur von vertrauenswürdigen Adressen und über einen internen Kanal erlaubt. Die Einstellungen der Oberfläche wurden an die tatsächlich genutzte Domain angepasst, und die Einschränkung wurde aus einem externen Netz überprüft.

Rücksprungadresse auf Seiten des Panels beschränkt

Ein Sicherheitsforscher stellte fest, dass die technische Rücksprungadresse nach der Wiederherstellung einer Sitzung vom Browser als Wechsel zu einer externen Website interpretiert werden konnte. Das Szenario setzte eine gültige Sitzung voraus und verschaffte keinen Zugriff auf das Konto oder auf Daten.

Die Rücksprungadresse wird jetzt aus einer geschlossenen Liste interner Seiten gewählt. Jeder andere Wert führt zur Startseite des Panels. Die Korrektur ist durch automatisierte negative Tests abgedeckt.

DMARC-Durchsetzung aktiviert

Ein Sicherheitsforscher stellte fest, dass die DMARC-Richtlinie von createyourvpn.com nur im Überwachungsmodus lief und nicht verlangte, Nachrichten bei fehlgeschlagener Prüfung abzulehnen. Wir haben p=reject für die Hauptdomain und sp=reject für ihre nicht sendenden Subdomains aktiviert. Transaktions-E-Mails bleiben auf separaten Versand-Subdomains mit eigenen SPF-, DKIM- und DMARC-Richtlinien isoliert.

MTA-STS und TLS-Berichte aktiviert

Ein Sicherheitsforscher stellte fest, dass MTA-STS und TLS-Berichte für eingehende E-Mails von createyourvpn.com nicht eingerichtet waren. Wir haben eine MTA-STS-Richtlinie veröffentlicht und TLS-Berichte aktiviert. Die Richtlinie läuft zunächst im Testmodus, während wir den Weiterleitungsweg des Drittanbieters prüfen; nach fehlerfreien Berichten aktivieren wir die Durchsetzung.

Kontrolle über Kontositzungen hinzugefügt

Ein Sicherheitsforscher stellte fest, dass die Kopie eines Partnersitzungs-Tokens nach der Abmeldung aktiv bleiben konnte, wenn sie separat erneuert worden war. Wir haben Sitzungen auf eine einheitliche serverseitige Identität umgestellt: Die Abmeldung widerruft nun die gesamte aktuelle Sitzung, während „Überall abmelden“ alle aktiven Sitzungen beendet.

Im Panel gibt es jetzt den Bereich „Kontositzungen“. Dort sind die aktuellen Anmeldungen mit Gerät, IP-Adresse, Anmeldezeitpunkt und letzter Aktivität zu sehen, außerdem der Verlauf erfolgreicher und fehlgeschlagener Anmeldeversuche der letzten 90 Tage. Sitzungen lassen sich einzeln oder alle auf einmal beenden.

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.

Stärkerer Schutz für das öffentliche Supportformular

Der Sicherheitsforscher 0xVicky entdeckte, dass unser öffentliches Supportformular für übermäßig viele Anfragen missbraucht werden konnte. Wir haben Beschränkungen pro Besucher und für den Gesamtverkehr eingeführt, den internen Übermittlungskanal des Formulars geschützt und die Prüfung von Anhängen verstärkt. Vielen Dank für die verantwortungsvolle Meldung.

Sitzungsverwaltung und Versand von Anmeldecodes

Aufgrund von Meldungen eines externen Forschers haben wir zwei benachbarte Bereiche überprüft: den Lebenszyklus einer Partnersitzung und den Weg der E-Mail mit dem Anmeldecode. Keiner der Befunde ermöglichte Zugriff auf Konten, Partnerdaten oder Nutzerverkehr.

Security-Header auf den Storefront-Seiten

Die Storefronts der Partner sendeten die Security-Header nicht, die Panel und API längst senden — darunter jenen, der fremden Websites das Einbetten der Seite in einen Frame verbietet. Kontodaten oder Sitzungen ließen sich so nicht auslesen. Jetzt geht der vollständige Satz mit jeder Antwort der Storefronts hinaus, und die Aussage SR-15 benennt jedes von uns betriebene Frontend.

Nutzer können ihren Abo-Link selbst zurücksetzen

Ein Abo-Link ist ein Geheimnis: Wer ihn hat, erhält denselben Zugang wie die Person, der er gehört. Nutzer können ihn im eigenen Konto selbst zurücksetzen — der bisherige Link funktioniert nicht mehr, und die dahinterliegenden Zugangsdaten werden neu ausgestellt. Ein so geschlossener Link bleibt geschlossen, auch wenn Daten aus einer Sicherung wiederhergestellt werden.

E-Mail-Adressen von Storefront-Nutzern werden nicht mehr aufbewahrt

Eine Person gibt ihre E-Mail-Adresse ein, um sich bei der Storefront eines Partners anzumelden, doch die Adresse bleibt bei uns nicht liegen: Die Code-Mail geht raus, und die Adresse wird sofort gelöscht. Das Konto wird an einem unumkehrbaren Fingerabdruck erkannt, aus dem sich die Adresse nicht wiederherstellen lässt, und der Kontoname enthält sie ebenfalls nicht.

Der Zugriff auf das Panel zur Verwaltung der Infrastruktur wurde eingeschränkt

Ein externer Forscher meldete, dass eine administrative Oberfläche zur Verwaltung der Infrastruktur aus dem öffentlichen Internet antwortete. Die Oberfläche war durch eine Anmeldung geschützt, Hinweise auf unbefugten Zugriff wurden nicht gefunden. Der Bericht wurde angenommen und der Zugriff eingeschränkt.

Die Oberfläche ist jetzt nur noch von freigegebenen Adressen erreichbar, die Anforderungen an die Authentifizierung wurden verschärft und die beteiligten Komponenten aktualisiert. Das Ergebnis wurde von außerhalb unseres Netzes überprüft. Zusätzlich haben wir unsere öffentlich erreichbare Angriffsfläche überprüft und eine regelmäßige Kontrolle eingeführt. Die Prämie wurde in der höchsten Stufe ausgezahlt.

Ungenutzten Autorisierungspfad der Partner-API entfernt

Die API unterstützte einen zusätzlichen cookie-basierten Autorisierungspfad, den die aktuelle server-side-Architektur nicht benötigte. In production wurde kein Cross-Site-Angriff festgestellt, doch der zusätzliche Pfad vergrößerte die Angriffsfläche für künftige Fehler. Die API verwendet nun eine einzige, explizit definierte Autorisierungsmethode, die durch negative Tests abgedeckt ist.

Garantierte Löschung des Verwaltungsschlüssels nach Serverlöschung

Die Löschung des verschlüsselten Verwaltungsschlüssels lief nach Netzwerkoperationen im Hintergrund und wurde bei deren Fehlschlagen möglicherweise nicht wiederholt. Wir haben die Schlüssellöschung von der Netzwerkkaskade entkoppelt und einen garantierten erneuten Versuch hinzugefügt. Die Szenarien nicht erreichbarer Server und unterbrochener Prozess sind durch Tests abgedeckt.

Kryptografische Schlüssel der Plattform nach Zweck getrennt

Eine interne Überprüfung ergab, dass ein einziges Geheimnis für zwei verschiedene kryptografische Aufgaben verwendet wurde. Das schuf keine direkte Umgehung, vergrößerte aber die Auswirkungen einer Schlüsselkompromittierung. Die beiden Zwecke wurden getrennt, und jeder wird nun unabhängig rotiert.

Öffentliche Angriffsfläche der production-API verringert

Die interaktive technische API-Dokumentation war ohne Authentifizierung erreichbar. Sie gewährte keinen Zugriff auf geschützte Daten, erleichterte aber das Studium der internen Struktur der API. In production ist die Dokumentation nun deaktiviert und bleibt zugleich in einer isolierten Umgebung für die Entwicklung verfügbar.

Schutz gegen unsichere Cross-Origin-Konfiguration hinzugefügt

Die aktuelle production-Konfiguration ließ keine beliebigen Origins zu, doch der Code erlaubte eine gefährliche Kombination von Parametern, falls ein Betreiber sie falsch konfigurierte. Diese Kombination wird nun beim Start abgelehnt und durch einen automatisierten Test abgedeckt.

Interne Überprüfung vor dem Programmstart

Am 15. Juli 2026 haben wir eine interne Sicherheitsüberprüfung von CreateYourVPN begonnen. Die Korrekturen, die wir abgeschlossen und erneut verifiziert haben, sind nachstehend veröffentlicht; weitere folgen, sobald sie ausgerollt und bestätigt sind.