EUVD-2025-210935
GHSA-26vp-8gxg-v4pg
Severity by source
AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
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.
Primary rating from Vendor (https://github.com/xwiki/xwiki-rendering).
CVSS VectorVendor: https://github.com/xwiki/xwiki-rendering
Lifecycle Timeline
4DescriptionCVE.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
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.
Wazuh SIEM platform versions 4.4.0 through 4.9.0 contain an unsafe deserialization vulnerability in the DistributedAPI t
BentoML version 1.4.2 and earlier contains an unauthenticated remote code execution vulnerability through insecure deser
pgAdmin 4 contains critical remote code execution vulnerabilities in the Query Tool download and Cloud Deployment endpoi
The renderLocalView function in render/views.py in graphite-web in Graphite 0.9.5 through 0.9.10 uses the pickle Python
BentoML is a Python library for building online serving systems optimized for AI apps and model inference. Rated critica
OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph
pyLoad download manager version prior to 0.5.0b3.dev77 exposes the Flask SECRET_KEY through an unauthenticated endpoint.
Langflow (a visual LLM pipeline builder) contains a critical unauthenticated code execution vulnerability (CVE-2026-3301
In Mercurial before 4.1.3, "hg serve --stdio" allows remote authenticated users to launch the Python debugger, and conse
Unauthenticated remote code execution affects Kestra OSS (the open-source event-driven orchestration platform) prior to
Unauthenticated remote code execution in Marimo ≤0.20.4 allows attackers to execute arbitrary system commands via the `/
pyLoad is the free and open-source Download Manager written in pure Python. Rated medium severity (CVSS 5.3), this vulne
Same weakness CWE-95 – Eval Injection
View allShare
External POC / Exploit Code
Leaving vuln.today