XWiki Platform CVE-2025-58049

Requires the server-side PDF export feature to have been used (a PDF export job must have run and serialized its status to the permanent directory), AND the attacker must obtain read access to that permanent data directory or a backup of it - e.g. filesystem access on the XWiki host, an accessible/unencrypted backup, or post-compromise access. Because the encryption key (default data/configuration.properties) is stored alongside the cookie data, no separate key is needed. LIMITING FACTORS: this is not remotely exploitable over the network despite the NVD AV:N label - it depends on out-of-band access to server storage; impact is confined to disclosure of the credentials of users who triggered PDF exports; unaffected if instances are patched to 16.4.8/16.10.7/17.4.0-rc-1 or if data-directory backups are encrypted and access-controlled.

This is a credential-disclosure flaw (CWE-212, improper removal of sensitive information) where XWiki's server-side PDF export job persists the triggering user's cookies - including the encrypted username/password - unencrypted in the serialized job status inside the permanent data directory; because the encryption key lives in the same directory (data/configuration.properties), possession of the data directory (or a backup of it) yields the effective plaintext credentials. The published NVD vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N (7.5) is materially overstated relative to the actual attack: exploitation does NOT occur over the network by an unauthenticated remote attacker - it requires access to the server's filesystem/permanent directory or a data-directory backup, which is a local or post-compromise/insider condition, so a more honest vector is AV:L with elevated privileges. EPSS is very low (0.05%, 17th percentile) and there is no CISA KEV listing, consistent with a low-velocity, non-wormable secondary-impact bug. Input marks POC as publicly available, but the cited 'exploit' reference is the vendor Jira ticket XWIKI-23151 rather than turnkey weaponized exploit code, so treat exploitability as demonstrated-in-concept, not mass-exploitable. Net: a real and worth-patching data-hygiene/credential-exposure issue that amplifies the blast radius of any data-directory or backup compromise, but NOT an internet-facing critical - priority is moderate and mainly matters where backups are broadly accessible or the data directory is exposed.

An attacker who obtains a copy of the XWiki permanent data directory - for example an unencrypted or loosely-permissioned filesystem backup, a misconfigured share, or via a separate server compromise - reads the serialized PDF export job status files and extracts the stored user cookies. Because the encryption key resides in the same data directory, the attacker decrypts the embedded username/password cookie to recover the equivalent of the requesting user's plaintext credentials. The vendor Jira ticket (XWIKI-23151) publicly documents the issue, but the disclosure requires access to the data directory rather than a remote network request.