The analysis of the security patch (commit 74f6de68da1572c1d7e9c6e30e9f77f7c5596b1b) reveals two main categories of vulnerabilities related to Cross-Site Scripting (XSS).
First, the core token replacement system in DNN Platform was insecure by design. The various TokenReplace classes did not encode the output of the tokens by default. The patch addresses this by introducing a new method, AddPropertySource, in BaseCustomTokenReplace.cs. This method wraps property sources with encoding handlers (HTML, URL, JavaScript), making HTML encoding the new default. Previously, property sources were added directly to a dictionary, returning raw, unencoded values. This design flaw meant any module or skin using tokens with user-supplied input (e.g., from a URL via RequestPropertyAccess) was likely vulnerable to reflected XSS. The vulnerable functions identified are the constructors of the various TokenReplace classes, as this is where the insecure, non-encoding property sources were configured.
Second, the patch fixed several instances of manual HTML construction without proper output encoding in the JournalParser.cs component. Methods like GetList, GetLikeListHTML, and GetCommentRow were concatenating strings to build HTML, directly embedding data like user names, display names, and URLs without sanitization. The patch rectifies this by consistently applying WebUtility.HtmlEncode to all dynamic data before it is embedded in the HTML output.
The root cause of the vulnerability was a failure to consistently apply output encoding for user-controllable data, both in the centralized token replacement system and in manual HTML string building. An attacker could exploit this by crafting a URL with malicious JavaScript in a parameter that gets processed by a token, or by setting a malicious value (like a display name) that is later rendered unencoded on a page.