noname-elv/cve-2026-48907CLI de Python que explota CVE-2026-48907 en Joomla JCE mediante la carga de importación de perfiles, verifica las rutas del shell y abre un canal de comandos interactivo en objetivos autorizados.
E.L.V — Exploit Loader & Vulnerability Firmware
Utilidad de investigación de ciberseguridad para evaluación de vulnerabilidades autorizada.
E.L.V CVE Research & Assessment Framework es una utilidad de línea de comandos basada en Python destinada a la investigación de seguridad controlada y la evaluación de vulnerabilidades autorizada.
La implementación proporcionada contiene funcionalidad para:
El código fuente actual identifica su objetivo de investigación como:
CVE-2026-48907 Joomla! JCE Extension < 2.9.99.5 Unauthenticated RCE
Esa afirmación sobre el CVE/producto son metadatos proporcionados por el código fuente y no han sido verificados de forma independiente por este README. Antes de publicar una afirmación de seguridad, valide el identificador, las versiones afectadas, el aviso, el componente afectado y la información de remediación contra una fuente de confianza de CVE/proveedor.
Este proyecto interactúa con aplicaciones web remotas y la implementación proporcionada incluye funcionalidad destinada a subir un payload personalizado del lado del servidor y comunicarse con un shell subido.
Úselo solo contra sistemas para los que tenga autorización explícita.
No use este proyecto para:
Para un laboratorio seguro, use un entorno aislado de VM/contenedor local o un objetivo de entrenamiento deliberadamente vulnerable.
| Campo | Valor |
|---|---|
| Proyecto | E.L.V CVE Research & Assessment Framework |
| Autor / Motor | HxN / E.L.V |
| Versión | 1.0.0 |
| Lenguaje | Python |
| Plataforma | *nix / sistemas tipo Unix |
| Licencia | GNU GPL v3 |
| Interfaz | Línea de comandos |
| Cliente HTTP | requests |
| Concurrencia | ThreadPoolExecutor |
| Propósito Principal | Investigación y evaluación de seguridad autorizada |
El código fuente proporcionado elv-cve.py contiene los siguientes componentes principales.
El script lee un archivo local proporcionado a través de la opción --shell.
El código fuente describe esto como un archivo de shell/uploader personalizado y termina cuando el archivo especificado no puede leerse.
El programa admite dos modos de objetivo mutuamente excluyentes:
Para cada objetivo, el script realiza una solicitud GET contra la raíz del objetivo y espera una respuesta HTTP 200 antes de continuar.
La implementación busca en el HTML devuelto un valor relacionado con CSRF usando expresiones regulares.
Actualmente se implementan dos patrones.
El script construye una solicitud de carga multipart contra:```text /index.php?option=com_jce
La solicitud incluye la tarea de importación de perfil y el token extraído.
### 6. Verificación de rutas candidatas
Tras la solicitud de carga, el programa comprueba varias ubicaciones posibles para el archivo resultante.
El código fuente actual contiene estas rutas candidatas:```text
/tmp/
/images/
/images/stories/
/media/
Para un único objetivo, el programa actual invoca una interfaz de comandos interactiva cuando informa una ruta de shell subida correctamente.
La fuente envía comandos utilizando parámetros POST denominados:```text cmd c
Debido a que esta funcionalidad puede dar lugar a la ejecución remota de comandos, debe restringirse a entornos aislados y explícitamente autorizados.
### 8. Procesamiento de múltiples objetivos
Cuando se proporciona un archivo de objetivos, el programa utiliza un `ThreadPoolExecutor` y procesa los objetivos de forma concurrente.
El número de hilos predeterminado en el código fuente es:```text
10
A grandes rasgos, la implementación actual sigue este flujo:```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
---
## Requisitos
La fuente proporcionada importa:
- Módulos de la biblioteca estándar de Python:
- `random`
- `re`
- `time`
- `argparse`
- `sys`
- `os`
- `json`
- `threading`
- `concurrent.futures`
- Módulos de terceros:
- `requests`
- `urllib3`
Por lo tanto, una instalación mínima de dependencias es:```bash
python3 -m pip install requests urllib3
Para despliegues reproducibles, fija las dependencias en un archivo requirements.txt.
Ejemplo:```text requests urllib3
---
## Instalación
Clona o copia el proyecto en un entorno de evaluación aislado.
Ejemplo:```bash
git clone <YOUR-REPOSITORY-URL>
cd <YOUR-REPOSITORY-DIRECTORY>
Crea un entorno virtual:```bash python3 -m venv .venv
Actívalo:```bash
source .venv/bin/activate
Instalar dependencias:```bash python3 -m pip install -r requirements.txt
Verificar Python:```bash
python3 --version
Verifica la dependencia:```bash python3 -c "import requests, urllib3; print('Dependencies OK')"
> Reemplace `<YOUR-REPOSITORY-URL>` y `<YOUR-REPOSITORY-DIRECTORY>` con los valores utilizados por su repositorio.
---
## Interfaz de línea de comandos
La fuente define las siguientes opciones de línea de comandos.
### Selección de objetivo```text
-u, --url
URL de destino único.```text -f, --file
Ruta a un archivo que contiene las URL de destino.
Estas opciones son mutuamente excluyentes y se requiere una de ellas.
### Selección de payload```text
--shell
Ruta al archivo de payload personalizado local.
Este argumento es requerido por la implementación actual.
-t, --threads
Número de hilos de trabajo.
Predeterminado:```text
10
-v, --verbose
Habilita el flag verbose expuesto por el analizador de argumentos.
Nota: la fuente actual define esta opción pero no utiliza `args.verbose` para cambiar materialmente el comportamiento de la salida.
### Opción de salida```text
-o, --output
El argumento está definido por el parser, pero la implementación actual no utiliza args.output al escribir el resultado final. La ruta del resultado actual está codificada de forma fija como:```text
ELV_CVE/success.txt
Este es un detalle de implementación que vale la pena corregir en una versión futura.
---
## Archivos de entrada
### Lista de objetivos
El modo de lista de objetivos espera una URL por línea.
Las líneas en blanco se ignoran.
Las líneas que comienzan con `#` se ignoran.
Formato conceptual:```text
https://authorized-target-01.example
https://authorized-target-02.example
# laboratory target
https://authorized-target-03.example
Solo los objetivos que estés explícitamente autorizado a evaluar deben colocarse en el archivo.
El argumento --shell apunta a un archivo local que el programa lee como texto.
La fuente proporcionada no valida el contenido del archivo más allá de leerlo correctamente.
Para un desarrollo y pruebas seguros, utiliza un fixture de prueba inofensivo en lugar de un payload que ejecute comandos.
El programa crea:```text ELV_CVE/
Para el modo multiobjetivo, escribe:```text
ELV_CVE/success.txt
El origen actual escribe las URL de shell exitosas en este archivo.
Ejemplo de formato de resultado:```text https://authorized-lab.example/path/to/result
El programa también imprime un resumen de finalización que contiene el número de resultados exitosos en relación con el número de objetivos cargados.
---
## Concurrencia
El modo multiobjetivo utiliza:```python
ThreadPoolExecutor
El número de hilos configurado por defecto es 10.
Una mayor concurrencia puede aumentar:
Para evaluaciones controladas, comience con un valor de concurrencia bajo y auméntelo solo cuando el entorno y la autorización lo permitan.
La implementación proporcionada utiliza requests.Session() para la comunicación HTTP.
Las principales operaciones de red son:
El código fuente utiliza tiempos de espera de solicitud explícitos:
Estos valores están codificados de forma fija en el código fuente actual.
La implementación establece:```python s.verify = False
y suprime `InsecureRequestWarning`.
Esto significa que la verificación de certificados está deshabilitada.
Esto puede ser útil en un laboratorio desechable con certificados autofirmados, pero **no se recomienda para herramientas de seguridad de producción normales**.
Una implementación más segura debería hacer que la verificación de certificados sea configurable y mantener la verificación habilitada de forma predeterminada.
---
## Registro y resultados
La fuente utiliza un bloqueo de hilo alrededor de `safe_print()` para reducir las colisiones de salida entre los hilos de trabajo.
Las categorías de estado típicas incluyen:```text
failed
success
El objeto de resultado también puede contener campos como:```text url status reason shell_url
El colector multiobjetivo además verifica:```text
uploaded_hidden
Sin embargo, la implementación de exploit() proporcionada actualmente no devuelve ese estado.
Esto indica un área donde el modelo de resultados podría depurarse en una versión futura.
La implementación actual maneja varios casos de fallo:
Una solicitud HTTP fallida se registra como un objetivo fallido con el mensaje de excepción.
Si la solicitud GET inicial no devuelve HTTP 200, el procesamiento se detiene para ese objetivo.
Si no se puede extraer el token esperado, el objetivo se reporta como una verificación de vulnerabilidad fallida.
Las excepciones durante la solicitud de carga se capturan y el script continúa con el siguiente intento de extensión/ruta.
Si el archivo de payload local no existe, el programa termina con un error.
El canal interactivo maneja KeyboardInterrupt y sale de la sesión.
Las funciones principales en el código fuente proporcionado son:
safe_print(msg)Asistente de salida por consola seguro para hilos.
read_custom_shell(filepath)Lee el archivo de payload local como texto UTF-8 con errores de decodificación ignorados.
interactive_shell(shell_url)Proporciona la interfaz interactiva de comandos HTTP después de una ruta de shell reportada como exitosa.
exploit(url, shell_content, interactive=False)Realiza el flujo de trabajo de procesamiento del objetivo y devuelve un diccionario de resultados.
main()Maneja:
Este proyecto tiene varias características sensibles a la seguridad que deben entenderse antes de su uso.
El modo interactivo es capaz de enviar comandos a un endpoint HTTP remoto. Esto lo hace sustancialmente más sensible que un escáner pasivo.
No exponga ni distribuya payloads operativos de forma casual.
La verificación de certificados TLS está deshabilitada en la implementación actual.
Esto debería corregirse antes de tratar el proyecto como una herramienta de seguridad madura.
El payload se carga directamente desde un archivo local y se envía como parte de la solicitud HTTP.
Trate los archivos de payload como material ejecutable de pruebas de seguridad.
El código fuente actual no implementa un mecanismo sólido de autorización o lista de permitidos.
Una versión interna más segura debería admitir una lista explícita de objetivos permitidos.
La implementación actual no proporciona un limitador de tasa integral.
Por lo tanto, las solicitudes concurrentes deben controlarse cuidadosamente.
Los archivos de resultados pueden contener URLs asociadas con intentos de explotación exitosos. Proteja estos archivos como datos de evaluación sensibles.
Un flujo de trabajo de evaluación profesional debería verse así:```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
El objetivo de una evaluación de vulnerabilidades debe ser establecer el riesgo con el **mínimo impacto necesario**, no obtener acceso sin restricciones.
---
## Configuración de laboratorio recomendada
Para el desarrollo, cree un entorno dedicado que contenga:
- una VM Linux aislada;
- un servidor web local;
- una instalación de prueba de Joomla;
- el componente/versión de JCE correspondiente;
- aislamiento de red;
- instantáneas/copias de seguridad;
- cuentas de prueba;
- registros de la aplicación y del servidor web.
Evite realizar pruebas contra sistemas de producción no relacionados.
---
## Solución de problemas
### `ModuleNotFoundError: No module named 'requests'`
Instale la dependencia de Python:```bash
python3 -m pip install requests urllib3
Confirme que la ruta proporcionada existe y es legible:```bash ls -l
### La solicitud HTTP inicial falla
Verifique:
- la correctitud de la URL;
- DNS;
- conectividad de red;
- disponibilidad de HTTP/HTTPS;
- reglas de firewall;
- alcance del objetivo;
- registros del servidor.
### No se detecta el token CSRF
La respuesta del objetivo puede diferir de la estructura HTML esperada por las expresiones regulares en la implementación actual.
No asuma que la ausencia de un token significa que el objetivo es seguro o vulnerable. Trátelo como un resultado no concluyente.
### El archivo de resultados está vacío
Verifique:```text
ELV_CVE/success.txt
y revise la salida de la consola en busca de solicitudes HTTP fallidas, fallos en la extracción de tokens o rechazo de la carga.
La implementación proporcionada tiene varias limitaciones.
--verbose está definido pero actualmente no controla el registro detallado.--output está definido pero actualmente no se utiliza para la selección del archivo de resultados.json y sleep se importan pero no se utilizan de forma sustancial en la implementación mostrada.uploaded_hidden, aunque la función exploit() mostrada no devuelve ese estado.Antes de etiquetar una versión de calidad de producción, considere añadir:
Mueva los valores codificados de forma fija a una capa de configuración:
Utilice el módulo logging de Python en lugar de depender principalmente de print().
Niveles sugeridos:```text DEBUG INFO WARNING ERROR
### Esquema de resultados
Defina un objeto de resultado consistente, por ejemplo:```text
target
status
reason
http_status
evidence
timestamp
Separar la verificación de vulnerabilidades de la ejecución de comandos.
Una arquitectura más segura es:```text Detection → Verification → Evidence
con la ejecución interactiva de comandos deshabilitada por defecto.
### Lista de objetivos permitidos
Requerir un archivo de alcance explícito o una lista de permitidos antes de realizar acciones de red.
### Fijación de dependencias
Usar un `requirements.txt` o un archivo de bloqueo con versiones de dependencias probadas.
### Pruebas
Añadir pruebas unitarias para:
- normalización de URL;
- análisis de tokens;
- análisis de listas de objetivos;
- serialización de resultados;
- manejo de errores;
- manejo de rutas candidatas.
---
## Estructura de repositorio sugerida
Un repositorio limpio podría usar:```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
No hagas commit de listas de objetivos reales, credenciales, payloads de shell, datos de sesión ni resultados de evaluación sensibles.
Entradas recomendadas para .gitignore:```gitignore
pycache/
*.py[cod]
.venv/
venv/
.env
ELV_CVE/
*.log
*.tmp
.DS_Store
Los artefactos de evaluación sensibles deben permanecer fuera del repositorio público.
---
## Versionado
El proyecto actual se identifica como:```text
v1.0.0
Para futuras versiones, se recomienda el versionado semántico:```text MAJOR.MINOR.PATCH
Ejemplo:```text
1.0.0
1.1.0
1.1.1
2.0.0
Usa un incremento de versión mayor al realizar cambios que rompan la compatibilidad con la CLI, el formato de resultados o la arquitectura.
Posibles hitos futuros:
Un informe de seguridad útil debe documentar:```text Title Affected Asset Affected Component Version Severity CVE / Advisory Description Preconditions Evidence Business Impact Remediation Retest Result Timeline
Evite incluir credenciales, información personal, datos no relacionados o salida de comandos innecesaria en un informe público.
---
## Guía de Remediación
Para un despliegue de Joomla/JCE afectado, la remediación debe basarse en el **aviso oficial del proveedor/seguridad y el rango de versiones afectadas confirmado**, en lugar de depender únicamente de los metadatos CVE incrustados en este script.
Las acciones defensivas generales incluyen:
1. Identificar las versiones instaladas de Joomla y JCE.
2. Determinar si el despliegue se encuentra dentro del rango afectado confirmado.
3. Actualizar a una versión corregida compatible con el proveedor cuando esté disponible.
4. Revisar los registros del servidor web y de la aplicación en busca de actividad sospechosa de carga/importación.
5. Inspeccionar archivos inesperados en directorios accesibles desde la web.
6. Rotar credenciales si se sospecha de compromiso.
7. Revisar mecanismos de persistencia y tareas programadas.
8. Volver a probar después de la remediación.
9. Preservar la evidencia relevante de acuerdo con el proceso de respuesta a incidentes de la organización.
---
## Atribución
La marca del proyecto y los metadatos de origen identifican el motor como:
**HxN / E.L.V**
Versión del proyecto:
**1.0.0**
---
## Licencia
Este proyecto está destinado a distribuirse bajo la:
**GNU General Public License v3.0**
Consulte el archivo `LICENSE` adjunto para obtener el texto completo de la licencia.
Si el repositorio aún no contiene un archivo `LICENSE`, agregue el texto oficial de GNU GPL v3 antes de publicar el repositorio como licenciado bajo GPL.
---
## Descargo de responsabilidad
Este software se proporciona para investigación de seguridad autorizada, pruebas de seguridad defensiva, educación y uso en laboratorio controlado.
El autor y los colaboradores no son responsables del uso indebido, acceso no autorizado, daños, pérdida de datos, interrupción del servicio o cualquier otra consecuencia derivada del uso de este software.
Usted es el único responsable de garantizar que sus actividades de prueba cumplan con las leyes, contratos, políticas y requisitos de autorización explícita aplicables.
**Solo pruebe sistemas que posea o sistemas para los que tenga permiso explícito de prueba.**
---
## Nota final
Este README documenta el comportamiento expuesto por el código fuente `elv-cve.py` proporcionado. Distingue intencionalmente los detalles de implementación de las afirmaciones que requieren verificación independiente de vulnerabilidad/aviso.
Para un repositorio público, verifique la información de CVE y agregue referencias autorizadas del proveedor/aviso antes de describir el proyecto como un exploit confirmado para un producto/versión en particular.