Hey y'all,

The tl;dr:

• LLMs found vulnerabilities on Pyfedi, published them, and caused a federation-wide security issue
• I run a fork of Pyfedi that has used LLMs to both customize for needs + find and patch security issues. The current fork of PeachPie has multiple patches for vulns, both those disclosed and others I found.
• As a policy, I'd rather have anything I attach to the public internet inspected on an automated basis for vulns...the current Pyfedi contributor policy prohibits LLM contributions, making it impossible to trust that that code is appropriate to run in a production/public-internet connected environment.

The details:

Michael here, your admin at theATL.social. And this is being written by actual human Michael and not AI Michael. (more on that later). There's been some events in the Piefed community the past few days, due to LLM-identified vulnerabilities identified in the Piefed software, hosted at https://codeberg.org/rimu/pyfedi

In response, Piefed.social was offline until the vulnerabilities were patched by rimu, and Piefed.zip is still offline. I've also been in communication with some other admins about this.

I run a fork of Piefed, "peachpie", which is used on peachpie.theatl.social. I started this fork to 1) add some additional behavior to integrate the Pyfedi software into my services stack at theATL.social, 2) to add additional typing & unit/integration testing, and 3) address less-critical security issues that I thought were not adequately addressed in upstream, but I wanted to at least address on my fork.

The fork was on a public repo that I've made private. Why? Because a check of the vulnerabilities of which I was informed + additional vulns I found made it irresponsible to make completely public. These were found by an LLM - specifically, Claude Code w/ Opus 4.7.

There was a time before LLMs when I set up and operated theATL.social using only my human brain and Stack Overflow posts where needed. But, now is not then, and it has become almost trivial to point an LLM at a software stack and tell it to find a vulnerability. We may not be getting Anthropic's Mythos just yet, but there will be an Opus 4.8, a GPT 5.6, 6.0, etc., and it's going to be increasingly easy to crack open any piece of open-source software for malicious purposes.

For that reason is why I rely on an LLM to conduct security reviews, adjudicate and investigate severity myself, plan fixes, and test those fixes. If I didn't do that on the software I run on theATL.social, my entire stack would have been owned many months/years ago.

The current policy of the Pyfedi repo for LLMs is [that] "[Pyfedi] project does not allow contributions generated by large languages models (LLMs)."

This policy was sensible a year ago when LLMs were writing shit code. But to maintain this policy now when it is clear that LLMs have a higher rate of finding true positive vulnerabilities than humans can find is irresponsible at best.

I'm grateful that the license for Pyfedi is GPLed so that the community can fork and share improvements to the code. I'll make my own repo public again in a few days so that my own review and improvements can be shared. But, for any open source software, I will never blindly run something attached to the public internet that has not had some type of automated vulnerability review.

Accordingly, Pyfedi is amazing software and I'm grateful for rimu for building it, but with their current contribution guidelines in place, I just can't trust that the upstream software can be run without additional review and modifications.

Good write up. Thanks for all that you do!