Upload Arbitrário de Arquivos Autenticado levando à Execução Remota de Código Análise técnica e reprodução controlada do CVE-2026-38526 no Webkul Krayin CRM 2.2.x.
Upload arbitrário de arquivos autenticado levando à execução remota de código — Análise técnica e reprodução controlada da CVE-2026-38526 no Webkul Krayin CRM 2.2.x.
A CVE-2026-38526 é uma vulnerabilidade de upload arbitrário de arquivos autenticado que afeta o Webkul Krayin CRM 2.2.x.
A funcionalidade vulnerável é exposta por meio do endpoint de upload do TinyMCE da aplicação:
POST /admin/tinymce/upload
A aplicação não restringe suficientemente o tipo de arquivo que pode ser enviado. Um usuário autenticado pode enviar um arquivo com uma extensão executável no lado do servidor, como .php. A aplicação armazena o arquivo enviado e retorna sua URL acessível.
Quando a implantação permite a execução de PHP a partir do local de upload, o arquivo enviado pode posteriormente ser requisitado por meio do servidor web, resultando em execução remota de código no contexto do processo da aplicação web.
O registro publicado da CVE classifica a vulnerabilidade como CVSS 3.1: 9.9 (Crítica).
Este repositório contém minha própria análise técnica e reprodução controlada da vulnerabilidade.
A vulnerabilidade já havia sido divulgada publicamente sob a CVE-2026-38526. Este trabalho não reivindica a descoberta da vulnerabilidade. O objetivo desta pesquisa foi compreender a implementação vulnerável, reproduzir o caminho de exploração em um ambiente controlado e examinar as condições que transformam o problema de upload de arquivos em execução remota de código.
A vulnerabilidade também foi utilizada na máquina Hack The Box GCSB 2026 Nexus, que proporcionou um ambiente prático para estudar o problema.
Produto: Webkul Krayin CRM Versões afetadas: 2.2.x Vulnerabilidade: Upload arbitrário de arquivos Impacto resultante: Execução remota de código Autenticação: Necessária Vetor de ataque: Rede CWE: CWE-434 — Upload irrestrito de arquivo com tipo perigoso CVSS: 9.9 Crítica CVE: CVE-2026-38526
A funcionalidade vulnerável é tratada por:
/admin/tinymce/upload
O endpoint aceita um arquivo enviado por meio do parâmetro file. A lógica relevante da aplicação deriva o nome do arquivo armazenado a partir do nome original do arquivo e preserva sua extensão original.

Esse comportamento é importante porque a aplicação não está simplesmente aceitando um objeto enviado; ela está retendo uma extensão executável controlada pelo atacante e tornando o objeto resultante acessível por meio do mecanismo de armazenamento da aplicação.
O problema principal é a validação insuficiente no lado do servidor dos arquivos enviados.
A aplicação utiliza a extensão original fornecida pelo cliente ao construir o nome do arquivo armazenado. Não há uma lista de permissões suficientemente restritiva que impeça tipos de arquivo executáveis de chegarem à camada de armazenamento.
O fluxo relevante é

O uso de um nome de arquivo gerado não resolve o problema subjacente.
Por exemplo, transformar shell.php em um nome de arquivo gerado como .php não torna o arquivo enviado seguro se o servidor continuar a interpretar arquivos .php como código PHP executável.
Um upload irrestrito não significa automaticamente execução remota de código.
O caminho de execução depende do tratamento do arquivo enviado pelo servidor.
No cenário de implantação vulnerável, a cadeia torna-se

Se a execução de PHP estiver desabilitada para o diretório de upload, o caminho direto para RCE pode ser impedido, embora a fraqueza subjacente de upload arbitrário de arquivos permaneça.
wget:
wget https://raw.githubusercontent.com/Ish3ng0m4/CVE-2026-38526-KrayinCRM/main/poc/upload.py
wget https://raw.githubusercontent.com/Ish3ng0m4/CVE-2026-38526-KrayinCRM/main/poc/marker.php
curl:
curl -LO https://raw.githubusercontent.com/Ish3ng0m4/CVE-2026-38526-KrayinCRM/main/poc/upload.py
curl -LO https://raw.githubusercontent.com/Ish3ng0m4/CVE-2026-38526-KrayinCRM/main/poc/marker.php
2. Coloque os arquivos em
poc/
├── upload.py
└── marker.php
3. Crie um ambiente Python e instale a dependência
python3 -m venv .venv
source .venv/bin/activate
pip install requests
4. Torne o PoC executável
chmod +x poc/upload.py
6. Execute-o
python3 poc/upload.py \
--url http://[Lab_IP:PORT] \
--email [email protected] \
--password 'YOUR_PASSWORD'
A exploração requer uma conta autenticada capaz de acessar a funcionalidade vulnerável.
Em alto nível:
O contexto de execução resultante é determinado pela implantação subjacente. Em uma implantação Linux típica, esta pode ser a conta de serviço do servidor web, como:
www-data
Isso não fornece automaticamente privilégios de root no sistema operacional. O impacto adicional depende das permissões e da configuração do ambiente comprometido.
O comportamento vulnerável pode ser reduzido a três operações importantes.
Obter o arquivo enviado
$file = request()->file('file');
A aplicação recebe o arquivo fornecido pelo cliente.
Preservar a extensão controlada pelo cliente
$filename = md5($file->getClientOriginalName().time())
.'.'.$file->getClientOriginalExtension();
O nome do arquivo em si é alterado, mas a extensão original é mantida. Esta é uma distinção importante: a randomização do nome do arquivo não é validação do tipo de arquivo.
Armazenar e expor o arquivo
$path = $file->storeAs($this->storagePath, $filename);
return [
'file' => $path,
'file_name' => $file->getClientOriginalName(),
'file_url' => Storage::url($path),
];
A aplicação armazena o arquivo e fornece sua URL ao cliente.
A exploração bem-sucedida pode fornecer a um atacante a execução de código sob os privilégios da aplicação web.
Dependendo da implantação, isso pode permitir que um atacante:
Leia arquivos da aplicação
Acessar a configuração do aplicativo
Obtenha credenciais de banco de dados ou outros segredos
Modifique dados da aplicação
Implante código malicioso adicional
Pivote para outros sistemas acessíveis a partir do host comprometido
Tente escalada de privilégios adicional