CVE-2026-111912 in Admidio
Summary
by MITRE • 10/17/2026
Admidio from 5.0.0 before 5.0.16 contains an insecure direct object reference vulnerability in ForumService::saveTopic() that allows authenticated members to modify other users' forum topics. Attackers can replace the topic_uuid parameter in their own topic_save request, reusing their CSRF token, to overwrite the victim topic's title and first post.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/17/2026
The identified vulnerability represents a critical failure in access control mechanisms within Admidio versions 5.0.0 through 5.0.15, specifically located in the ForumService::saveTopic() function. This flaw is classified as an Insecure Direct Object Reference (IDOR), which corresponds to CWE-639 in the Common Weakness Enumeration standard. The core issue stems from insufficient server-side validation of object identifiers during state-changing operations. While the application correctly authenticates users and validates their session tokens, it fails to verify that the authenticated user possesses ownership or administrative privileges over the specific forum topic identified by the provided UUID. This architectural oversight allows any logged-in member to interact with resources belonging to other users without authorization, fundamentally breaking the principle of least privilege and proper object-level access control.
The technical exploitation mechanism relies on manipulating the topic_uuid parameter within HTTP requests directed at the saveTopic endpoint. An attacker who has successfully authenticated into the system can capture a valid Cross-Site Request Forgery (CSRF) token associated with their own session. By constructing a malicious request that targets this CSRF token but substitutes the target resource identifier, the attacker can overwrite arbitrary forum topics. Specifically, the vulnerability permits the modification of critical fields such as the topic title and the content of the first post within another user's thread. The reuse of the victim’s or attacker’s own valid CSRF token bypasses anti-CSRF protections because the server validates the token against the session rather than checking if the action is authorized for that specific resource, highlighting a common misconfiguration where integrity checks are decoupled from authorization logic.
The operational impact of this vulnerability extends beyond simple data modification to include potential reputational damage and content poisoning within community-driven platforms. Since forum topics often serve as primary communication channels in Admidio deployments, an attacker can deface public discussions by altering titles or injecting malicious text into the initial post. This capability facilitates phishing campaigns if the modified first post contains links to external malicious sites, thereby leveraging the trust users place in established community threads. Furthermore, the ability to silently overwrite content disrupts information integrity and audit trails, making it difficult for administrators to track unauthorized changes without detailed logging mechanisms that may not be enabled by default. The persistence of this flaw across multiple minor versions indicates a systemic gap in regression testing regarding access control validation for user-generated content endpoints.
To mitigate this vulnerability, immediate action is required to upgrade the Admidio installation to version 5.0.16 or later, where these checks have been rectified. For environments that cannot be immediately patched, administrators should implement strict server-side authorization logic in custom modules if applicable, ensuring that every write operation verifies ownership of the target object against the current user’s identity. Additionally, enhancing CSRF protection by binding tokens to specific resource IDs rather than just session validity can provide a layer of defense-in-depth. Regular security audits focusing on IDOR patterns and comprehensive unit testing for access control scenarios are recommended to prevent similar flaws in future development cycles. Monitoring logs for anomalous modification patterns involving topic UUIDs outside the requester’s ownership can also aid in early detection of exploitation attempts.