the may 2026 fedi software vulnerability

2026-05<br>the may 2026 fedi software vulnerability

alternate title: the most annoying person you’ve ever known has just gotten a reason to become even more annoying

(via mia)

a little before this post ought to go up, mastodon, iceshrimp.net, misskey (and it’s many forks), wafrn, and any other fedi software implementing ld-signatures should’ve released a security update. apply it.

after mastodon reached out to us to let us know we may be vulnerable, i was part of the response to this vulnerability on the iceshrimp.net side. this jumble of words and sentences is intended to be my own personal thoughts about all this, as given my loud opinions around the code that got exploited, i think a “told you so” would be appropriate.

#what went wrong

ld-signatures. a rarely implemented and effectively deprecated part of the de-facto protocol that mastodon loudly warns other implementors to not bother with, and which already has a replacement that wouldn’t have broken in this way if implementations had already switched to itand to be fair, we do not have it either, as it demands upgrading from rsa to ed25519, which in the direction w3c wants to take the protocol, demands replacing the mostly ok http signature draft a mediocre dev like me could implement in a weekend, and could reasonably be updated to fix the quirks in a compatible way, with an rfc way overbuilt with, as far as i can see, miniscule benefits over some vague “spec adherence”.

additionally, due to iceshrimp.net’s odd requirement of supporting misskey database migrations (although, since then we have added migrations that make moving back to a misskey-based software difficult), a lot of our current tech choices are pretty much just “misskey done in c#”, so we do not really support multiple keys on an actor just yet.

you do not need to be claude mythos in order to think this may be a good place to look for vulnerabilities in.

#the eLLephaMt in the room

but just because it’s obvious in hindsight does not mean many people will actually look there. this specific vulnerability was, according to the mastodon maintainer who reached out to us, found by anthropic (and given the timing, i’d assume via mythos)

Doyensec has contacted us on behalf of Anthropic to report a vulnerability in Mastodon regarding verification of Linked Data Signatures. When evaluating this, we also discovered other variants of that same vulnerability.

due to this connection to anthropic, we were initially a bit hesitant to actually treat this as a security vulnerability, and i could feel my fellow maintainers being a bit uneasy while patching it.

in the brief period of time waiting for a proof of concept from the reporter, to validate this as a security issue, i myself was able to find another way to exploit this in iceshrimp.net. which did not apply to mastodon as iceshrimp.net does json-ld expansion (the bare minimum, hence the bug), whereas mastodon does not.

#ok so what actually went wrong

there are multiple ways to represent the same rdf graph (what ld-signatures validate) as compacted json-ld (what nearly all implementations parse, though very little do expansion).

therefore, if you convince a victim to inline a malicious json-ld object, and sign the “wrapping” object (by, say boosting a malicious post, for example), some obscure json-ld functionality can be used to re-order properties around, letting the attacker influence the object signed by the victim’s signature.

the root cause underlying it all is that ld-signatures, and activitystreams “as-specified”, works on rdf triples and graphs, whereas nearly all implementations used in the real world treat activitystreams as plain old json with some annoying quirks. interestingly, the spec says this is fine

#now for the told you so part

i have previously described a theoretical security vulnerability using json-ld @context cache poisoning to sneak in malicious objects through potential validation, although that particular exploit uses a different, much simpler json-ld mechanism, and also requires the victims to use the origin based security model.

which pretty much everyone does, as in contemporary AP you do not have enough backlinks and other clues you can look for to verify someone is allowed to do something, but all the identifiers are urlsif you want to shout “just add the actor sending the activity into the url as well 4head”, this is where that response goes

now, i am a little biased here. i am a well documented json-ld hater. i also have an implementation of the algorithms under my belt, so you can decide if i have a point or am Just Not Seeing The Future, Maaaaaan.

#the mitigation

what was our mitigation? we’re rejecting any activity that makes use of @included, @graph, or @reverse, and we’re rejecting any activity that expands to an array with more than one object

and how much real world communication this brute force mitigation breaks? well, i don’t have the exact...