CVE-2026-116878 in Semantic MediaWiki
Summary
by MITRE • 10/27/2026
Semantic MediaWiki from 2.5.0 before 7.3.1 contains an uncontrolled resource consumption vulnerability that allows anonymous attackers to force quadratic computation by supplying a zero limit to Special:PropertyLabelSimilarity. Attackers can send repeated requests with limit=0 to bypass the SQL LIMIT and trigger pairwise similar_text() comparisons, exhausting PHP CPU, memory, and database connections.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/27/2026
The vulnerability identified in Semantic MediaWiki versions ranging from 2.5.0 up to but not including 7.3.1 represents a critical uncontrolled resource consumption flaw within the application's property label similarity functionality. This specific weakness is located in the Special:PropertyLabelSimilarity endpoint, which is designed to find similar labels for properties used in semantic data structuring. The core technical issue stems from an improper validation of input parameters, specifically regarding how the limit parameter is processed by the backend logic. When a user supplies a value of zero or fails to provide a valid positive integer for this limit, the application fails to enforce standard pagination constraints that would normally cap the number of database records retrieved and subsequently compared. This lack of boundary enforcement allows an attacker to manipulate the query execution path into performing significantly more computational work than intended by the system architecture.
From a technical perspective, the flaw exploits the interaction between PHP's string comparison functions and SQL query construction. When the limit is set to zero or omitted in certain contexts, the application bypasses the SQL LIMIT clause that restricts the result set size. Consequently, the backend proceeds to execute pairwise comparisons using the similar_text() function across all available property labels rather than a restricted subset. The similar_text() algorithm has quadratic time complexity relative to the length of the strings being compared and the number of pairs generated. As the dataset grows or as multiple requests are processed in parallel, this results in an exponential increase in CPU cycles and memory allocation required for each request. This behavior transforms what should be a lightweight lookup operation into a heavy computational burden that scales poorly with input size and concurrency levels.
The operational impact of this vulnerability is severe, primarily manifesting as a Denial of Service condition against the hosting infrastructure. Because the attack can be executed by anonymous users without requiring authentication, it presents a low-barrier vector for malicious actors seeking to disrupt service availability. By sending repeated requests with the manipulated limit parameter, attackers can exhaust available PHP CPU resources and memory pools on the web server. Furthermore, each comparison operation typically involves database interactions that consume connection slots in the backend DBMS. A sustained attack can lead to resource exhaustion across all three layers: application logic, runtime environment, and data storage. This results in service degradation for legitimate users, potential crashes of PHP-FPM workers or Apache/Nginx processes, and eventual unavailability of the wiki instance until resources are reclaimed or services restarted.
This vulnerability aligns with CWE-400, which classifies issues related to Uncontrolled Resource Consumption, specifically highlighting scenarios where an attacker can cause a system to consume excessive amounts of CPU, memory, or disk space through crafted inputs. In terms of offensive security frameworks, this behavior is consistent with ATT&CK technique T1496, Resource Hijacking, although in this context it serves primarily as a denial-of-service vector rather than for cryptomining purposes. The lack of input validation on the limit parameter also reflects CWE-20 Improper Input Validation, indicating that the application did not adequately sanitize or restrict user-supplied data before processing it within critical logic paths.
Mitigation strategies must focus on immediate patching and defensive configuration adjustments. Organizations running affected versions should upgrade to Semantic MediaWiki version 7.3.1 or later, where this input validation issue has been resolved by enforcing strict integer constraints on the limit parameter regardless of user input. For environments that cannot be patched immediately due to operational dependencies, temporary mitigations include implementing web application firewall rules to block requests containing specific query string patterns associated with the exploit vector, such as those targeting Special:PropertyLabelSimilarity with a zero or null limit value. Additionally, configuring rate limiting on anonymous endpoints can help mitigate the impact of repeated automated attacks by throttling request frequency before they accumulate sufficient resource consumption to cause harm. Monitoring server metrics for unusual spikes in CPU usage correlated with wiki API calls should also be established to detect ongoing exploitation attempts early.