WordPress WP_HTML_Token Deserialization Flaw Enables Code Execution

WordPress is an open publishing platform for the Web. Unserialization of instances of the WP_HTML_Token class allows for code execution via its __destruct() magic method. This issue was fixed in WordPress 6.4.2 on December 6th, 2023. Versions prior to 6.4.0 are not affected.

WordPress is the affected product; the normalized record identifies the package as wordpress-develop.

• WordPress versions >= 6.4.0 < 6.4.2 are confirmed affected.
• WordPress versions prior to 6.4.0 are identified by the CNA advisory as not affected.
• WordPress 6.4.2 is the confirmed patched release.
• The available evidence does not establish the status of every other release branch beyond these boundaries. Do not infer that every later or parallel branch has been verified merely because a fix exists for one release.

WordPress unserializes instances of the WP_HTML_Token class, and the class's __destruct() magic method can then lead to code execution. This is CWE-502: Deserialization of Untrusted Data, where untrusted serialized data is processed in a way that can trigger dangerous object behavior. The record identifies a potentially network-reachable attack path, but it does not identify the endpoint, request field, parser entry point, or serialized-data source involved. The available assessments agree that attack complexity is low and user interaction is not required, but they disagree about privileges: the CNA advisory records high privileges, while the NVD assessment records no privileges. The implementation detail changed by the fix is not disclosed in the available evidence.

• The described attack path is network reachable, has low complexity, and does not require user interaction.
• The vendor/CNA advisory models high privileges as required, while the NVD assessment models no privileges as required. The actual request path and deployment permissions should therefore be verified instead of treating either model as universal.
• The advisory states that the vulnerability was publicly disclosed as a zero-day, but the supplied record does not confirm exploitation in the wild. The known_exploited field is null and public_exploit is false; this does not prove that exploitation never occurred.
• Research returned a GitHub repository that purports to contain an exploit module, but its content has reliability issues and does not establish a working exploit for this record. It should not be treated as a substitute for the vendor advisory.

The confirmed technical outcome is code execution through unserialization of WP_HTML_Token and its __destruct() magic method. Depending on the permissions of the WordPress or PHP process, environment isolation, and accessible secrets, this could enable site modification, data access, or service disruption.

The vendor/CNA advisory models limited confidentiality and integrity impact with no availability impact and requires high privileges. The NVD assessment models no required privileges with higher confidentiality, integrity, and availability impact. The record does not explain this difference, so defenders should not assume that exploitation always requires authentication or is always anonymous.

Whether execution can cross the WordPress security boundary depends on process permissions and host isolation. The available technical description is insufficient to confirm that scope.

The flaw is described as capable of code execution in the WordPress process. If successfully triggered, possible consequences include unauthorized changes to site content or configuration, access to data and secrets readable by the web process, or service disruption. These outcomes depend on process permissions and deployment isolation and are not evidence of a specific breach.

The vendor/CNA advisory and the NVD assessment use different assumptions about required privileges and impact, so actual exposure must be validated against each deployment's architecture and request path. The available evidence identifies no specific victim, campaign, breach, or indicator.

1. Upgrade installations in the affected range to WordPress 6.4.2, the confirmed fixed release identified by the advisory.
2. If an immediate update is not possible, treat the system as exposed and apply compensating controls that have been validated for the specific deployment. The available evidence provides no authoritative temporary mitigation or endpoint-specific workaround.
3. After updating, verify the version actually used by the web server and runtime, and check for stale instances, images, or source trees that could still be served.
4. Review the web process's permissions and application paths that handle serialized data to limit possible consequences if malicious input is received, but do not treat this as a replacement for the confirmed update.

1. Inventory every WordPress core deployment and compare its running version with the affected range and fixed boundary in affected_summary.
2. Verify the version used by the live runtime, not only the version in a source tree, image tag, or package metadata. Include duplicate WordPress copies in web roots, container images, and staging environments that could reach production.
3. Review application and web-server telemetry for requests that reached code paths performing WordPress object unserialization. The advisory provides no endpoint, request field, or log signature, so this is a precautionary review rather than a confirmed IOC check.
4. For systems that may have been exposed, review unexpected changes to content, configuration, administrative accounts, files, and process activity. These are general investigation signals, not record-specific indicators.
5. Do not treat the absence of suspicious logs as proof of safety. Patch status and version inventory remain the decisive checks.