What is the CVSS score of EUVD-2025-210935?

EUVD-2025-210935 has a CVSS 3.1 base score of 9.9 (Critical). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H.

Which versions of XWiki Rendering are affected by EUVD-2025-210935?

XWiki Rendering (xwiki-rendering-xml) contains a critical vulnerability that enables any authenticated user with basic editing privileges to take full control of the wiki and read or modify all…. A patch is available.

Is there a public PoC exploit available for EUVD-2025-210935?

Yes, a public proof-of-concept exploit is available for EUVD-2025-210935. Prioritise patching immediately.

How to fix or mitigate EUVD-2025-210935?

Within 24 hours, inventory all XWiki deployments using the xwiki-rendering-xml module and apply the vendor-released patch: 14.10.2 (or later) to every affected instance; if immediate patching is not possible, restrict wiki editing rights to trusted administrators and isolate the service from untrusted networks. Within 7 days, verify patch deployment across all instances, review authentication and edit logs for anomalous Groovy or Python macro execution or unauthorized content changes, and enforce least privilege so only necessary users can edit profiles or documents. Within 30 days, complete a full upgrade of dependent XWiki components, re-test the affected extension points, and establish ongoing monitoring for vendor advisories and suspicious rendering activity.

XWiki Rendering EUVD-2025-210935

| CVE-2025-53837 CRITICAL

Eval Injection (CWE-95)

2026-09-18 https://github.com/xwiki/xwiki-rendering

GHSA-26vp-8gxg-v4pg

RCE Python Java Code Injection

9.9

CVSS 3.1 · Vendor: https://github.com/xwiki/xwiki-rendering

Severity by source

Vendor (https://github.com/xwiki/xwiki-rendering) PRIMARY

9.9 CRITICAL

AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

vuln.today AI

9.9 CRITICAL

Remote, low-complexity attack needing only a low-privilege account that can edit a profile (PR:L); injected macros run with programming rights, escaping the rendering sandbox (S:C) for full C/I/A compromise.

3.1 AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

Primary rating from Vendor (https://github.com/xwiki/xwiki-rendering).

CVSS VectorVendor: https://github.com/xwiki/xwiki-rendering

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Changed

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Metadata Corrected

Sep 18, 2026 - 15:40 vuln.today

tag: Java added

Metadata Corrected

Sep 18, 2026 - 15:40 vuln.today

tag: Atlassian removed

Analysis Generated

Sep 18, 2026 - 15:30 vuln.today

CVE Published

Sep 18, 2026 - 15:05 github-advisory

CRITICAL 9.9

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

17 maven packages depend on org.xwiki.rendering:xwiki-rendering-xml (4 direct, 13 indirect)

Ecosystem-wide dependent count for version 14.10.2.

DescriptionCVE.org

Impact

Any user who can edit their own user profile or any other document can execute arbitrary script macros including Groovy and Python macros that allow remote code execution including unrestricted read and write access to all wiki contents. The reason is that rendering output is included as content of HTML macros without further escaping and it is thus possible to close the HTML macro and inject script macros that are executed with programming rights.

This can be demonstrated by adding an object of type XWiki.UIExtensionClass to a document with content {{html wiki="true"}}~{~{~/~h~t~m~l~}~}~ ~{~{~c~a~c~h~e~}~}~{~{~g~r~o~o~v~y~}~}~p~r~i~n~t~l~n~(~1~)~{~{~/~g~r~o~o~v~y~}~}~{~{~/~c~a~c~h~e~}~}{{/html}}, extension point id org.xwiki.platform.html.head, extension id org.xwiki.myuser.test and extension scope "current user". When opening <xwiki-server>/xwiki/bin/view/Main/?sheet=CKEditor.ContentSheet&xpage=plain where <xwiki-server> is the URL of the XWiki installation, the output should start with {{/html}} {{cache}}{{groovy}}println(1){{/groovy}}{{/cache}} and not with 1</p>.

This escaping was always missing at least in XWiki syntax version 2, it is definitely exploitable in XWiki 3.3 Milestone 1 via the user profile (not through extension points), though this has also been fixed by a separate patch, see the advisory. Exploitable extension points include org.xwiki.platform.search.ui.docdoesnotexist which has been added in XWiki 8.3 Milestone 1.

Patches

This has been patched in XWiki 14.10.2 and 15.0 RC1 by making sure that rendering output cannot close the surrounding HTML macro.

Workarounds

It is in principle possible to add escaping to all places where rendering output is used in wiki documents but at the moment there is no list of them.

For more information

If you have any questions or comments about this advisory:

Open an issue in Jira XWiki.org
Email us at [Security Mailing List](mailto:security@xwiki.org)

Articles & Coverage 2

News 20 New Java Vulnerabilities - 5 Critical, 15 High, 2 With POC Sep 19, 2026 News Critical Code Injection in XWiki Rendering XML Module - CVE-2025-53837 Sep 19, 2026

AnalysisAI

Authenticated code injection in XWiki Rendering (the xwiki-rendering-xml module, versions before 14.10.2) lets any user who can edit their own user profile - or any other document - close the surrounding HTML macro and inject Groovy or Python script macros that execute with programming rights, granting remote code execution and unrestricted read/write access to all wiki contents. Exploitation requires only a low-privilege, authenticated account (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, severity 9.9) and needs no victim interaction beyond the affected page being rendered; the attacker reaches the flaw through rendered output that is embedded in an HTML macro without escaping, with exploitable sinks including the user profile (since XWiki syntax 2.0, demonstrably exploitable from XWiki 3.3 Milestone 1) and the extension point org.xwiki.platform.search.ui.docdoesnotexist (added in XWiki 8.3 Milestone 1). No confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis, though the vendor advisory documents a detailed reproduction payload and the scope change (S:C) combined with high confidentiality, integrity and availability impact makes this a genuine high-priority issue; vendors have released the fix in XWiki 14.10.2 and 15.0 RC1.

Technical ContextAI

The flaw is a CWE-95 (Improper Neutralization of Directives in Dynamically Evaluated Code / Eval Injection) defect in XWiki's rendering pipeline. XWiki syntax 2.0 allows raw rendering output to be placed as the content of an HTML macro; the XHTML printer class org.xwiki.rendering.renderer.printer.XHTMLWikiPrinter passed that raw text through to printRaw() without neutralizing the XWiki macro closing token. Because the surrounding document is re-parsed as wiki syntax, an attacker who can store content (for example an object of type XWiki.UIExtensionClass) can emit the literal sequence {{/html}} to terminate the enclosing HTML macro early and then open new macros. The commit 92bc8095ed3acce15ab200c8525e1623b4898be5 fixes this by escaping the full {{/html}} sequence as {{/html}} inside printRaw(), and additionally by detecting and escaping any trailing prefix of {{/html}} (the characters {, /, h, t, m, l, }, }) so that a string split across multiple render calls cannot be recombined into the full closing token - a defensive check the patch author notes may be applied even where the escaping is not contextually ideal, such as JSON output and HTML comments. The impact is compounded by XWiki's script macro model: {{groovy}} and {{python}} macros execute with the rights of the document's author, so injected macros run with programming rights regardless of the attacker's own privileges. Detection is difficult because the injected content looks like ordinary wiki markup, and the extension-point sinks (for example org.xwiki.platform.html.head and org.xwiki.platform.search.ui.docdoesnotexist) are reached through user-controlled extension data rather than obvious page bodies.

RemediationAI

Upgrade the rendering module and the XWiki Platform distribution to the patched releases: XWiki 14.10.2 or 15.0 RC1 (artifact org.xwiki.rendering:xwiki-rendering-xml 14.10.2), which prevent rendering output from closing the surrounding HTML macro via the escaping logic added in commit 92bc8095ed3acce15ab200c8525e1623b4898be5; full details are in the advisory at https://github.com/xwiki/xwiki-rendering/security/advisories/GHSA-26vp-8gxg-v4pg and the release notes at https://github.com/xwiki/xwiki-rendering/releases/tag/xwiki-rendering-14.10.2 and https://github.com/xwiki/xwiki-rendering/releases/tag/xwiki-rendering-15.0-rc-1. Note that vendor-released patch status is confirmed, but no supported workaround exists: the advisory states that escaping could in principle be added at every place where rendering output is used in wiki documents, yet there is no inventory of those locations, so manual hardening is incomplete by design. If immediate upgrading is impossible, compensate by tightening the prerequisite that makes this exploitable - restrict document and profile edit rights to trusted users, disable open self-registration so no low-privilege account can be created, remove programming rights from non-administrative authors, and disable or restrict Groovy and Python script macros (the execution surface the injection targets) - accepting the trade-off that these measures break legitimate wiki scripting, custom extensions and self-service profile editing, and that any residual user able to edit a document that flows into an HTML macro (including extension points such as org.xwiki.platform.search.ui.docdoesnotexist) can still trigger the flaw. Because exploitation yields full read/write access to wiki contents, treat any pre-patch instance with untrusted editors as potentially compromised and review recently created objects (for example XWiki.UIExtensionClass instances) and rendered output for injected {{/html}} or script-macro sequences.