CVE-2026-78738 in Silverpeas
Summary
by MITRE • 09/09/2026
Silverpeas Core 6.4.6 is vulnerable to Cross Site Scripting (XSS) via the Document management file upload feature.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/09/2026
The vulnerability identified in Silverpeas Core version 6.4.6 represents a significant security flaw within its document management subsystem, specifically affecting the file upload functionality. This issue manifests as a Stored Cross-Site Scripting (XSS) attack vector, which is particularly dangerous because it allows an attacker to inject malicious client-side scripts into web pages viewed by other users rather than just targeting the immediate user interacting with the vulnerable input field. The root cause lies in insufficient sanitization and validation of file metadata or associated content during the upload process. When a user uploads a document, the system processes various attributes such as filenames, descriptions, or embedded properties without adequately filtering out executable script tags or event handlers that could be interpreted by the browser's rendering engine.
From a technical perspective, this flaw aligns with CWE-79, which categorizes improper neutralization of input during web page generation. The application fails to properly encode special characters within user-supplied data before storing it in the backend database and subsequently displaying it on subsequent pages. Consequently, when an administrator or another authorized user accesses a document list or view that includes the compromised file's metadata, the browser executes the injected script in their context. This execution occurs with the privileges of the authenticated session, allowing the malicious code to interact directly with the application’s Document Object Model and potentially perform actions on behalf of the victim without their knowledge or consent.
The operational impact of this vulnerability is severe due to its stored nature. Unlike reflected XSS, which requires tricking a user into clicking a specially crafted link, stored XSS persists in the system's data store. This means that every time any authorized user views the affected document information, they are exposed to the attack payload. Attackers can exploit this to steal session cookies or authentication tokens, hijack active sessions, perform unauthorized actions such as deleting documents or modifying settings, and phish credentials by presenting fake login forms within the application interface. In an enterprise environment where Silverpeas is used for content management, this could lead to a complete compromise of user accounts and potentially serve as a pivot point for further network intrusion if internal systems are accessible from the web application context.
This vulnerability maps directly to MITRE ATT&CK technique T1059.007, which covers JavaScript execution in browser-based attacks. The attack chain typically involves an attacker uploading a file with malicious metadata, waiting for a victim user to view the document list or details page, and then executing arbitrary code within that trusted context. This behavior is consistent with common patterns observed in web application vulnerabilities where input validation is either absent or incorrectly implemented during both storage and retrieval phases of data handling.
Mitigation strategies should focus on implementing robust input validation and output encoding mechanisms. Developers must ensure that all user-supplied inputs, especially those related to file uploads such as filenames and descriptions, are strictly validated against a whitelist of allowed characters before being stored in the database. Furthermore, when rendering this data back to the client side, it is critical to apply context-sensitive HTML entity encoding to prevent any script tags from being interpreted by the browser. Upgrading to a patched version of Silverpeas Core that addresses these validation gaps is the primary remediation step. Additionally, implementing Content Security Policy headers can provide an additional layer of defense by restricting the sources from which scripts are allowed to execute, thereby mitigating the impact even if some injection attempts succeed temporarily until a full patch is deployed.