The wp_kses() Rewrite: What Plugin Authors Should Test

A progress report published on 7 October 2026 on the WordPress Core blog describes a replacement for wp_kses(), the function that strips disallowed markup from untrusted input and sits underneath wp_kses_post() and most of the sanitising that plugins do. The new version is built on the HTML API and parses input structurally, where the legacy code patched it token by token with regular expressions. The progress report is a request for testing, and it names behaviours that will change.

Timeline and the opt-out

The report tracks the work in ticket #66208. It states that the new parser is the default now, with the legacy implementation still available, and that release timing is WordPress 7.2 or 7.3 depending on what testing finds. It also warns that the legacy code will be removed in a future release, possibly in 7.2.0 with no transition support. The roadmap to 7.2 lists improved HTML processing as one of its security workstreams, without a deliverable date, so the report is the better guide to what will ship.

The temporary escape hatch is a filter. Adding add_filter( 'wp_kses_force_legacy_parser', '__return_true' ) forces the old behaviour, and returning false keeps the new parser active explicitly. The report calls this a compatibility measure, not a long-term setting.

What changes in the output

The behaviour changes that most affect third-party code are these:

• Markup is normalised: tag names are lowercased, attributes are double-quoted, and self-closing flags on void elements such as <img /> are dropped.
• Stray angle brackets survive as text. Content like <$500 or >5yo was previously removed and is now escaped, so it stays visible.
• Ambiguous ampersands follow browser rules. Named references without a semicolon, such as &copy, are decoded in text nodes but not in attributes, and a URL in text containing &section= may render with a section sign.
• When script and style are not allowed, their contents are now removed along with the tags. Previously the code inside stayed in the output.
• Incomplete trailing fragments, such as an unfinished <butto, are discarded, and unclosed special elements are removed entirely.
• SVG and MathML are handled only as far as the parser can be certain. Where content needs more complex parsing, output is cut off before it begins.

Unbalanced tags are still preserved, because existing code depends on concatenating sanitised fragments. The report also says the logic leans conservative, since the function is a security boundary, so some inputs that were safe may now be rejected.

Eight checks to run before 7.2

The report’s own list of things to test translates into a short routine for any plugin or theme that passes content through wp_kses():

1. Run the test suite with the legacy filter on and off, and compare the outputs.
2. Check URLs in text and attributes, and make sure query strings use &.
3. Check what happens to disallowed script and style content, and confirm that removal is acceptable.
4. Feed it strings containing stray < or >, such as prices or comparisons.
5. Check truncated fragments at the end of strings, especially where output is concatenated.
6. Check title, svg and math content if your code passes it through.
7. Check any code that relies on markup remaining unbalanced.
8. Replace brittle string comparisons in tests with assertEqualHTML(), which ignores insignificant differences such as attribute order and quoting.

Why a site owner should care

Sanitising behaviour also interacts with the automated security review of plugin releases, which scores each release during a cooldown before it is distributed. A plugin whose output differs under the new parser is a plugin that should be tested before its next release goes out, not after a user reports a broken block.

Most site owners will never call wp_kses() directly, but anything that stores user-submitted HTML does: comment forms, form builders, review plugins, page-builder widgets. A change in how an ampersand or an unclosed tag is treated shows up as a broken link or a truncated block, not as an error message. The report gives no benchmark figures for the claimed performance improvement, and invites readers to supply them.

The roadmap for the same release also lists the sudo mode and Secrets API work, and the feedback window is the beta period. Anyone who maintains code that sanitises HTML should report differences on ticket #66208 while the legacy filter still exists to compare against.