CVE-2022-36094 is a cross-site scripting (XSS) vulnerability affecting the XWiki Platform, a widely used generic wiki platform. The vulnerability exists in the Web Parent POM component of the platform, specifically in the handling of attachment history views. Versions from 1.0 up to but not including 13.10.6, and from 14.0 up to but not including 14.3-rc-1, are affected. The issue arises because the platform improperly neutralizes input during web page generation, allowing an attacker to store malicious JavaScript code within an attachment's name that contains JavaScript. When a user views the history of such an attachment, the stored script executes in their browser context. This vulnerability is classified under CWE-79 (Improper Neutralization of Input During Web Page Generation) and CWE-80 (Improper Neutralization of Script-Related HTML Tags in a Web Page). The attack vector requires the attacker to have the ability to upload or rename attachments to include malicious JavaScript code. The vulnerability does not require user authentication to trigger the script execution, but the attacker must have sufficient privileges to upload or rename attachments. The issue can be mitigated by updating to patched versions 13.10.6 or 14.3-rc-1 or by replacing the vulnerable template file 'viewattachrev.vm' with a patched version. No known exploits have been reported in the wild as of the publication date, but the vulnerability poses a risk of session hijacking, credential theft, or other malicious actions performed in the context of the victim's browser session when viewing attachment histories.

For European organizations using XWiki Platform, this vulnerability could lead to significant security risks including unauthorized access to sensitive information, session hijacking, and potential lateral movement within internal networks. Since XWiki is often used for internal documentation and collaboration, exploitation could compromise confidential corporate data, intellectual property, or internal communications. The attack could also facilitate phishing or social engineering campaigns by injecting malicious scripts that alter displayed content or capture user inputs. The impact is heightened in sectors with strict data protection requirements such as finance, healthcare, and government institutions. Additionally, compromised user sessions could lead to further exploitation of internal systems. The vulnerability affects availability indirectly by potentially causing users to lose trust in the platform or by triggering administrative lock-downs. Given the medium severity and the requirement for an attacker to upload or rename attachments, the risk is moderate but non-negligible, especially in environments with lax access controls or insufficient monitoring.

1. Immediate patching: Upgrade XWiki Platform installations to version 13.10.6 or later, or 14.3-rc-1 or later, to apply the official fix. 2. Temporary workaround: Replace the vulnerable 'viewattachrev.vm' template with the patched version from the vendor if immediate upgrade is not feasible. 3. Access control hardening: Restrict permissions to upload or rename attachments only to trusted users to reduce the attack surface. 4. Input validation and sanitization: Implement additional server-side validation to sanitize attachment names and prevent script injection. 5. Monitoring and logging: Enable detailed logging of attachment uploads and history views to detect suspicious activities. 6. User awareness: Educate users about the risks of viewing untrusted attachment histories and encourage reporting of unusual behavior. 7. Web application firewall (WAF): Deploy or update WAF rules to detect and block malicious script payloads targeting the attachment history functionality. 8. Regular security assessments: Conduct periodic code reviews and penetration testing focused on XWiki customizations and integrations to identify residual or new vulnerabilities.