CVE-2026-42569 : bypass auth phpVMS import legacy (CVSS 9.4)

Les faits

phpVMS, plateforme PHP open-source utilisée par des centaines de communautés de simulation aérienne virtuelle pour gérer schedules, pirep, classement pilotes et flottes virtuelles, fait l'objet d'une advisory critique publiée le 9 mai 2026. La vulnérabilité, référencée CVE-2026-42569 et indexée GHSA dans le dépôt GitHub officiel nabeelio/phpvms, atteint un score CVSS v3.1 de 9.4 (Critical). Le vecteur AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H confirme une exploitabilité réseau sans authentification ni interaction utilisateur.

La faille découle d'une accessibilité non maîtrisée de fonctionnalités d'import legacy. Lors de la transition de phpVMS de la branche v5 historique vers la branche v7 moderne, l'éditeur a réintroduit pour des raisons de migration un ensemble d'endpoints sous /importer/ destinés à parser et importer des données issues d'anciennes installations v5 vers le schéma v7. Cette fonctionnalité, marquée comme dépréciée, devait être réservée à un script CLI d'administration ; elle est restée exposée sur les routes HTTP publiques jusqu'à la version 7.0.5 incluse, sans contrôle d'authentification ni middleware de session.

Concrètement, un attaquant non authentifié peut envoyer une requête POST forgée vers l'endpoint /importer/ ou ses sous-routes (/importer/pireps, /importer/users, /importer/schedules selon les routes documentées) en pointant vers un fichier d'import contrôlé. Le contrôleur exécute alors les opérations internes d'import : INSERT, UPDATE, DELETE sur la base, manipulation de fichiers (avatars, livrées d'avions, signatures de pilotes), et invocation de fonctions de traitement d'images susceptibles d'enchaîner sur d'autres primitives.

D'après l'analyse publiée par TheHackerWire et reprise par DailyCVE, la racine du défaut relève de CWE-639 (Authorization Bypass Through User-Controlled Key) couplé à une exposition d'IDOR : les endpoints d'import acceptent un identifiant d'objet ou un chemin de fichier en paramètre, sans vérification du contexte d'autorisation. Selon les ressources accédées par le code interne au /importer (notamment les opérations sur stockage local et appels à des bibliothèques de traitement), l'impact peut s'étendre jusqu'à une corruption majeure des données opérationnelles voire une perte d'intégrité applicative complète.

Les chercheurs de TheHackerWire indiquent que, contrairement à une RCE traditionnelle au sens strict (pas de chemin direct prouvé vers l'exécution de commandes shell arbitraires dans la version actuelle des écritures), la vulnérabilité reste classée critique en raison de la combinaison absence d'authentification + écriture en base + manipulation système de fichiers + auto-exposition publique. Pour un site phpVMS donné, un attaquant peut effacer la totalité des PIREP (rapports de vol), réécrire le classement des pilotes, ou injecter des entrées d'utilisateurs frauduleux disposant de privilèges administrateur, créant ainsi une porte dérobée durable.

La chronologie publique : la vulnérabilité a été remontée fin avril 2026 par un chercheur indépendant via le programme de divulgation responsable de phpVMS sur GitHub. L'éditeur Nabeel Shahzad, mainteneur principal du projet, a confirmé le rapport sous 48 heures et publié la version 7.0.6 le 9 mai 2026, avec en parallèle l'advisory GHSA et l'inscription de la CVE dans le NVD. Les notes de release de la 7.0.6 listent en première ligne Removal of legacy import HTTP endpoints, moved to CLI-only operation, comme correctif principal.

Aucune exploitation in-the-wild n'est documentée à ce jour. Cependant, la nature publique des installations phpVMS, ces sites sont indexés par Google et facilement énumérables via Shodan ou des dorks ciblant les chemins typiques de phpVMS (/dashboard, /pireps, /flights), combinée à la trivialité de l'exploitation rend la fenêtre de patch critique. Les communautés virtuelles touchées incluent souvent des instances anciennes et peu maintenues hébergées chez des prestataires de mutualisé, scénario classique de sites oubliés mais publiquement accessibles.

Sur le plan plus large, CVE-2026-42569 illustre un anti-pattern récurrent dans les CMS PHP de niche : la conservation de fonctionnalités legacy au cas où lors de migrations majeures, sans gating d'authentification strict, créant des portes dérobées involontaires qui survivent plusieurs années. Le même schéma a été observé sur OpenCart, vBulletin et plusieurs forums communautaires PHP en 2024-2025.

Impact et exposition

L'exposition concerne toute installation phpVMS publique en version inférieure ou égale à 7.0.5. Selon une énumération via dorks Google effectuée la semaine de l'advisory, plusieurs centaines d'instances phpVMS publiques ont été identifiées sur l'internet ouvert, dont une part significative en versions 7.0.x antérieures au correctif. Les sites hébergés sur du mutualisé entry-level (souvent les communautés de simulation) sont les plus exposés car leurs cycles de mise à jour sont irréguliers.

Conditions d'exploitation : zéro authentification, requête POST classique, payload d'import minimal. Aucune compétence offensive avancée n'est requise, un curl avec un fichier d'import préformaté suffit. Le PoC n'a pas été publié officiellement par l'auteur de la découverte, mais la lecture du diff entre 7.0.5 et 7.0.6 (public sur GitHub) trace immédiatement les routes vulnérables et leur signature.

Surface d'attaque applicative : intégrité des données pilotes (classements, heures de vol, certifications), manipulation de comptes utilisateurs (création d'admin frauduleux), corruption ou suppression des PIREP (potentiellement plusieurs années d'historique communautaire), atteinte à l'image et à la confiance des communautés concernées. Pour les communautés monétisées (boutiques de skins, abonnements premium pour fonctionnalités avancées), un risque financier et réputationnel direct existe.

Les hébergements phpVMS connectés à des intégrations externes (Discord webhooks, Slack notifications, intégrations VATSIM/IVAO) héritent du périmètre de confiance, et un attaquant peut potentiellement pivoter vers ces canaux en réécrivant les configurations applicatives stockées en base.

Recommandations immédiates

• Mettre à jour phpVMS vers la version 7.0.6 ou supérieure (advisory : phpVMS Security Release 7.0.6 du 9 mai 2026 et GitHub Security Advisory associée sur le dépôt nabeelio/phpvms).
• Mitigation immédiate si patch impossible sous 24 h : ajouter une règle reverse proxy (Nginx, Apache, Cloudflare) bloquant l'accès aux URI matchant /importer (return 403 sur location ~ ^/importer).
• Auditer les logs HTTP du serveur web pour identifier toute requête POST historique vers /importer/* hors fenêtre de migration légitime.
• Vérifier l'intégrité de la base de données : table users (recherche de comptes admin créés hors période normale d'inscription), table pireps (suppression massive), table aircraft (modifications inattendues).
• Renforcer le contrôle d'accès en réservant l'admin phpVMS à un VPN ou en imposant une authentification HTTP supplémentaire (htpasswd) pour les chemins sensibles.
• Effectuer une sauvegarde complète avant migration vers 7.0.6 et vérifier l'absence de portes dérobées résiduelles (utilisateurs admin inconnus, modifications de fichiers PHP avec timestamps incohérents) post-mise-à-jour.