CVE-2025-32960 is a cross-site scripting (XSS) vulnerability classified under CWE-79, affecting the CUBA Platform's REST API add-on versions prior to 7.2.7. The vulnerability arises from improper neutralization of input during web page generation. Specifically, the REST API accepts an input parameter representing a file path and name. If the file name ends with the '.html' extension, the REST API responds with a Content-Type header set to 'text/html'. This behavior allows an attacker to upload a malicious HTML file containing JavaScript code. When the vulnerable API serves this file, the browser interprets it as an HTML document and executes the embedded JavaScript code, leading to an XSS attack. Successful exploitation requires the attacker to first upload a malicious file to the system, which implies some level of prior access or interaction with the application. The vulnerability was addressed and patched in version 7.2.7 of the CUBA REST API add-on. Until patching, a workaround is available as documented by Jmix, the framework related to CUBA Platform. No known exploits have been reported in the wild as of the publication date (April 22, 2025). The vulnerability primarily impacts confidentiality and integrity by enabling script execution in the context of the victim's browser, potentially allowing session hijacking, data theft, or unauthorized actions on behalf of the user. The attack vector requires user interaction (e.g., visiting a maliciously crafted URL or resource), and the attacker must have the capability to upload files to the system, which may limit the scope of exploitation to environments where such uploads are permitted or insufficiently controlled.

For European organizations using the CUBA Platform REST API add-on versions prior to 7.2.7, this vulnerability poses a moderate security risk. Exploitation could lead to unauthorized script execution in users' browsers, potentially resulting in session hijacking, theft of sensitive information, or unauthorized operations within web applications relying on the REST API. This is particularly concerning for organizations handling sensitive personal data or critical business processes, as it could facilitate data breaches or compromise user trust. The requirement for prior file upload limits the attack surface but does not eliminate risk, especially in environments where user-generated content or file uploads are common and not strictly validated. Industries such as finance, healthcare, and government services in Europe, which often use enterprise-grade platforms like CUBA, may face increased risk due to the sensitivity of their data and regulatory requirements (e.g., GDPR). Additionally, the vulnerability could be leveraged in targeted attacks against web applications that integrate this REST API, potentially impacting availability if exploited to inject disruptive scripts. However, the absence of known exploits in the wild and the availability of patches and workarounds reduce immediate risk if organizations act promptly.

1. Immediate upgrade to CUBA Platform REST API add-on version 7.2.7 or later to apply the official patch addressing this vulnerability. 2. Implement strict file upload validation controls to restrict allowed file types and sanitize file names, preventing malicious HTML or script files from being uploaded. 3. Employ Content Security Policy (CSP) headers to restrict the execution of unauthorized scripts in browsers, mitigating the impact of any potential XSS payloads. 4. Review and harden access controls around file upload functionalities to ensure only authenticated and authorized users can upload content. 5. Monitor web application logs for unusual file upload activities or access patterns to detect potential exploitation attempts. 6. Educate developers and administrators on secure coding practices related to input validation and output encoding, especially when handling user-supplied data in web responses. 7. Utilize web application firewalls (WAFs) configured to detect and block common XSS attack patterns targeting the REST API endpoints. 8. Apply the documented workaround from the Jmix documentation if immediate patching is not feasible, ensuring temporary risk reduction.