Chrome drops XSLT on 17 November. What breaks in InterSystems, and the fix for your version

Chrome stops running XSLTdefinitionA way to turn raw XML into a page someone can actually read. Browsers have done it for years. Chrome and Edge are taking it out now, mostly for security reasons. on 17 November 2026, and Edge follows in December. When it does, the XML messages in the InterSystems Message ViewerdefinitionThe Management Portal screen your integration staff use to look up a single message. It's where they check what actually went through a production. and Visual TracedefinitionIt draws one message's path through a production, step by step. When an interface misbehaves, this is where engineers go to see which step it reached and what it said there. stop showing as formatted pages. Your interfaces keep running and no data changes, but the screens your integration team reads every day go blank or show raw markup. Put the fixed IRIS or HealthShare build on before your browsers update, or set the browser policy that buys you time. If you're still on Caché or Ensemble, treat this as the last fix before maintenance ends on 31 March 2027.

When an interface fails overnight, the on-call engineer opens Visual Trace, finds the message and reads it. If that page can't render, they're stuck working from raw XML or exports. Every incident takes longer, and so does every audit query about what a message contained.

InterSystems rated the operational risk High in its 21 October advisory, DP-456155, and we'd agree. Nobody's data leaks and nothing's lost. Still, a hospital's integration team loses its main window into live traffic on the day a routine browser update arrives, and that hurts during an outage.

The list of affected products is long. InterSystems names IRIS, IRIS for Health, Health Connect, EMPI, TrakCare and most of the HealthShare family, from Unified Care Record to Provider Directory. It also says it's still checking the full scope, so expect that list to grow.

For engineers: Chrome is removing both the XSLTProcessor JavaScript class and the xml-stylesheet processing instruction when it points at an XSLT file. An xml-stylesheet that points at CSS still works. Google's reasons are security and low use. It cites memory-safety bugs in libxslt and puts XSLT at about 0.02% of page loads. Firefox and WebKit have said they plan to remove it too, so switching browsers won't save you for long.

Most sites on an Extended MaintenancedefinitionInterSystems' slower release track, the one 2025.1 and 2026.1 sit on. These lines keep getting maintenance builds for years, so they usually get fixes like this one first. release have an easy path. If you're on 2025.1 or 2026.1, take the .6 maintenance build, test your productions on it and roll it out. It's a maintenance release on the line you already run, so it's a much smaller job than a version upgrade.

The awkward spots are at the edges. 2024.1 and Caché sites get their fix about five days before Chrome changes, if it lands on time. Sites that follow the Continuous Delivery track on 2026.2 have to move up to 2026.3.0, which arrives a day after Chrome does. Both groups should set up the browser policy described below as a bridge.

Chrome and Edge both have an enterprise policy called XSLTEnableddefinitionAn enterprise browser policy in Chrome and Edge. Set it on and XSLT keeps working on managed machines until version 176.. Set it to on and XSLT keeps working on managed machines, whatever the browser's default is. Google says the policy stops working in Chrome 176, on 17 August 2027, and Microsoft plans the same for Edge 176. InterSystems' advisory doesn't mention it, but both browser makers document it for exactly this kind of transition.

We'd use it as a bridge on the machines your integration and support staff use, and nowhere else. Browsers keep patching, the portal keeps rendering, and you get to install the InterSystems fix in a normal change window instead of in the week before Chrome flips. Turn it off again once every instance those people log into is on a fixed build.

For one machine, the setting is a DWORD called XSLTEnabled with the value 1, under the Edge or Chrome policy key in the registry. Microsoft's support article gives the exact commands. For a fleet, push it through Group Policy or Intune, then check it shows up at edge://policy or chrome://policy after a browser restart.

Microsoft also suggests the opposite test, and we'd run it this week. Set XSLTEnabled to disabled on one test machine and click through the Management Portal, Zen Reports and anything else your teams open in a browser. Whatever breaks on that machine is what breaks for everyone in November. It catches more than InterSystems screens. Microsoft has already said its own RD Web Access page fails when XSLT is off.

If you're still on Caché or Ensemble, 2018.1.13 is the release you need for this problem. It's also one of the last you'll get. InterSystems said in 2023 that no Caché or Ensemble maintenance releases are planned after 31 March 2027. It hasn't set an end date for support, so you can still open a case. But there won't be new builds for the next browser change or the next security flaw.

This advisory shows what that looks like in practice. A change outside InterSystems' control broke the product, and the fix came as a maintenance release. After March there's no next maintenance release to carry it. Some sites are already there. InterSystems said in 2023 it doesn't plan Caché maintenance releases outside Windows and Red Hat, and macOS stopped at 2018.1.9. If you run anything else, check with InterSystems before you count on 2018.1.13.

Use the 2018.1.13 rollout as your rehearsal for the IRIS move. You'll inventory instances, test productions and plan a change window anyway. Write down how long each step takes and what broke. That's most of the information an IRIS migration plan needs, gathered while you're doing work you have to do regardless.

We patch and upgrade InterSystems IRIS and HealthShare, and we move Caché and Ensemble to IRIS. For this change we'd start with an inventory of every instance and build, test the fixed release against your productions on a copy, and set up the browser bridge for the machines that need it. Read more on our InterSystems page, ask about InterSystems engineers, or book an assessment if you'd like the version check done for you.