The vulnerability in the ActivityPub handler isn't a missing authorization check — it's a check that binds to the wrong entity. The verify_mod_action function confirms the actor has moderator privileges over the community receiving the activity, but then operates on a target post without verifying that the post actually belongs to that community. A moderator of Community A can submit an activity to feature a post from Community B in A's featured feed, and the handler accepts it because the authorization check validated the moderator's status on the receiving community, not the post's ownership.
The fix is a one-line comparison: post.community_id == community.id. But that simplicity is the real warning. A one-line gap that went unnoticed means the threat model never accounted for cross-community federation at this layer. The ActivityPub protocol treats featured collections as loosely coupled — any object can be added to any collection — but the application's authorization model assumes moderators control only their own community's surfaces. That mismatch is where this class of flaw lives.
Audit every handler in crates/apub that dereferences self.object after a verify_mod_action call. Add a provenance check: does this object actually belong to the community we're authorizing against? The one-liner patches this instance but leaves the architectural condition intact. More handlers likely have the same gap. The CVSS score captures the authorization bypass but misses the real impact: users interpret featured-feed placement as curation endorsement, so injecting external posts into a community's featured feed is trust injection across federation boundaries, not just a field update.