We just published a new episode of BEAM There, Done That that I think deserves a focused discussion here.
Peter Ullrich spent an afternoon at ElixirConf EU running a $10 Claude experiment against the most-downloaded Hex packages. He found a critical vulnerability in decimal - a library used by almost every database and money-handling package in the ecosystem - in under 30 minutes, with no prior security experience. Since then he’s been systematically scanning further down the list and has reported roughly twice as many vulnerabilities as have been published so far.
Jonathan Machen, EEF CISO and operator of the Erlang Ecosystem Foundation’s CVE Numbering Authority, joins to explain what happens on the receiving end of those reports and where the infrastructure currently stands.
For library maintainers specifically: Jonathan’s single recommendation is to enable private vulnerability reporting on GitHub (three clicks) and write a security policy. If Peter finds something in your library, this is how he reaches you privately before anything is public. Without it, disclosure gets significantly harder for everyone.
The patterns appearing most often:
String.to_atom/1 and binary_to_term/1 enabling atom table exhaustion or remote code execution
HTTP libraries with missing buffer caps on WebSocket connections
Sobelow and Credo catch a meaningful portion of these statically
Peter’s prompts are open source - linked from his blog post if you want to run a scan on your own codebase. He recommends feeding your application file-by-file to Claude Opus with a prompt focused on externally-reachable attack vectors.
The bigger picture: the obscurity advantage the ecosystem relied on for 30 years is eroding. The EEF is building real infrastructure to replace it (CNA, AGES initiative, supply chain security), but it’s currently funded by a single sponsorship and staffed largely by volunteers. If your company is running Phoenix in production, that’s worth thinking about.
Happy to discuss the technical patterns, the disclosure process, or anything else from the episode.
For library maintainers specifically: Jonathan’s single recommendation is to enable private vulnerability reporting on GitHub (three clicks) and write a security policy. If Peter finds something in your library, this is how he reaches you privately before anything is public. Without it, disclosure gets significantly harder for everyone.
Good idea, I added a SECURITY.md and enabled private channel reporting on all my Elixir repos
In short Peter started using LLMs to find massive vulnerabilities in the most used libs in the Erlang ecosystem. He discusses how he found them and Jonatan talks about how we should respond, how you can protect yourself as a maintainer and user, and he also discusses how the EEF is at a breaking point and needs help with handling CVEs in the long term.
Where does the CVE come from though. Sure you can build a tracking platform, but what the foundation built is actually being able to have CVE issued for our ecosystem in the first place - one controlled by people understanding our ecosystem.
These are the people with more work on their hands than time to deal with it. You’re free to think their claims are FUD, but their trackrecord of securing funding, becoming a CVE Numbering Authority – creating not just a CVE tracking page but one validating, scoring and issuing CVEs – working with the standards bodies involved in all that, working through the raising number of CVEs, handling communciation with maintainers and reporters. All these are real accomplishments of the foundation in recent years. These are the people telling you they’re understaffed and/or underfunded. What they do is not an lazy afternoon job.
If you don’t trust them the problem is real, there’s other reports of the same problems like e.g. of the maintainer of curl:
To your individual suggestions:
build a CVE tracking website (for the MVP: an afternoon’s work?)
We have something better: https://cna.erlef.org/. Not just a tracker, but an issuing body of CVEs.
auto-send CVE alert to the project maintainer
The point is that maintainers should be informed before CVEs are made public, so fixes are available at the time the CVE becomes public. Reporting is just a part of the work we need to deal with.
That doesn’t seem to exist, but I’m very sure Peter Ullrich is at the top currently. I’m also sure there would be ways to calculate the data based on the APIs you get of https://cna.erlef.org/. You could try to build it. The website is also open source on Erlang Ecosystem Foundation CNA · GitHub.
That makes it sound like there’s no transparency. The foundation has been talking at conferences, creating blog posts (like this one), is free for people to join and attend the meetings and all their financials are public. I’m not sure what else you’re expecting in terms of transparency.
TLDR: It’s fine to think this is less urgent than stated, but making is sound like what the people at the foundation do is to be challenged by some random afternoon coding session doesn’t match reality.
It’s fine to think this is less urgent than stated
I do believe the CVE problem is real. I just wonder why the heavy push towards a centralized organization with insider ‘experts’ that spread heavy FUD. Building a cadre of middle-manager / regulators should be an anti-goal. IMO the first impulse should be towards a lightweight/decentralized approach, which could be done readily.
I understand AI can be divisive but this is not an accurate summary of the episode and both the EEF and Jonatan have done a lot of positive work for the community, especially when it comes to security.
You can criticize the process and the structure but it is unfair to describe the work they have done as FUD or a way to get funds. Let’s please respect each other.
You need to have a handful of people you can trust and are security experts to coordinate the whole process. The number of CVEs are going to increase in the short-medium term and the community will need assistance because it will be the first-time experience for many of us
Most funds related to security will require an organization and those funds are important for projects like Hex Security Audit
There is literally one person working on it today and yet it is being labelled as a cadre of middle-manager and bureaucracy
But most importantly, if you believe in a lightweight/decentralized approach, you can either:
engage constructively with the current process to improve it
or go ahead and build the solution you want to see: gather the funds (or don’t), perform security audits for important projects, establish your own CNA for Hex package owners, and reach out to maintainers
The only reason we have a podcast episode to listen to is because people are doing work for the community. So if we want to challenge them, we should put our work into it too.
The CVE Numbering Authority System is designed for decentralization. I welcome projects starting their own CNA. This is however quite a lot of work (bureaucracy, setting up all Report channels like OSV.dev, training participants etc.) So it only makes sense if you’re either a larger company that covers its Elixir Bindings or a large project in general. If anybody wants to do that, I’m happy to support that journey.
But most of our projects will not fit that model. And it also doesn’t make sense for a project with 2 maintainers to invest all that time in something that they hopefully only have to interact with very sparsely.
We included all Hex.pm packages in the scope (unless covered otherwise) to provide help to maintainers and to publish advisories with good metadata so that tooling can work well with it.
You can just write a bash script that finds all *.(ex|erl|rs|js) files in a project and run them 1-by-1 through an LLM of your choice (mine is Opus 4.8 with max effort, but GPT 5.5 is also good I heard). If you find a vulnerability, please report it privately to either the CNA (cna@erlef.org) or to the author through GitHub private vulnerability reporting or email, but also then please add members of the CNA to your reports so that they can assign CVEs. The maintainer side of this process is explained by the EEF here: Maintainer Process | Erlang Ecosystem Foundation CNA
Just wanted to drop in and say that I am extremely impressed with the work that the EEF security folks are doing, especially given spike in workload due to these new AI scanning tools. Bravo team! Recently I was talking to maintainers of the GitHub Advisory Database, and unprompted they brought up the EEF team and praised them, so it’s not just me that’s noticing.
I don’t agree with the evaluation that they’re taken a heavyweight approach in any particular way. My experience having worked on several CVEs with them is that it’s very lightweight and substantially easier than doing it alone.
I do hope more BEAM companies step forward to support the security team. Their work is invaluable and saves us all a great deal of money and risk.
