zeropathai/proftpd-cve-2026-42167-pocPOCs para demostrar CVE-2026-42167 en ProFTPD
Demostraciones de prueba de concepto para CVE-2026-42167, una vulnerabilidad de inyección SQL en el pipeline de registro mod_sql de ProFTPD que permite a un atacante no autenticado ejecutar SQL arbitrario — e inyectar usuarios puerta trasera en la base de datos de autenticación FTP o lograr ejecución remota de código en el host de la base de datos.
Todos los POCs son específicos de PostgreSQL, pero los de usuarios puerta trasera funcionan con backends MySQL y SQLite con algunas modificaciones a la consulta inyectada (lo cual dejamos como ejercicio para el lector).
is_escaped_text() en mod_sql SQLLog (CVE-2026-42167, CWE-89)El mod_sql de ProFTPD registra cada comando FTP a través del mecanismo SQLLog / SQLNamedQuery. Al resolver variables de formato como %U (nombre de usuario original) o %{basename} (componente de nombre de archivo), el framework llama a is_escaped_text() para decidir si es necesario escapar — y omite el escape por completo para cualquier valor que comience y termine con una comilla simple y no contenga comillas simples internas (por ejemplo, '|| (SELECT 1) ||'). La verificación es puramente sintáctica y se ejecuta sobre la entrada sin procesar controlada por el atacante, por lo que no puede distinguir "pre-escapado por código confiable" de "diseñado por un atacante para parecer pre-escapado".
El patrón estándar documentado envuelve las variables de formato entre comillas simples para seguridad SQL:
SQLNamedQuery log_activity INSERT "'%U', '%r', '%m'" activity_log
SQLLog * log_activity
SQLLog ERR_* log_activity
Cuando un atacante proporciona un valor de la forma '<payload>', la sustitución produce ''<payload>'' en el SQL final — los literales de cadena vacía cierran las comillas circundantes y el payload se ejecuta como SQL sin procesar. Con PostgreSQL (PQexec) o SQLite (sqlite3_exec), el soporte de consultas apiladas significa que el payload puede ser una declaración completa INSERT, UPDATE, CREATE TABLE o COPY TO PROGRAM.
El código vulnerable está en contrib/mod_sql.c (el framework SQL compartido), no en ningún backend específico, por lo que todos los backends SQL están afectados — pero la superficie de ataque depende de cómo el administrador haya configurado el registro. Un servidor es explotable cuando se cumplen ambas de las siguientes condiciones:
El administrador ha definido un SQLNamedQuery INSERT (o UPDATE) cuya cadena de formato interpola una de estas variables controlables por el atacante envuelta en comillas simples — por ejemplo, "'%U', '%m'". Las variables que provienen de la entrada del atacante son:
| Var | Significado |
|---|---|
%A | cadena de contraseña de inicio de sesión anónimo |
%J | parámetros del comando (todo después del verbo) |
%S | cadena del mensaje de respuesta (puede incluir entrada del atacante reflejada en errores) |
%U | nombre de usuario original de USER (establecido antes de la autenticación, disponible incluso en inicio de sesión fallido) |
%d | nombre del directorio (último componente de la ruta) |
%l | respuesta ident RFC 1413 (controlada por el atacante si ejecutan identd) |
%m | método/verbo FTP (el atacante elige qué comando enviar) |
%r | comando FTP completo (verbo + args) |
%u | nombre de usuario autenticado |
%{basename} | componente del nombre de archivo del argumento de ruta, sin prefijo de directorio |
%f, %F y %D parecen controlados por el atacante pero siempre se resuelven a rutas absolutas que comienzan con /, por lo que no pueden cumplir con el requisito de comenzar con ' de is_escaped_text().
El administrador ha vinculado ese SQLNamedQuery a una directiva SQLLog para un comando FTP (o clase de comando) al que el atacante puede acceder. Los comodines ampliamente documentados SQLLog * y SQLLog ERR_* son el caso más amplio y lo que hace que la ruta %U sea pre-autenticación: ERR_* se activa en un USER fallido, por lo que no se necesitan credenciales. Directivas por comando como SQLLog STOR cubren a cualquier usuario autenticado.
El bypass convierte la ruta de registro en una primitiva SQL arbitraria en el backend. Los dos escenarios de mayor impacto:
Inyectar un usuario puerta trasera con privilegios arbitrarios (bypass de autenticación).
El backend de autenticación SQL de ProFTPD lee nombres de usuario, hashes de contraseñas, uid, gid, homedir y shell de la misma tabla users en la que el INSERT de registro ahora puede escribir. Un INSERT INTO users apilado introduce una cuenta elegida por el atacante — uid=0, homedir=/, contraseña en texto plano — y luego el atacante inicia sesión normalmente con acceso completo al sistema de archivos a través del daemon FTP. Alcanzable pre-autenticación a través de la ruta %U + SQLLog ERR_*, o post-autenticación a través de cualquier variable controlada por el atacante vinculada a un comando que el atacante pueda emitir (por ejemplo, %{basename} + SQLLog STOR). Funciona en PostgreSQL y SQLite (ambos soportan consultas apiladas).
Ejecución remota de código en el host de la base de datos mediante COPY TO PROGRAM.
COPY (SELECT …) TO PROGRAM '<cmd>' de PostgreSQL ejecuta <cmd> a través de un shell en el servidor de base de datos. Una inyección de consulta apilada que emite COPY TO PROGRAM otorga ejecución arbitraria de comandos del sistema operativo como el usuario postgres del sistema, que es suficiente para exfiltración de credenciales, movimiento lateral y persistencia. Alcanzable a través de las mismas rutas de activación que el caso de puerta trasera (pre-autenticación mediante %U o post-autenticación mediante %{basename}, etc.). Específico de PostgreSQL, y requiere que el rol de base de datos de ProFTPD tenga privilegios de superusuario (el requisito previo para COPY TO PROGRAM) — común en implementaciones de un solo inquilino donde el rol es el propietario de la base de datos.
Los POCs en este repositorio apuntan específicamente a PostgreSQL — el caso más fuerte, ya que PQexec() soporta consultas apiladas y COPY TO PROGRAM proporciona ejecución directa de comandos del sistema operativo. El bypass en sí está en el framework SQL compartido y afecta a todos los backends:
PQexec, RCE mediante COPY TO PROGRAM.sqlite3_exec, se ejecuta bajo PRIVS_ROOT en el worker de proftpd — la inyección de puerta trasera funciona de la misma manera; la primitiva RCE difiere (no hay equivalente a COPY TO PROGRAM, pero una tabla users escribible en un backend SQL de proceso raíz es suficiente).users o a la ejecución del sistema operativo desde dentro del único INSERT de registro es más difícil. La manipulación de una sola declaración (exfiltración de subconsultas en un espacio de VALUES, ciego basado en tiempo, ciego basado en errores) es directa; convertir eso en una escritura en una tabla diferente requiere sortear varios obstáculos:
mod_sql_mysql llama a mysql_real_query() sin CLIENT_MULTI_STATEMENTS, por lo que un ; INSERT INTO users … final es rechazado por la conexión.users o en un archivo en disco.