# Erl-matter vulnerability **URL:** \ **Category:** Chat / Discussions\ **Tags:** security, distributed-erlang\ **Created:** [January 23, 2026, 1:21pm UTC](https://erlangforums.com/t/erl-matter-vulnerability/5391 "2026-01-23T13:21:33Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![jj1bdx](https://erlangforums.com/user_avatar/erlangforums.com/jj1bdx/32/278_2.png) [@jj1bdx](https://erlangforums.com/u/jj1bdx)\ **Post date:** [January 23, 2026, 1:21pm UTC](https://erlangforums.com/t/erl-matter-vulnerability/5391/1 "2026-01-23T13:21:33Z")
I’ve discovered that this attack against automatically-generated distributed Erlang cookie file (aka ~/.erlang.cookie ) is presumably effective at least since OTP 18.0 (in 2015), and the security hole isn’t fixed as of OTP 28.3.1. > **[GitHub - gteissier/erl-matter: Erlang distribution weaknesses and tooling](https://github.com/gteissier/erl-matter?tab=readme-ov-file#guessing-an-erlang-cookie)** > > Erlang distribution weaknesses and tooling While choosing something more secure, such as using TLS between distributed Erlang nodes, is strongly preferred, remaining this sort of vulnerability as default is not good. An obviously possible workaround is to use cryptographically strong PRNG to generate the cookie file content, which requires crypto module. The PRNG in auth.erl is indeed weak to be thoroughly exploited in a short time. Also, the seeding function depends on boot timing, which would not have much diverse output (i.e., of small entropy) between multiple booting attempts of BEAM. Another radical approach would be banning the automatic generation of weak cookies altogether. I am wondering what should be done to this known security hole. – Kenji ---
**Author:** ![filmor](https://erlangforums.com/user_avatar/erlangforums.com/filmor/32/988_2.png) [@filmor](https://erlangforums.com/u/filmor)\ **Post date:** [January 23, 2026, 3:59pm UTC](https://erlangforums.com/t/erl-matter-vulnerability/5391/2 "2026-01-23T15:59:13Z")
Does anyone seriously assume that clear-text Erlang distribution with cookies prevents anything but accidental connections? ---
**Author:** ![jj1bdx](https://erlangforums.com/user_avatar/erlangforums.com/jj1bdx/32/278_2.png) [@jj1bdx](https://erlangforums.com/u/jj1bdx)\ **Post date:** [January 24, 2026, 3:16am UTC](https://erlangforums.com/t/erl-matter-vulnerability/5391/3 "2026-01-24T03:16:10Z")
I think the problem is that the connection made is no longer accidental but deliberately exploited. ---
**Author:** ![nickva](https://erlangforums.com/user_avatar/erlangforums.com/nickva/32/578_2.png) [@nickva](https://erlangforums.com/u/nickva)\ **Post date:** [January 24, 2026, 5:54am UTC](https://erlangforums.com/t/erl-matter-vulnerability/5391/4 "2026-01-24T05:54:52Z")
> I think the problem is that the connection made is no longer accidental but deliberately exploited. The cookie mechanism is only supposed to prevent from your own accidental connections to nodes you don’t intend to. In that case you don’t have to crack the cookie, you already know it (since you set it in your own infra setup). The documentation mentions some of this in: > **[Security - Distributed Erlang — Erlang System Documentation v28.3.1](https://www.erlang.org/doc/system/distributed.html#security)** > > A distributed Erlang system consists of a number of Erlang runtime systems communicating with each other. Each such runtime system is called a node. Message passing between processes at different nodes, as well as links and monitors, are transparent... ---
**Author:** ![jj1bdx](https://erlangforums.com/user_avatar/erlangforums.com/jj1bdx/32/278_2.png) [@jj1bdx](https://erlangforums.com/u/jj1bdx)\ **Post date:** [January 24, 2026, 6:05am UTC](https://erlangforums.com/t/erl-matter-vulnerability/5391/5 "2026-01-24T06:05:24Z")
There are two issues: 1. The seed is highly predictable due to the usage of erlang:monotonic\_time(), which starts from zero at the boot time of BEAM, and erlang:unique\_integer(). The result of seed value is predictable as described in erl-matter README.md. In my case on macOS 26.2 running on Mac mini 2023, the value was within (3.8 to 4.2) \* 10^8. 2. Guessing the seed from the generated string is easy due to the simple linear congruential generation method of the cookie string. I’ve created a mitigation code PoC in [GitHub - jj1bdx/vuln\_erldist: PoC for mitigating erl-matter cookie string attack against auto-generated distributed Erlang cookies](https://github.com/jj1bdx/vuln_erldist/) by changing the following algorithms: - Since auth.erl uses a function in lists module, I assume depending on a module in stdlib will be fine. This means I can use rand module PRNG. - Generation of seed by time-dependent values is performed by `rand:seed/2`. - Computation of the cookie string is performed by `rand:uniform_s/2`. The above modification successfully thwarts the erl-matter attack of guessing the seed from the autogenerated cookie strings. I will review this code further and will make a pull request to OTP later. – Kenji ---
**Author:** ![jj1bdx](https://erlangforums.com/user_avatar/erlangforums.com/jj1bdx/32/278_2.png) [@jj1bdx](https://erlangforums.com/u/jj1bdx)\ **Post date:** [January 24, 2026, 6:08am UTC](https://erlangforums.com/t/erl-matter-vulnerability/5391/6 "2026-01-24T06:08:54Z")
> The cookie mechanism is only supposed to prevent from your own accidental connections to nodes you don’t intend to. I agree with this, but my concern is that the auto-generated cookie string is still weak and can be easily cracked by the third-party attackers. ---
**Author:** ![ieQu1](https://erlangforums.com/user_avatar/erlangforums.com/iequ1/32/2633_2.png) [@ieQu1](https://erlangforums.com/u/ieQu1)\ **Post date:** [January 24, 2026, 3:47pm UTC](https://erlangforums.com/t/erl-matter-vulnerability/5391/7 "2026-01-24T15:47:16Z")
Unencrypted distribution should only be used in a trusted network, think backplane network connecting blades in a server rack. Documentation clearly states that. In an untrusted network, man in the middle doesn’t even need to know the cookie to perform attacks, I believe. ---
**Author:** ![Led](https://erlangforums.com/user_avatar/erlangforums.com/led/32/1594_2.png) [@Led](https://erlangforums.com/u/Led)\ **Post date:** [January 24, 2026, 9:17pm UTC](https://erlangforums.com/t/erl-matter-vulnerability/5391/8 "2026-01-24T21:17:36Z")
Erlang cookies aren’t about security, they’re about “name-spacing”. ---
**Author:** ![jj1bdx](https://erlangforums.com/user_avatar/erlangforums.com/jj1bdx/32/278_2.png) [@jj1bdx](https://erlangforums.com/u/jj1bdx)\ **Post date:** [January 25, 2026, 4:46am UTC](https://erlangforums.com/t/erl-matter-vulnerability/5391/9 "2026-01-25T04:46:14Z")
Of course once a cookie is stolen you can do anything. And I 100% agree with what’s written in the documentation. OTOH, I think using a weak PRNG is something which should be fixed, because Erlang/OTP already has a far better PRNG implementation. ---
**Author:** ![jj1bdx](https://erlangforums.com/user_avatar/erlangforums.com/jj1bdx/32/278_2.png) [@jj1bdx](https://erlangforums.com/u/jj1bdx)\ **Post date:** [January 25, 2026, 4:46am UTC](https://erlangforums.com/t/erl-matter-vulnerability/5391/10 "2026-01-25T04:46:58Z")
I think an abuse of the namespace is still a problem. ---
**Author:** ![jj1bdx](https://erlangforums.com/user_avatar/erlangforums.com/jj1bdx/32/278_2.png) [@jj1bdx](https://erlangforums.com/u/jj1bdx)\ **Post date:** [January 25, 2026, 4:49am UTC](https://erlangforums.com/t/erl-matter-vulnerability/5391/11 "2026-01-25T04:49:13Z")
I’ve posted a pull request to the OTP repository as [auth.erl: use rand module PRNG for cookie generation by jj1bdx · Pull Request #10590 · erlang/otp · GitHub](https://github.com/erlang/otp/pull/10590) ---
**Author:** ![jj1bdx](https://erlangforums.com/user_avatar/erlangforums.com/jj1bdx/32/278_2.png) [@jj1bdx](https://erlangforums.com/u/jj1bdx)\ **Post date:** [January 26, 2026, 9:02am UTC](https://erlangforums.com/t/erl-matter-vulnerability/5391/12 "2026-01-26T09:02:15Z")
OTP Team declined to accept the fix in this repository. The details are described [here](https://github.com/erlang/otp/pull/10590#issuecomment-3798491289). ---
**Author:** ![raimo](https://erlangforums.com/user_avatar/erlangforums.com/raimo/32/867_2.png) [@raimo](https://erlangforums.com/u/raimo)\ **Post date:** [January 26, 2026, 10:23am UTC](https://erlangforums.com/t/erl-matter-vulnerability/5391/13 "2026-01-26T10:23:29Z")
@jj1bdx: Your PR would have made it harder to guess the cookie, and harder to reverse calculate the seed from a known cookie since using `erlang:system_time()` instead of `erlang:monotonic_time()` probably increases the entropy a bit, and because the PRNG is no longer an unscrambled LCG. I think that just using the default automatic seed in `rand` would have been slightly better since it maybe adds another few bits of entropy (the node name and a hash of the process generating the seed), but more importantly it does not just XOR all the entropy bits onto each other, instead it feeds them into iterations of SplitMix64, which should to preserve the entropy better, and make it harder to reverse calculate the seed). Nevertheless, with such an improvement, it would have been harder to write a toolbox to “crack” the Erlang auto generated cookie, so it may not have been written. Now some projects that have kept the Erlang distribution port exposed gets a proper slap on their fingers for not reading the documentation warnings … which is a good thing. Thank you @jj1bdx for bringing back this matter to the community’s attention! ---
**Author:** ![jj1bdx](https://erlangforums.com/user_avatar/erlangforums.com/jj1bdx/32/278_2.png) [@jj1bdx](https://erlangforums.com/u/jj1bdx)\ **Post date:** [January 26, 2026, 4:17pm UTC](https://erlangforums.com/t/erl-matter-vulnerability/5391/14 "2026-01-26T16:17:17Z")
Thanks Raimo. Two things I learned: 1. Do not use `erlang:monotonic_time()` for obtaining boot-time entropy; 2. The seed of an unscrambled LCG sequence will be easily revealed by using modern math tools such as [Sagemath](https://www.sagemath.org/). ---
**Author:** ![raimo](https://erlangforums.com/user_avatar/erlangforums.com/raimo/32/867_2.png) [@raimo](https://erlangforums.com/u/raimo)\ **Post date:** [January 27, 2026, 9:34am UTC](https://erlangforums.com/t/erl-matter-vulnerability/5391/15 "2026-01-27T09:34:11Z")
1. It may be that the entropy of `erlang:system_time()` is also not very large, since the point in time when the automatic cookie was generated may be predictable. If you know the time within a week the estimated entropy would be at most 49 bits. As an edge example, we have heard of products that cold boot and generate the cookie before the correct time has been acquired, so the clock was just after 1 Jan 1970 where the clock chip starts off. In such systems it can be really problematic to find decent entropy. 2. Thank you for the pointer to Sagemath! I know that the author of our `rand` algorithms, and the author of the competing Permuted Congruential Generators have been in a word feud / verbal pie throwing regarding the predictability of PRNGs, and then reverse calculated each other’s generators and scramblers. So any PRNG that is not cryptographically secure can be reverse calculated, with more or less effort. Their debate was related to the one in this thread - is a middle class of security (hard to predict) between cryptographically secure and completely predictable useful, or would such a class of security just give a false sense of security so it should be avoided… ---
**Author:** ![matthiasl](https://erlangforums.com/user_avatar/erlangforums.com/matthiasl/32/1652_2.png) [@matthiasl](https://erlangforums.com/u/matthiasl)\ **Post date:** [January 28, 2026, 10:08am UTC](https://erlangforums.com/t/erl-matter-vulnerability/5391/16 "2026-01-28T10:08:40Z")
Thanks for the mention of the the “pie throwing” between the PRNG designers, it was new to me. There’s a calm description and demonstration on John D. Cook’s blog, with the throwers making an appearance in the comments; I thought it was interesting enough to read: [https://www.johndcook.com/blog/2017/08/16/manipulating-a-random-number-generator/](https://www.johndcook.com/blog/2017/08/16/manipulating-a-random-number-generator/) ---
**Author:** ![raimo](https://erlangforums.com/user_avatar/erlangforums.com/raimo/32/867_2.png) [@raimo](https://erlangforums.com/u/raimo)\ **Post date:** [January 28, 2026, 12:24pm UTC](https://erlangforums.com/t/erl-matter-vulnerability/5391/17 "2026-01-28T12:24:37Z")
Yes. There they are! That was a quite civil tone, but it is that very dispute. Melissa O’Neill says Sebastiano Vigna’s generators are “trivially predictable” and strives for something better (according to some definition). Vigna says - that’s pointless and yours, just like any other PRNG, are also predictable. ---
**Author:** ![mmzeeman](https://erlangforums.com/user_avatar/erlangforums.com/mmzeeman/32/467_2.png) [@mmzeeman](https://erlangforums.com/u/mmzeeman)\ **Post date:** [January 28, 2026, 1:23pm UTC](https://erlangforums.com/t/erl-matter-vulnerability/5391/18 "2026-01-28T13:23:07Z")
> [@raimo](#): > > Now some projects that have kept the Erlang distribution port exposed gets a proper slap on their fingers for not reading the documentation warnings … which is a good thing. Is undergoing a security breach a good educational “slap on your fingers” for not RTFMing though? ---
**Author:** ![raimo](https://erlangforums.com/user_avatar/erlangforums.com/raimo/32/867_2.png) [@raimo](https://erlangforums.com/u/raimo)\ **Post date:** [January 28, 2026, 2:36pm UTC](https://erlangforums.com/t/erl-matter-vulnerability/5391/19 "2026-01-28T14:36:32Z")
Well, there is no solution that Erlang/OTP can implement, except to advise projects to not expose the unsecure distribution port. We could change some defaults, so using the distribution gets harder, but the question is if there is a good enough compromise between ease of development vs. smaller footgun… ---
**Author:** ![mworrell](https://erlangforums.com/user_avatar/erlangforums.com/mworrell/32/267_2.png) [@mworrell](https://erlangforums.com/u/mworrell)\ **Post date:** [January 28, 2026, 2:49pm UTC](https://erlangforums.com/t/erl-matter-vulnerability/5391/20 "2026-01-28T14:49:55Z")
In addition I would also like to point out that the Erlang cookie is explicitly mentioned in a **Security** section. This section also mentions things like “random strings”, “built into the system at the lowest level” etc. This doesn’t sound like a big red warning that the cookies are insecure and should never be used to secure (public) nodes. On the contrary, it does write that the cookie implements security… > **[13.7  Security - Erlang -- Distributed Erlang](https://www.erlang.org/docs/20/reference_manual/distributed#id89236)** > > Authentication determines which nodes are allowed to communicate with each other. In a network of different Erlang nodes, it is built into the system at the lowest possible level. Each node has its own magic cookie, which is an Erlang atom. [Next page](https://erlangforums.com/t/erl-matter-vulnerability/5391.md?page=2)