The vulnerability CVE-2025-3864 in Hackney arises from the improper release of HTTP connections to the pool after handling 307 Temporary Redirect responses (and other redirect statuses like 301, 302, 303, 308). This can lead to connection pool exhaustion and a denial-of-service.

The analysis of the provided patch (commit 8f13ddac50d1626f8b9a47a08bd599e4efe1773d) pinpoints the hackney:reply_response/2 function in src/hackney.erl as the location of the vulnerability and its fix.

Before the patch, when reply_response/2 handled a response where the body was not expected to be streamed by the client (NState#client.with_body is false), it would proceed to update the state via hackney_manager:update_state/1. However, for redirect responses in conjunction with a connection pool, merely updating the state was insufficient. The connection would not be returned to the pool because the (potentially empty) body of the redirect response was not explicitly skipped or consumed. This is a necessary step for the hackney_pool mechanism to consider the connection free.

The patch rectifies this by introducing a specific check within reply_response/2. It now determines if the response is a redirect (IsRedirect) and if a connection pool is being used (IsPool). If both conditions are true, it explicitly calls hackney_response:skip_body(NState). This action ensures that the connection is properly processed and made available for release back to the pool, thus preventing exhaustion.

Therefore, hackney:reply_response/2 is the key function that, in its vulnerable state, contained the flawed logic. During exploitation (repeated 307 redirects to an application using Hackney with a connection pool), this function would be invoked, and its failure to release connections would manifest as the denial of service.