abraxaslabs.tech  ·  github.com/abraxas  ·  @abraxas_null  ·  [email protected]  ·  joomla-articles-catid

joomla-articles-catid

वर्ग: विशेषाधिकार अवशेष पहुँच: रिमोट

Joomla CMS 6.1.3 (0f2d4de) - Open Source Matters

प्रशासक ArticleController::allowAdd com_content.category.{catid} की जाँच करता है। api/components/com_content/src/Controller/ArticlesController.php में कोई allowAdd नहीं है। फिर ApiController::add() बिना किसी डेटा के allowAdd() को कॉल करता है, इसलिए JSON catid कभी जाँच में प्रवेश नहीं करता। आधार allowAdd सत्य है यदि उपयोगकर्ता किसी भी श्रेणी में बना सकता है।

एक Manager-वर्ग API उपयोगकर्ता, जिसे core.login.api और एक श्रेणी पर create प्रदान किया गया है, उस श्रेणी में एक लेख POST कर सकता है जिसमें उसे UI में मना किया गया है।

ID	अभी तक कोई CVE नहीं
वर्ग	विशेषाधिकार अवशेष / प्राधिकरण बायपास
पहुँच	रिमोट (core.login.api के साथ API टोकन)
CWE	CWE-863
CVSS	मध्यम: 6.5 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N
उत्पाद	Joomla CMS
प्रभावित	6.1.3 (0f2d4de4729eb951e0878fec98c7990da07915b2), POST /api/index.php/v1/content/articles
प्रमाणीकरण	Manager (समूह 6) के लिए API टोकन, जिसमें core.login.api, com_content core.manage, और केवल एक श्रेणी पर core.create हो। कोई Super User नहीं। डिफ़ॉल्ट core.login.api केवल Super User के लिए है।
लाइसेंस	GNU Affero GPL v3.0
लैब	केवल 127.0.0.1

हमलावर क्या कर सकता है

एक गैर-Super-User API टोकन का उपयोग करें जो एक श्रेणी में बना सकता है, उन श्रेणियों में प्रकाशित करने के लिए जिनसे उन्हें प्रतिबंधित किया गया है। वे इस अवशेष से Super User नहीं बनते। यह अनधिकृत प्रकाशन है, साइट अधिग्रहण नहीं और छिपे हुए लेखों का पठन नहीं।

विशेषाधिकार	विधि / पथ	प्रकार	लैब-प्रमाणित या अनुमानित
उस श्रेणी में एक लेख बनाएँ जिसमें उन्हें मना किया गया है	POST /api/index.php/v1/content/articles JSON catid of B	अखंडता	लैब-प्रमाणित। HTTP 200, #__content id=1, catid=9 (Press), शीर्षक poc-art-JOOMLA-ARTICLES-CATID-WITNESS
केवल Drafts की अनुमति होते हुए Official notices / Press में प्रकाशित प्रति रखें	वही POST, state=1	अखंडता	लैब-प्रमाणित मना किए गए Press में निर्माण। किसी भी अन्य श्रेणी संपत्ति के लिए अनुमानित जिसमें core.create मना है
API के माध्यम से एक मौजूदा लेख संपादित करें	PATCH /api/index.php/v1/content/articles/{id}	लागू नहीं	इस Manager के लिए बंद अनुमानित। आधार allowEdit को घटक core.edit चाहिए; लैब com_content नियम Author (4) को core.edit देते हैं, Manager (6) को नहीं। लैब ने PATCH नहीं किया
API के माध्यम से एक लेख हटाएँ	DELETE /api/index.php/v1/content/articles/{id}	लागू नहीं	बंद अनुमानित। आधार allowDelete को घटक core.delete चाहिए। लैब ने DELETE नहीं किया
प्रशासक से अनुमत श्रेणी A में एक लेख सहेजें	POST ... task=article.save jform[catid]=A	इच्छित	लैब-प्रमाणित इच्छित रूप में खुला। HTTP 200, मना नहीं
प्रशासक से मना किए गए श्रेणी B में एक लेख सहेजें	वही कार्य, jform[catid]=B	लागू नहीं	लैब-प्रमाणित बंद। HTTP 200 "not permitted" / create-not-permitted के साथ (UI allowAdd on com_content.category.B)
स्टॉक Manager (बिना core.login.api) के साथ API को हिट करें	Bearer token / X-Joomla-Token	लागू नहीं	बंद अनुमानित। डिफ़ॉल्ट core.login.api केवल Super User (समूह 8) के लिए है। यह लैब इसे पहले समूह 6 को प्रदान करता है
contacts / banners / newsfeeds पर वही अंतराल	POST /api/index.php/v1/contacts (और सहोदर) विदेशी catid के साथ	अखंडता	अनुमानित। उन API नियंत्रकों में भी allowAdd का अभाव है। लैब ने उन्हें नहीं आजमाया
Super User / installer RCE	लागू नहीं	लागू नहीं	बंद। Manager Manager ही रहता है

मैंने इसे कैसे खोजा

मैंने 2026-07/08 JSST लहर के बाद 6.1.3 को पिन किया। Groups API को पहले से ही core.admin की आवश्यकता है। Media webservice को पहले से ही override पर core.edit की आवश्यकता है। Articles API अभी भी ApiController के माध्यम से गिरता है और "किसी भी श्रेणी में बनाएँ" को प्रत्येक catid के लिए पर्याप्त मानता है।

public function add()
{
    if (!$this->allowAdd()) {
        throw new NotAllowed('JLIB_APPLICATION_ERROR_CREATE_RECORD_NOT_PERMITTED', 403);
    }
    $recordId = $this->save();
    $this->displayItem($recordId);
}

आधार जाँच:

protected function allowAdd($data = [])
{
    $user = $this->app->getIdentity();

    if (!$user->authorise('core.manage', $this->option)) {
        return false;
    }

    return $user->authorise('core.create', $this->option)
        || \count($user->getAuthorisedCategories($this->option, 'core.create'));
}

प्रशासक UI पहले से ही catid पर आधारित है:

protected function allowAdd($data = [])
{
    $categoryId = ArrayHelper::getValue(
        $data,
        'catid',
        $this->input->getInt('filter_category_id'),
        'int'
    );

    if ($categoryId) {
        return $this->app->getIdentity()->authorise(
            'core.create',
            'com_content.category.' . $categoryId
        );
    }

    return parent::allowAdd();
}

पहले से दर्ज गलत मोड़: UI HTTP 200 को अनुमति के रूप में पढ़ना (B का इनकार "not permitted" बॉडी है); घटक core.create को छेद मानना (लैब Manager के पास कोई नहीं है; आधार getAuthorisedCategories गणना के लिए एक श्रेणी की अनुमति पर्याप्त है); core.login.api के बिना एक स्टॉक Manager। नाटक: एक रिवर्स शेल। ओरेकल Press में API 200 प्लस Drafts पर UI अनुमति प्लस Press पर UI इनकार है।

वही पिन अवशेष: levels API, menu items API, media override।

लैब

python3 joomla-articles-catid-Abraxas-Labs.py

या

cd lab
./run.sh

लक्ष्य केवल http://127.0.0.1:19550। इमेज joomla:6.1.3-php8.3-apache प्लस mariadb:11.4।

SUCCESS joomla-articles-catid api-http=200 article-id=1 catid=9 cat-a=8 cat-b=9 ui-a=200 ui-b=200 JOOMLA-ARTICLES-CATID-WITNESS

article-id अगला #__content autoincrement है (स्वच्छ 6.1.3 इंस्टॉल पर 1)। ui-a / ui-b HTTP 200 हैं; B का इनकार UI "not permitted" बॉडी है, 403 स्थिति नहीं।

समाधान

api/components/com_content/src/Controller/ArticlesController.php पर allowAdd (और allowEdit) को उसी तरह ओवरराइड करें जैसे प्रशासक ArticleController: com_content.category.{catid} पर core.create की जाँच करें। अनुरोध JSON को ApiController::add() में पास करें ताकि catid वास्तव में उस जाँच तक पहुँचे। यदि वे नियंत्रक डिफ़ॉल्ट allowAdd पर रहते हैं तो contacts, banners, और newsfeeds पर वही पैटर्न लागू करें।

संदर्भ