The vulnerability lies in the unsafe deserialization of Erlang terms from HTTP API responses. The function request/4, present in hex_core and its vendored versions in hex and rebar3, directly uses binary_to_term/1 on the response body. This function is known to be unsafe on untrusted input as it allows the creation of new atoms. An attacker, by controlling the API response, could send a crafted binary term that creates a vast number of unique atoms, leading to the exhaustion of the Erlang VM's atom table. This causes the VM to crash, resulting in a denial-of-service. The patches for all three affected repositories replace the direct call to binary_to_term/1 with a new, safer function (safe_binary_to_term/1) that internally calls binary_to_term/2 with the safe option. This option prevents the creation of new atoms, thus mitigating the DoS vulnerability. The safe function also validates the term to prevent the deserialization of executable code, hardening it against potential remote code execution.