this post was submitted on 15 May 2026
116 points (100.0% liked)

Announcements

714 readers
94 users here now

lemmy.zip annoucements

The same rules as the main instance apply here.

founded 2 years ago
MODERATORS
 

Edit: see pinned comment for update

Hello All,

Due to the incredibly irresponsible disclosure of a security vulnerability for Piefed, we've had to take Piefed.zip offline until a fix can be put in place.

I'll update more once I have more information.

Many thanks

Demigodrick

you are viewing a single comment's thread
view the rest of the comments
[–] Blaze@lemmy.zip 2 points 1 day ago (1 children)

You can look at https://codeberg.org/rimu/pyfedi/releases/tag/v1.6.25 to see the changes.

Basically, the 0-day was mostly someone running an LLM and trying to discover vulnerabilities without double checking them. Most of the things reported were not applicable (mentioning functions that don’t even exist), others were not applicable but led to some tangent hardening.

Lemmy also had a SSRF vulnerability a month ago: https://github.com/LemmyNet/lemmy/security/advisories/GHSA-q537-8fr5-cw35

[–] fiat_lux@lemmy.zip 2 points 12 hours ago

The raw changes are interesting but not particularly descriptive of the problem(s?) it intends to resolve, so I can't gauge whether it achieves the goal from this. The description of the version bump as simply "security improvements" doesn't help me determine if any of these changes add dedicated tests or anything else to prevent future occurrences (and I'm not traversing the repository on my phone). Additionally, the issue acknowledged via inline comment: "This will probably break PeerTube federation" is odd to omit from even the briefest changelog. In my opinion, this is not that reassuring an update.

The LLM generated report of Lemmy's vulnerability, which I note requires an entire DNS configuration to exploit, is a little ironic to point to as an authoritative source while characterizing the Piefed exploit discovery as "someone running an LLM and trying to discover vulnerabilities without double checking them".

But I don't think it's necessary or helpful to have a competitive security score-card situation between packages either - I would much prefer that each ActivityPub implementation is meaningfully improving their development lifecycle processes, especially around security risk mitigation, even if they don't go quite as far as having a formal "security posture".