Toute équipe d’ingénierie connaît ce serrement d’estomac lorsqu’un avis de sécurité signalant une faille d’exécution de code à distance (RCE) au score CVSS 9.2 vise le runtime de son backend. Le 21 octobre 2026, l’équipe de PHP publiait un correctif d’urgence. L’infrastructure d’encrypted1on1 s’appuie sur PHP. Notre plateforme a été mise à jour pratiquement dès la publication du correctif. Mais cet événement a constitué une validation pratique grandeur nature de notre architecture : pourquoi une compromission complète du serveur n’a jamais pu exposer les échanges intimes de vos 1 à 1, et l’honnêteté technique sur ce que le chiffrement côté client protège — et ce qu’il ne peut pas empêcher.
Ce qui s’est passé (et pourquoi il fallait agir sur-le-champ)
Le 21 octobre 2026, les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 de PHP ont été publiées afin de combler deux vulnérabilités critiques : CVE-2026-109618 et CVE-2026-109619. Toutes deux affichent un score CVSS de 9.2 et permettent à un attaquant distant non authentifié d’exécuter du code arbitraire sur la machine.
Les alertes du CERT-EU et d’experts en sécurité ont confirmé que les détails techniques étaient débattus publiquement et que des démonstrateurs d’exploitation (PoC) circulaient en quelques heures. Il ne s’agissait nullement d’un correctif à différer à la prochaine fenêtre de maintenance : l’intervention immédiate s’imposait.
encrypted1on1 tourne sur PHP 8.5 au sein du conteneur officiel FrankenPHP. Les images corrigées ont été mises en ligne sur Docker Hub dès le soir même.
Les mesures déployées sur notre plateforme
Nous avons déployé les conteneurs actualisés sur l’ensemble de notre infrastructure pratiquement dès la publication du correctif :
- Notre plateforme a été reconstruite sur la base PHP 8.5.12 et redémarrée sans aucune interruption de service.
- Aucune modification de code requise : Nos Dockerfiles de production ciblant le tag
php8.5, une simple reconstruction de l’image a immédiatement embarqué la version assainie du runtime PHP. - Audit et analyse des journaux : Un audit approfondi des requêtes réseau et des anomalies système sur nos proxys frontaux et nos processus applicatifs n’a révélé aucun indice d’analyse malveillante ou d’attaque avant ou pendant l’intervention.
Pourquoi les notes de 1 à 1 n’ont jamais été lisibles sur le serveur
C’est précisément dans de telles circonstances qu’une architecture Zero-Knowledge justifie chaque ligne de code consacrée à sa conception.
Dans un outil traditionnel de 1 à 1 ou un wiki d’entreprise (Notion, Google Docs, Slack ou un SIRH en cloud), une exécution de code non authentifiée sur le serveur est un désastre absolu. L’attaquant ouvre un shell, récupère les identifiants de la base de données et extrait toutes les tables. En un instant, des années de confidences se retrouvent exposées en clair : doutes sur les compétences, contestations salariales, signes d’épuisement et retours sans fard.
Sur encrypted1on1, le serveur est structurellement aveugle au contenu de vos réunions. Les notes, les sujets d’ordre du jour, les réflexions personnelles et les brouillons de feedback sont chiffrés directement dans le navigateur de l’utilisateur à l’aide d’AES-GCM-256 avant même qu’un seul octet ne transite sur le réseau.
Ce que notre base de données héberge n’est que du texte chiffré opaque :
- Les réponses et réflexions intimes des deux participants (brouillons comme notes validées) ;
- Les commentaires, accords, thèmes de discussion et plans d’action ;
- Les notes rétrospectives privées de chaque collaborateur ;
- Le suivi d’étape et l’évolution des objectifs de carrière.
Les clés cryptographiques nécessaires au déchiffrement sont calculées localement sur les terminaux des participants à partir de leurs mots de passe au moyen de l’algorithme Argon2id. Ces clés ne quittent jamais l’appareil en clair. Le serveur ne conserve que des enveloppes scellées qu’il est mathématiquement incapable d’ouvrir.
Même si un pirate dérobait une copie intégrale de notre base de données de production et tous les volumes du disque, il ne disposerait que de blocs chiffrés indéchiffrables sans les mots de passe de chaque utilisateur. C’est la pierre angulaire de notre démarche : nous ne vous demandons pas de croire aveuglément que nos serveurs ne connaîtront jamais de faille zero-day. Un bogue dans PHP, dans une bibliothèque C sous-jacente ou dans notre propre code n’entraîne pas la divulgation des confidences partagées lors d’un 1 à 1.
La frontière honnête : ce que le chiffrement de bout en bout protège (et ne protège pas)
La crédibilité en matière de sécurité s’établit sur la transparence technique et non sur des slogans mercatiques. Voici la délimitation exacte de notre modèle de menace face à une machine compromise :
1. Les métadonnées restent visibles sur le serveur. Le chiffrement de bout en bout préserve l’intimité de vos échanges, mais le serveur assure la coordination opérationnelle. Un pirate disposant d’un accès root sur le serveur pourrait consulter les identifiants de compte, qui rencontre qui en 1 à 1, la régularité et l’horodatage des sessions. En outre, par choix ergonomique, quelques données génériques d’organisation demeurent non chiffrées : titres d’objectifs, échéances, statut et modèles de questions de l’entreprise. L’inventaire complet est documenté en toute transparence dans notre modèle de menaces.
2. Le chiffrement protège les données au repos, non la livraison future du code. encrypted1on1 est une application web moderne : votre navigateur télécharge le code JavaScript servi par l’hôte. Si un attaquant parvenait à exécuter du code de manière persistante sur le serveur, il pourrait théoriquement tenter d’altérer ces scripts frontaux pour dérober le mot de passe d’un utilisateur lors de sa prochaine connexion. Nous nous en prémunissons grâce à des en-têtes CSP stricts (Content-Security-Policy), des images de conteneurs immuables et le contrôle d’intégrité des sous-ressources. Toutefois, aucun chiffrement côté client ne peut empêcher un serveur web totalement compromis de tenter de délivrer du code malveillant à de futurs visiteurs.
Ce qu’il faut retenir : Le chiffrement de bout en bout transforme ce qui aurait constitué une violation rétroactive catastrophique de l’historique en une banale opération de mise à jour d’urgence. Les données rédigées par le passé restent inviolables ; corriger le serveur sans attendre préserve la sécurité des sessions à venir. Les deux approches sont indissociables.
Comment mettre à jour votre instance auto-hébergée (Guide pas à pas)
Si vous hébergez vous-même encrypted1on1 avec notre pile Docker, l’intervention s’effectue en moins de deux minutes et ne requiert aucune migration de base de données ni modification de configuration.
Étape 1 : Récupérer l’image de base corrigée.
Le script de déploiement compile votre conteneur applicatif, mais Docker peut réutiliser la couche de base présente dans son cache local. Un pull explicite garantit l’emploi de la version assainie de PHP 8.5.12 :
docker pull dunglas/frankenphp:php8.5Étape 2 : Reconstruire et redéployer.
Lancez le script de déploiement standard depuis la racine de votre projet :
PROD_COMPOSE_FILE=docker-compose.prod.yml ./docker/prod/deploy.sh(Ou simplement ./docker/prod/deploy.sh si votre environnement définit déjà le fichier compose).
Le script compile automatiquement l’image avec votre code actuel, recrée le conteneur, applique les migrations, rafraîchit le cache applicatif et effectue un contrôle de santé interne.
Remarque : Il n’est pas obligatoire de faire un git pull du code applicatif si vous souhaitez uniquement appliquer le correctif de sécurité. Reconstruire la version actuelle sur la nouvelle image de base suffit amplement.
Étape 3 : Vérifier la version de PHP dans le conteneur.
Contrôlez l’exécutable PHP au sein du conteneur en fonctionnement :
docker compose -f docker-compose.prod.yml --env-file .env.prod exec app php -vLe terminal doit afficher PHP 8.5.12 (ou supérieur).
Si vous faites tourner encrypted1on1 directement sans conteneur Docker, mettez à jour les paquets PHP de votre distribution et redémarrez le processus applicatif (worker FrankenPHP ou PHP-FPM) pour vider l’ancien binaire de la mémoire vive.
En conclusion : Fiez-vous aux mathématiques, pas aux promesses
D’autres vulnérabilités surviendront à l’avenir — dans PHP, dans le noyau Linux, dans OpenSSL ou dans les moteurs de navigateur. Aucun éditeur ne peut garantir de bonne foi que ses machines ne feront jamais tourner un composant vulnérable durant un court intervalle de temps.
Ce que nous pouvons vous garantir — et ce que notre code source ouvert vous permet de contrôler de manière indépendante —, c’est que le dialogue intime de vos équipes ne repose jamais sur la bonne volonté d’un serveur. Quand l’infrastructure chancelle, les mathématiques protègent vos données.
Une question sur cette mise à jour ou sur notre modèle cryptographique ? Venez échanger avec nous sur GitHub.