CVE-2026-116208 in YesWiki
Summary
by MITRE • 10/25/2026
YesWiki from 4.6.2 before 4.7.0 contains a missing authorization vulnerability in ActivityPubService::syncActorPosts that lets malicious ActivityPub servers manipulate other actors' mirrored entries. Attackers can serve a poisoned outbox with cross-actor Delete, Update, or Create activities during admin-initiated sync to delete, overwrite, forge, or mass-delete entries.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/25/2026
The vulnerability identified in YesWiki versions prior to 4.7.0 represents a critical failure in access control mechanisms within the ActivityPub integration layer. Specifically, the flaw resides in the ActivityPubService::syncActorPosts function, which is responsible for synchronizing content from external federated social networks into the local wiki instance. This component acts as an intermediary that fetches and processes posts from remote actors to maintain a mirrored view of their activity within the YesWiki environment. The core technical deficiency is a missing authorization check during this synchronization process, allowing any ActivityPub server to inject malicious activities that affect users other than the one initiating or being synchronized with. This breaks the fundamental principle of identity isolation in federated systems, where actions should be strictly bound to the authenticated actor's scope.
From a technical perspective, an attacker can exploit this flaw by hosting a rogue ActivityPub server configured as a poisoned outbox. During an admin-initiated sync operation, which is typically used to refresh or import content from trusted sources, the vulnerable function processes incoming activities without verifying whether those actions are authorized for the target local user. Consequently, malicious actors can serve specially crafted JSON-LD payloads containing Delete, Update, or Create activities that reference other users' entries rather than their own. This allows the attacker to perform unauthorized deletions of existing wiki pages, overwrite legitimate content with forged material, or create new entries under another user's identity. The exploitation relies on the trust relationship established during synchronization, where the system assumes incoming data is benign and properly scoped.
The operational impact of this vulnerability is severe due to its potential for widespread data integrity compromise and denial of service. By leveraging cross-actor manipulation, an attacker can mass-delete critical wiki entries, effectively destroying organizational knowledge or historical records without authentication as those users. Alternatively, the ability to forge content enables sophisticated social engineering attacks where malicious actors impersonate legitimate contributors by posting deceptive information under their names. This undermines trust in the platform's authenticity and could lead to significant reputational damage for affected organizations. Furthermore, if sensitive administrative pages are targeted, it may disrupt workflow continuity or expose confidential information through unauthorized modifications.
This vulnerability aligns with CWE-269, which describes Improper Privilege Assignment, as well as CWE-862, Missing Authorization, highlighting the failure to enforce proper access controls on critical functions. In terms of offensive security frameworks, this behavior corresponds to MITRE ATT&CK technique T1530, Data from Information Repositories, where adversaries exfiltrate or manipulate data stored in repositories like wikis and databases. It also touches upon T1498, Network Denial of Service, if the primary intent is mass deletion leading to service disruption. The attack vector involves remote network interaction via HTTP/HTTPS requests directed at the ActivityPub endpoints, making it accessible over standard web infrastructure without requiring local access or prior compromise of user credentials beyond initial synchronization triggers.
Mitigation strategies must focus on immediate patching and enhanced input validation. Organizations running YesWiki versions from 4.6.2 up to but not including 4.7.0 should upgrade immediately to version 4.7.0, where this authorization check has been implemented in the syncActorPosts method. Until upgrading is feasible, administrators can mitigate risk by disabling automatic synchronization features or restricting ActivityPub integrations to only known and trusted domains through strict allowlisting mechanisms. Additionally, implementing rigorous validation of incoming JSON-LD payloads to ensure that actor IDs match expected scopes before processing Delete, Update, or Create operations would provide a defensive layer against such manipulation. Regular audits of synchronized content and monitoring for anomalous deletion patterns can also help detect potential exploitation attempts early in the attack lifecycle.