3. Composants Affectés

Veuillez séparer par des virgules lors de la soumission au formulaire CVE :

Texte brut

4. Vecteur d'Attaque

Un administrateur authentifié peut envoyer une requête HTTP POST spécialement conçue contenant une URL de plugin JAR distant malveillant au point de terminaison /apis/api.console.halo.run/v1alpha1/plugins/-/install-from-uri.

5. Analyse Technique et Chaîne d'Attaque

L'exécution de code à distance se produit via la séquence d'opérations suivante :

1. Ingestion du point de terminaison : La méthode PluginEndpoint.installFromUri() traite le corps de la requête entrante (InstallFromUriRequest) et extrait la chaîne uri fournie par l'utilisateur. Aucun filtrage par liste blanche de domaines n'est appliqué.
2. Récupération de fichier non protégée : L'URI extrait est transmis à DefaultReactiveUrlDataBufferFetcher.fetch(uri). Contrairement aux autres composants réseau internes de Halo, ce récupérateur n'invoque pas HttpSecurityUtils.secureHttpClient(), contournant ainsi les restrictions d'adresses IP de réseau privé/loopback (protection SSRF).
3. Persistance locale du fichier : Le contenu en streaming téléchargé depuis l'URI distant est écrit dans un répertoire temporaire local sur le serveur hôte via writeToTempFile(content).
4. Chargement dynamique des classes : L'application transmet le chemin temporaire à pluginService.install(path), qui utilise le JarPluginLoader de PF4J pour décompresser et charger le fichier JAR.
5. Enregistrement et exécution des beans Spring : Une fois que PF4J a fini de charger le contexte, le DefaultPluginApplicationContextFactory de Spring analyse automatiquement les métadonnées dans le plugin.yaml du plugin et enregistre toutes les classes d'extension déclarées dans le contexte d'application en tant que beans Spring actifs.
6. Déclenchement de l'exécution du code : Tout code malveillant placé dans les blocs d'initialisation statiques (static {}) de la classe d'extension ou dans les blocs de méthode annotés avec @PostConstruct sera exécuté immédiatement lors de la création de l'instance via Runtime.getRuntime().exec().

Segment de code source vulnérable (PluginEndpoint.java lignes 422-428) :

Java

6. Preuve de Concept (PoC)

Étape 1 : Héberger l'artefact malveillant

L'attaquant compile un fichier JAR de plugin PF4J/Halo standard (poc-plugin.jar) contenant une classe d'extension avec un mécanisme d'exécution de charge utile dans un hook de cycle de vie @PostConstruct ou un bloc statique. L'attaquant l'héberge sur un serveur d'écoute externe :

Bash

Étape 2 : Déclenchement de la vulnérabilité

L'utilisateur administratif authentifié envoie la requête HTTP suivante au serveur Halo cible :

HTTP

Étape 3 : Résultat attendu

Le serveur traite l'installation, récupère l'artefact depuis le serveur de l'attaquant, enregistre l'extension et exécute la commande système compilée, compromettant ainsi l'hôte cible.

7. Impact

• Compromission du système : Accès complet à l'infrastructure d'hébergement ou au conteneur Docker sous les privilèges du processus applicatif.
• Vol de données : Exposition directe des bases de données backend, des identifiants applicatifs sensibles, des clés de configuration (application.yaml) et des fichiers stockés.
• Mouvement latéral : Le serveur peut être utilisé comme point de pivot pour attaquer les réseaux internes du site, car le mécanisme de téléchargement peut accéder aux points de terminaison loopback ou d'infrastructure interne en contournant les règles de sortie standard.

8. Recommandations de Remédiation

1. Imposer des listes blanches de domaines absolues : Appliquer des règles de validation strictes sur l'argument uri entrant. Restreindre les schémas d'installation à distance aux places de marché officielles vérifiées et fiables de l'écosystème (par exemple, https://awesome.halo.run).
2. Intégrer des récupérateurs sécurisés : Refactoriser DefaultReactiveUrlDataBufferFetcher pour utiliser l'utilitaire existant HttpSecurityUtils.secureHttpClient() afin de rejeter les requêtes pointant vers loopback (127.0.0.1), link-local (169.254.169.254) ou les réseaux de classe privée (10.0.0.0/8, 192.168.0.0/16).
3. Vérification cryptographique des plugins : Mettre en œuvre une norme de vérification de signature numérique pour les modules JAR externes. Le contexte JarPluginLoader doit valider les hachages de fichiers ou les signatures cryptographiques par rapport aux clés publiques fournies par le dépôt officiel avant de les transmettre au DefaultPluginApplicationContextFactory pour l'instanciation du contexte.