Chromium's XSLT 1.0 Drop Just Broke RD Web Access for Some Windows Servers

A Chromium browser update that removes support for XSLT 1.0 has begun breaking Windows Server RD Web Access, according to telemetry Microsoft tracks. The impact is currently small — over just 0.02% of traffic — but it’s a concrete example of how a security-driven change in a web browser can ripple outward and break enterprise infrastructure that nobody expected to touch.

If you run or rely on RD Web Access, this is worth understanding now, before your users start hitting a broken portal. Here’s what changed, why it happened, and what you can do about it.

Why Chromium is dropping XSLT 1.0

XSLT (XSL Transformations) is a W3C standard, first published in 1999, that turns XML documents into other formats such as HTML. For decades it has quietly powered a large amount of enterprise document processing, even though most everyday web users have never heard of it.

The catch is the implementation. The reference implementation of XSLT 1.0, the C library known as libxslt, is built on aging C/C++ code. That kind of code relies on manual memory management, which is precisely what makes it a memory-safety hazard — bugs in it can be exploited for crashes or, worse, remote code execution.

From a browser vendor’s perspective, the math is simple. With XSLT 1.0 usage sitting at just 0.02% of all traffic, the number of sites that actually depend on it is tiny. Through the Chromium project, Google and Microsoft have decided that keeping a vulnerable code path alive for such a small slice of the web isn’t worth the security risk. The result is that Chromium-based browsers — Google Chrome and Microsoft Edge — are removing XSLT 1.0 support entirely.

Why this breaks RD Web Access

RD Web Access is a role within Windows Server’s Remote Desktop Services. It hosts a web portal that lets users sign in from any browser and launch their assigned remote desktops and applications without installing special client software.

The portal’s pages are rendered using XSLT 1.0 transformations. The server holds XML data alongside an accompanying XSLT stylesheet, and the browser is expected to run the transformation to produce the final HTML you see. It’s a legacy rendering model, but one that has worked reliably for years.

When a Chromium-based browser drops XSLT 1.0 support, it can no longer perform that transformation. For RD Web Access, that means the portal page fails to render properly — users can hit errors or see a broken, incomplete page instead of their list of remote resources.

What this means for you

The 0.02% figure is the key thing to keep in mind. It’s not a universal outage — many deployments still work because not every user has rolled out the updated browser, and the exact trigger depends on which Chromium build and channel reached each machine.

In practice, that means the problem is uneven. Some users on the same server may be able to reach the portal fine while others hit a broken page, which makes it easy to dismiss as an intermittent glitch when it’s actually the browser update. If you’re an admin, don’t assume a single user’s complaint is isolated — check whether that user (and colleagues) recently picked up the updated Edge or Chrome.

What you can do about it

For now, there’s no clean switch to flip on the server side, because the fix has to come from either the browser or Microsoft’s RD Web Access code. A few practical options:

Delay the browser update. If you manage a fleet, hold back the Chromium update on the machines users hit the portal from, until Microsoft ships a fix.
Use a non-Chromium browser. For admins who just need to reach the portal to manage it, an alternative browser that still supports XSLT 1.0 can bridge the gap.
Watch Microsoft’s guidance. Keep an eye on official Windows Server update notes and support pages for an RD Web Access patch that stops relying on browser-side XSLT.

Microsoft’s own Remote Desktop Services tooling has historically moved toward server-side rendering to avoid exactly this kind of browser dependency, so a longer-term fix likely follows that direction rather than asking users to keep an old browser engine alive.

What this means for the wider ecosystem

This is probably not the last time you’ll see it. As XSLT 1.0 continues to fade and browsers finish removing it, other legacy web-dependent enterprise tools may start showing the same failure mode. IT teams that still lean on older XML/XSLT rendering patterns should treat this as an early signal to plan migrations away from browser-side transformations.

The broader takeaway is that enterprise features built on web standards can be quietly destabilized by changes made elsewhere in the stack. What looked like a routine browser security update turned into an operational headache for at least some Windows Server shops.

Source: Neowin

Over to you: Are you holding back the Chromium update on your server machines, or waiting for Microsoft to patch RD Web Access?