A call to action: Use LLM agents to find vulnerabilities in your code before someone else does!

[arcanemachine]

I was looking at Hackney on hex.pm and, I noticed in the Versions tab that there were a lot of vulnerabilities… and they are super recent!

Takeaways so far:

• If you’re using Hackney and you haven’t updated in the last 3 days (!), you should probably update sooner than later.

• The new hex.pm interface looks great!

• hex.pm shows which versions of packages have known vulnerabilities. (Is this part of the redesign? I love it!)

---

OK, so that’s pretty crazy… How are there so many vulnerabilities so recently?! (If you’re like me, your first thought was probably “Mythos!!!”, which is close, but wrong.)

So I came here to search for info about Hackney, and… nothing! But there’s a post over on the Erlang Forums about it. At the very end, @benoitc notes:

Thanks to @PJUllrich, Ganbagana and tepel-chen for the reports, and to
maennchen for coordinating disclosure.

I recognized the first name immediately: Peter Ullrich. (I don’t know who the others are, but I’m thankful for their efforts as well!)

So I hopped over to his blog, and: jackpot!

What the CVE?

Long story short, he used Opus 4.7 to find vulnerabilities in some packages, including Decimal (EDIT: I just realized I need to update that one too!). He doesn’t mention Hackney (the blog post is from May 12, 2026, but the security patch for Hackney is from May 25, for version >= 4.0.1). But I think it’s safe to assume that he applied the same process to Hackney as well. (Thank you, Peter!)

---

So where does that leave us? I’m glad you asked!

As I’m sure you know, we live in a world where you can basically talk to your computer, and it can write code to some degree or another!

Unfortunately, the bad guys know this too! And it’s only a matter of time before they make their way over to you. Yes, you, some guy in Nebraska!

So, to everyone out there, whether you are a library maintainer, a cog in some corporate machine, a coder with some free time on their hands, or some random idiot dumping yet more AI-related content to the Elixir Forums, I entreat you: Start using LLM agents to break the software you use before someone else beats you to the punch! Break your own stuff, break your dependencies… Break everything! (And be a good citizen and report it responsibly, please. )

We have a fairly nice, quiet ecosystem here. Let’s do our best to make sure we don’t get pantsed every other day like the poor folks in some of those other ecosystems!

It doesn’t have to break the bank… the $20 Claude plan doesn’t get you very far these days, but the $20 OpenAI/Codex plan can still get you pretty far (for now…). There are also open models such as GLM 5.1 and Kimi K2.6 which are surprisingly capable, and can be run on cheap subscriptions such as Opencode Go if you’re cash-strapped. (It’s $5/month for the first month, then $10/month. GLM 5.1 is a little slow sometimes, but it provides unbeatable value for the money.) If you’ve never used a coding harness, OpenCode is a great open-source tool you can get started with.

If you’re even remotely curious, I encourage you to get out there and give it a shot!

[DaAnalyst]

.. OR pin your dependencies.

[maennchen]

The EEF CVE Numbering Authority is currently handling a much higher volume of reports than we did only a few months ago:

CVE Activity - https://cna.erlef.org/

We also have a backlog of findings that is larger than our current capacity to triage, report, and coordinate. Because of that, we are prioritizing based on severity, exploitability, and how many users are likely affected.

I do recommend scanning your own projects. That is useful, and maintainers are in the best position to understand whether a finding is actually relevant in context. One good tool to do so is: GitHub - alpha-omega-security/scrutineer: Security through scrutiny · GitHub

If you find an issue in a library you maintain or depend on, please reach out to the CNA so we can coordinate disclosure properly: Maintainer Process | Erlang Ecosystem Foundation CNA

What I would not recommend at this point is everyone scanning everything, uncoordinated, and then sending large numbers of raw findings to maintainers. There is a lot of work involved in proving that a finding is real, understanding impact, preparing a patch, coordinating with maintainers, and publishing a useful advisory. We do not want to overload maintainers with unverified reports or duplicate work.

If you want to help with broader scanning efforts, please reach out to us on the EEF Slack so we can coordinate that work and focus it where it helps most.

On the Hex side, there is also active work happening to make this easier for users:

• Advisory integration is already visible on Hex.pm and will also be integrated into the CLI, including mix deps.get / hex.audit.
• Dependency cooldown is being worked on to reduce the risk from freshly published compromised or vulnerable releases.

There’s a lot of background work that went into making the advisories actionable: Starting the CNA, exporting data into OSV.dev, standardizing how we report metadata etc.

All of this work takes a lot of time. So if your employer is not yet a sponsor of the EEF, I highly recommend to become a sponsor to make this work sustainable: Erlang Ecosystem Foundation - Supporting the BEAM community

[DaAnalyst]

@maennchen

One good tool to do so is: GitHub - alpha-omega-security/scrutineer: Security through scrutiny · GitHub

and who scrutinizes the scrutineer?

[DaAnalyst]

Real question now: why not simply use a dev container (if the fear is dev env getting compromised)?

[benoitc]

LLMs won’t always help. They may eventually find an issue, but not necessarily depending on the version being used, the available context, or the memory they have access to. Some of the “critical” issues that were reported were actually related to how requests were being sent, and I am still not convinced that all of them should have been classified as security issues when they were relatively small functional bugs.

What would be more helpful is for users to spend some time testing the software that is available on Git before making such reports. Functional bugs and other issues can often be identified that way before they become larger discussions.

This is one of the reasons we open source the software in the first place: so people can use it, test it, validate it, and contribute feedback. Otherwise, there is little difference from simply buying a piece of software and interacting with it as a closed product.