Skip to content
KitploitKITPLOIT
StrumentiExploitsBlog
Log in
Invia
StrumentiExploitsBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

FeedContattoPrivacy© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
joomla-menu-items-api — Joomla 6.1.3 - Alta - Remota - ACL - residuo dell'API degli elementi di menu | Kitploit
Strumenti/GitHubGitHub/abraxas/joomla-menu-items-api
Autenticazione e AutorizzazioneAnalisi delle VulnerabilitàExploitSfruttamento di Applicazioni WebSicurezza WebPenetration TestingSicurezza delle APILab e Pratica
GitHubabraxas/joomla-menu-items-api

joomla-menu-items-api

Joomla 6.1.3 - Alta - Remota - ACL - residuo dell'API degli elementi di menu

Vedi Repository
206 giorni faNon ancora revisionato

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi

Abraxas Labs - joomla-menu-items-api

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

Write-up: https://abraxaslabs.tech/research/joomla-menu-items-api

joomla-menu-items-api

Classe: Privilegio residuo Raggiungibilità: Remota

Joomla CMS 6.1.3 (0f2d4de) - Open Source Matters

L'interfaccia amministrativa per le voci di menu verifica com_menus.menu.{id} e rifiuta menutype == main. api/components/com_menus/src/Controller/ItemsController.php non ha allowAdd / allowEdit, quindi ApiController richiede solo core.manage più core.create / core.edit su com_menus.

Un utente con token che può gestire un menu può effettuare una POST su /api/index.php/v1/menus/administrator/items verso un menu a cui è negato l'accesso nell'interfaccia, incluso il menu protetto main dell'amministratore.

IDnessuna CVE al momento
ClassePrivilegio residuo / bypass dell'autorizzazione
RaggiungibilitàRemota (token 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
ProdottoJoomla CMS
Affetto6.1.3 (0f2d4de4729eb951e0878fec98c7990da07915b2)
AutenticazioneUtente API remoto con core.login.api + core.manage + core.create/core.edit su com_menus, non Super User. Il valore predefinito di core.login.api è riservato solo al Super User.
LicenzaGNU Affero GPL v3.0
Labsolo 127.0.0.1

Cosa può fare un attaccante

Utente con token che può creare voci solo sul menu A. Non può comunque installare estensioni a meno che non abbia già tale permesso. Non diventa Super User grazie a questo privilegio residuo.

PrivilegioMetodo / percorsoTipoDimostrato in laboratorio o dedotto
Creare una voce su un menu a cui è negato l'accessoPOST /api/index.php/v1/menus/administrator/items con menutype di BintegritàDimostrato in laboratorio. HTTP 200, voce 102 su staffmenu, titolo poc-JOOMLA-MENU-ITEMS-API-WITNESS
Inserire un URL sul menu protetto main dell'amministratoreStessa POST con menutype=mainintegritàDimostrato in laboratorio HTTP 200. L'interfaccia allowEdit restituisce false per main
Indirizzare lo staff verso un login simile o nascondere una voce admin realeVoce URL pubblicata su un menu adminintegrità / ricognizioneDedotto dalla scrittura. In laboratorio è stato inserito https://example.invalid/
Modificare o eliminare voci su menu di cui non sono proprietariPATCH / DELETE API usano la stessa mancanza di allow*integritàDedotto. In laboratorio è stata esercitata la creazione
Installare estensioni o diventare Super UserRichiede altre ACLn/dEscluso. Il Manager non è Super User

Escluso su questa versione: aggiunta/salvataggio nell'interfaccia su staffmenu per lo stesso utente (not permitted). L'aggiunta nell'interfaccia su labmenu funziona ancora. Il controllo core.admin dell'API Groups dalla 6.1.1 è invariato.

Come l'ho trovato

Ho fissato la versione 6.1.3 dopo l'ondata JSST del 2026. L'ItemController dell'amministratore fa già la cosa giusta:

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);

Il controller degli elementi API non sovrascrive allowAdd / allowEdit. Il ApiController predefinito controlla solo il componente core.manage più core.create / core.edit. Il percorso canSave del modello controlla solo il componente core.edit. La copia/spostamento in batch controlla già l'asset del menu.

Vicoli ciechi già registrati: interpretare l'HTTP 200 dell'UI come autorizzazione (il corpo è "not permitted"); considerare sufficiente core.manage su com_menus nell'UI (l'UI si basa comunque su com_menus.menu.{id}); un Manager standard senza core.login.api. Scenario: una reverse shell. L'oracolo è API 200 su staffmenu e main più il rifiuto dell'UI su B.

Stessi residui del pin: levels API, media override, articles catid.

Lab

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

o

cd lab
./run.sh

Prendi di mira solo http://127.0.0.1:19530. Immagine 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 restituiscono HTTP 200; il diniego di B è il corpo "not permitted" dell'interfaccia, non uno stato 403.

La correzione

Copiare ItemController::allowAdd / allowEdit (e delete) sul controller API, incluso il blocco main. Verificare l'asset di tipo menu in canSave allo stesso modo.

Riferimenti

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

Licenza

GNU Affero GPL v3.0. Vedi LICENSE. Solo laboratorio loopback. Nessuna garanzia.

Scarica lo strumento