Beveiligingsjournaal.

Kwetsbaarheid CVE-2026-98432 in de Linux-kernel gedicht

Er is een kwetsbaarheid, CVE-2026-98432, gevonden in de manier waarop de Linux-kernel inkomende TCP-verbindingen verwerkt. Deze treft Linux-servers, ongeacht welke dienst erop draait.

De kernels van de platformservers en van actieve VPN-servers van partners met ondersteunde systeemversies zijn bijgewerkt naar een versie met de oplossing.

Afgestemde limieten voor het openbare supportformulier

Een rapport van Parth Narula liet zien dat met een ander e-mailadres via ons openbare supportformulier extra verzoeken konden worden verstuurd. We hebben de limieten van het formulier op elkaar afgestemd, zodat een ander adres geen extra verzoeken meer oplevert. Bedankt voor de verantwoorde melding.

De toegang tot de supportinterface is beperkt

Een externe onderzoeker wees erop dat de supportinterface vanaf het internet bereikbaar was. De interface vereiste authenticatie; er zijn geen aanwijzingen gevonden voor ongeoorloofde toegang of openbaarmaking van gebruikersgegevens.

We hebben het supportsysteem uit het publieke oppervlak gehaald: toegang is alleen toegestaan vanaf vertrouwde adressen en via een intern kanaal. De instellingen van de interface zijn afgestemd op het domein dat in gebruik is, en de beperking is gecontroleerd vanaf een extern netwerk.

Terugkeeradres beperkt tot pagina's van het paneel

Een beveiligingsonderzoeker ontdekte dat het interne terugkeeradres na het herstellen van een sessie door de browser kon worden geïnterpreteerd als navigatie naar een externe site. Het scenario vereiste een geldige sessie en gaf geen toegang tot het account of tot gegevens.

Het terugkeeradres wordt nu gekozen uit een gesloten lijst van interne pagina's. Elke andere waarde leidt naar de startpagina van het paneel. De oplossing wordt gedekt door geautomatiseerde negatieve tests.

DMARC-handhaving ingeschakeld

Een beveiligingsonderzoeker ontdekte dat het DMARC-beleid van createyourvpn.com alleen in bewakingsmodus werkte en niet vereiste dat berichten die niet door de controle kwamen, werden afgewezen. We hebben p=reject voor het hoofddomein en sp=reject voor de subdomeinen die geen e-mail verzenden ingeschakeld. Transactionele e-mail blijft gescheiden op aparte verzendsubdomeinen met hun eigen SPF-, DKIM- en DMARC-beleid.

MTA-STS en TLS-rapportage ingeschakeld

Een beveiligingsonderzoeker ontdekte dat MTA-STS en TLS-rapportage niet waren ingesteld voor inkomende e-mail van createyourvpn.com. We hebben een MTA-STS-beleid gepubliceerd en TLS-rapportage ingeschakeld. Het beleid werkt eerst in testmodus terwijl we het doorstuurpad van de externe partij controleren; handhaving wordt na foutloze rapporten ingeschakeld.

Controle over accountsessies toegevoegd

Een beveiligingsonderzoeker ontdekte dat een kopie van een partnersessietoken na uitloggen actief kon blijven als die afzonderlijk was vernieuwd. We hebben sessies aan één serveridentiteit gekoppeld: uitloggen trekt nu de volledige huidige sessie in, terwijl ‘Overal uitloggen’ alle actieve sessies beëindigt.

In het paneel is het gedeelte ‘Accountsessies’ toegevoegd. Daarin zijn de huidige aanmeldingen te zien met apparaat, IP-adres, aanmeldtijdstip en laatste activiteit, plus de geschiedenis van geslaagde en mislukte inlogpogingen van de afgelopen 90 dagen. Elke sessie kan afzonderlijk worden beëindigd, of alle sessies tegelijk.

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.

Sterkere bescherming voor het openbare supportformulier

Beveiligingsonderzoeker 0xVicky ontdekte dat ons openbare supportformulier kon worden misbruikt om buitensporig veel verzoeken te versturen. We hebben limieten per bezoeker en voor het totale verkeer toegevoegd, het interne verzendkanaal van het formulier beschermd en de controle van bijlagen aangescherpt. Bedankt voor de verantwoorde melding.

Sessiebeheer en verzending van inlogcodes

Naar aanleiding van meldingen van een externe onderzoeker hebben we twee aangrenzende gebieden herzien: de levenscyclus van een partnersessie en het traject van de e-mail met de inlogcode. Geen van de bevindingen gaf toegang tot accounts, partnergegevens of gebruikersverkeer.

Beveiligingsheaders op de storefront-pagina's

De storefronts van partners stuurden de beveiligingsheaders niet die het paneel en de API al stuurden, waaronder de header die andere sites verbiedt de pagina in een iframe te tonen. Accountgegevens of sessies waren zo niet te lezen. De volledige set gaat nu mee met elke reactie van de storefronts, en bewering SR-15 noemt elke frontend die wij hosten.

Gebruikers kunnen hun abonnementslink zelf resetten

Een abonnementslink is een geheim: wie hem heeft, krijgt dezelfde toegang als de eigenaar. De gebruiker kan hem zelf resetten in het eigen account: de vorige link werkt niet meer en de bijbehorende toegangsgegevens worden opnieuw uitgegeven. Een zo gesloten link blijft gesloten, ook wanneer gegevens uit een back-up worden hersteld.

E-mailadressen van storefront-gebruikers worden niet meer bewaard

Iemand vult zijn e-mailadres in om in te loggen op de storefront van een partner, maar het adres blijft niet bij ons hangen: de mail met de code gaat eruit en het adres wordt meteen verwijderd. Het account wordt herkend aan een onomkeerbare vingerafdruk waaruit het adres niet te herleiden is, en ook de accountnaam bevat het niet.

De toegang tot het beheerpaneel van de infrastructuur is beperkt

Een externe onderzoeker meldde dat een beheerinterface voor de infrastructuur reageerde vanaf het publieke internet. De interface was beveiligd met authenticatie en er zijn geen sporen van ongeoorloofde toegang gevonden. Het rapport is aanvaard en de toegang is beperkt.

De interface is nu alleen bereikbaar vanaf goedgekeurde adressen, de authenticatie-eisen zijn aangescherpt en de betrokken componenten zijn bijgewerkt. Het resultaat is buiten ons netwerk gecontroleerd. Daarnaast hebben we ons publieke oppervlak doorgelicht en een periodieke controle toegevoegd. De beloning is op het hoogste niveau uitbetaald.

Een ongebruikt autorisatiepad van de partner-API verwijderd

De API ondersteunde een extra op cookie gebaseerd autorisatiepad dat de huidige server-side-architectuur niet nodig had. In production is geen cross-site-aanval aangetroffen, maar het extra pad vergrootte het oppervlak voor toekomstige fouten. De API gebruikt nu één expliciet gedefinieerde autorisatiemethode, gedekt door negatieve tests.

Gegarandeerd wissen van de beheersleutel na verwijdering van een server

Het wissen van de versleutelde beheersleutel liep na netwerkbewerkingen op de achtergrond en werd mogelijk niet herhaald als die bewerkingen mislukten. We hebben het wissen van de sleutel losgekoppeld van de netwerkcascade en een gegarandeerde nieuwe poging toegevoegd. De scenario's van een onbereikbare server en een onderbroken proces zijn gedekt door tests.

Cryptografische sleutels van het platform gescheiden op basis van doel

Een interne beoordeling wees uit dat één geheim voor twee verschillende cryptografische taken werd gebruikt. Dit leverde geen directe omzeiling op, maar vergrootte de impact van een sleutelcompromittering. De twee doelen zijn gescheiden en elk wordt nu onafhankelijk geroteerd.

Publiek oppervlak van de production-API verkleind

Interactieve technische API-documentatie was zonder authenticatie bereikbaar. Ze gaf geen toegang tot beschermde gegevens, maar maakte het bestuderen van de interne structuur van de API eenvoudiger. In production is de documentatie nu uitgeschakeld, terwijl ze beschikbaar blijft in een geïsoleerde omgeving voor ontwikkeling.

Beveiliging toegevoegd tegen een onveilige cross-origin-configuratie

De huidige production-configuratie stond geen willekeurige origins toe, maar de code liet een gevaarlijke combinatie van parameters toe als een beheerder die verkeerd configureerde. Die combinatie wordt nu bij het opstarten geweigerd en is gedekt door een geautomatiseerde test.

Interne beoordeling vóór de lancering van het programma

Op 15 juli 2026 zijn we begonnen met een interne beveiligingsbeoordeling van CreateYourVPN. De correcties die we hebben afgerond en opnieuw geverifieerd, zijn hieronder gepubliceerd; er volgen er meer naarmate ze worden uitgerold en bevestigd.