When you add tinymce angular to a project you are adopting two things: a thin Angular wrapper (@tinymce/tinymce-angular) and the full TinyMCE rich-text editor underneath it, and nearly all of the security risk lives in the editor, not the wrapper. Rich-text editors are a classic XSS surface because their entire job is to accept, store, and re-render HTML, so the sanitization behavior of the bundled TinyMCE version is what you actually need to track.
This guide explains the split, the recent CVEs that matter, and how to keep a tinymce-angular integration on safe ground.
How @tinymce/tinymce-angular is structured
Install it with the peer editor:
npm install @tinymce/tinymce-angular tinymce
The @tinymce/tinymce-angular package is an official wrapper. It exposes an <editor> component and binds Angular's change detection to TinyMCE's API. It is deliberately small. The tinymce package is the real engine: the DOM parsing, the schema, the content sanitization, and the plugin system.
That structure has a direct security consequence. When a TinyMCE XSS advisory is published, it is filed against tinymce, and your fix is to bump tinymce, not the Angular wrapper. Teams that only watch @tinymce/tinymce-angular for updates can sit on a vulnerable editor for months because the wrapper version never moved.
The XSS CVEs you should know about
TinyMCE's sanitizer has been the subject of multiple sanitization-bypass advisories over the years, and rich-text editors will keep producing them because the problem space is adversarial. In May 2026 a cluster of four cross-site scripting issues, CVE-2026-47759 through CVE-2026-47762, were published. All four are stored or DOM-based XSS caused by gaps in TinyMCE's content sanitization. They carry a split score: GitHub rated each 8.7 (High) while NVD rated each 5.4 (Medium), a reminder that a single "severity" number can mislead.
The affected ranges were all versions before 5.11.1, the 6.0.0 line up to but not including 7.9.3, and the 8.0.0 line before 8.5.1. Patched releases are 5.11.1, 7.9.3, and 8.5.1 or later. Notably, the final 6.x release is 6.8.6, and no patched 6.x build exists for these four CVEs, so an app pinned to TinyMCE 6 has to either move to 7.9.3 or later or arrange a supported 5.11.1 branch.
An older advisory, CVE-2022-23494, covered a different XSS in the editor's content handling. The pattern repeats: sanitizer bypass, patch, repeat. That is not a knock on TinyMCE specifically; it is the nature of any editor that renders rich content.
Defense in depth for tinymce angular
Keeping the editor patched is necessary but not sufficient. Layer these controls.
Keep DOMPurify on. TinyMCE runs DOMPurify sanitization by default. Prior to TinyMCE 6.4 it could not be disabled; from 6.4 onward the xss_sanitization option lets you turn it off. Do not turn it off. If a plugin or migration guide suggests disabling it, that is a red flag.
Sanitize on the server too. Content typed into a client-side editor is trivially bypassable by an attacker who posts directly to your API. Whatever TinyMCE cleans in the browser, sanitize again server-side before storage and before rendering. Client sanitization is a UX nicety; the server control is the real one.
Set a Content Security Policy. A strict CSP that blocks inline event handlers and untrusted script sources turns many editor-based XSS payloads into inert markup even if a sanitizer bypass slips through. It is the backstop for the bypass you have not heard about yet.
Pin both packages and scan them. Commit your lockfile so the exact tinymce version is reproducible, and make sure your software composition analysis tracks the tinymce engine, not just the wrapper. An SCA tool such as Safeguard will flag a vulnerable tinymce even when your @tinymce/tinymce-angular version looks current, which is exactly the blind spot that bites teams here.
A quick self-check
Run this and compare against the patched floors above:
npm ls tinymce @tinymce/tinymce-angular
If tinymce resolves below 5.11.1, or into 6.x, or below 7.9.3 on the 7 line, plan an upgrade. Major-version jumps to TinyMCE 7 carry migration cost, so budget for it rather than treating it as a one-line bump.
FAQ
Is @tinymce/tinymce-angular safe to use?
The wrapper itself is a thin, low-risk layer. The safety of your integration depends on the bundled tinymce version, which has had multiple XSS sanitization-bypass CVEs. Keep tinymce on a patched release, leave DOMPurify enabled, and sanitize server-side as well.
Which TinyMCE versions fix the 2026 XSS CVEs?
CVE-2026-47759 through CVE-2026-47762 are fixed in TinyMCE 5.11.1, 7.9.3, and 8.5.1 or later. There is no patched 6.x build for these issues; the 6.x line ended at 6.8.6, so TinyMCE 6 users must upgrade to 7.9.3 or later or arrange a supported 5.11.1 branch.
Do I update tinymce or tinymce-angular to fix a vulnerability?
Update tinymce. XSS advisories are filed against the editor engine, not the Angular wrapper. It is common for the wrapper version to stay the same while the underlying tinymce needs a bump, so track both in your dependency scan.
Is client-side sanitization in TinyMCE enough?
No. An attacker can post directly to your backend and skip the editor entirely. Treat TinyMCE's in-browser sanitization as a convenience and enforce your real sanitization on the server, backed by a strict Content Security Policy.