CVE-2026-23963 in Mastodon
Summary
by MITRE • 01/22/2026
Mastodon is a free, open-source social network server based on ActivityPub. Prior to versions 4.5.5, 4.4.12, and 4.3.18, the server does not enforce a maximum length for the names of lists or filters, or for filter keywords, allowing any user to set an arbitrarily long string as the name or keyword. Any local user can abuse the list or filter fields to cause disproportionate storage and computing resource usage. They can additionally cause their own web interface to be unusable, although they must intentionally do this to themselves or unknowingly approve a malicious API client. Mastodon versions v4.5.5, v4.4.12, v4.3.18 are patched.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 02/03/2026
The vulnerability described in CVE-2026-23963 represents a resource exhaustion issue within the Mastodon social network server implementation that affects multiple versions prior to the security patches released in v4.5.5, v4.4.12, and v4.3.18. This flaw resides in the server's handling of user-defined list and filter configurations, specifically lacking proper input validation for the maximum length of names and keywords. The issue stems from the absence of length constraints on user-controllable fields that are stored in the database and processed by the server's backend systems. When users create lists or filters with excessively long strings, the server stores these values without limitation, leading to potential abuse scenarios that can consume disproportionate system resources.
The technical nature of this vulnerability aligns with CWE-770, which describes allocation of resources without limits or appropriate bounds, and CWE-1321, which covers improper restriction of excessive authentication attempts. Attackers can exploit this weakness by creating lists or filters with extremely long strings that consume excessive memory and processing time during server operations. The impact extends beyond simple resource consumption to potentially rendering the web interface unusable for the malicious user, as the excessive data processing can cause performance degradation that affects the user's own experience. This creates a scenario where users can inadvertently or deliberately cause denial of service conditions for themselves, though the primary concern lies in the potential for resource exhaustion that could affect other users on the same server instance.
The operational impact of this vulnerability manifests in several ways that can compromise system stability and performance. When users create lists or filters with arbitrarily long strings, the server must store these values in its database and process them during various operations such as rendering user interfaces, performing searches, or handling API requests. The lack of length restrictions means that storage space can be consumed rapidly, and processing time can increase exponentially with string length, potentially leading to timeouts and service disruptions. Additionally, the web interface may become unresponsive or slow to respond as the server struggles to handle these oversized data structures, particularly when the interface attempts to display or process these maliciously long list or filter names. The vulnerability also creates opportunities for attackers to craft malicious API clients that can systematically abuse this weakness, potentially affecting multiple users or server resources simultaneously.
Mitigation strategies for this vulnerability should focus on implementing proper input validation and length restrictions for user-controllable fields. Server administrators should immediately upgrade to the patched versions v4.5.5, v4.4.12, or v4.3.18, depending on their current installation. The patched versions implement maximum length constraints for list names and filter keywords, preventing the storage and processing of excessively long strings. Organizations should also consider implementing additional monitoring and alerting for unusual resource consumption patterns that might indicate abuse of this vulnerability. The ATT&CK framework categorizes this type of vulnerability under T1499, which covers resource exhaustion attacks, and T1078, which covers valid accounts, as the vulnerability can be exploited through legitimate user accounts. Security teams should also consider implementing rate limiting and resource usage monitoring to detect and prevent abuse of this vulnerability in environments where immediate patching is not possible.