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

joomla-articles-catid

Classe: Privilégio remanescente Alcance: Remoto

Joomla CMS 6.1.3 (0f2d4de) - Open Source Matters

O ArticleController::allowAdd do administrador verifica com_content.category.{catid}. api/components/com_content/src/Controller/ArticlesController.php não possui allowAdd. O ApiController::add() então chama allowAdd() sem dados, então o catid do JSON nunca entra na verificação. O allowAdd base é verdadeiro se o usuário puder criar em qualquer categoria.

Um usuário de API da classe Manager, com core.login.api concedido e permissão de criação em uma categoria, pode fazer POST de um artigo em uma categoria na qual ele é negado na UI.

ID	sem CVE ainda
Classe	Privilégio remanescente / bypass de autorização
Alcance	Remoto (token de API com core.login.api)
CWE	CWE-863
CVSS	Médio: 6.5 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N
Produto	Joomla CMS
Afetado	6.1.3 (0f2d4de4729eb951e0878fec98c7990da07915b2), POST /api/index.php/v1/content/articles
Autenticação	Token de API para Manager (grupo 6) com core.login.api, com_content core.manage e core.create em uma categoria apenas. Sem Super User. O padrão de core.login.api é apenas Super User.
Licença	GNU Affero GPL v3.0
Lab	apenas 127.0.0.1

O que um atacante pode fazer

Usar um token de API de não-Super-User que pode criar em uma categoria para publicar em categorias das quais ele está banido. Ele não se torna Super User a partir desse remanescente. Isso é publicação não autorizada, não é tomada de controle do site e não é leitura de artigos ocultos.

Privilégio	Método / caminho	Tipo	Comprovado em lab ou inferido
Criar um artigo em uma categoria da qual ele é negado	POST /api/index.php/v1/content/articles JSON catid de B	integridade	Comprovado em lab. HTTP 200, #__content id=1, catid=9 (Press), título poc-art-JOOMLA-ARTICLES-CATID-WITNESS
Plantar cópia publicada em Official notices / Press enquanto só é permitido Drafts	Mesmo POST, state=1	integridade	Comprovado em lab a criação em Press negada. Inferido para qualquer outro asset de categoria com core.create negado
Editar um artigo existente via API	PATCH /api/index.php/v1/content/articles/{id}	n/a	Inferido fechado para este Manager. O allowEdit base precisa do componente core.edit; as regras de com_content do lab dão core.edit para Author (4), não Manager (6). O lab não fez PATCH
Excluir um artigo via API	DELETE /api/index.php/v1/content/articles/{id}	n/a	Inferido fechado. O allowDelete base precisa do componente core.delete. O lab não fez DELETE
Salvar um artigo na categoria permitida A pelo administrador	POST ... task=article.save jform[catid]=A	pretendido	Comprovado em lab aberto como pretendido. HTTP 200, não negado
Salvar um artigo na categoria negada B pelo administrador	Mesma task, jform[catid]=B	n/a	Comprovado em lab fechado. HTTP 200 com "not permitted" / create-not-permitted (UI allowAdd em com_content.category.B)
Acessar a API com um Manager padrão (sem core.login.api)	Bearer token / X-Joomla-Token	n/a	Inferido fechado. O padrão de core.login.api é apenas Super User (grupo 8). Este lab o concede ao grupo 6 primeiro
Mesma falha em contacts / banners / newsfeeds	POST /api/index.php/v1/contacts (e similares) com catid estrangeiro	integridade	Inferido. Esses controllers de API também não possuem allowAdd. O lab não os exercitou
RCE de Super User / instalador	n/a	n/a	Fechado. Manager permanece Manager

Como eu encontrei

Fixe em 6.1.3 após a onda JSST de 2026-07/08. A API de Groups já exige core.admin. O webservice de Media já exige core.edit em override. A API de Articles ainda passa pelo ApiController e trata "criar em qualquer categoria" como suficiente para todo catid.

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

Verificação base:

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

A UI do administrador já se baseia em 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();
}

Caminhos errados já registrados: ler HTTP 200 da UI como permissão (a negação de B é o corpo "not permitted"); tratar o core.create do componente como a falha (o Manager do lab não tem nenhum; uma categoria permitida é suficiente para a contagem base de getAuthorisedCategories); um Manager padrão sem core.login.api. Teatro: um reverse shell. O oráculo é API 200 em Press mais UI permitindo em Drafts mais UI negando em Press.

Outros remanescentes do mesmo pin: levels API, menu items API, media override.

Lab

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

ou

cd lab
./run.sh

Alvo apenas http://127.0.0.1:19550. Imagem joomla:6.1.3-php8.3-apache mais 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 é o próximo autoincrement de #__content (1 em uma instalação limpa do 6.1.3). ui-a / ui-b são HTTP 200; a negação de B é o corpo "not permitted" da UI, não um status 403.

A correção

Sobrescrever allowAdd (e allowEdit) em api/components/com_content/src/Controller/ArticlesController.php da mesma forma que o ArticleController do administrador: verificar core.create em com_content.category.{catid}. Passar o JSON da requisição para ApiController::add() para que catid realmente chegue a essa verificação. Aplicar o mesmo padrão a contacts, banners e newsfeeds se esses controllers permanecerem no allowAdd padrão.

Referências