ProFTPD SQL injection flaw can lead to remote code execution on vulnerable servers

A newly disclosed ProFTPD vulnerability can allow attackers to turn a SQL injection bug into authentication bypass, privilege escalation, or remote code execution in some server setups. The flaw is tracked as CVE-2026-42167 and affects the mod_sql module used by ProFTPD for database-backed authentication and logging.

The issue has a CVSS 3.1 score of 8.1, which places it in the high-severity range. It does not affect every ProFTPD installation in the same way, but servers using mod_sql with SQL logging or database authentication need urgent review.

ProFTPD 1.3.9a includes the stable fix, while ProFTPD 1.3.10rc1 also contains the patch. Administrators should update immediately and check whether their Linux distribution has already shipped a fixed package.

At a glance

Item	Details
Vulnerability	CVE-2026-42167
Affected software	ProFTPD mod_sql
Flaw type	SQL injection
CWE	CWE-89
CVSS score	8.1, high severity
Affected versions	ProFTPD 1.3.9 and earlier, depending on configuration
Fixed versions	ProFTPD 1.3.9a and ProFTPD 1.3.10rc1

What makes CVE-2026-42167 dangerous

ProFTPD is a popular FTP server used on Linux and Unix systems. Hosting providers, control panels, and server administrators often use it to manage file transfers for websites, user accounts, and shared hosting environments.

The vulnerable component is mod_sql. This module lets ProFTPD use a database for user authentication, quota tracking, ban lists, and activity logging. That makes it useful for large hosting environments where administrators do not want to create a local Linux account for every FTP user.

The risk appears when ProFTPD logs attacker-controlled values into a SQL database. In some configurations, values such as the username can reach SQL logging queries before authentication completes.

How the ProFTPD SQL injection works

The vulnerability comes from the way mod_sql checks whether text has already been escaped before it gets inserted into a SQL query. If attacker-controlled input starts and ends with a single quote, with no quote in between, the escaping logic can wrongly treat it as safe.

That mistake can allow a crafted username or another logged value to change the structure of the SQL query. The result depends on how the ProFTPD server, mod_sql module, and SQL backend are configured.

In the most serious case, an attacker could reach remote code execution when the SQL backend allows command execution. The NVD description specifically mentions cases involving logged USER requests with expansions such as %U and database features such as PostgreSQL’s COPY TO PROGRAM.

Possible impact on vulnerable servers

• Attackers may inject SQL through values handled by mod_sql logging.
• Some setups may expose the issue before authentication.
• Attackers may create or modify FTP users in database-backed authentication setups.
• Privilege escalation may occur if injected SQL changes user permissions.
• Remote code execution may be possible when the SQL backend permits command execution.
• Attackers may extract sensitive database content through blind SQL injection techniques.

Why hosting environments face higher risk

Shared hosting providers often rely on database-backed FTP accounts. This lets them manage many FTP users from one central database instead of maintaining separate system users for every website or customer.

That same design can increase the impact of CVE-2026-42167. If an attacker can inject SQL into the user table, they may be able to add a backdoor FTP account, alter privileges, or gain access beyond the intended directory.

The issue becomes more severe when the database user has excessive privileges. A ProFTPD service account should not connect to PostgreSQL, MySQL, or MariaDB with broad administrative permissions.

What administrators should do now

Administrators should first identify whether mod_sql is enabled. A standard ProFTPD installation without mod_sql logging or SQL-backed authentication may not expose the same attack surface.

If mod_sql is enabled, administrators should upgrade to ProFTPD 1.3.9a or a newer fixed release as soon as possible. Distribution packages may use different version strings, so teams should also check their vendor security tracker.

Debian’s tracker, for example, shows several stable package branches as vulnerable while listing the sid package as fixed. This means teams should not assume a system is patched only because it receives routine updates.

Mitigation checklist

• Upgrade ProFTPD to a fixed release, such as 1.3.9a or 1.3.10rc1.
• Check vendor package trackers for Debian, Ubuntu, Slackware, and other distributions.
• Disable mod_sql logging temporarily if patching cannot happen immediately.
• Review SQLNamedQuery and SQLLog directives for attacker-controlled variables.
• Remove unnecessary database privileges from the ProFTPD database account.
• Audit FTP user tables for unexpected accounts or privilege changes.
• Inspect database logs for unusual INSERT, UPDATE, COPY, or authentication-related queries.
• Limit internet exposure for FTP services where possible.

Security teams should check for signs of abuse

Patching closes the vulnerability, but it does not prove that a server stayed clean before the update. Administrators should review recent FTP logs, SQL logs, and authentication events for suspicious usernames or unusual command patterns.

Teams should also check for newly created FTP accounts, unexpected UID or GID values, changed home directories, and accounts with broader file access than expected. Any unexplained database change should receive attention.

If the ProFTPD database account had elevated SQL privileges, the investigation should go deeper. Security teams should review whether attackers used database-level functions to run system commands or write files to sensitive paths.

FAQ