This is the multi-page printable view of this section. Click here to print.
Announcements
Pixelfed Vulnerability and Impacts to Federation
A recent Pixelfed vulnerability and how it impacts Hachyderm.
If you’re an instance admin and need to reach out to us to refederate, please skip to the “For mods and admins” section (linked on the right nav menu).
Information about the vulnerability
Pixelfed v0.12.5, released 24 Mar 2025, fixes a flaw in how Follows and Followers Only posts were handled by PixelFed. Before this release, private accounts (accounts that require follower approval) could be followed without approval, and any visible post to any user on a Pixelfed instance was accessible to all users on the entire instance. This allowed unintended access to private content. This is true for all instances federating with the Pixelfed instance, not just the instance itself or other Pixelfed instances.
You can read more about this vulnerability here:
- NIST CVE-2025-30741 (Web Archive Link)
- Github Advisory
- Forkus.Cool Blog Post 25 Mar 2025 (Web Archive Link)
- Fediverse Report for 1 April 2025
Why are we talking about Pixelfed and how does this impact Hachyderm?
To restate succinctly:
This vulnerability can expose followers-only posts on all follower-only accounts for all instances using the ActivityPub protocol, regardless of what implementation they are using.
How? The short version.
Understanding the gist of the vulnerability requires understanding a couple of mechanics around followers / following and followers-only posts. For the former, when you “lock” your account or make it “private,” what you are enabling is the ability to manually approve followers. Only once you have approved the follow request is the follower approved and the follower allowed to follow you. (For public accounts approval is automatic unless the account’s instance is otherwise moderated by you or your instance.)
Another part of follow / following mechanics is a process referred to as synchronization. This is the process that makes sure your followers list stays updated. For example, if someone deletes their account, this process removes it from your follower list.
Furthermore, when you make a followers-only post, what is supposed to happen is that post should go to your followers collection only. This means notifying the instances hosting the accounts of your followers to relay that post to accounts specifically in your followers collection.
What was happening with Pixelfed versions 0.12.4 and earlier was that Pixelfed hadn’t correctly implemented account following, which means “locked” / “private” accounts can be followed by any Pixelfed user without explicit approval. This means that posts federated with Pixelfed instances that were marked as “followers-only” were being displayed to accounts that Pixelfed had allowed to follow you, but were not necessarily the followers you intended.
Since Hachyderm is a Mastodon instance, that also means that any instances running Pixelfed v0.12.4 or earlier that we federate with can expose private posts on Hachyderm to these instances, additionally, any pixelfed servers running v0.12.5 may still be exposing followers-only content until Pixelfed implements follower collection synchronization.
What about other ActivityPub implementations?
This same type of vulnerability can happen in other federated software using ActivityPub as well.
This is why you should never post sensitive or highly private content: the privacy of that content is only as strong as the least secure part of the network or software. (The software itself, the server it’s running on, and everything else it needs to run.)
For highly sensitive content, we recommend using services that support end-to-end encryption and limiting who you are sharing it with. Depending on the type of content and how you need to share it, this can include options like Signal or Matrix.
What actions we have taken
Due to the severity of the issue, we have defederated with all Pixelfed instances that are not running version 0.12.5, since versions prior to 0.12.5 allowed for followers that were not approved to access followers-only content.
In addition, since defederation is a silent action (a defederated instance doesn’t receive a notification), we have reached out to impacted instances, where their contact information was available, to explain the situation and how we can resolve and refederate.
Determining the impact
It is always important to make an informed decision when making a server-wide decision as a moderation team. This includes understanding what options are available to you and their impact.
In this case, the only real tool that prevents data exposure on this scale is defederation. All other solutions, like limiting, still allow data to be shared and thus exposed.
Since we knew we were going to need to make multiple defederations, we made sure we knew the full scope of the impact of this action. This is doubly true for this CVE, as we typically prefer to give instance admins time to react to information they receive, and, as many of us in tech know, upgrade paths are not always smooth and straightforward.
For the impact analysis, we gathered the following data:
- How many Pixelfed instances are we federating with?
- What versions of Pixelfed are those instances running?
- How much cross-pollination (followers / following) is occurring on those instances?
As a result of our analysis, we determined that the risk to Hachydermian’s private data was high and the cross-pollination on the impacted instances was very low.
The impact data
Prior to the vulnerability, Hachyderm was federating with 96 instances running Pixelfed. Due to the CVE, we have defederated with 63 of those instances.
(Since this action is due to a security vulnerability, we will refederate with instances that patch the vulnerability. Head to the mods and admins section of this post to learn more.)
A breakdown of the Pixelfed instances we are/were federating with:
- 33 are running 0.12.5 (released 24 Mar 2025)
- 46 are running 0.12.4 (released 8 Nov 2024)
- 17 are running a version earlier than 0.12.4 (0.12.3 was released 1 Jul 2024)
There isn’t a robust way to query Mastodon for how many offline instances it is still trying to federate with, so an unknown percentage of these were already offline with one or more failed retries to connect. To put it another way, it is likely that a number of instances that haven’t been updated “in a long while” were just offline and that information didn’t propagate properly. There just is not a good way to know exactly how many or which. (This is not a bug in Pixelfed, this is common for federating software.)
For the follower / following relationships:
- For 93 of all 96 Pixelfed instances, regardless of software version, there were 5 or fewer following in either direction.
- For 2 of the instances, there were between 5 and 10 following in either direction.
- pixelfed.social is the outlier and outlined in the next section
What about pixelfed.social
Since pixelfed.social is the largest instance, by far, we’re going to show a little more data. To say it first so it isn’t missed:
pixelfed.social is running v0.12.5, so we will not be defederating with pixelfed.social as part of the response to this CVE. The additional information below is only because we provided comparable information, in aggregate, for the other 95 Pixelfed instances.
Now on to the data:
- pixelfed.social is running Pixelfed v0.12.5
- There are 1073 unique Hachyderm accounts following 956 unique pixelfed.social accounts and 864 unique pixelfed.social accounts following 651 unique Hachyderm accounts.
For mods and admins running Pixelfed instances
First and foremost: HugOps. Planning urgent upgrades for CVEs (and related) is stressful and time-consuming, and that is even more true for the volunteer teams across the Fediverse. You’ve got this!
We’ve also got this with you. We’ve done our best to find contact information to reach out to your admins and mod teams depending on what was listed on your instance or documentation if present, to ensure that you were aware of the situation. Due to the volume of instances impacted by this, this process is still ongoing at the time of publishing this blog post.
We’re happy to refederate with any instance that was defederated from as a result of this CVE. As mentioned in our emails as well, please email us once you have upgraded to 0.12.5 and we will refederate with you. You can also respond to the email that we sent out with the same information.
For anyone looking to communicate with Hachyderm moderation in general, please see both our documentation landing page and our Reporting and Communication page.
For fellow Mastodon admins
In the interest of expediency, we published this announcement so that people can see the analysis and impact of our decision. We will publish a separate, shorter, post to include our methods for gathering the above information for the benefit of the broader Mastodon community.
Defederation from Threads
Defederating from Threads
Hello Hachyderm! In alignment with our prior posts about inter-instance federation, and Threads in particular, Hachyderm has defederated with Threads due to their changes in moderation policy as of the publication of this post.
For those interested in learning more about Threads specifically, please read on.
Changes to Meta’s moderation policies and published statements by Mark Zuckerberg
On Tuesday, 7 Jan 2025, Mark Zuckerberg published a series of posts that described changes to Threads moderation practice, and Wired published an article about Meta’s updated moderation (Hateful Conduct) policies. Other articles have been published while we worked on this blog post as the decisions and implications evolve.
In short, Meta updated its Hateful Content policy to explicitly allow harassment for targeted groups and remove earlier protections. We strongly encourage others, especially moderation teams, to look beyond the current version of their Hateful Content policy and also look at the diff between their 2024 and 2025 policies to see what was altered and removed. You can do this by clicking on the Jan 2025 date on the left nav bar.
Threads is now in conflict with Hachyderm’s inter-instance moderation policies
When we consider defederating instances we consider the Hachyderm community, especially vulnerable members. This means that when we evaluate other instances we look at the impacts of those communities on our community.
We initially Limited Threads primarily to make Threads content “opt-in”, as much as Mastodon tools allow, as there are several news sources, government accounts (people and agencies), and so forth on Threads. (Relevantly, among the top followed Threads accounts were POTUS and Barack Obama.) This meant we also committed to manually moderating individual harmful accounts, and interactions with their content, to maintain community safety on Hachyderm while Threads was Limited.
Threads’ recent changes in their moderation policies, both what they’ve put in and what they’ve taken out (read the diff), puts their moderation practices in direct conflict with ours. Essentially, Threads may indeed be large enough that many users are just looking to exist somewhere on social media and are not necessarily de facto fans of Mark Zuckerberg et al., but we anticipate these changes to moderation will shift the user base of Threads in a way that is damaging to the Hachyderm community, so we are defederating from them before that can occur.
Risk and Value Considerations
When we consider defederating, another factor we consider is actual and perceived loss of value to members of the Hachyderm community. Being able to follow and interact with POTUS, local politicians, government agencies, family, friends, etc. from Hachyderm is potentially valuable.
Mid-2024 it seemed likely that Threads would be the social media platform many of those accounts would use or use as their primary social media presence. So it appeared that the long-term value was medium to high, while the slow roll-out of federation allowed us the ability and time to moderate Threads manually with low to low-medium community risk.
Between Meta’s policy changes and the increasing popularity of Bluesky, it seems many individuals are abandoning Threads. It seems likely that politicians and government agencies will or are moving their primary social media presence elsewhere. It now appears that the long-term value is low, and even with the slow roll-out for federation the risk to our community has changed to high.
There’s no perfect “calculation” here, but essentially the long-term risk/reward ratio went from overall medium-high to very low because of how significantly these policy changes increase risk of harm.
What was the data on Threads prior to defederation?
Part of how we handled Threads was meeting the situation where it was at any given time. This is why we were watching their policies, interactions with Hachyderm, news cycles, etc. This is also another reason that we mention here, and in earlier posts, about the slow roll-out of federation. It means that the “instance”, in the federation sense, is significantly smaller than the broader platform. To clarify what this means:
- Not all Threads accounts are federating, in fact most are not.
- Of the Threads accounts that are federating, not all are fully federating.
- In practice, this means that Fediverse users can see and read a user’s Threads posts, the Threads user cannot see Fediverse interactions with their posts. Functionally, this is/was similar to the experience of posting and boosting posts from Twitter bridges.
Specific data:
- There were ~10,000 total Threads accounts federating with Hachyderm.
- There is no way from the data to tell how many of these are fully or partially federating.
- To put this in perspective:
- This is significantly smaller than Mastodon Social (~265k accounts) and approximately the same size as other larger Fedi instances including Mastodon Online (~25k accounts).
- This is approximately 0.0036% of Threads users overall, as Threads has approximately 275 million active users (as of Nov 2024).
- There was one user-generated report regarding a Threads user. In that case it was not about harmful content but a user interaction. There were no other reports sent to Hachyderm moderation about Threads interactions.
To put this in perspective (and acknowledging that these two instances do not have the same moderation policy that Threads now does), we’ve fielded ~500 reports (in total) regarding Mastodon Social and 45 reports (in total) regarding Mastodon Online.
There were 2033 unique Hachyderm accounts following 919 unique Threads accounts and 26 unique Threads accounts following 22 unique Hachyderm accounts.
- For other mods, note that the queries to figure out are not what the Admin Dashboard is running. We’ll put the queries at the bottom of this blog post.
How does this tie into our overall moderation decision? Essentially, the changes to their moderation policy, whether they revert them or not, increase the risk of harm drastically and have a high likelihood of changing the Threads platform account demographics faster than our ability to manually moderate them. In that respect, the decision that we would need to defederate from Threads was made after we reviewed Threads’ current policy and its diff when it was released on Tuesday.
Before enacting the decision, we needed to understand the impact on the Hachyderm community and prepare this statement. Since the queries on the dashboard didn’t provide the level of granularity we needed, Hachyderm moderation and infrastructure coordinated to ensure that we were surfacing the correct data to inform our decision (the last bullet point above and the queries in the next section). This allows us to know how many Hachydermians would be impacted and to what degree. Thank you for your patience in this regard, as due to the significance of the follow/following severances that are occurring we wanted to be accurate in providing this data.
Queries to run to gather the above data
The query to run for “how many unique accounts on my instance are following Threads accounts” is:
Follow.joins(:target_account).merge(Account.where(domain: 'threads.net')).group(:account_id).count.keys.size
Our result in this case is 2033.
The query to run for “how many unique Threads accounts are following accounts on my instance” is:
Follow.joins(:account).merge(Account.where(domain: 'threads.net')).group(:account_id).count.keys.size
Our result in this case is 26.
The query to run for “how many unique accounts on my instance are being followed by Threads accounts” is:
Follow.joins(:account).merge(Account.where(domain: 'threads.net')).group(:target_account_id).count.keys.size
Our result in this case is 22.
The query to run for “how many unique Threads accounts do accounts on my instance follow” is:
Follow.joins(:target_account).merge(Account.where(domain: 'threads.net')).group(:target_account_id).count.keys.size
Our result in this case is 919.
Queries behind the admin dashboard
These numbers are different from what appears in the admin dashboard (instanceDomain.com/admin/instances/threads.net) because the dashboard runs different queries.
The “Their Followers Here” query is:
Follow.joins(:target_account).merge(Account.where(domain: domain)).count
In our dashboard this displayed as 6014.
The “Our Followers There” query is:
Follow.joins(:account).merge(Account.where(domain: 'threads.net')).count
In our dashboard this displayed as 27.
These numbers aren’t deduplicated, so they may not meet your needs when determining how heavily your instance is interacting with Threads.
10 Jan 2025 update: One of the four queries was dropped when we initially published this announcement late Thursday evening. We’ve added the query, as well as taken the opportunity to fix a couple typos and add small clarifiers.
Threads Update
What is Threads?
Threads is an online social media and social networking service operated by Meta Platforms. The app offers users the ability to post and share text, images, and videos, as well as interact with other users’ posts through replies, reposts, and likes. Closely linked to Meta platform Instagram and additionally requiring users to both have an Instagram account and use Threads under the same Instagram handle, the functionality of Threads is similar to X (formerly known as Twitter)1 and Mastodon.
What is the status of their ActivityPub implementation?
As of December 13, 2023, Threads has begun to test their implementation of ActivityPub. As of December 22, 2023, only seven users from Threads are federating with Hachyderm’s instance. For all other users on Threads, we are seeing that the system is not federating correctly due to certificate errors on Threads side. We understand that they are working to resolve those certification issues with assistance from the Mastodon core team.
Based on the available Terms of Use and Supplemental Privacy Policy provided by Meta, they are not selling any of the data they have. This is not official legal or privacy advice for individual users, and we recommend evaluating the linked documents yourself to determine for yourselves.
With regards to the section in the privacy policy
Information From Third Party Services and Users: We collect information about the Third Party Services and Third Party Users who interact with Threads. If you interact with Threads through a Third Party Service (such as by following Threads users, interacting with Threads content, or by allowing Threads users to follow you or interact with your content), we collect information about your third-party account and profile (such as your username, profile picture, and the name and IP address of the Third Party Service on which you are registered), your content (such as when you allow Threads users to follow, like, reshare, or have mentions in your posts), and your interactions (such as when you follow, like, reshare, or have mentions in Threads posts).
It’s important to remember a few things:
- The Mastodon/ActivityPub at their core uses a form of caching of information in order to make the process as seamless as possible. For example, when you create a verified link on your profile, every instance that your profile opens on does its own checks of the links and saves the validation on that third party server. This helps prevent malicious actors from falsifying their verified links that would then trickle out to other instances.
- We don’t transmit user IP’s to any third party instances as part of your interaction. If Meta is able to collect your IP, it would be through a direct interaction with a post on their server or CDN.
How does this impact Hachyderm?
At this point, Threads tests of the ActivityPub do not impact us directly. Based on the available information, they haven’t breached any rules of this instance, they aren’t selling any of the data as discussed above, and the user pool is so limited that even if they did, our team’s ability to moderate that would be quick and decisive. In addition, any users that do want to block Threads at this time, can follow the instructions in the next section to pre-emptively block Threads at their account level.
As a result, we will continue to follow our standard of monitoring each instance on a case by case to see how the situation evolves, and if a time comes that we see Threads federations as a risk to the safety of our users and community, we will defederate at that time.
Indirectly, we know that admins of other instances have expressed that they will defederate with any instances that will continue to federate with Threads. While we hope that the information in this blog post has helped people understand the currently limited risk of continuing to federate with Threads, we also know that other instances have a much more limited set of resources and may need to preemptively defederate with the Threads instance. The beauty of the Fediverse is that each instance has that right and ability.
How to block Threads.
- Search for “threads.net” in the search box
- Select a user from the results
- Open the menu from the profile
- Select “Block domain threads.net
- Read the prompt and select your desired action
To understand the ramifications of blocking an instance, please review the Mastodon documentation for details on what happens.
Next Steps
As Threads continues to implement their integration with ActivityPub and the Fediverse at large, we will watch how those users integrate with our community and how their service interacts with our servers. If you would like to learn more about our criteria for how Hachyderm handles federating with other instances, please review our A Minute from the Moderators - July Edition where we list out our criteria.
Crypto Spam Attacks on Fediverse
The Situation
Starting around 8 May 2023, we began to receive reports that Mastodon Social was being inundated with crypto spam.
Initially, it appeared that only Mastodon Social, and then Mastodon World, were impacted. In each case we Limited the instance and made a site-wide announcement. As the issue progressed, it became clear that more instances were being targeted for this same style of crypto spam. As a result, we have decided to change our communication strategy to utilize this blog post as a source for what’s happening and who is being impacted, rather than relying on increasingly frequent site-wide announcements.
As it stands: right now we have seen waves of spam from Mastodon Social, Mastodon World, and now TechHub Social. These waves usually mean that we receive over 100-200 reports in less than a few hours. (By contrast, we usually receive ~20 reports per week.)
What this means for Hachydermians (and Mastodon users in general)
Spam attacks seem to make use of open federation to either find accounts to misuse follow/unfollow behaviors, DMs, comments, and other invasive behaviors. In general, Limiting a server is sufficient for mitigating the impacts of these behaviors. Limiting means that Hachydermian’s posts no longer show up in the Federated feeds of impacted instances, which means that bots can no longer use the Federated feed as a vector for malicious behavior. While this is a good thing and means that these bots will no longer be able to spam Hachydermians, the Limit works both ways. This means:
- The posts for Limited instances will no longer show up on the Federated feed
- You will receive approval requests for all accounts on Limited instances
- User profiles will appear to have been “Hidden by instance moderators”
The UI messages for the latter two are a little difficult at times to determine what it means. Essentially, you will see the same message for a user to follow you from an instance that’s been Limited, and for you to view their profile page, as you would if we had only Limited that specific user.
For users on the impacted instances, these messages should not be taken as the individual user has engaged in any sort of malicious activity. In general, when we see individual-level malicious activity, we suspend federation (block) the individual user rather than Limit them. Instead, these messages are only a consequence of us needing to Limit the servers while they are doing their best to manage the spam attacks they are undergoing.
The impacted instances
We are maintaining the list of instances that we are Limiting as a result of the current crypto spam attack here. Note that this is not all instances we currently have Limited for any reason, only the ones that are experiencing this specific scenario. We will continue to announce when new instances are added to this list via our Hachyderm Hachyderm account and link back to this blog post. Instances that are no longer impacted will be un-Limited and removed from the list below. (When the list is empty, that means that all instances have been un-Limited.)
Updates
Update 25 May 2023 - we’ve been crypto spam free from Mastodon Social and Mastodon World, so we’ve gone ahead an un-Limited those instances.
Update 2 Jun 2023 - we’ve been crypto spam free from TechHub Social, so we’ve gone ahead and un-Limited that instance! That’s the last one, so this incident is resolved.
Updating Domain Blocks
Today we are unblocking x0f.org from our list of suspended instances to federate with.
Hachyderm will begin federating with x0f.org immediately.
Reason for suspending
We believe the original suspension was related to early moderation actions taken earlier in 2022. The moderation actions took place before Hachyderm had a process/policy in place to communicate and provide reasoning for the suspension.
Reason for removing suspension
According to our records, we have no reports on file that constitute a suspension of this domain. The domain was brought to our attention as likely flagged by mistake. After review we have determined that there is no reason to suspend this domain.
A Note On Suspensions
It is important to us to protect Hachyderm’s community and our users. We may not always get this right, and we will often make mistakes. Thank you to our dedicated users for surfacing this (and the other 13 domains) we have removed from our suspension list. Thank you to the broader fediverse for being patient with us as we continue to iterate on our processes in this unprecedented space.
Opening Hachyderm Registrations
Yesterday I made the decision to temporarily close user registrations for the main site: hachyderm.io.
Today I am making the decision to re-open user registrations again for Hachyderm.
Reason for Closing
The primary reason for closing user registrations yesterday was related to the DDoS Security Threat that occurred the morning after our Leaving the Basement migration.
The primary vector that was leveraging Hachyderm infrastructure for perceived malicious use, was creating spam/bot accounts on our system. Out of extreme precaution, we closed signups for roughly 24 hours,
Reason for Opening
Today, Hachyderm does not have a targeted growth or capacity number in mind.
However, what we have observed is that user adoption as dropped substantially compared to November. In my opinion, I believe that we will see substantially less adoption in December than we did in November.
We will be watching closely to validate this hypothesis, and will leverage this announcement page as an official source of truth if our posture changes.
For now we have addressed some more detail on growth, registrations, and sustainability in our Growth and Sustainability blog.