PraisonAI CVE-2026-44338 : un serveur d'agents sans authentification, exploité en 3h44

De quoi parle-t-on ?

Le 11 mai 2026 à 13h56 UTC, GitHub a publié l’advisory GHSA-6rmh-7xcm-cpxj, assignée CVE-2026-44338 (CVSS 7.3, élevée), pour PraisonAI — un framework open-source d’orchestration multi-agents qui compte environ 7 100 étoiles sur GitHub. L’ancien serveur API Flask livré dans src/praisonai/api_server.py désactive en dur l’authentification par défaut. N’importe quel appelant capable d’atteindre le processus peut lister les agents et déclencher le workflow configuré sans présenter le moindre jeton.

L’équipe Threat Research de Sysdig a observé le premier sondage ciblé — un scanner s’identifiant comme CVE-Detector/1.0 — atteindre l’un de ses capteurs à 17h40 UTC le jour même, soit trois heures et quarante-quatre minutes après la publication de l’advisory. Les versions 2.5.6 à 4.6.33 sont vulnérables ; le correctif a été livré dans 4.6.34 sur PyPI. La faille a été signalée par l’utilisateur GitHub shmulc8.

Comment ça marche

L’advisory décrit trois défauts qui coopèrent, tous visibles dans le code public :

# src/praisonai/api_server.py — extrait illustratif de la logique vulnérable
AUTH_ENABLED = False        # constante codée en dur
AUTH_TOKEN   = None         # jamais lue dans l'environnement, jamais surchargeable

def check_auth():
    if not AUTH_ENABLED:
        return True         # les deux routes "protégées" tombent en fail-open
    # ...

Les deux endpoints censés être derrière ce contrôle ne sont en pratique gardés par rien :

• GET /agents retourne le nom du fichier agents.yaml et la liste des agents configurés.
• POST /chat accepte n’importe quel corps JSON contenant une clé message, ignore sa valeur, et exécute PraisonAI(agent_file="agents.yaml").run() — c’est-à-dire le graphe d’agents complet de l’opérateur.

Lorsqu’il est lancé directement, le script se lie aussi à 0.0.0.0:8080. Le module APIConfig dans src/praisonai/praisonai/deploy/models.py conserve auth_enabled = False comme défaut, et le YAML de déploiement échantillon recommande host: 0.0.0.0 couplé à auth_enabled: false — propageant silencieusement ce défaut non sécurisé jusque dans les déploiements des opérateurs. Le chemin plus récent, serve agents, n’est pas concerné : il se lie à 127.0.0.1 et accepte --api-key.

Le honeypot de Sysdig a capté le schéma de reconnaissance qui a suivi la divulgation. Un seul hôte sur DigitalOcean (146.190.133.49) a exécuté deux passes de scanner espacées de huit minutes, balayant environ 70 requêtes chacune. La seconde passe s’est concentrée sur les empreintes d’agents IA (/praisonai/version.txt, /pyproject.toml, /docs, /openapi.json), puis a envoyé la sonde de validation : GET /agents sans en-tête Authorization et User-Agent: CVE-Detector/1.0. L’hôte a renvoyé 200 OK avec la liste des agents, confirmant le contournement.

Pourquoi c’est important

Le contournement n’est pas, en lui-même, une exécution de code arbitraire. Le handler /chat ignore le message soumis, donc l’attaquant ne peut pas injecter un prompt libre. Ce qu’il obtient, c’est l’invocation non authentifiée de ce que le agents.yaml de l’opérateur est câblé pour faire — et en production cela inclut généralement un code_interpreter, un outil shell ou de fichiers, un fetch web, ou un client HTTP. Le plafond d’impact réaliste va donc du drain de quota modèle, côté peu cher, jusqu’à l’exécution d’outils d’agent et à la divulgation de configuration, côté coûteux.

Deux constats plus larges rendent cette CVE intéressante :

• Le schéma se répète dans toute la stack d’agents IA. Sysdig la rapproche d’autres cas récents d’exploitation rapide sur Marimo, LMDeploy (CVE-2026-33626) et Langflow (CVE-2026-33017) — tous des projets petits à moyens dont le défaut exposé sur Internet ouvre un runtime puissant à des appelants anonymes.
• Trois heures et demie est le nouveau plancher. Un dépôt à environ 7 100 étoiles n’est plus « sous les radars ». L’outillage adverse reverse désormais les patchs, génère des scanners et balaie l’espace IPv4 public à la vitesse des advisory.

Défenses

1. Mettez à jour immédiatement. Passez à PraisonAI 4.6.34 ou plus récent. Tout ce qui se trouve dans la plage 2.5.6–4.6.33 est vulnérable tel que livré.
2. Arrêtez d’utiliser l’ancien entrypoint. Basculez sur la commande serve agents, qui se lie à 127.0.0.1 et exige --api-key. Considérez api_server.py comme déprécié.
3. Auditez les templates de déploiement. Si votre infra-as-code a été générée depuis l’échantillon PraisonAI, cherchez-y auth_enabled: false et host: 0.0.0.0. Les deux doivent être inversés.
4. Default-deny sur les déclencheurs d’agents. Tout chemin HTTP qui se termine par PraisonAI(...).run() — ou son équivalent dans LangChain, CrewAI, AutoGen — est une action qui change l’état du monde et doit exiger une authentification, pas opter pour elle.
5. Détectez au périmètre. Les appels non authentifiés réussis ne laissent aucun signal de « missing auth » dans les logs applicatifs. Ajoutez des règles WAF pour GET /agents et POST /chat dépourvus d’en-tête Authorization, et signalez la chaîne User-Agent: CVE-Detector/1.0 partout où elle apparaît.
6. Auditez la facturation des fournisseurs de modèles et les secrets référencés dans agents.yaml pour toute activité postérieure au 11 mai 2026, et faites tourner toute clé citée par le workflow.

Statut

Élément	Référence	Date	Notes
Advisory GitHub	GHSA-6rmh-7xcm-cpxj	2026-05-11 13:56 UTC	CVSS 7.3, CWE-306 / CWE-668 / CWE-1188
Identifiant CVE	CVE-2026-44338	2026-05-11	Publié au NVD
Première sonde ciblée	Capteur Sysdig TRT	2026-05-11 17:40 UTC	CVE-Detector/1.0, ~3h44 après la divulgation
Release corrigée	PraisonAI 4.6.34	2026-05-11	PyPI
Plage vulnérable	2.5.6 — 4.6.33	—	Toutes les versions antérieures sont également vulnérables pour le script legacy

L’enseignement profond est structurel. Le serveur legacy de PraisonAI est un petit bug — trois lignes, un défaut, une adresse de bind — mais il se situe à la même jonction que tout framework multi-agents finit par atteindre : un déclencheur HTTP qui, derrière le rideau, exécute un agent arbitraire utilisant des outils. Tout framework qui livre ce déclencheur avec une authentification en opt-in plutôt qu’en opt-out doit être considéré comme exploitable dès la première exposition à Internet.