noname-elv/cve-2026-48907Python-CLI, die CVE-2026-48907 in Joomla JCE über einen Profile-Import-Upload ausnutzt, Shell-Pfade verifiziert und einen interaktiven Befehlskanal auf autorisierten Zielen öffnet.
E.L.V — Exploit Loader & Vulnerability Firmware
Cybersecurity-Forschungswerkzeug für autorisierte Schwachstellenbewertung.
E.L.V CVE Research & Assessment Framework ist ein Python-basiertes Kommandozeilenwerkzeug, das für kontrollierte Sicherheitsforschung und autorisierte Schwachstellenbewertung vorgesehen ist.
Die bereitgestellte Implementierung enthält Funktionalität für:
Der aktuelle Quellcode identifiziert sein Forschungsziel als:
CVE-2026-48907 Joomla! JCE Extension < 2.9.99.5 Unauthenticated RCE
Diese CVE-/Produktangabe sind Metadaten, die vom Quellcode bereitgestellt werden, und wurden von diesem README nicht unabhängig verifiziert. Bevor Sie eine Sicherheitsbehauptung veröffentlichen, validieren Sie den Identifier, die betroffenen Versionen, den Advisory, die betroffene Komponente und die Behebungsinformationen anhand einer vertrauenswürdigen Hersteller-/CVE-Quelle.
Dieses Projekt interagiert mit entfernten Webanwendungen, und die bereitgestellte Implementierung enthält Funktionalität, die darauf abzielt, eine benutzerdefinierte serverseitige Payload hochzuladen und mit einer hochgeladenen Shell zu kommunizieren.
Verwenden Sie es nur gegen Systeme, für die Sie ausdrückliche Autorisierung besitzen.
Verwenden Sie dieses Projekt nicht, um:
Verwenden Sie für ein sicheres Labor eine isolierte lokale VM-/Container-Umgebung oder ein absichtlich verwundbares Trainingsziel.
| Feld | Wert |
|---|---|
| Projekt | E.L.V CVE Research & Assessment Framework |
| Autor / Engine | HxN / E.L.V |
| Version | 1.0.0 |
| Sprache | Python |
| Plattform | *nix / Unix-ähnliche Systeme |
| Lizenz | GNU GPL v3 |
| Schnittstelle | Kommandozeile |
| HTTP-Client | requests |
| Nebenläufigkeit | ThreadPoolExecutor |
| Hauptzweck | Autorisierte Sicherheitsforschung und -bewertung |
Der bereitgestellte Quellcode elv-cve.py enthält die folgenden Hauptkomponenten.
Das Skript liest eine lokale Datei, die über die Option --shell bereitgestellt wird.
Der Quellcode beschreibt dies als eine benutzerdefinierte Shell-/Uploader-Datei und beendet sich, wenn die angegebene Datei nicht gelesen werden kann.
Das Programm unterstützt zwei sich gegenseitig ausschließende Zielmodi:
Für jedes Ziel führt das Skript eine GET-Anfrage gegen das Ziel-Root durch und erwartet eine HTTP-200-Antwort, bevor es fortfährt.
Die Implementierung durchsucht das zurückgegebene HTML mithilfe regulärer Ausdrücke nach einem CSRF-bezogenen Wert.
Derzeit sind zwei Muster implementiert.
Das Skript konstruiert eine Multipart-Upload-Anfrage gegen:```text /index.php?option=com_jce
Die Anfrage enthält die Profil-Import-Aufgabe und das extrahierte Token.
### 6. Überprüfung des Kandidatenpfads
Nach der Upload-Anfrage prüft das Programm mehrere mögliche Speicherorte für die resultierende Datei.
Die aktuelle Quelle enthält diese Kandidatenpfade:```text
/tmp/
/images/
/images/stories/
/media/
Für ein einzelnes Ziel ruft das aktuelle Programm eine interaktive Befehlsschnittstelle auf, wenn es einen erfolgreich hochgeladenen Shell-Pfad meldet.
Die Quelle sendet Befehle unter Verwendung von POST-Parametern mit den Namen:```text cmd c
Da diese Funktionalität zur Remote-Befehlsausführung führen kann, sollte sie auf isolierte, ausdrücklich autorisierte Umgebungen beschränkt werden.
### 8. Verarbeitung mehrerer Ziele
Wenn eine Zieldatei angegeben wird, verwendet das Programm einen `ThreadPoolExecutor` und verarbeitet die Ziele nebenläufig.
Die Standard-Thread-Anzahl im Quellcode ist:```text
10
Auf hoher Ebene folgt die aktuelle Implementierung diesem Ablauf:```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
---
## Anforderungen
Die bereitgestellte Quelle importiert:
- Python-Standardbibliotheksmodule:
- `random`
- `re`
- `time`
- `argparse`
- `sys`
- `os`
- `json`
- `threading`
- `concurrent.futures`
- Drittanbietermodule:
- `requests`
- `urllib3`
Eine minimale Abhängigkeitsinstallation ist daher:```bash
python3 -m pip install requests urllib3
Für reproduzierbare Deployments sollten Abhängigkeiten in einer requirements.txt-Datei festgeschrieben werden.
Beispiel:```text requests urllib3
---
## Installation
Klonen oder kopieren Sie das Projekt in eine isolierte Assessment-Umgebung.
Beispiel:```bash
git clone <YOUR-REPOSITORY-URL>
cd <YOUR-REPOSITORY-DIRECTORY>
Erstellen Sie eine virtuelle Umgebung:```bash python3 -m venv .venv
Aktivieren Sie es:```bash
source .venv/bin/activate
Abhängigkeiten installieren:```bash python3 -m pip install -r requirements.txt
Verify Python:```bash
python3 --version
Überprüfen Sie die Abhängigkeit:```bash python3 -c "import requests, urllib3; print('Dependencies OK')"
> Ersetzen Sie `<YOUR-REPOSITORY-URL>` und `<YOUR-REPOSITORY-DIRECTORY>` durch die Werte, die von Ihrem Repository verwendet werden.
---
## Kommandozeilenschnittstelle
Die Quelle definiert die folgenden Kommandozeilenoptionen.
### Zielauswahl```text
-u, --url
Einzelne Ziel-URL.```text -f, --file
Pfad zu einer Datei, die Ziel-URLs enthält.
Diese Optionen schließen sich gegenseitig aus und eine davon ist erforderlich.
### Payload-Auswahl```text
--shell
Pfad zur lokalen benutzerdefinierten Payload-Datei.
Dieses Argument ist von der aktuellen Implementierung erforderlich.
-t, --threads
Anzahl der Worker-Threads.
Standard:```text
10
-v, --verbose
Aktiviert das von dem Argument-Parser bereitgestellte Verbose-Flag.
Hinweis: Die aktuelle Quelle definiert diese Option, verwendet jedoch `args.verbose` nicht, um das Ausgabeverhalten wesentlich zu ändern.
### Ausgabeoption```text
-o, --output
Das Argument wird vom Parser definiert, aber die aktuelle Implementierung verwendet args.output nicht, wenn das Endergebnis geschrieben wird. Der aktuelle Ergebnispfad ist fest codiert auf:```text
ELV_CVE/success.txt
Dies ist ein Implementierungsdetail, das in einer zukünftigen Version behoben werden sollte.
---
## Eingabedateien
### Zielliste
Der Ziellisten-Modus erwartet eine URL pro Zeile.
Leere Zeilen werden ignoriert.
Zeilen, die mit `#` beginnen, werden ignoriert.
Konzeptionelles Format:```text
https://authorized-target-01.example
https://authorized-target-02.example
# laboratory target
https://authorized-target-03.example
Nur Ziele, für deren Bewertung Sie ausdrücklich autorisiert sind, sollten in die Datei aufgenommen werden.
Das Argument --shell verweist auf eine lokale Datei, die das Programm als Text liest.
Die bereitgestellte Quelle validiert den Inhalt der Datei nicht über das erfolgreiche Lesen hinaus.
Für sichere Entwicklung und Tests verwenden Sie ein harmloses Test-Fixture anstelle einer befehlsausführenden Payload.
Das Programm erstellt:```text ELV_CVE/
Für den Multi-Target-Modus schreibt es:```text
ELV_CVE/success.txt
Die aktuelle Quelle schreibt erfolgreiche Shell-URLs in diese Datei.
Beispiel-Ergebnisformat:```text https://authorized-lab.example/path/to/result
Das Programm gibt außerdem eine Abschlusszusammenfassung aus, die die Anzahl der erfolgreichen Ergebnisse im Verhältnis zur Anzahl der geladenen Ziele enthält.
---
## Nebenläufigkeit
Der Multi-Target-Modus verwendet:```python
ThreadPoolExecutor
Die konfigurierte Thread-Anzahl beträgt standardmäßig 10.
Eine höhere Parallelität kann Folgendes erhöhen:
Bei kontrollierten Assessments sollte mit einem niedrigen Parallelitätswert begonnen und dieser nur erhöht werden, wenn die Umgebung und die Autorisierung dies zulassen.
Die bereitgestellte Implementierung verwendet requests.Session() für die HTTP-Kommunikation.
Die wichtigsten Netzwerkoperationen sind:
Der Quellcode verwendet explizite Request-Timeouts:
Diese Werte sind im aktuellen Quellcode fest kodiert.
Die Implementierung setzt:```python s.verify = False
und unterdrückt `InsecureRequestWarning`.
Das bedeutet, dass die Zertifikatsüberprüfung deaktiviert ist.
Das kann in einem Wegwerf-Lab mit selbstsignierten Zertifikaten nützlich sein, ist aber **für normale Produktions-Sicherheitstools nicht empfehlenswert**.
Eine sicherere Implementierung sollte die Zertifikatsüberprüfung konfigurierbar machen und die Überprüfung standardmäßig aktiviert lassen.
---
## Logging und Ergebnisse
Die Quelle verwendet eine Thread-Sperre um `safe_print()`, um Ausgabekollisionen zwischen Worker-Threads zu reduzieren.
Typische Statuskategorien umfassen:```text
failed
success
Das Ergebnisobjekt kann auch Felder wie die folgenden enthalten:```text url status reason shell_url
Der Multi-Target-Collector prüft zusätzlich auf:```text
uploaded_hidden
Die bereitgestellte exploit()-Implementierung gibt diesen Status derzeit jedoch nicht zurück.
Dies weist auf einen Bereich hin, in dem das Ergebnis-Modell in einer zukünftigen Version bereinigt werden könnte.
Die aktuelle Implementierung behandelt mehrere Fehlerfälle:
Eine fehlgeschlagene HTTP-Anfrage wird als fehlgeschlagenes Ziel mit der Ausnahmemeldung erfasst.
Wenn die anfängliche GET-Anfrage nicht HTTP 200 zurückgibt, wird die Verarbeitung für dieses Ziel beendet.
Wenn das erwartete Token nicht extrahiert werden kann, wird das Ziel als fehlgeschlagene Schwachstellenprüfung gemeldet.
Ausnahmen während der Upload-Anfrage werden abgefangen und das Skript fährt mit dem nächsten Erweiterungs-/Pfadversuch fort.
Wenn die lokale Payload-Datei nicht existiert, wird das Programm mit einem Fehler beendet.
Der interaktive Kanal behandelt KeyboardInterrupt und beendet die Sitzung.
Die Hauptfunktionen im bereitgestellten Quellcode sind:
safe_print(msg)Thread-sichere Konsolenausgabe-Hilfsfunktion.
read_custom_shell(filepath)Liest die lokale Payload-Datei als UTF-8-Text mit ignorierten Dekodierungsfehlern.
interactive_shell(shell_url)Stellt die interaktive HTTP-Befehlsschnittstelle nach einem gemeldeten erfolgreichen Shell-Pfad bereit.
exploit(url, shell_content, interactive=False)Führt den Zielverarbeitungs-Workflow aus und gibt ein Ergebnis-Dictionary zurück.
main()Behandelt:
Dieses Projekt weist mehrere sicherheitsrelevante Eigenschaften auf, die vor der Verwendung verstanden werden sollten.
Der interaktive Modus ist in der Lage, Befehle an einen entfernten HTTP-Endpunkt zu senden. Dadurch ist er wesentlich sensibler als ein passiver Scanner.
Betriebliche Payloads sollten nicht leichtfertig offengelegt oder weitergegeben werden.
Die TLS-Zertifikatsüberprüfung ist in der aktuellen Implementierung deaktiviert.
Dies sollte korrigiert werden, bevor das Projekt als ausgereiftes Sicherheitstool betrachtet wird.
Die Payload wird direkt aus einer lokalen Datei geladen und als Teil der HTTP-Anfrage übermittelt.
Behandeln Sie Payload-Dateien als ausführbares Sicherheitstest-Material.
Der aktuelle Quellcode implementiert keinen starken Autorisierungs- oder Allowlist-Mechanismus.
Eine sicherere interne Version sollte eine explizite Ziel-Allowlist unterstützen.
Die aktuelle Implementierung bietet keinen umfassenden Rate-Limiter.
Gleichzeitige Anfragen sollten daher sorgfältig kontrolliert werden.
Ergebnisdateien können URLs enthalten, die mit erfolgreichen Ausnutzungsversuchen verbunden sind. Schützen Sie diese Dateien als sensible Bewertungsdaten.
Ein professioneller Bewertungs-Workflow sollte wie folgt aussehen:```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
Das Ziel einer Schwachstellenbewertung sollte darin bestehen, das Risiko mit der **minimal notwendigen Auswirkung** festzustellen, nicht darin, uneingeschränkten Zugriff zu erlangen.
---
## Empfohlener Laboraufbau
Für die Entwicklung eine dedizierte Umgebung erstellen, die Folgendes enthält:
- eine isolierte Linux-VM;
- einen lokalen Webserver;
- eine Test-Joomla-Installation;
- die relevante JCE-Komponente/Version;
- Netzwerkisolation;
- Snapshots/Backups;
- Testkonten;
- Anwendungs- und Webserver-Logs.
Vermeiden Sie Tests gegen nicht zugehörige Produktionssysteme.
---
## Fehlerbehebung
### `ModuleNotFoundError: No module named 'requests'`
Die Python-Abhängigkeit installieren:```bash
python3 -m pip install requests urllib3
Bestätigen Sie, dass der angegebene Pfad existiert und lesbar ist:```bash ls -l
### Erste HTTP-Anfrage schlägt fehl
Prüfen:
- URL-Korrektheit;
- DNS;
- Netzwerkkonnektivität;
- HTTP/HTTPS-Verfügbarkeit;
- Firewall-Regeln;
- Zielbereich;
- Server-Logs.
### CSRF-Token wird nicht erkannt
Die Zielantwort kann von der HTML-Struktur abweichen, die von den regulären Ausdrücken in der aktuellen Implementierung erwartet wird.
Gehen Sie nicht davon aus, dass ein fehlendes Token bedeutet, dass das Ziel sicher oder verwundbar ist. Behandeln Sie es als ein nicht schlüssiges Ergebnis.
### Ergebnisdatei ist leer
Prüfen:```text
ELV_CVE/success.txt
und die Konsolenausgabe auf fehlgeschlagene HTTP-Anfragen, Token-Extraktionsfehler oder Upload-Ablehnung zu überprüfen.
Die bereitgestellte Implementierung weist mehrere Einschränkungen auf.
--verbose ist definiert, steuert derzeit jedoch keine detaillierte Protokollierung.--output ist definiert, wird derzeit jedoch nicht für die Auswahl der Ergebnisdatei verwendet.json und sleep werden importiert, aber in der gezeigten Implementierung nicht wesentlich verwendet.uploaded_hidden, obwohl die gezeigte exploit()-Funktion diesen Status nicht zurückgibt.Bevor eine produktionsreife Version getaggt wird, sollte Folgendes in Betracht gezogen werden:
Feste Werte in eine Konfigurationsschicht verschieben:
Das logging-Modul von Python verwenden, anstatt sich hauptsächlich auf print() zu verlassen.
Empfohlene Stufen:```text DEBUG INFO WARNING ERROR
### Ergebnis-Schema
Definiere ein konsistentes Ergebnisobjekt, zum Beispiel:```text
target
status
reason
http_status
evidence
timestamp
Trennen Sie die Schwachstellenverifizierung von der Befehlsausführung.
Eine sicherere Architektur ist:```text Detection → Verification → Evidence
mit standardmäßig deaktivierter interaktiver Befehlsausführung.
### Ziel-Allowlisting
Erfordern Sie eine explizite Scope-Datei oder Allowlist, bevor Netzwerkaktionen ausgeführt werden.
### Dependency-Pinning
Verwenden Sie eine `requirements.txt` oder Lock-Datei mit getesteten Abhängigkeitsversionen.
### Tests
Fügen Sie Unit-Tests hinzu für:
- URL-Normalisierung;
- Token-Parsing;
- Parsing der Zielliste;
- Ergebnis-Serialisierung;
- Fehlerbehandlung;
- Behandlung von Kandidatenpfaden.
---
## Vorgeschlagene Repository-Struktur
Ein sauberes Repository könnte Folgendes verwenden:```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
Committen Sie keine echten Ziel-Listen, Anmeldedaten, Shell-Payloads, Sitzungsdaten oder sensiblen Bewertungsergebnisse.
Empfohlene .gitignore-Einträge:```gitignore
pycache/
*.py[cod]
.venv/
venv/
.env
ELV_CVE/
*.log
*.tmp
.DS_Store
Sensible Bewertungsartefakte sollten außerhalb des öffentlichen Repositorys verbleiben.
---
## Versionierung
Das aktuelle Projekt identifiziert sich als:```text
v1.0.0
Für zukünftige Releases wird semantische Versionierung empfohlen:```text MAJOR.MINOR.PATCH
Beispiel:```text
1.0.0
1.1.0
1.1.1
2.0.0
Verwende eine Erhöhung der Hauptversion, wenn du Breaking Changes an der CLI, am Ergebnisformat oder an der Architektur vornimmst.
Mögliche zukünftige Meilensteine:
Ein nützlicher Sicherheitsbericht sollte dokumentieren:```text Title Affected Asset Affected Component Version Severity CVE / Advisory Description Preconditions Evidence Business Impact Remediation Retest Result Timeline
Vermeiden Sie die Aufnahme von Anmeldedaten, personenbezogenen Informationen, nicht relevanten Daten oder unnötiger Befehlsausgabe in einen öffentlichen Bericht.
---
## Anleitung zur Behebung
Für eine betroffene Joomla/JCE-Bereitstellung sollte die Behebung auf der **offiziellen Hersteller-/Sicherheitsempfehlung und dem bestätigten betroffenen Versionsbereich** basieren, anstatt sich ausschließlich auf die in diesem Skript eingebetteten CVE-Metadaten zu verlassen.
Allgemeine defensive Maßnahmen umfassen:
1. Identifizieren Sie die installierten Joomla- und JCE-Versionen.
2. Stellen Sie fest, ob die Bereitstellung in den bestätigten betroffenen Bereich fällt.
3. Führen Sie ein Upgrade auf eine vom Hersteller unterstützte korrigierte Version durch, sobald verfügbar.
4. Überprüfen Sie Webserver- und Anwendungsprotokolle auf verdächtige Upload-/Import-Aktivitäten.
5. Untersuchen Sie unerwartete Dateien in webzugänglichen Verzeichnissen.
6. Rotieren Sie Anmeldedaten, wenn eine Kompromittierung vermutet wird.
7. Überprüfen Sie Persistenzmechanismen und geplante Aufgaben.
8. Testen Sie nach der Behebung erneut.
9. Bewahren Sie relevante Beweise gemäß dem Incident-Response-Prozess der Organisation auf.
---
## Zuordnung
Projekt-Branding und Quellmetadaten identifizieren die Engine als:
**HxN / E.L.V**
Projektversion:
**1.0.0**
---
## Lizenz
Dieses Projekt ist für die Verteilung unter der folgenden Lizenz vorgesehen:
**GNU General Public License v3.0**
Siehe die beigefügte `LICENSE`-Datei für den vollständigen Lizenztext.
Wenn das Repository noch keine `LICENSE`-Datei enthält, fügen Sie den offiziellen GNU GPL v3-Text hinzu, bevor Sie das Repository als GPL-lizenziert veröffentlichen.
---
## Haftungsausschluss
Diese Software wird für autorisierte Sicherheitsforschung, defensives Sicherheitstesting, Bildung und kontrollierte Laborumgebungen bereitgestellt.
Der Autor und die Mitwirkenden sind nicht verantwortlich für Missbrauch, unbefugten Zugriff, Schäden, Datenverlust, Dienstunterbrechungen oder andere Konsequenzen, die sich aus der Nutzung dieser Software ergeben.
Sie sind allein dafür verantwortlich, sicherzustellen, dass Ihre Testaktivitäten mit geltenden Gesetzen, Verträgen, Richtlinien und ausdrücklichen Autorisierungsanforderungen übereinstimmen.
**Testen Sie nur Systeme, die Ihnen gehören oder für die Sie eine ausdrückliche Genehmigung zum Testen haben.**
---
## Abschließende Anmerkung
Diese README dokumentiert das Verhalten, das durch den bereitgestellten `elv-cve.py`-Quellcode offengelegt wird. Sie unterscheidet bewusst zwischen Implementierungsdetails und Behauptungen, die eine unabhängige Schwachstellen-/Advisory-Verifizierung erfordern.
Für ein öffentliches Repository verifizieren Sie die CVE-Informationen und fügen Sie maßgebliche Hersteller-/Advisory-Referenzen hinzu, bevor Sie das Projekt als bestätigten Exploit für ein bestimmtes Produkt/eine bestimmte Version beschreiben.