XWiki Commons may allow privilege escalation to programming rights via user's first name

An attacker with only edit rights sets a short text property (e.g., their first name in their profile, or a field in an AWM application) to a value containing XWiki syntax such as `{{cache}}` and `{{groovy}}` macros [ref_id=2][ref_id=3]. When the property is rendered, the injected macros are executed with programming rights instead of being displayed as escaped text [ref_id=1]. This allows the attacker to run arbitrary Groovy or Velocity code, escalating from edit privileges to full programming rights [CWE-150].

The vulnerability resides in the short text property rendering logic within the `xwiki-commons-xml` module. The advisory [ref_id=2] identifies the package `org.xwiki.commons:xwiki-commons-xml` as the affected component. The Jira issues [ref_id=1] and [ref_id=3] show that the bug is triggered when short text fields (such as a user's first name or AWM application short text fields) are displayed without proper escaping.

The patch was released in versions 13.10.9, 14.4.4, and 14.7RC1 [ref_id=2]. The fix addresses the improper neutralization of escape sequences in short text properties, ensuring that user-supplied values are properly escaped before rendering so that XWiki syntax (such as `{{cache}}` and `{{groovy}}` macros) is displayed as literal text rather than being interpreted and executed. No patch diff is provided in the bundle, but the advisory [ref_id=2] states that upgrading or patching the `xwiki-commons-xml` JAR file resolves the issue.

1. Log in as a user without script rights. 2. Set your first name to `{{cache id="userProfile"}}{{groovy}}println("Hello from groovy!"){{/groovy}}{{/cache}}` [ref_id=3]. 3. Observe that the first name is rendered as "Hello from groovy!" instead of the escaped literal text, confirming code execution with programming rights [ref_id=2].