Skip to content
KitploitKITPLOIT
ToolsExploitsBlog
Log in
Einreichen
ToolsExploitsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

FeedsKontaktDatenschutz© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
joomla-menu-items-api — Joomla 6.1.3 – Hoch – Remote – ACL – API-Reste bei Menüeinträgen | Kitploit
Tools/GitHubGitHub/abraxas/joomla-menu-items-api
Authentifizierung & AutorisierungSchwachstellenanalyseExploitationWebanwendungs-ExploitationWebsicherheitPenetrationstestsAPI-SicherheitLabs & Praxis
GitHubabraxas/joomla-menu-items-api

joomla-menu-items-api

Joomla 6.1.3 – Hoch – Remote – ACL – API-Reste bei Menüeinträgen

Repository anzeigen
20vor 6 TagenNoch nicht geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen

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

Klasse: Privilegien-Rest Reichweite: Remote

Joomla CMS 6.1.3 (0f2d4de) - Open Source Matters

Die Administrator-Oberfläche für Menüeinträge prüft com_menus.menu.{id} und verweigert menutype == main. api/components/com_menus/src/Controller/ItemsController.php hat kein allowAdd / allowEdit, daher fragt ApiController nur nach core.manage plus core.create / core.edit auf com_menus.

Ein Token-Benutzer, der ein Menü verwalten darf, kann per POST /api/index.php/v1/menus/administrator/items auf ein Menü zugreifen, für das ihm in der Oberfläche der Zugriff verweigert wird, einschließlich des geschützten Administrator-Menüs main.

IDnoch keine CVE
KlassePrivilegien-Rest / Autorisierungsumgehung
ReichweiteRemote (API-Token mit core.login.api)
CWECWE-863
CVSSHoch: 8.1 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
ProduktJoomla CMS
Betroffen6.1.3 (0f2d4de4729eb951e0878fec98c7990da07915b2)
AuthRemote-API-Benutzer mit core.login.api + core.manage + core.create/core.edit auf com_menus, kein Super User. Standardmäßig ist core.login.api nur für Super User.
LizenzGNU Affero GPL v3.0
Labnur 127.0.0.1

Was ein Angreifer tun kann

Token-Benutzer, der nur Einträge auf Menü A erstellen darf. Er kann weiterhin keine Erweiterungen installieren, sofern er diese Berechtigung nicht bereits besitzt. Durch diesen Rest wird er nicht zum Super User.

PrivilegMethode / PfadArtIm Lab nachgewiesen oder abgeleitet
Einen Eintrag auf einem Menü erstellen, für das ihm der Zugriff verweigert wirdPOST /api/index.php/v1/menus/administrator/items mit menutype von BIntegritätIm Lab nachgewiesen. HTTP 200, Eintrag 102 auf staffmenu, Titel poc-JOOMLA-MENU-ITEMS-API-WITNESS
Eine URL auf dem geschützten Administrator-Menü main platzierenDerselbe POST mit menutype=mainIntegritätIm Lab nachgewiesen HTTP 200. UI allowEdit gibt für main false zurück
Mitarbeiter auf eine nachgeahmte Anmeldeseite leiten oder einen echten Admin-Eintrag verbergenVeröffentlichter URL-Eintrag auf einem Admin-MenüIntegrität / ReconAbgeleitet aus dem Schreibzugriff. Im Lab wurde https://example.invalid/ platziert
Einträge auf Menüs bearbeiten oder löschen, die ihm nicht gehörenAPI PATCH / DELETE nutzt dasselbe fehlende allow*IntegritätAbgeleitet. Im Lab wurde das Erstellen getestet
Erweiterungen installieren oder Super User werdenBenötigt andere ACLn/aGeschlossen. Manager ist kein Super User

Geschlossen bei diesem Pin: UI-Hinzufügen/Speichern auf staffmenu für denselben Benutzer (not permitted). UI-Hinzufügen auf labmenu funktioniert weiterhin. Die core.admin-Sperre der Groups-API aus 6.1.1 ist unberührt.

Wie ich es gefunden habe

Ich habe 6.1.3 nach der JSST-Welle 2026 gepinnt. Der Administrator-ItemController macht bereits das Richtige:

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

Der API-Items-Controller überschreibt allowAdd / allowEdit nicht. Der Standard-ApiController prüft nur die Komponente core.manage plus core.create / core.edit. Der canSave-Pfad des Modells prüft nur die Komponente core.edit. Batch-Kopieren/Verschieben prüfen bereits das Menü-Asset.

Bereits festgehaltene Fehlannahmen: UI-HTTP 200 als Erlaubnis zu lesen (der Body lautet „not permitted"); core.manage auf com_menus in der UI als ausreichend zu betrachten (die UI richtet sich weiterhin nach com_menus.menu.{id}); ein Standard-Manager ohne core.login.api. Theater: eine Reverse Shell. Das Orakel ist API 200 auf staffmenu und main plus UI-Verweigerung auf B.

Überbleibsel derselben Pin-Phase: levels API, media override, articles catid.

Lab

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

oder

cd lab
./run.sh

Ziel nur http://127.0.0.1:19530. Image 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 liefern HTTP 200; die Verweigerung von B ist der UI-Text „not permitted", kein 403-Status.

Die Behebung

Kopiere ItemController::allowAdd / allowEdit (und delete) in den API-Controller, einschließlich des main-Blocks. Prüfe das Menütyp-Asset in canSave auf dieselbe Weise.

Referenzen

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

Lizenz

GNU Affero GPL v3.0. Siehe LICENSE. Nur Loopback-Lab. Keine Gewährleistung.

Tool herunterladen