Possible fix(deps): 5 vulnerable dependencies in mix.lock

[begininvoke]

This might be a false positive, but mix.lock around line 20 looked worth a second pair of eyes.

The SOCKS5 transport in hackney upgrades a connection to TLS using ssl:connect/2, which defaults to an infinite timeout. A hostile SOCKS5 proxy can complete the SOCKS5 handshake and then stall (or send a partial TLS ServerHello), causing the connecting process to block indefinitely. This uncontrolled resource consumption creates a high‑severity denial‑of‑service vulnerability.

Something like this might fix it:

--- a/src/hackney_socks5.erl
+++ b/src/hackney_socks5.erl
@@
-    % Upgrade to TLS
-    case ssl:connect(Socket, Options) of
+    % Upgrade to TLS
+    case ssl:connect(Socket, Options ++ [{timeout, Timeout}]) of
        {ok, SSLSocket} -> {ok, SSLSocket};
        {error, Reason} -> {error, Reason}
    end.

For reference: rule CVE-2026-47071. Rated high.

If I have misread how this is used, sorry for the noise — feel free to close.

---

Found with automated scanning (RedGem) and reviewed before opening. If it is not useful, closing it is completely fine.