CVE-2026-116873 in Semantic MediaWikiinfo

Summary

by MITRE • 10/27/2026

Semantic MediaWiki from 7.3.0 before 7.3.1 contains a missing authorization vulnerability in the smwtask API module that allows unauthenticated attackers to run queued jobs and force store updates. Attackers can use the public anonymous CSRF token with run-joblist to execute arbitrary job types in unbounded counts, or invoke update on sysop-protected pages, leaking page titles and exhausting resources.

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Analysis

by VulDB Data Team • 10/27/2026

The vulnerability identified in Semantic MediaWiki versions prior to 7.3.1 represents a critical failure in access control mechanisms within the smwtask API module. This flaw allows unauthenticated attackers to bypass intended authorization checks, effectively granting them the ability to execute queued background jobs and force store updates without valid credentials or session validation. The root cause lies in the improper verification of user permissions when processing requests directed at this specific API endpoint, which should strictly require administrative privileges for certain operations but instead accepts input from anonymous users due to a logic error in the authentication flow.

From a technical perspective, the exploitation vector relies on the misuse of public anonymous CSRF tokens combined with the run-joblist parameter. Attackers can leverage these tokens to submit arbitrary job types in unbounded quantities, leading to severe resource exhaustion and potential denial of service conditions for the target system. Furthermore, by invoking update operations on pages that are typically protected under sysop-level permissions, attackers can trigger actions that were not intended for public access. This capability allows them to force store updates even on restricted content, bypassing standard page protection mechanisms designed to prevent unauthorized modifications or information disclosure.

The operational impact of this vulnerability is significant, encompassing both availability and confidentiality risks. The ability to execute arbitrary jobs in unbounded counts can rapidly deplete server resources such as CPU cycles, memory, and database connections, potentially rendering the wiki service unavailable to legitimate users. Additionally, the forced updates on protected pages enable information leakage by exposing page titles that would otherwise remain hidden from anonymous visitors. This disclosure of internal structure or sensitive content metadata aids attackers in further reconnaissance efforts, facilitating more targeted attacks against the organization hosting the Semantic MediaWiki instance.

This issue aligns with CWE-284 Improper Access Control and CWE-798 Use of Hard-coded Credentials if applicable to token handling, though primarily it reflects a failure in enforcing authorization policies as described by CWE-862 Missing Authorization. In terms of offensive security frameworks, the exploitation technique corresponds to ATT&CK T1053 Scheduled Task/Job which involves executing system-level or application-level tasks without proper authentication, and potentially T1074 Data Staged if used for exfiltration preparation through resource exhaustion leading to crash dumps or logs exposure.

Mitigation strategies must prioritize immediate patching of the Semantic MediaWiki installation to version 7.3.1 or later where these authorization checks have been corrected. Administrators should also implement web application firewalls that monitor API endpoints for unusual patterns such as high-frequency job submissions from single IP addresses, which can indicate an ongoing exploitation attempt. Additionally, reviewing and tightening CSRF token policies ensures that anonymous tokens are not misused for privileged operations. Regular audits of access control lists and permission settings across all API modules will help prevent similar vulnerabilities in the future by ensuring strict adherence to the principle of least privilege.

Responsible

VulnCheck

Reservation

10/27/2026

Disclosure

10/27/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

low

Sources

Do you want to use VulDB in your project?

Use the official API to access entries easily!