noname-elv/cve-2026-48907CLI Python qui exploite CVE-2026-48907 dans Joomla JCE via un upload d'import de profil, vérifie les chemins du shell et ouvre un canal de commande interactif sur des cibles autorisées.
E.L.V — Exploit Loader & Vulnerability Firmware
Utilitaire de recherche en cybersécurité pour l'évaluation de vulnérabilités autorisée.
E.L.V Cadre de Recherche & d'Évaluation CVE est un utilitaire en ligne de commande basé sur Python destiné à la recherche en sécurité contrôlée et à l'évaluation de vulnérabilités autorisée.
L'implémentation fournie contient des fonctionnalités permettant de :
Le code source actuel identifie sa cible de recherche comme :
CVE-2026-48907 Joomla! JCE Extension < 2.9.99.5 Unauthenticated RCE
Cette affirmation concernant la CVE/le produit est des métadonnées fournies par le code source et n'ont pas été vérifiées de manière indépendante par ce README. Avant de publier une affirmation de sécurité, validez l'identifiant, les versions affectées, l'avis, le composant affecté et les informations de remédiation auprès d'une source fiable de fournisseur/CVE.
Ce projet interagit avec des applications web distantes et l'implémentation fournie inclut des fonctionnalités destinées à téléverser un payload côté serveur personnalisé et à communiquer avec un shell téléversé.
Utilisez-le uniquement contre des systèmes pour lesquels vous disposez d'une autorisation explicite.
N'utilisez pas ce projet pour :
Pour un laboratoire sécurisé, utilisez un environnement VM/conteneur local isolé ou une cible d'entraînement délibérément vulnérable.
| Champ | Valeur |
|---|---|
| Projet | E.L.V Cadre de Recherche & d'Évaluation CVE |
| Auteur / Moteur | HxN / E.L.V |
| Version | 1.0.0 |
| Langage | Python |
| Plateforme | Systèmes *nix / de type Unix |
| Licence | GNU GPL v3 |
| Interface | Ligne de commande |
| Client HTTP | requests |
| Concurrence | ThreadPoolExecutor |
| Objectif principal | Recherche et évaluation de sécurité autorisées |
Le code source elv-cve.py fourni contient les composants principaux suivants.
Le script lit un fichier local fourni via l'option --shell.
Le code source décrit ceci comme un fichier shell/uploader personnalisé et se termine lorsque le fichier spécifié ne peut pas être lu.
Le programme prend en charge deux modes de cible mutuellement exclusifs :
Pour chaque cible, le script effectue une requête GET contre la racine de la cible et attend une réponse HTTP 200 avant de continuer.
L'implémentation recherche dans le HTML retourné une valeur liée au CSRF à l'aide d'expressions régulières.
Deux motifs sont actuellement implémentés.
Le script construit une requête de téléversement multipart contre :```text /index.php?option=com_jce
La requête inclut la tâche d'importation de profil et le jeton extrait.
### 6. Vérification du chemin candidat
Après la requête d'envoi, le programme vérifie plusieurs emplacements possibles pour le fichier résultant.
Le code source actuel contient ces chemins candidats :```text
/tmp/
/images/
/images/stories/
/media/
Pour une cible unique, le programme actuel invoque une interface de commande interactive lorsqu'il signale un chemin de shell téléversé avec succès.
La source envoie des commandes à l'aide de paramètres POST nommés :```text cmd c
Comme cette fonctionnalité peut entraîner une exécution de commande à distance, elle doit être restreinte à des environnements isolés et explicitement autorisés.
### 8. Traitement multi-cibles
Lorsqu'un fichier de cibles est fourni, le programme utilise un `ThreadPoolExecutor` et traite les cibles de manière concurrente.
Le nombre de threads par défaut dans le code source est :```text
10
À un niveau élevé, l'implémentation actuelle suit ce flux :```text Start │ ├── Parse command-line arguments │ ├── Load local payload file │ ├── Load one target OR target list │ ├── Create ELV_CVE output directory │ ├── Target processing │ │ │ ├── GET target │ ├── Check HTTP response │ ├── Extract token │ ├── Submit profile-import request │ ├── Check candidate file paths │ └── Record result │ └── Write results / display summary
---
## Prérequis
La source fournie importe :
- des modules de la bibliothèque standard Python :
- `random`
- `re`
- `time`
- `argparse`
- `sys`
- `os`
- `json`
- `threading`
- `concurrent.futures`
- des modules tiers :
- `requests`
- `urllib3`
Une installation minimale des dépendances est donc :```bash
python3 -m pip install requests urllib3
Pour des déploiements reproductibles, épinglez les dépendances dans un fichier requirements.txt.
Exemple :```text requests urllib3
---
## Installation
Clonez ou copiez le projet dans un environnement d'évaluation isolé.
Exemple :```bash
git clone <YOUR-REPOSITORY-URL>
cd <YOUR-REPOSITORY-DIRECTORY>
Créez un environnement virtuel :```bash python3 -m venv .venv
Activez-le :```bash
source .venv/bin/activate
Installez les dépendances :```bash python3 -m pip install -r requirements.txt
Vérifier Python :```bash
python3 --version
Vérifiez la dépendance :```bash python3 -c "import requests, urllib3; print('Dependencies OK')"
> Remplacez `<YOUR-REPOSITORY-URL>` et `<YOUR-REPOSITORY-DIRECTORY>` par les valeurs utilisées par votre dépôt.
---
## Interface en ligne de commande
La source définit les options de ligne de commande suivantes.
### Sélection de la cible```text
-u, --url
URL cible unique.```text -f, --file
Chemin vers un fichier contenant les URL cibles.
Ces options sont mutuellement exclusives et l'une d'elles est requise.
### Sélection de la charge utile```text
--shell
Chemin vers le fichier de payload personnalisé local.
Cet argument est requis par l'implémentation actuelle.
-t, --threads
Nombre de threads de travail.
Par défaut :```text
10
-v, --verbose
Active l'indicateur verbose exposé par l'analyseur d'arguments.
Remarque : la source actuelle définit cette option mais n'utilise pas `args.verbose` pour modifier matériellement le comportement de sortie.
### Option de sortie```text
-o, --output
L'argument est défini par l'analyseur syntaxique, mais l'implémentation actuelle n'utilise pas args.output lors de l'écriture du résultat final. Le chemin du résultat actuel est codé en dur sur :```text
ELV_CVE/success.txt
Il s'agit d'un détail d'implémentation qu'il vaut la peine de corriger dans une future version.
---
## Fichiers d'entrée
### Liste de cibles
Le mode liste de cibles attend une URL par ligne.
Les lignes vides sont ignorées.
Les lignes commençant par `#` sont ignorées.
Format conceptuel :```text
https://authorized-target-01.example
https://authorized-target-02.example
# laboratory target
https://authorized-target-03.example
Seules les cibles que vous êtes explicitement autorisé à évaluer doivent être placées dans le fichier.
L'argument --shell pointe vers un fichier local que le programme lit comme du texte.
La source fournie ne valide pas le contenu du fichier au-delà de sa lecture réussie.
Pour un développement et des tests sûrs, utilisez un fichier de test inoffensif plutôt qu'un payload exécutant des commandes.
Le programme crée :```text ELV_CVE/
Pour le mode multi-cibles, il écrit :```text
ELV_CVE/success.txt
La source actuelle écrit les URL de shell réussies dans ce fichier.
Exemple de format de résultat :```text https://authorized-lab.example/path/to/result
Le programme affiche également un résumé d'achèvement contenant le nombre de résultats réussis par rapport au nombre de cibles chargées.
---
## Concurrence
Le mode multi-cibles utilise :```python
ThreadPoolExecutor
Le nombre de threads configuré est par défaut à 10.
Une concurrence plus élevée peut augmenter :
Pour les évaluations contrôlées, commencez par une valeur de concurrence faible et augmentez-la uniquement lorsque l'environnement et l'autorisation le permettent.
L'implémentation fournie utilise requests.Session() pour la communication HTTP.
Les principales opérations réseau sont :
Le code source utilise des délais d'expiration de requête explicites :
Ces valeurs sont codées en dur dans le code source actuel.
L'implémentation définit :```python s.verify = False
et supprime `InsecureRequestWarning`.
Cela signifie que la vérification du certificat est désactivée.
Cela peut être utile dans un laboratoire jetable avec des certificats auto-signés, mais ce n'est **pas recommandé pour des outils de sécurité en production normale**.
Une implémentation plus sûre devrait rendre la vérification des certificats configurable et garder la vérification activée par défaut.
---
## Journalisation et résultats
La source utilise un verrou de thread autour de `safe_print()` pour réduire les collisions de sortie entre les threads de travail.
Les catégories d'état typiques incluent :```text
failed
success
L'objet résultat peut également contenir des champs tels que :```text url status reason shell_url
Le collecteur multi-cibles vérifie en outre :```text
uploaded_hidden
Cependant, l'implémentation exploit() fournie ne renvoie pas actuellement ce statut.
Cela indique un point où le modèle de résultat pourrait être amélioré dans une future version.
L'implémentation actuelle gère plusieurs cas d'échec :
Une requête HTTP échouée est enregistrée comme cible en échec avec le message d'exception.
Si le GET initial ne renvoie pas HTTP 200, le traitement s'arrête pour cette cible.
Si le jeton attendu ne peut pas être extrait, la cible est signalée comme une vérification de vulnérabilité échouée.
Les exceptions lors de la requête d'upload sont interceptées et le script continue avec la tentative d'extension/chemin suivante.
Si le fichier de payload local n'existe pas, le programme se termine avec une erreur.
Le canal interactif gère KeyboardInterrupt et quitte la session.
Les fonctions principales du code source fourni sont :
safe_print(msg)Assistant de sortie console thread-safe.
read_custom_shell(filepath)Lit le fichier de payload local en texte UTF-8 avec les erreurs de décodage ignorées.
interactive_shell(shell_url)Fournit l'interface de commande HTTP interactive après un chemin de shell signalé comme réussi.
exploit(url, shell_content, interactive=False)Exécute le flux de traitement de la cible et renvoie un dictionnaire de résultat.
main()Gère :
Ce projet présente plusieurs caractéristiques sensibles en matière de sécurité qui doivent être comprises avant utilisation.
Le mode interactif est capable d'envoyer des commandes à un point de terminaison HTTP distant. Cela le rend nettement plus sensible qu'un scanner passif.
Ne pas exposer ou distribuer des payloads opérationnels à la légère.
La vérification des certificats TLS est désactivée dans l'implémentation actuelle.
Cela devrait être corrigé avant de considérer le projet comme un outil de sécurité mature.
Le payload est chargé directement depuis un fichier local et soumis dans le cadre de la requête HTTP.
Traitez les fichiers de payload comme du matériel exécutable de test de sécurité.
Le code source actuel n'implémente pas de mécanisme d'autorisation ou de liste blanche robuste.
Une version interne plus sûre devrait prendre en charge une liste blanche explicite de cibles.
L'implémentation actuelle ne fournit pas de limiteur de débit complet.
Les requêtes concurrentes doivent donc être contrôlées avec soin.
Les fichiers de résultats peuvent contenir des URL associées à des tentatives d'exploitation réussies. Protégez ces fichiers comme des données d'évaluation sensibles.
Un flux de travail d'évaluation professionnel devrait ressembler à :```text Authorization ↓ Define Scope ↓ Prepare Isolated Test Environment ↓ Confirm Target Ownership / Permission ↓ Perform Minimal Verification ↓ Collect Evidence ↓ Stop Exploitation Once Proof Is Established ↓ Remediate ↓ Retest ↓ Document Findings
L'objectif d'une évaluation de vulnérabilité devrait être d'établir le risque avec le **minimum d'impact nécessaire**, et non d'obtenir un accès illimité.
---
## Configuration de laboratoire recommandée
Pour le développement, créez un environnement dédié contenant :
- une VM Linux isolée ;
- un serveur web local ;
- une installation Joomla de test ;
- le composant/version JCE concerné ;
- un isolement réseau ;
- des snapshots/sauvegardes ;
- des comptes de test ;
- les journaux de l'application et du serveur web.
Évitez de tester contre des systèmes de production non liés.
---
## Dépannage
### `ModuleNotFoundError: No module named 'requests'`
Installez la dépendance Python :```bash
python3 -m pip install requests urllib3
Confirmez que le chemin fourni existe et est lisible :```bash ls -l
### La requête HTTP initiale échoue
Vérifiez :
- l'exactitude de l'URL ;
- le DNS ;
- la connectivité réseau ;
- la disponibilité de HTTP/HTTPS ;
- les règles de pare-feu ;
- la portée de la cible ;
- les journaux du serveur.
### Le jeton CSRF n'est pas détecté
La réponse de la cible peut différer de la structure HTML attendue par les expressions régulières de l'implémentation actuelle.
Ne partez pas du principe qu'un jeton manquant signifie que la cible est sécurisée ou vulnérable. Considérez-le comme un résultat non concluant.
### Le fichier de résultats est vide
Vérifiez :```text
ELV_CVE/success.txt
et inspectez la sortie de la console pour les requêtes HTTP échouées, les échecs d'extraction de jetons ou le rejet de téléversement.
L'implémentation fournie présente plusieurs limitations.
--verbose est définie mais ne contrôle pas actuellement la journalisation détaillée.--output est défini mais n'est pas actuellement utilisé pour la sélection du fichier de résultats.json et sleep sont importés mais ne sont pas réellement utilisés dans l'implémentation présentée.uploaded_hidden, bien que la fonction exploit() présentée ne renvoie pas ce statut.Avant de publier une version de qualité production, envisagez d'ajouter :
Déplacez les valeurs codées en dur vers une couche de configuration :
Utilisez le module logging de Python au lieu de vous appuyer principalement sur print().
Niveaux suggérés :```text DEBUG INFO WARNING ERROR
### Schéma de résultat
Définissez un objet de résultat cohérent, par exemple :```text
target
status
reason
http_status
evidence
timestamp
Séparer la vérification de vulnérabilité de l'exécution de commandes.
Une architecture plus sûre est :```text Detection → Verification → Evidence
avec l'exécution interactive de commandes désactivée par défaut.
### Liste d'autorisation des cibles
Exiger un fichier de périmètre explicite ou une liste d'autorisation avant que les actions réseau ne soient effectuées.
### Épinglage des dépendances
Utiliser un fichier `requirements.txt` ou un fichier de verrouillage avec des versions de dépendances testées.
### Tests
Ajouter des tests unitaires pour :
- la normalisation des URL ;
- l'analyse des jetons ;
- l'analyse de la liste des cibles ;
- la sérialisation des résultats ;
- la gestion des erreurs ;
- la gestion des chemins candidats.
---
## Structure de dépôt suggérée
Un dépôt propre pourrait utiliser :```text
.
├── README.md
├── LICENSE
├── requirements.txt
├── elv-cve.py
├── tests/
│ ├── test_parser.py
│ ├── test_results.py
│ └── test_token_parser.py
├── docs/
│ └── methodology.md
└── examples/
└── targets.example.txt
Ne committez pas de listes de cibles réelles, d'identifiants, de charges utiles shell, de données de session ou de résultats d'évaluation sensibles.
Entrées .gitignore recommandées :```gitignore
pycache/
*.py[cod]
.venv/
venv/
.env
ELV_CVE/
*.log
*.tmp
.DS_Store
Les artefacts d'évaluation sensibles doivent rester en dehors du dépôt public.
---
## Versionnage
Le projet actuel s'identifie comme suit :```text
v1.0.0
Pour les versions futures, le versionnage sémantique est recommandé :```text MAJOR.MINOR.PATCH
Exemple :```text
1.0.0
1.1.0
1.1.1
2.0.0
Utilisez une incrémentation de version majeure lors de modifications incompatibles de la CLI, du format de résultat ou de l'architecture.
Jalons futurs potentiels :
Un rapport de sécurité utile doit documenter :```text Title Affected Asset Affected Component Version Severity CVE / Advisory Description Preconditions Evidence Business Impact Remediation Retest Result Timeline
Évitez d'inclure des identifiants, des informations personnelles, des données non liées ou des sorties de commandes inutiles dans un rapport public.
---
## Recommandations de remédiation
Pour un déploiement Joomla/JCE affecté, la remédiation doit être fondée sur **l'avis officiel du fournisseur/de sécurité et la plage de versions affectées confirmée**, plutôt que de se fier uniquement aux métadonnées CVE intégrées dans ce script.
Les actions défensives générales incluent :
1. Identifier les versions installées de Joomla et de JCE.
2. Déterminer si le déploiement se situe dans la plage affectée confirmée.
3. Mettre à niveau vers une version corrigée prise en charge par le fournisseur lorsqu'elle est disponible.
4. Examiner les journaux du serveur web et de l'application pour détecter toute activité suspecte de téléversement/importation.
5. Inspecter les fichiers inattendus dans les répertoires accessibles via le web.
6. Renouveler les identifiants si une compromission est suspectée.
7. Examiner les mécanismes de persistance et les tâches planifiées.
8. Retester après la remédiation.
9. Préserver les preuves pertinentes conformément au processus de réponse aux incidents de l'organisation.
---
## Attribution
L'image de marque du projet et les métadonnées sources identifient le moteur comme :
**HxN / E.L.V**
Version du projet :
**1.0.0**
---
## Licence
Ce projet est destiné à être distribué sous la :
**GNU General Public License v3.0**
Consultez le fichier `LICENSE` accompagnant pour le texte complet de la licence.
Si le dépôt ne contient pas encore de fichier `LICENSE`, ajoutez le texte officiel de la GNU GPL v3 avant de publier le dépôt sous licence GPL.
---
## Avertissement
Ce logiciel est fourni pour la recherche en sécurité autorisée, les tests de sécurité défensive, l'éducation et l'utilisation en laboratoire contrôlé.
L'auteur et les contributeurs ne sont pas responsables de toute utilisation abusive, accès non autorisé, dommage, perte de données, interruption de service ou toute autre conséquence résultant de l'utilisation de ce logiciel.
Vous êtes seul responsable de vous assurer que vos activités de test sont conformes aux lois applicables, aux contrats, aux politiques et aux exigences d'autorisation explicite.
**Ne testez que les systèmes que vous possédez ou pour lesquels vous disposez d'une autorisation explicite de test.**
---
## Note finale
Ce README documente le comportement exposé par le code source `elv-cve.py` fourni. Il distingue intentionnellement les détails d'implémentation des affirmations qui nécessitent une vérification indépendante de la vulnérabilité/de l'avis.
Pour un dépôt public, vérifiez les informations CVE et ajoutez des références faisant autorité du fournisseur/de l'avis avant de décrire le projet comme un exploit confirmé pour un produit/une version particulière.