Around one tenth of CVEs published by the EEF CNA are caused by atom exhaustion, a denial-of-service vulnerability that is well understood, often preventable, and still showing up in production Erlang and Elixir applications.
Correction (2026-05-29): An earlier version of this post stated that
approximately one third of EEF CNA CVEs are caused by atom exhaustion. The
correct figure is approximately one tenth. The text has been updated.
And it’s a footgun with a proposed fix that is known to have worked in Logix.
I assume you’re referring to a local / global atom table split like it was proposed in EEP20.
There’s a lot of discussion around that here: On garbage-collecting atoms
what is Logix?
If OTP was to allow non-atoms as names for processes and ETS tables, I believe most needs for runtime generation of atoms would go away.
Yes there is list_to_existing_atom/1 but that doesn’t cover all cases.
Logix is specifically mentioned in EEP-20 as a reference to the Logix implementation of Flat Concurrent Prolog
It seems the logix language sourceforge link is for something quite different
I think it’s this one: https://www.nongnu.org/efcp/Logix/index.html
Logix was an implementation of Flat Concurrent Prolog, one of the sources of Erlang.
No, wrong Logix. This one:
EFCP homepage
I think something is off with your math. Over one third of the CVEs are attributed to the CWE-400 + CWE-770, but only 5 of those 24 are atom exhaustion (that I could find). So it is one tenth of all CVEs that are caused by atom exhaustion.
Not trying to diminish the problems caused by atom exhaustion, but the title and description here does not match the blogpost which just says that a “large part” of the CVE with CWE-400 are caused by atom exhaustion.
You’re right. I got the math wrong here.
I conflated the broader CWE-400 / CWE-770 resource-exhaustion category with atom exhaustion specifically. The correct number is not one third of all EEF CNA CVEs.
With the current CVE volume we are dealing with, I did not spend enough time verifying that number before publishing. When I looked up the CWE-400 / CWE-770 percentage, it matched my intuition, so I failed to question whether it applied to atom exhaustion specifically. That was my mistake.
I’ll update the blog post title and intro, and add a correction note so this is clear.
Just for the reference, if somebody finds this message and thinks that this problem is unavoidable. It’s absolutely not.
Libraries like gproc cover the case of process registration. gproc is backed by ets, so there’s some overhead, but binary_to_(existing)_atom has overhead too. This works for all gen_servers and gen_statems and whatnot.
For ets tables one has to be a little more creative, but it’s nothing that a deliberate design cannot solve. In the simplest case, one can just use a single named table and prefix all keys with a “namespace”.
Not that it solves the atom problem, but I note that the union/find method in EEP 20 could already be used for binaries. It might speed up certain kinds of applications that do a lot of equivalence checks on binaries, such as merkle trees.