Skip to content
KitploitKITPLOIT
HerramientasExploitsBlog
Log in
Enviar
HerramientasExploitsBlog
Enviar

¡Herramientas de Hacking, PenTest y Ciberseguridad para tu Arsenal de Seguridad!

Kitploit es un directorio de herramientas de hacking, ciberseguridad y pentesting. Descubre las últimas actualizaciones de proyectos para encontrar vulnerabilidades, analizar sistemas, automatizar pruebas y fortalecer tu seguridad.

FeedsContactoPrivacidad© 2026 Kitploit

Directorio de Herramientas

Categorías

Ver todas las categorías
Loading categories
joomla-menu-items-api — Joomla 6.1.3 - Alta - Remota - ACL - restos de la API de elementos de menú | Kitploit
Herramientas/GitHubGitHub/abraxas/joomla-menu-items-api
Autenticación y AutorizaciónAnálisis de VulnerabilidadesExplotaciónExplotación de Aplicaciones WebSeguridad WebPruebas de PenetraciónSeguridad de APIsLabs y Práctica
GitHubabraxas/joomla-menu-items-api

joomla-menu-items-api

Joomla 6.1.3 - Alta - Remota - ACL - restos de la API de elementos de menú

Ver Repositorio
4hace 2 díasAún no revisado

Más Populares

Ver todos →

Descubre las herramientas más usadas por nuestra comunidad.

Explora todas las herramientas

Explora nuestra colección de herramientas

Ver todas las herramientas →
Compartir

Abraxas Labs - joomla-menu-items-api

abraxaslabs.tech  ·  github.com/abraxas  ·  @abraxas_null  ·  [email protected]  ·  joomla-menu-items-api

joomla-menu-items-api

Clase: Privilegio residual Alcance: Remoto

Joomla CMS 6.1.3 (0f2d4de) - Open Source Matters

La interfaz de administración para elementos de menú verifica com_menus.menu.{id} y rechaza menutype == main. api/components/com_menus/src/Controller/ItemsController.php no tiene allowAdd / allowEdit, por lo que ApiController solo solicita core.manage más core.create / core.edit sobre com_menus.

Un usuario con token que puede gestionar un menú puede hacer POST a /api/index.php/v1/menus/administrator/items sobre un menú al que se le deniega el acceso en la interfaz, incluido el menú protegido de administrador main.

IDsin CVE todavía
ClasePrivilegio residual / omisión de autorización
AlcanceRemoto (token de API con core.login.api)
CWECWE-863
CVSSAlto: 8.1 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
ProductoJoomla CMS
Afectado6.1.3 (0f2d4de4729eb951e0878fec98c7990da07915b2)
AutenticaciónUsuario remoto de API con core.login.api + core.manage + core.create/core.edit sobre com_menus, no Super User. Por defecto core.login.api es solo para Super User.
LicenciaGNU Affero GPL v3.0
Laboratoriosolo 127.0.0.1

Qué puede hacer un atacante

Usuario con token que puede crear elementos solo en el menú A. Aún no puede instalar extensiones a menos que ya tenga ese permiso. No se convierte en Super User a partir de este residual.

PrivilegioMétodo / rutaTipoProbado en laboratorio o inferido
Crear un elemento en un menú al que se le deniega el accesoPOST /api/index.php/v1/menus/administrator/items con menutype de BintegridadProbado en laboratorio. HTTP 200, elemento 102 en staffmenu, título poc-JOOMLA-MENU-ITEMS-API-WITNESS
Colocar una URL en el menú protegido de administrador mainMismo POST con menutype=mainintegridadProbado en laboratorio HTTP 200. La interfaz allowEdit devuelve false para main
Dirigir al personal a un inicio de sesión similar o ocultar un elemento de administración realElemento de URL publicado en un menú de administraciónintegridad / reconocimientoInferido a partir de la escritura. El laboratorio colocó https://example.invalid/
Editar o eliminar elementos en menús que no poseenLa API PATCH / DELETE usa el mismo allow* ausenteintegridadInferido. El laboratorio ejercitó la creación
Instalar extensiones o convertirse en Super UserNecesita otra ACLn/aCerrado. Manager no es Super User

Cerrado en este pin: añadir/guardar en la interfaz sobre staffmenu para el mismo usuario (not permitted). Añadir en la interfaz sobre labmenu todavía funciona. La puerta core.admin de la API de grupos de 6.1.1 no se ha tocado.

Cómo lo encontré

Fijé 6.1.3 después de la oleada JSST de 2026. El ItemController del administrador ya hace lo correcto:

return $user->authorise('core.create', 'com_menus.menu.' . $menutypeID);
if ($item->menutype == 'main') {
    return false;
}
return $user->authorise('core.edit', 'com_menus.menu.' . (int) $menutypeID);

El controlador de elementos de la API no sobrescribe allowAdd / allowEdit. El ApiController por defecto solo verifica el componente core.manage más core.create / core.edit. La ruta canSave del modelo solo verifica el componente core.edit. La copia/movimiento por lotes ya verifica el recurso del menú.

Caminos equivocados ya registrados: leer HTTP 200 de la interfaz como permitido (el cuerpo es "not permitted"); tratar core.manage sobre com_menus como suficiente en la interfaz (la interfaz todavía se basa en com_menus.menu.{id}); un Manager estándar sin core.login.api. Teatro: un reverse shell. El oráculo es API 200 en staffmenu y main más denegación en la interfaz sobre B.

Residuales del mismo pin: levels API, media override, articles catid.

Laboratorio

python3 joomla-menu-items-api-Abraxas-Labs.py

o

cd lab
./run.sh

Objetivo solo http://127.0.0.1:19530. Imagen joomla:6.1.3-php8.3-apache.

SUCCESS joomla-menu-items-api api-b-http=200 item-id=102 menutype=staffmenu api-main-http=200 ui-add-b=200 ui-save-b=200 JOOMLA-MENU-ITEMS-API-WITNESS

ui-add-b / ui-save-b son HTTP 200; la denegación de B es el cuerpo "not permitted" de la interfaz, no un estado 403.

La solución

Copiar ItemController::allowAdd / allowEdit (y delete) al controlador de la API, incluido el bloque main. Verificar el recurso del tipo de menú en canSave de la misma manera.

Referencias

  • github.com/joomla/joomla-cms etiqueta 6.1.3 (0f2d4de4729eb951e0878fec98c7990da07915b2)
  • ItemsController.php
  • ItemController.php
  • Misma etiqueta: joomla-levels-api · joomla-media-override · joomla-articles-catid
  • CWE-863

Licencia

GNU Affero GPL v3.0. Ver LICENSE. Solo laboratorio en loopback. Sin garantía.

Descargar herramienta