On Wednesday, September 16, the Drupal security team published SA-CORE-2026-013, a moderately critical advisory covering a cross-site scripting vulnerability in the CKEditor 5 library that ships with core. It is not the drop-everything tier that SA-CORE-2026-004 was in May. It is the more common and more quietly dangerous kind: an authenticated user with ordinary content permissions can plant a payload that fires in the browser of whoever edits that content next, including your site administrators.
What shipped
The advisory covers Drupal core 10.5.0 through 10.6.16, 11.0.0 through 11.3.16, and 11.4.0 through 11.4.6. The fixed releases are 10.6.17, 11.3.17, and 11.4.7, all published alongside the advisory. Drupal 8 and 9 are end-of-life and were not evaluated.
The risk score is 13 out of 25, at the upper end of "moderately critical." The vector breaks down as basic attack complexity, an authenticated user required, some confidentiality and integrity impact, theoretical exploitability at publication, and default target distribution. That last flag matters: CKEditor 5 is the default WYSIWYG editor in Drupal 10 and 11, so nearly every site is in scope unless it has deliberately turned the editor off.
The underlying issue is upstream. CKEditor published two advisories the same morning:
- GHSA-rh54-vffm-5fvp, rated high. A prototype pollution bug in
es-toolkit, a utility library CKEditor 5 depends on, becomes script execution when the editor processes incomingstyleattribute values. It affects CKEditor 5 from 45.0.0 onward. - GHSA-v6mg-96c6-gmpq, rated low. Crafted markup under a specific General HTML Support configuration that allows object insertion. It only applies where that feature is enabled and configured permissively, and the script runs in a context isolated from your origin.
Both are fixed in CKEditor 5 48.5.1 and the 47.7.4 LTS release. Drupal core bundles the compiled library, so the core update is how you get the fix. The reporter credited on the Drupal advisory is Piotrek Koszuliński, who leads CKEditor 5 at CKSource. This was found and disclosed by the vendor, not observed in the wild.
The advisory also carries a line agencies should not skip: contributed projects may bundle additional CKEditor plugins that are not packaged in core, and those need their own review.
Our take
The exposure is about who can create content, not who can use the editor. The advisory is explicit that the attacker does not need CKEditor access themselves. They need to be able to create or edit a node. The victim is whoever opens that node in the WYSIWYG editor next. On a marketing site with three trusted editors, that is a small circle and the risk is modest. On a university site, a membership community, an intranet, or anything with open registration and a content-creating role, this is a privilege escalation path from "can post" to "runs script in the admin's browser." Stored XSS against an administrator is how sessions get hijacked and accounts get taken over. Scope your urgency by that question, not by the severity label alone.
Third-party library advisories are now the normal shape of a core advisory. This one is two hops removed from anything a Drupal developer wrote: a utility library inside an editor inside a CMS. There is no code review on your side that would have caught it. The only defense is the boring one, which is patching core on a cadence short enough that a vendor-disclosed bug never sits unpatched for weeks. If your last core update was more than one minor release ago, this advisory is the prompt.
Updating core may not be the whole fix. Some contributed modules vendor their own compiled CKEditor 5 plugin builds against older engine versions. The advisory's note about contributed projects is not boilerplate. Inventory which contrib modules add CKEditor 5 plugins on each site and check whether they have shipped updates. Until they do, disabling a plugin is safer than leaving it.
The 10.5 line gets forced forward. The only Drupal 10 release with this fix is 10.6.17. Sites still on 10.5.x have to take the 10.6 minor update to be patched, and Drupal 10 itself reaches end of life on December 9. We wrote about that cliff last week. If this advisory is what finally pushes a 10.5 site to 10.6, use the same change window to schedule the Drupal 11 upgrade instead of doing two disruptive updates twelve weeks apart.
Theoretical exploitability is a window, not a pass. No exploit was known at publication, and the vendor disclosed it. That earns you a staged rollout rather than an emergency one: apply to a staging clone, run the editorial smoke test, promote. That whole loop should still complete within a day or two, not at the next sprint boundary. The advisory being public is what starts the clock on someone weaponizing it.
What to do right now
- Update core to 11.4.7, 11.3.17, or 10.6.17 on every site configured to use CKEditor 5, which is almost all of them.
- List every contributed module that adds CKEditor 5 plugins on each site. Check each for a security release. Disable any that bundle an older engine and have no update yet.
- Rank sites by who can create content. Open registration plus any content-creating role goes to the top of the queue. Three-editor marketing sites can follow the normal staged path.
- Confirm your 10.x sites are on 10.6. If any are still on 10.5, this update is the 10.6 move. Book the Drupal 11 upgrade in the same conversation.
- Check your General HTML Support configuration. The low-severity issue only matters where GHS is enabled and permits object insertion. Most sites do not need that allowed.
- Subscribe to Drupal security advisories at drupal.org/security if you are not already, and confirm your hosting provider is relaying them.
Originally referenced: Drupal core - Moderately critical - Third-party libraries - SA-CORE-2026-013 on Drupal.org.
If you manage Drupal sites and want help sizing exposure across a portfolio, auditing contributed CKEditor plugins, or folding this into a Drupal 11 upgrade plan before December, get in touch.
