The Invisible Minefield: Weaponizing CSS in XWiki Comments

Enterprise wikis are the digital equivalent of a company's collective brain. They hold documentation, secrets, and the inherent trust of every employee who logs in. When you visit your internal XWiki instance, you don't expect to be navigating a minefield. You expect links to lead where they say they lead, and buttons to do what they say they do.

But CVE-2026-26000 flips that trust on its head. It’s not a fancy memory corruption bug, and it doesn't require a master's degree in heap Feng Shui. It relies on something far more insidious: the browser's blind obedience to Cascading Style Sheets (CSS).

This vulnerability allows an unauthenticated attacker to turn a benign comment section into a trap. By injecting specific CSS, they can hijack the entire viewport. The user thinks they are clicking "Save" on a document, or "Log Out," or just clicking blank space to focus the window. In reality, they are clicking a hidden trapdoor that sends them straight to a phishing site or a drive-by download server. It is the digital equivalent of putting a poster over a hole in the floor.

The root cause here is a classic case of "features over security." XWiki allows users to style their comments using CSS. This sounds nice in principle—maybe you want your text to be red, or your table to have a border. The problem is that CSS, by default, is not scoped to the element it is defined in unless you use specific technologies like Shadow DOM (which XWiki wasn't using for comments).

When you allow a user to write a <style> block in a comment, those styles apply to the entire document. This is the "Cascading" part of CSS, and it's also the security flaw. The developers likely sanitized HTML to prevent Cross-Site Scripting (XSS), scrubbing out <script> tags and on* event handlers. But they left the door wide open for styling.

An attacker doesn't need JavaScript to ruin your day. They just need to break out of the comment box. By using properties like position: fixed, top: 0, and z-index: 99999, an element defined inside a lowly comment can ascend to the heavens and cover the entire application interface. The browser renders this faithfully, because as far as it knows, this is just how the page is supposed to look.

Let's look at how a researcher (or attacker) weaponizes this. The goal is to create a "clickjack" scenario where the user intends to interact with the Wiki but unknowingly interacts with our payload.

We need two things: an anchor tag (<a>) to serve as the destination, and a <style> block to make it weaponized. Here is the payload structure confirmed by the integration tests:

<!-- The Trap -->
<a href="https://attacker-controlled-site.com/login_harvest" class="phantom-link"></a>
 
<!-- The Weaponization -->
<style>
  a.phantom-link {
    position: fixed;
    top: 0;
    left: 0;
    width: 100vw;   /* 100% of Viewport Width */
    height: 100vh;  /* 100% of Viewport Height */
    z-index: 2147483647; /* Max signed 32-bit integer */
    opacity: 0;     /* Invisible to the eye */
    cursor: default; /* Don't change the mouse cursor */
  }
</style>

The Mechanics:

1. position: fixed: Rips the element out of the normal document flow and glues it to the browser window.
2. 100vw/vh: Forces the element to stretch across the entire screen.
3. z-index: Ensures this element sits on top of everything else—navigation bars, buttons, and content.
4. opacity: 0: Makes the element invisible. The user still sees the wiki underneath.

The result? The entire screen becomes a single, giant, invisible hyperlink. The next time the user clicks anywhere, the browser triggers the navigation event to the attacker's URL.

Fixing this is tricky. You could try to parse and sanitize CSS, but CSS parsers are notoriously difficult to secure (browsers are lenient, parsers are strict). Instead of blocking the CSS, XWiki opted for Frontend Link Protection.

The fix (commits 29cb81f3 and 7b5a4f8c) introduces a JavaScript interceptor, link-protection.js. Instead of preventing the overlay, they prevent the action resulting from the click.

How it works:

1. Event Listener: The script attaches a global click listener to all <a> tags.
2. Verification: When a click occurs, it checks the destination URL against a whitelist (trustedDomains).
3. Intervention: If the domain is external and untrusted, it halts the navigation and throws a window.confirm dialog.

// Pseudo-code representation of the fix logic
document.addEventListener('click', function(event) {
    let target = event.target.closest('a');
    if (!target) return;
 
    if (isExternal(target.href) && !isTrusted(target.href)) {
        event.preventDefault();
        if (confirm("You are leaving the wiki to go to " + target.href)) {
            window.location.href = target.href;
        }
    }
});

This is a "defense in depth" approach. The invisible overlay might still exist, but it can no longer silently spirit the user away. The sudden popup warning breaks the illusion and alerts the user.

As a hacker, looking at this fix makes my ears perk up. The defense relies entirely on a whitelist and URL parsing. This is where the next vulnerability usually hides.

1. The Open Redirect Bypass The interceptor allows links to trustedDomains. Usually, the wiki itself is trusted. If the wiki (or any other trusted domain in the config) has an Open Redirect vulnerability, the check is bypassed.

• Scenario: https://wiki.corp.com is trusted.
• Attack Link: https://wiki.corp.com/redirect?url=https://evil.com
• Result: The JavaScript sees wiki.corp.com, gives it a thumbs up, and lets the navigation happen. The server then redirects the user to evil.com. Game over.

2. The URL Parser Confusion JavaScript's URL API and the regex used in the protection script might disagree on what constitutes a "host." Techniques involving @ (credentials) or rare unicode characters could potentially trick the parser into thinking a malicious domain is actually a trusted one (e.g., https://trusted.com@attacker.com).

While the patch closes the immediate door, it shifts the burden of security to the integrity of the trusted domains.