Documentum Webtop CVE-2025-3271

Exploitation requires a valid authenticated account in Documentum Webtop (PR:L per CVSS 4.0 vector) - unauthenticated external attackers cannot exploit this directly. A second prerequisite is active victim interaction: a target user must view or open the content containing the injected payload (UI:A). The attacker must have write access to a content field or feature within Webtop that is rendered to other users without output encoding. Exploitation is bounded to the victim's browser session - there is no server-side code execution component from this vulnerability alone. The attack is further limited to environments running Webtop versions prior to 16.7.1.

The CVSS 4.0 score of 4.8 (Medium) reflects meaningful but constrained risk. The PR:L metric confirms exploitation is limited to authenticated users, eliminating unauthenticated threat actors from the attack surface. The UI:A requirement means passive exploitation is not possible - a victim must actively interact with attacker-crafted content, further reducing automatable exploitation potential. Impact metrics VC:L/VI:L with no availability impact indicate the blast radius is bounded to the victim session rather than the underlying server. No public exploit code exists and the vulnerability is not listed in the CISA KEV catalog, placing this in the 'no public exploit identified at time of analysis' category. Real-world risk is moderate for organizations where Documentum users have varying privilege levels, as an attacker with minimal permissions could target higher-privileged content managers. The OpenText advisory (KB0869472) is restricted to authenticated support portal users, limiting independent verification of exploitation details.

An authenticated Documentum Webtop user with basic document-creation privileges injects a JavaScript payload into a document metadata field or comment that is later rendered without encoding. When a higher-privileged user (such as a document manager or administrator) opens or reviews the affected document, the script executes in their browser, capturing their session cookie and forwarding it to an attacker-controlled endpoint. No public proof-of-concept exists, but the attack pattern is consistent with well-understood stored XSS techniques.