LiquidFiles is a managed file transfer product. CVE-2025-56132 is a user enumeration in its password reset endpoint: versions before 4.2 return a distinguishable response when the submitted email does not exist.
The 4.2 fix is not to make the responses identical. The 4.2 fix is to block non-existent emails from logins for between 18 and 36 hours. The block requires the server to record which emails are non-existent. Recording which emails are non-existent is the enumeration the bug exposes.
The PoC is a Project Discovery nuclei template. It does two things. First it sends:
POST /password_reset HTTP/1.1
Host: <target>
Content-Type: application/x-www-form-urlencoded
user[email]=nonexistent-user-enumtest-12345@test.invalidThe server replies with a 302 redirect and sets a session cookie named _filetransfer_session. The cookie is set the same way for valid and invalid emails; the redirect status is the same too. Nothing in the headers tells the cases apart.
Then the template follows the redirect:
GET / HTTP/1.1
Host: <target>The matcher checks the response body for two literal strings together: LiquidFiles (proves the host is the right product) and invalid_email (proves the password reset just rejected the email).
matchers:
- type: dsl
dsl:
- "contains_all(body, 'invalid_email','LiquidFiles')"
- "status_code == 200"
condition: andWhen the email exists, that string is absent. The redirect-then-render pattern means the side effect lives in the session, not the immediate response: the password reset endpoint stores a flash message keyed to the session cookie, and the next page rendered for that cookie reads the flash. There is no source code to confirm the implementation in detail; LiquidFiles is closed. The differential is the public artifact, and the public artifact is the bug.
The LiquidFiles 4.2.0 release notes describe three security changes that bear on this CVE:
Read carefully. The first change addresses the verbose-error variant of the channel: by default, the verbose error message is no longer rendered. That removes the body string the nuclei template checks for. It does not address the underlying state machine; it changes the rendering layer.
The second change adds a per-user lockout on real users. Ten consecutive failed logins forces the user to set a new password.
The third change adds a per-non-existent-email lockout. Submit an email that does not exist and the system will refuse logins to that string for the next 18 to 36 hours. The randomization is a hedge against attackers timing the unblock window to recover state.
The third change is the active mitigation against enumeration that the CVE record cites. It is also the change that requires the server to know, at the time of attempt, that the submitted email is non-existent. That decision is the bug.
CISA-ADP classified CVE-2025-56132 as CWE-305: Authentication Bypass by Primary Weakness. CWE-305 covers cases where authentication is structurally bypassable: a missing check, a broken predicate, a forged credential. This is not that.
The matching CWE is CWE-204: Observable Response Discrepancy. The bug is informational. It does not bypass authentication; it leaks state about authentication-relevant identifiers, and the leak is the same channel an attacker would read to mount a credential attack.
The classification matters because it sets the defender's frame. CWE-305 implies "patch and the bypass closes." CWE-204 implies "the channel keeps observable state, mitigations are rate-limits and uniform responses, and the structural fix is to make valid and invalid responses indistinguishable to a network observer." A CWE-204 framing would have made the 4.2 release notes' approach legible. Lockout is a CWE-204 mitigation. CWE-305 does not call for it because CWE-305 is not this bug.
The NVD record for CVE-2025-56132 carries this paragraph:
LiquidFiles filetransfer server is vulnerable to a user enumeration issue in its password reset functionality. The application returns distinguishable responses for valid and invalid email addresses, allowing unauthenticated attackers to determine the existence of user accounts.
Version 4.2 introduces user-based lockout mechanisms, though enumeration remains possible by default.
Both sentences are vendor-sourced. Both cannot be marketed at once.
The first half names the bug. The second half names the patch. The trailing clause names the post-patch state. "Enumeration remains possible by default" is not the language a vendor uses when the patch closes the bug. It is the language a vendor uses when the patch does not, and the vendor wants the record to say so.
An attacker submits [email protected] to the login endpoint. The server checks whether [email protected] is a real user.
If alice exists, login is attempted. After ten failed attempts she is forced to change her password.
If alice does not exist, the email is added to a non-existent-block list for between 18 and 36 hours. Subsequent attempts using that email are rejected at the lockout layer rather than reaching the underlying check.
The branch is "is [email protected] a real user." The branch is the side channel. The branch is what the password reset endpoint exposes and what every other identity-aware endpoint must read. Adding a non-existent-block list does not remove the branch. It makes the branch's outcome observable in one more way.
A patient attacker observing the same target across several days does not need the verbose error string anymore. Submit [email protected] once. Submit again ten minutes later, then an hour later, then six hours later. If subsequent attempts are blocked at the lockout layer, alice was non-existent on the first attempt. If they proceed to a credential check, alice exists. The block is itself the channel.
The NVD record adds one sentence the release notes leave out:
Earlier versions only have IP-based rate limiting, which can be circumvented through distributed requests.
Pre-4.2 LiquidFiles did have rate limiting on this endpoint. The rate limit was per-IP. The channel the rate limit was protecting was the same channel the 4.2 lockout protects today: distinguishable response on submitted email.
Per-IP rate limiting against an unauthenticated channel is a throttle against one attacker source. An attacker with a residential proxy pool, a small VPS spread, or any cloud provider's IP-range library treats per-IP rate limiting as a coordination tax. Each request from a fresh IP returns the same response the bug exposes; the rate limit slows the rate at which any single source can read the channel and does nothing about the channel.
The 4.2 lockout migrates the throttle from the source IP onto the email string itself. That is harder to evade because the attacker cannot rotate the email he is checking. It is not a structural fix to the bug. It is a finer-grained throttle against the same observation, two release cycles in. The fix reads the bug it was supposed to close.
The second change in the release notes gets less attention. Quoting again:
If a user fails to login 10 times in a row, the user will be required to change their password.
Real users can be enumerated through the password reset endpoint. Real users can be forced to change passwords by submitting ten wrong passwords against their email. The two changes compose.
An attacker with a list of fifty enumerated users at a target organization can force fifty password resets by submitting roughly five hundred wrong logins. The cost is five hundred HTTP round trips. The effect is that fifty users will, on their next login, be told to set a new password. Help-desk volume goes up. Service availability for those users goes down for whatever interval the password change takes.
The change is described in the release notes as a security feature. In a system whose enumeration channel remains open, it is also a denial-of-service primitive whose precondition is the bug.
LiquidFiles is a managed file transfer product. The user list is the list of people who send and receive files inside and across organizational boundaries: legal, finance, HR, vendor partnerships, M&A coordinators. The same lists that draw spear-phishing campaigns and credential-stuffing runs draw user enumeration as a step zero.
Cleo, MOVEit, GoAnywhere. The MFT breach pattern of the last three years has consistently rewarded attackers who knew which accounts were real before they tried to compromise them. CVE-2025-56132 is a step-zero bug in a step-zero target.
LiquidFiles is closed source. The 4.2 release notes describe the mitigations the vendor added; they do not describe what the password reset endpoint does on the wire when the email is valid. The differential is observable through the nuclei template, the vendor's CVE record, and the response patterns the template documents. The controller that decides whether to set the invalid_email flash, the lockout-list implementation, the timing characteristics of either: closed.
What the public artifacts already say: the vendor's mitigation depends on the channel. The vendor's CVE record acknowledges that the channel is open by default after the patch. The mitigation is rate-limiting enforcement against the same observation the bug enables.
PoC: projectdiscovery/nuclei-templates · CVE-2025-56132.yaml
The block is itself the channel.