Deux projets open source qu'on héberge soi-même ont reçu une CVE notée 9.8 ce week-end : phpMyFAQ, publiée dans NVD le 17 octobre 2026, et Vanus, publiée le 18 octobre.
Les deux mènent à une prise de contrôle sans authentification, mais par deux chemins opposés. Vanus livre un secret administrateur identique pour toutes les installations — l'erreur la plus ancienne du métier. phpMyFAQ, lui, a ajouté une fonction de sécurité moderne, les passkeys WebAuthn, et c'est son implémentation qui ouvre la porte.
| Projet | CVE | Faille | Versions (description NVD) |
|---|---|---|---|
| Vanus | CVE-2026-111998 | Identifiants par défaut (CWE-1392) | 0.8.0 à 0.9.0 |
| phpMyFAQ | CVE-2026-111911 | Authentification incorrecte (CWE-287) | 4.0.0 à antérieures à 4.1.9 |
Les deux : CVSS 3.1 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) et CVSS 4.0 9.3, publiés par VulnCheck (CNA) — pas par NVD. Statut NVD : « Received » pour Vanus, « Deferred » pour phpMyFAQ. Ni l'une ni l'autre n'est au CISA KEV à la date de rédaction.
Vanus — CVE-2026-111998 : un jeton cluster-admin pour tout le monde
Vanus est une plateforme d'événements (bus d'événements, namespaces, utilisateurs et rôles). Selon la description NVD, les versions 0.8.0 à 0.9.0 contiennent un jeton administrateur codé en dur. Il suffit de l'envoyer comme jeton Bearer au port proxy gRPC de la passerelle pour obtenir les droits cluster-admin sans s'authentifier.
Avec ces droits, un attaquant peut gérer les namespaces, les eventbus, les utilisateurs, les jetons et les rattachements de rôles, et lire ou publier des événements. Sur un bus d'événements, ce dernier point est le plus sérieux : lire, c'est voir passer les données métier ; publier, c'est injecter des messages que les consommateurs en aval traiteront comme légitimes.
Les références NVD pointent vers le code source de la v0.9.0 (la constante et le contrôleur de tenant concernés), vers l'issue GitHub #647 du projet et vers l'advisory VulnCheck. NVD ne mentionne aucune version corrigée : consulte l'issue et l'advisory avant de conclure qu'une mise à jour suffit.
phpMyFAQ — CVE-2026-111911 : enregistrer une passkey sur le compte d'un autre
phpMyFAQ est une application PHP de FAQ et de base de connaissances. Selon la description NVD, à partir de la 4.0.0 et avant la 4.1.9, les endpoints d'enregistrement WebAuthn rattachent une passkey à n'importe quel compte, sans authentification ni validation du challenge.
Le scénario décrit :
- l'attaquant « prépare » le nom d'utilisateur de la victime ;
- il soumet une attestation forgée au format
none(fmt=none) pour enregistrer sa propre passkey sur ce compte ; - il se connecte avec cette passkey, sans mot de passe et sans TOTP.
C'est l'ironie du sujet : la double authentification est contournée par le mécanisme même qui devait la renforcer. Le format d'attestation none est légitime dans WebAuthn ; le problème décrit est que l'enregistrement n'exige ni session authentifiée ni challenge valide.
D'après la formulation « before 4.1.9 », la 4.1.9 est la première version hors de la plage décrite. NVD ne fournit pas de configuration CPE ; vérifie la version corrigée dans les deux advisories GitHub du projet (GHSA-g6cq-6rqg-6c9p et GHSA-rg9h-f29v-xhxr) référencés par NVD.
Deux CVE que la correspondance CPE ne verra pas
Aucune des deux entrées n'a de configuration CPE. phpMyFAQ est en « Deferred » : NVD a décidé de ne pas l'enrichir, elle n'en aura donc pas. Vanus est en « Received » : rien n'indique qu'elle en aura une prochainement.
C'est le même angle mort que celui décrit dans notre article sur LangChat, DataBuff et Simple Admin Core : un outil qui rapproche les CVE du parc uniquement par CPE ne fera jamais remonter ces deux failles.
Détection
- Vanus : connexions au port proxy gRPC de la passerelle depuis des adresses hors de ton réseau applicatif ; utilisateurs, jetons ou rattachements de rôles que tu n'as pas créés ; événements publiés par des producteurs inconnus.
- phpMyFAQ : liste des passkeys enregistrées par compte — toute passkey que l'utilisateur n'a pas ajoutée lui-même, en particulier sur les comptes administrateurs ; requêtes anonymes vers les endpoints d'enregistrement WebAuthn dans les journaux du reverse proxy.
Mitigation
- phpMyFAQ : mettre à jour vers une version hors de la plage affectée en suivant les advisories GitHub, puis auditer et supprimer les passkeys suspectes — une passkey enregistrée par un attaquant reste valide après la mise à jour.
- Vanus : ne pas exposer le port proxy gRPC de la passerelle hors du réseau applicatif, et suivre l'issue #647 et l'advisory VulnCheck pour la correction.
- Après exposition : considérer comme compromis ce que l'application détient — jetons Vanus, comptes et contenus phpMyFAQ — et faire tourner les secrets.
- Plus généralement, ne pas publier d'interface d'administration d'une application auto-hébergée directement sur Internet : VPN ou reverse proxy authentifié.
Pourquoi surveiller en continu vos applications auto-hébergées
Deux failles critiques, publiées un week-end, sans CPE : exactement le profil de CVE qui passe sous le radar. Pour l'open source auto-hébergé, la veille doit chercher le nom du produit dans la description, pas seulement l'identifiant CPE.
Avec cveo.tech, ajoute Vanus, phpMyFAQ et tes autres applications à ton parc : la surveillance combine correspondance CPE et recherche par nom de produit, et t'alerte par email ou webhook.