CKEditor 5 is a framework that ships as a development environment, not a package

A workspace full of release tooling rather than an editor

The root `package.json` is named `ckeditor5-root` and carries `"private": true`, which is the first fact worth noticing. You cannot install this thing. It is the environment around the editor, and almost everything in it exists to build, document, test and publish the packages that other people install. The version field reads `48.5.1`, which matches the newest release tag, so the whole workspace moves in lockstep with a single version line rather than letting each plugin drift.

The dependency list makes that structure plain. There are six members of the `@ckeditor/ckeditor5-dev-*` family pinned around `^62.0.0`: `ckeditor5-dev-build-tools`, `ckeditor5-dev-utils`, `ckeditor5-dev-docs`, `ckeditor5-dev-release-tools`, `ckeditor5-dev-changelog`, `ckeditor5-dev-bump-year`, `ckeditor5-dev-license-checker`, `ckeditor5-dev-manual-server` and `ckeditor5-dev-web-crawler`. Add `ckeditor5-inspector` at `^5.0.1` for poking at the editor from the outside, `ckeditor5-react` at `^9.5.0`, and `ckeditor5-mermaid` pulled straight from a git ref rather than the registry. The presence of a dedicated license checker package tells you that licensing is a build step here, not an afterthought.

The rest of the tree confirms it. Six `tsconfig` variants split along `build`, `docs`, `manual`, `test` and `typedoc` boundaries, plus `vite.manual.mts` and `vitest.config.ts` for running the manual and the tests. `codecov.yml` and `.circleci/` sit at the root next to `.markdownlint.json` and `.syncpackrc.mjs`, that last one keeping dependency versions consistent across packages. `scripts/` and `scripts-tests/` hold the automation and its tests separately, and `.changelog/` is a directory rather than a file, so changelog entries are generated from somewhere. There is also `typings/` and `manual-assets/`. This is a project that treats its own documentation as a build artifact.

TypeScript types reached users at version 37

The README states plainly that CKEditor 5 is a TypeScript project and that starting from v37.0.0 the official packages provide native type definitions. That sentence does a lot of quiet work. Before it, using this editor from TypeScript meant either ambient declarations or a plugin that guessed. Now the editor's public API, its plugin interfaces and its command and schema shapes arrive typed, and the presence of `tsconfig.typedoc.json` in the root suggests the API reference is generated from the same sources that ship to npm.

That matters more for an editor than for a typical library. A rich text editor's main integration surface is a large set of plugin constructors, each with configuration, commands and schema rules, and getting the shape of any of them wrong tends to fail quietly rather than loudly. Typed definitions turn a class of runtime mystery into a compile error.

The other version line to keep in view is the node floor. The engines block asks for `"node": ">=24.11.0"` and `"pnpm": "^11.8.0"`, and the yarn entry is a small ASCII art box telling you that pnpm is now the package manager. The README also notes that the project supports modern bundlers. So the toolchain assumes a current Node and a workspace-aware package manager, which is reasonable in 2026 and worth confirming against your CI images before you plan an integration sprint.

Three ways in: the Builder, a coding agent, or a hand-written build

The Quick start section offers three distinct routes, and which one you pick shapes how much of the framework you end up owning.

The Builder is the low-commitment path. You choose a base editor type, add the plugins you want, and download a ready-to-use package. This is the sane starting point for most teams, because the bundle contains what you asked for and nothing else, and you avoid learning the build configuration just to ship a form.

The Build with AI section is new enough to be worth noticing. You can set CKEditor 5 up with an AI coding agent such as Claude Code, Cursor, Codex or Copilot by installing the official CKEditor skill, after which the agent handles installation, configuration and licensing. For a framework with this many interacting plugins, a packaged skill is a real convenience, and the fact that it covers licensing specifically suggests the vendor expects people to get that step wrong.

The third route is the framework path. The README keeps a separate section for it and links to a framework overview, and there are dedicated integration guides for Angular, React and Vue. This is where you stop consuming an editor and start assembling one: your own build, your own plugin list, your own schema. It is the route that gives you the most control and demands the most maintenance, since every dependency you add is one you must keep patched when a security release lands.

Two advisories, one day, and what they reveal about the editor's edges

The two most recent releases were published on 2026-09-16, and both carry the same headline: two cross-site scripting vulnerabilities in the CKEditor 5 engine. `v48.5.1` and `v47.7.4` were released within an hour of each other, which is the standard move when a fix has to reach both the current line and the LTS line at once.

The first advisory, `GHSA-rh54-vffm-5fvp`, is a prototype pollution issue in `es-toolkit`, a utility library used inside the CKEditor 5 codebase. The impact is unauthorized JavaScript execution when the editor processes incoming `style` attribute values. The underlying bug was fixed by that library's maintainers and the fix was pulled into CKEditor 5, which is a small reminder of how much of an editor's security surface actually lives in transitive dependencies.

The second, `GHSA-v6mg-96c6-gmpq`, is narrower and more interesting. It affects only installations where General HTML Support is enabled with a specific configuration that allows inserting objects, and it leads to code execution in a browser context isolated from the origin of the application embedding the editor. That is a classic permissions boundary, and it is worth reading twice: a feature sold as flexibility for accepting arbitrary HTML is also a feature that widens what an attacker can reach.

For an adopter the practical lesson is unglamorous. Pin your CKEditor version, subscribe to the security advisories for the repository, and treat General HTML Support as the option it is rather than a default. If your editor renders HTML that other users wrote, you are operating a parser over untrusted input, and two advisories landing together is a fair signal of where the sharp edges are.

The v47 LTS line and who it is actually for

`v47.7.4` is marked as a Long Term Support Edition release, available only to LTS subscribers, and its stated job is delivering security and critical maintenance fixes for the v47 line. That is a smaller promise than the current line gets, and it is the clearest statement in the repository about how the project thinks about time.

The split matters for procurement. The current release line receives features and fixes continuously; the LTS line receives only security and critical maintenance, and access to it is tied to a subscription. Teams that cannot absorb an editor upgrade every few months, usually because a rich text editor is embedded in dozens of downstream templates or in products they do not control end to end, are the intended customer. Everyone else is expected to track the current line.

The open issue count is the other side of that equation. The repository currently carries 732 open issues against a default branch of `master` and 10,495 stars, with the last push on 2026-09-21. A project this size with that many live issues is not neglected; it is absorbing a large surface of feature requests and bug reports from a genuinely popular component. It does mean that the gap between what you can configure and what someone has already solved is wide, and that reading the issue tracker before designing your plugin set is more productive than reading it after.

Licensing sits alongside all of this in the repository itself. The package license field points to `LICENSE.md` rather than naming a single license, and a `COPYING.GPL` file sits at the root beside it, with a dedicated license checker among the dev tooling to enforce whatever the current terms require. For the licensing question, the concrete starting point is `LICENSE.md` in this repository and the setup documentation, not a blog post.

The feature list is broad, and the plugin boundary is the real design

The README describes the feature surface in sweeping terms, and it is worth separating the genuinely different categories from the marketing shape.

There is real-time collaboration: comments, tracking changes, and the operational transformation keywords that appear in the root package suggest the sync layer is a first-class part of the product rather than an afterthought. There is document structure: tables, lists, font styles. There are domain-specific tools that most editors treat as plugins or not support at all, including Markdown input and output, source editing, and export to PDF and Word. There is media handling, with images and videos plus several upload and storage systems. There is accessibility tooling and multi-language support.

The reason to care about that list is not any single feature. It is that each of those capabilities is a plugin, and the plugin is the unit you configure, bundle, test and keep patched. General HTML Support, the feature named in one of the recent advisories, is exactly this kind of plugin: a wide door with a narrow lock.

So the useful way to evaluate CKEditor 5 against something like TinyMCE is to count doors rather than compare feature grids. List the plugins you would actually load in production, sum their upgrade risk, and check how each interacts with the data you store. An editor that gives you tracking changes and Markdown export in the same build may save you a year of work; the same editor shipped with a dozen optional plugins enabled for a blog post field is more surface than you needed. The repository's structure, a framework separate from any particular editor configuration, is built for exactly that kind of selection.

Editorial conclusion

CKEditor 5 is a defensible choice for a product team that needs collaboration features, structured output and a plugin API it can extend, and an expensive one for a team that only needs a text box with bold applied. The repository itself argues for the first case: TypeScript types on the public packages since v37.0.0, a framework layer documented separately from the editor, and a build toolchain that treats releases and licenses as first class concerns. The two advisories fixed in v48.5.1 are the part to plan around rather than worry about, because a component that renders other people's stored HTML will keep producing these and your upgrade path is `pnpm update` against a tagged release. If you take one concrete step, open `packages/` and count the plugins you would actually load, then compare that number against the 732 open issues before you commit a schedule.

Frequently asked questions

Official sources

1. ckeditor/ckeditor5 on GitHub
2. Issues
3. Project website
4. README
5. Releases