Build 1 publisher2 min readPublished September 16, 2026 at 1:06 AM PDT

A published ProFTPD mod_sql exploit needs a login and a privileged PostgreSQL role

Exploit-DB's entry for CVE-2026-42167 carries a CVSS of 8.1, and the proof of concept it publishes only fires after authentication, against a PostgreSQL backend whose database role can already run code. Triage starts in the ProFTPD config.

The Engineer · Build desk

Illustration accompanying A published ProFTPD mod_sql exploit needs a login and a privileged PostgreSQL role

What happened

Exploit-DB published EDB-ID 52658 on August 25, 2026, a working proof of concept for CVE-2026-42167 in the mod_sql extension of ProFTPD, a vulnerability scored 8.1 under CVSS v3.1.
Advisory information cited in the write-up says exploitation depends on how mod_sql is configured, with outcomes including authentication bypass, privilege escalation and remote code execution.
ProFTPD 1.3.9a is the fixed version named in the advisory. The flaw sits in the mod_sql extension, not the core FTP service.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

constraint A version scan cannot answer whether attacker input reaches the affected query, because the query is written locally by the administrator, so the work falls on whoever can read the config and the database grants.
exposure The set of servers the published script can actually hit is those where an attacker already holds credentials and the PostgreSQL role can execute code; other affected installs need a different exploit written for them.
decision Whether this earns an out-of-hours change window turns on two configuration answers: is SQL logging switched on, and can the database account run code.
cost Applicability costs nine questions per host in analyst time, and most of those answers live in local configuration files that no vulnerability feed carries.

mod_sql covers two jobs: SQL-backed authentication and SQL logging ^[9]. Logging is the part that makes this reachable, because the SQL statements are defined by the site administrator and those statements can incorporate FTP-related input ^[10]. The injected query on your server is text somebody at your site wrote. Two hosts running the same build can be exposed differently, so the question is whether attacker-controlled input gets into the affected query ^[7].

The published script is narrower than the vulnerability class name. It demonstrates a path that starts after authentication ^[5] and expects a PostgreSQL backend with database privileges strong enough to reach code execution ^[6]. Count the conditions and there are at least four: valid credentials, mod_sql in use, a logged field the attacker can influence, and a database role that can run code ^[17]. A site on MySQL with a restricted role fails two of them, and the script will not work there even if the injection is present. "The answers determine whether the PoC is actually applicable," the author of the write-up wrote ^[20].

Exploit-DB files the entry as a remote exploit against mod_sql functionality ^[4], and the demonstrated chain needs a login first ^[5].

"Don't confuse the existence of a public exploit with proof that every installation is vulnerable," the author wrote ^[13]. The same post says a CVE labelled RCE does not mean every installation is remotely exploitable with no prerequisites ^[16], and it recommends reading the exploit source before executing it, to extract the backend, privilege and input assumptions the chain rests on ^[18].

In my view, four simultaneous conditions makes for a low hit rate across a fleet and a certainty on the hosts that match.

Everything above comes from a single write-up published on dev.to: the score, the Exploit-DB metadata, the fixed version and the summary of the advisory ^[2]^[3]^[8]^[7]. The post does not reproduce the vendor advisory or the CVSS vector string.

What to watch

A CISA KEV entry for CVE-2026-42167: the write-up lists KEV as a source to check but does not report the CVE on it.
A second proof of concept against MySQL, or against the SQL-backed authentication path, would widen the reachable population beyond post-authentication PostgreSQL.
Publication of the CVSS vector string would show whether the 8.1 already priced in the authentication requirement.

Claim ledger

Ranked by verification strength, evidence, and original report placement.

[1]
A public exploit for CVE-2026-42167, a ProFTPD mod_sql vulnerability, is available on Exploit-DB.
ReportedSupportedView cited source
[2]
CVE-2026-42167 has a CVSS v3.1 score of 8.1.
ReportedSupportedView cited source
[3]
Exploit-DB published EDB-ID 52658 on August 25, 2026.
ReportedSupportedView cited source
[4]
Exploit-DB identifies the public entry as EDB-ID 52658 and describes it as a remote exploit targeting ProFTPD's mod_sql functionality.
ReportedSupportedView cited source
[5]
The published proof of concept demonstrates a post-authentication SQL injection-to-RCE path.
ReportedSupportedView cited source
[6]
The Exploit-DB proof of concept demonstrates a specific post-authentication attack path involving SQL injection and a PostgreSQL backend with sufficiently powerful database privileges.
ReportedSupportedView cited source
[7]
Published advisory information describes a SQL injection vulnerability in ProFTPD's mod_sql extension and states that exploitation depends on how mod_sql is configured.
ReportedSupportedView cited source
[8]
The advisory identifies ProFTPD 1.3.9a as the fixed version.
ReportedSupportedView cited source
[9]
mod_sql can be used for several purposes, including SQL-backed authentication and SQL logging.
ReportedSupportedView cited source
[10]
In the logging functionality, administrator-defined SQL queries can incorporate FTP-related input.
ReportedSupportedView cited source
[11]
The published advisory describes scenarios involving SQL logging and SQL-backed authentication, and depending on the configuration exploitation can result in authentication bypass, privilege escalation, or remote code execution.
ReportedSupportedView cited source
[13]
"Don't confuse the existence of a public exploit with proof that every installation is vulnerable."
ReportedSupportedSource: the author of the dev.to write-up on CVE-2026-42167View cited source
[16]
The write-up states that a CVE saying "RCE" does not automatically mean that every installation of the affected software is remotely exploitable with no prerequisites.
ReportedSupportedView cited source
[15]
The write-up recommends cross-referencing at least the CVE record, the vendor or maintainer advisory, Exploit-DB, the actual PoC code, and CISA KEV when determining whether there is evidence of known exploitation.
ReportedSupportedView cited source
[18]
The write-up advises reading the exploit script instead of immediately running it, looking for the authentication required, the attacker-controlled input, the database backend and privileges it expects, and how the final impact is achieved.
ReportedSupportedView cited source
[19]
The write-up lists CISA KEV as a source to cross-reference and does not state that CVE-2026-42167 appears in it, and it summarises the advisory without reproducing it or a CVSS vector string.
ReportedSupportedView cited source
[20]
"The answers determine whether the PoC is actually applicable."
ReportedSupportedSource: the author of the dev.to write-up on CVE-2026-42167View cited source
[21]
The write-up enumerates questions to ask when reviewing the PoC: does exploitation require authentication; which database backend is required; what database privileges are required; is mod_sql enabled; is SQL logging enabled; which FTP fields are being logged; can an attacker control those fields; does the target configuration use the same SQL query structure as the PoC; does the vulnerable process have enough privileges for the demonstrated impact.
ReportedSupportedView cited source
[12]
The PoC review checklist in the write-up runs to nine questions.
DerivedSupported1 source— sign in to open
[17]
At least four conditions must hold at once for the published PoC path to work: valid credentials, mod_sql in use, an administrator-defined logged query carrying attacker-influenced FTP input, and a PostgreSQL backend whose database privileges are sufficient for code execution.
DerivedSupported1 source— sign in to open

Sources

Publishers with included, body-backed reporting in this cluster.

dev.to
1 article · September 16, 2026
CVE-2026-42167: ProFTPD mod_sql RCE and How to Analyze the Exploit-DB PoC

Ask Clarity

Have a question this piece left open? The answer comes from its reporting and claim ledger — nothing else.

Try

Clarity analysis

How the coverage leans and what the record actually supports. Read the methodology

Perspective Coverage

How much of the coverage speaks to builders, operators and investors. It measures emphasis, not whether the story is right.

For anyone who maintains software like this, the useful part is the shape of the path. mod_sql builds administrator-written queries that can carry FTP-supplied values, and the published script carries that input into a PostgreSQL session whose role can already execute code. The post names 1.3.9a as the fix. It leaves out the patch, the vulnerable query and the proof-of-concept code, so a developer wanting to audit their own query construction gets the concept without the detail.

Reality

Evidence, adoption, hype gap, incentives and confidence, each read independently from the current record on the scale shown beneath it. How these are measured.

Evidence45

0100

Checkable identifiers, one voice behind them

Every technical fact traces to a single dev.to post: the Exploit-DB ID, the August publication date, the 8.1 score, the advisory's configuration caveat, the 1.3.9a fix. Those identifiers are specific enough to verify in a few minutes, and the author names the sources he cross-references. The advisory is never quoted, the CVSS vector never printed, and the proof of concept stays off the page, so the preconditions that make the story interesting rest on his reading of code the reader cannot see here.

Adoption20

0100

Working exploit published, real-world exposure unknown

The one hard event is the Exploit-DB publication on 25 August 2026, with a fixed release available in 1.3.9a. Beyond that, nobody has measured actual usage: there is no finding of exploitation in the wild, no KEV listing, and no count of ProFTPD servers running mod_sql logging against PostgreSQL with a privileged database role. Public code raises the cost of ignoring the CVE without saying how much of the installed base fits the path.

Hype gap−15

Topics and entities

Follow any of these and your For You feed starts watching them — no settings page required.

Topics

Entities

security
Horizon3 catches live exploitation of Sangoma Switchvox CVE-2026-9586 on honeypots
13 publishers
security
Someone enumerated LiteLLM's key tables 36 hours after the advisory hit defender feeds
1 publisher
build
Dovecot's 2.4 settings refactor drops the SQL escape its own passdb asked for
1 publisher
build
At least five ordering questions hide inside one updated_at column
1 publisher

What happened

Why it matters

What to watch

Claim ledger

Sources

Let Clarity write the post for you.

Topics and entities

Topics

Entities

Related stories

Claim ledger

Sources

Let Clarity write the post for you.

Topics and entities

Topics

Entities

Related stories

Perspective Coverage

Reality