CVE-2020-17463
Corrija agora. Ela está sob exploração confirmada pelo CISA e tem exploit funcional público.
Apply updates per vendor instructions.
Resumo
FUEL CMS 1.4.7 (framework baseado em CodeIgniter/PHP) tem injeção SQL no parâmetro col enviado aos endpoints administrativos /pages/items, /permissions/items e /navigation/items. A falha está no catálogo KEV da CISA por exploração confirmada em campo, tem PoC pública e template Nuclei, o que a torna um alvo fácil de automatizar mesmo sem sofisticação técnica do atacante.
Detalhamento técnico
A vulnerabilidade é uma injeção SQL clássica (CWE-89): o valor do parâmetro col chega a uma consulta SQL sem sanitização ou parametrização adequada antes de ser executado no backend de banco de dados do FUEL CMS. Os três endpoints afetados (/pages/items, /permissions/items, /navigation/items) são rotas do módulo administrativo da CMS usadas para listar registros em grades (grids) — o nome do parâmetro ("col", coluna) é consistente com uso em cláusulas de ordenação/filtragem dinâmica de colunas, um padrão clássico de SQLi por concatenação de identificador de coluna em vez de valor de dado, mas o fornecedor não publicou um advisory técnico detalhando o trecho de código corrigido, então essa mecânica exata não está confirmada oficialmente — apenas inferida do contexto dos endpoints e da natureza da falha.
O release 1.4.8 do FUEL CMS, lançado em 11/08/2020, é descrito pelo próprio changelog apenas como "Several security fixes" junto de atualizações para PHP 7.4, sem detalhar quais commits corrigem especificamente o CVE-2020-17463. Isso significa que não há um diff isolado e documentado pelo fornecedor apontando a linha exata da correção.
A presença de três endpoints distintos e semanticamente diferentes (páginas, permissões, navegação) atingidos pelo mesmo parâmetro sugere que a falha está numa função ou trait compartilhada pelo controller base do módulo admin do FUEL, e não em código duplicado em cada controller — o que também explicaria por que uma única correção resolveu os três pontos de injeção simultaneamente.
Como é explorada
O vetor é via requisição HTTP (GET ou POST, dependendo da rota) contendo o parâmetro col manipulado nos endpoints citados. O vetor CVSS oficial (AV:N/AC:L/PR:N/UI:N) indica exploração remota, sem interação do usuário e sem privilégios — ou seja, NVD trata isso como pré-autenticação. As fontes disponíveis não trazem confirmação técnica detalhada de que os endpoints /items são acessíveis sem login válido no painel administrativo; a classificação PR:N do CVSS é o indicativo mais forte disso, mas não há um trecho de advisory do fornecedor confirmando explicitamente a ausência de checagem de sessão nessas rotas.
A exploração em si depende do tipo de injeção que o payload no parâmetro col permite explorar (booleana, baseada em tempo, ou UNION-based) contra o SGBD usado pela instalação (tipicamente MySQL em instalações FUEL CMS). Como o CVE está no catálogo KEV da CISA, há confirmação de exploração ativa em ambientes reais — mas o catálogo não descreve o ator, a campanha nem o objetivo final observado, apenas a listagem e o prazo de remediação (10/06/2022).
A existência de PoC pública (Packet Storm) e de template Nuclei tornou esta CVE um alvo trivial para scanners automatizados de internet: qualquer instância FUEL CMS 1.4.7 exposta é candidata a varredura em massa, o que é consistente com o padrão típico de exploração registrado em CVEs no KEV com EPSS alto (0.90 no caso desta CVE, indicando probabilidade elevada de exploração observada por modelos preditivos).
Versões
Como se proteger
A correção oficial é atualizar para a versão 1.4.8 do FUEL CMS ou posterior. O release notes não detalha uma flag de configuração alternativa para desabilitar o ponto vulnerável, então não há um paliativo documentado pelo próprio fornecedor além de aplicar o patch.
Quem não puder atualizar imediatamente deve restringir o acesso de rede aos caminhos /pages/items, /permissions/items e /navigation/items — via proxy reverso, regra de firewall de aplicação ou controle de acesso — e garantir que essas rotas do painel administrativo não estejam expostas diretamente à internet sem autenticação forte na camada de rede (VPN, allowlist de IP). Regras de WAF genéricas para SQLi (bloqueio de padrões como UNION SELECT, SLEEP(), comentários SQL) no parâmetro col reduzem o risco de exploração automatizada, mas não eliminam a vulnerabilidade subjacente.
Não existe mitigação real apenas restringindo o método HTTP ou ocultando o painel via URL não padrão — isso não impede scanners que testam os caminhos fixos documentados na CVE. A única mitigação que resolve a causa raiz é a atualização de versão.
Como detectar
Procurar em logs de acesso web por requisições aos caminhos /pages/items, /permissions/items e /navigation/items contendo no parâmetro col caracteres típicos de SQLi: aspas simples, UNION SELECT, SLEEP(), CASE WHEN, comentários SQL (--, #, /* */) ou codificação incomum desses caracteres. Tráfego repetitivo e automatizado contra esses três caminhos específicos, vindo do mesmo IP ou faixa, é forte indício de varredura por ferramentas baseadas no template Nuclei público ou em scripts derivados do PoC do Packet Storm.
Não há assinatura oficial publicada pelo fornecedor nem indicador de comprometimento documentado nas fontes disponíveis — a detecção depende de regras genéricas de SQLi em WAF/IDS e de análise de logs de aplicação, já que não existe um IOC específico (hash, string de payload confirmada) divulgado pela CISA ou pelo mantenedor do projeto.