The vulnerability lies in the XML export feature of XWiki, which can be triggered by appending ?xpage=xml to a document URL. The root cause is an incomplete redaction mechanism for sensitive data. The analysis of the patch commit 742ee3482ef6c2bd4ad03d0de9cdd81d0e8f3d59 reveals the core of the issue.
The primary vulnerable function is com.xpn.xwiki.api.Document.getXMLContent(). Its pre-patch implementation relied on regular expressions to find and replace the content of fields named password and email. This approach is flawed because XWiki allows creating properties of type 'Password' or 'Email' with arbitrary names. If a user created a password field named 'secret', its value would be exposed in the XML export.
The patch addresses this by introducing a more robust, type-based filtering system. A new property, excludedPropertyTypes, was added to DocumentInstanceInputProperties to carry a set of property types to be excluded from serialization. The getXMLContent function was refactored to use this new system, explicitly requesting the exclusion of 'Password' and 'Email' types.
The actual filtering logic was implemented in com.xpn.xwiki.internal.filter.input.BaseObjectEventGenerator.write(). This function, which is called during the XML serialization process, was modified to check each property's type against the excludedPropertyTypes list. If a match is found, the property is skipped, effectively preventing its inclusion in the final XML output.
Therefore, an exploit would involve a user with view rights accessing a crafted URL, which would invoke com.xpn.xwiki.api.Document.getXMLContent(). In a vulnerable version, this would lead to the serialization process, including the BaseObjectEventGenerator.write method, writing sensitive data to the output because the necessary type checks were absent.