Journal de sécurité.

Vulnérabilité du noyau Linux CVE-2026-98432 corrigée

Une vulnérabilité, CVE-2026-98432, a été détectée dans la gestion des connexions TCP entrantes par le noyau Linux. Elle concerne les serveurs Linux quel que soit le service qu'ils exécutent.

Les noyaux des serveurs de la plateforme et des serveurs VPN actifs des partenaires utilisant des versions du système prises en charge ont été mis à jour vers une version corrigée.

Limites harmonisées pour le formulaire d’assistance public

Un rapport de Parth Narula a montré qu’avec une autre adresse e-mail, notre formulaire d’assistance public permettait d’envoyer des demandes supplémentaires. Nous avons harmonisé les limites du formulaire : changer d’adresse ne permet plus d’envoyer davantage de demandes. Merci pour ce signalement responsable.

L’accès à l’interface du service d’assistance a été restreint

Un chercheur externe a relevé que l’interface du service d’assistance était accessible depuis Internet. L’interface exigeait une authentification ; aucun signe d’accès non autorisé ni de divulgation de données d’utilisateurs n’a été constaté.

Nous avons retiré le service d’assistance de la surface publique : l’accès n’est autorisé que depuis des adresses de confiance et via un canal interne. Les paramètres de l’interface ont été alignés sur le domaine effectivement utilisé, et la restriction a été vérifiée depuis un réseau externe.

Adresse de retour limitée aux pages du panneau

Un chercheur en sécurité a découvert que l’adresse de retour technique utilisée après la restauration d’une session pouvait être interprétée par le navigateur comme une navigation vers un site externe. Le scénario nécessitait une session valide et ne donnait accès ni au compte ni aux données.

L’adresse de retour est désormais choisie dans une liste fermée de pages internes. Toute autre valeur mène à la page d’accueil du panneau. Le correctif est couvert par des tests négatifs automatisés.

Application de DMARC activée

Un chercheur en sécurité a découvert que la politique DMARC de createyourvpn.com fonctionnait uniquement en mode de surveillance et n’exigeait pas le rejet des messages qui échouaient à la validation. Nous avons activé p=reject pour le domaine principal et sp=reject pour ses sous-domaines qui n’envoient pas d’e-mails. Les e-mails transactionnels restent isolés sur des sous-domaines d’envoi distincts avec leurs propres politiques SPF, DKIM et DMARC.

MTA-STS et rapports TLS activés

Un chercheur en sécurité a découvert que MTA-STS et les rapports TLS n’étaient pas configurés pour les e-mails entrants de createyourvpn.com. Nous avons publié une politique MTA-STS et activé les rapports TLS. La politique fonctionne d’abord en mode test pendant que nous vérifions le chemin de transfert tiers ; l’application sera activée après réception de rapports sans erreur.

Ajout du contrôle des sessions du compte

Un chercheur en sécurité a découvert qu’une copie du jeton d’une session partenaire pouvait rester active après la déconnexion si elle avait été renouvelée séparément. Nous avons associé les sessions à une identité unique côté serveur : la déconnexion révoque désormais toute la session en cours, tandis que l’action « Se déconnecter partout » met fin à toutes les sessions actives.

Le panneau comporte désormais une section « Sessions du compte ». Elle affiche les connexions en cours avec l’appareil, l’adresse IP, l’heure de connexion et la dernière activité, ainsi que l’historique des tentatives de connexion réussies et échouées sur 90 jours. Les sessions peuvent être fermées une par une ou toutes d’un coup.

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.

Protection renforcée du formulaire d’assistance public

Le chercheur en sécurité 0xVicky a découvert que notre formulaire d’assistance public pouvait être détourné pour envoyer un nombre excessif de demandes. Nous avons ajouté des limites par visiteur et sur le trafic global, protégé le canal interne d’envoi du formulaire et renforcé la validation des pièces jointes. Merci pour ce signalement responsable.

Gestion des sessions et envoi des codes de connexion

À la suite de signalements d'un chercheur externe, nous avons revu deux domaines connexes : le cycle de vie d'une session partenaire et le trajet de l'e-mail contenant le code de connexion. Aucune de ces découvertes ne donnait accès aux comptes, aux données des partenaires ou au trafic des utilisateurs.

En-têtes de sécurité sur les pages des vitrines

Les vitrines des partenaires n'envoyaient pas les en-têtes de sécurité que le panneau et l'API envoyaient déjà, dont celui qui empêche d'autres sites d'afficher la page dans une iframe. Cette voie ne permettait de lire ni données de compte ni session. L'ensemble complet accompagne désormais chaque réponse des vitrines, et l'affirmation SR-15 nomme chaque frontend que nous hébergeons.

Chaque utilisateur peut réinitialiser son lien d'abonnement

Un lien d'abonnement est un secret : quiconque le détient obtient le même accès que son propriétaire. L'utilisateur peut le réinitialiser lui-même depuis son espace personnel : le lien précédent cesse de fonctionner et les accès associés sont réémis. Un lien fermé ainsi le reste, y compris après une restauration de données depuis une sauvegarde.

Les adresses e-mail des utilisateurs des vitrines ne sont plus conservées

Une personne saisit son e-mail pour se connecter à la vitrine d'un partenaire, mais l'adresse ne reste pas chez nous : l'e-mail contenant le code part, et l'adresse est supprimée aussitôt. Le compte est reconnu grâce à une empreinte irréversible dont l'adresse ne peut être reconstituée, et le nom du compte ne la contient pas non plus.

L'accès au panneau d'administration de l'infrastructure a été restreint

Un chercheur externe a signalé qu'une interface d'administration de l'infrastructure répondait depuis Internet. L'interface était protégée par une authentification et aucune trace d'accès non autorisé n'a été trouvée. Le rapport a été accepté et l'accès restreint.

L'interface n'est désormais accessible que depuis des adresses autorisées, les exigences d'authentification ont été renforcées et les composants concernés mis à jour. Le résultat a été vérifié depuis l'extérieur de notre réseau. Nous avons également passé en revue notre surface publique et mis en place un contrôle régulier. La récompense a été versée au niveau le plus élevé.

Suppression d'une voie d'autorisation inutilisée de l'API partenaire

L'API prenait en charge une voie d'autorisation supplémentaire fondée sur les cookie, dont l'architecture server-side actuelle n'avait pas besoin. Aucune attaque intersites n'a été constatée en production, mais cette voie supplémentaire élargissait la surface d'erreurs futures. L'API utilise désormais une méthode d'autorisation unique et explicitement définie, couverte par des tests négatifs.

Effacement garanti de la clé de gestion après la suppression d'un serveur

L'effacement de la clé de gestion chiffrée s'exécutait après des opérations réseau en arrière-plan et pouvait ne pas se répéter en cas d'échec de ces opérations. Nous avons découplé l'effacement de la clé de la cascade réseau et ajouté une nouvelle tentative garantie. Les scénarios de serveur injoignable et de processus interrompu sont couverts par des tests.

Clés cryptographiques de la plateforme séparées selon leur usage

Une revue interne a révélé qu'un même secret servait à deux tâches cryptographiques différentes. Cela ne créait aucun contournement direct, mais élargissait l'impact d'une compromission de la clé. Les deux usages ont été séparés et chacun fait désormais l'objet d'une rotation indépendante.

Réduction de la surface publique de l'API production

La documentation technique interactive de l'API était accessible sans authentification. Elle ne donnait accès à aucune donnée protégée, mais facilitait l'étude de la structure interne de l'API. En production, la documentation est désormais désactivée, tout en restant disponible dans un environnement isolé pour le développement.

Ajout d'un garde-fou contre une configuration cross-origin non sécurisée

La configuration production actuelle n'autorisait pas des origines arbitraires, mais le code permettait une combinaison dangereuse de paramètres si un opérateur la configurait mal. Cette combinaison est désormais rejetée au démarrage et couverte par un test automatisé.

Revue interne avant le lancement du programme

Le 15 juillet 2026, nous avons entamé une revue de sécurité interne de CreateYourVPN. Les correctifs que nous avons achevés et revérifiés sont publiés ci-dessous ; d'autres suivront à mesure de leur déploiement et de leur confirmation.