WordPress 7.0.3 fixes several stored cross-site scripting paths available to contributors through content and editor surfaces, plus an author-level safe-CSS filter bypass. A good response consolidates these related paths into one editorial review of posts, revisions, blocks, Quick Edit, dates, emoji-related settings, custom CSS, and rendered cache copies.
Use this for publishers, guest-author programs, newsrooms, membership communities, multisite networks, agencies, and any WordPress site where contributors or authors can create or modify content before an editor publishes it.
Quick answer
Update Core, list recent contributor and author edits during the exposure window, preserve suspicious revisions, inspect raw block markup and metadata, render controlled benign fixtures under each affected role, and compare editor, preview, published, feed, REST, and cached output. Remove unsafe content only after recording its author, revision, timestamp, and distribution.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Contributor draft | Benign marker in affected block and date surfaces | Unsafe markup is stripped or encoded in editor, preview, and API output |
| Quick Edit | Controlled title, slug, date, and metadata update | Saved values cannot create executable output |
| Author CSS | Clearly harmless invalid declaration marker | Safe-CSS controls reject or neutralize the marker |
| Distribution | Published fixture with warmed cache and feed | No representation serves active markup after update and purge |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Patch WordPress Core | Export recent posts, revisions, authors, roles, status transitions, Quick Edit changes, dates, custom CSS changes, and moderation history. | Contributor and author fixtures cannot store executable markup through affected editor surfaces. |
| Inventory low-privilege edits | Inspect raw block markup for Post Content, Post Date, HTML-like attributes, unexpected style content, emoji settings elements, and encoded payload fragments. | Recent edits, revisions, role changes, and custom CSS changes map to approved users. |
| Preserve suspicious revisions | Compare block editor, classic editor, preview, published HTML, REST, feeds, email, AMP or print output, and CDN copies. | Preview, published HTML, REST, feeds, email, and CDN copies contain no unsafe marker. |
| Clean unsafe content and sessions | Review role and capability plugins that may give contributors or authors more editing or unfiltered content access than expected. | Affected accounts, sessions, and content have documented cleanup and monitoring decisions. |
What to check first
- Export recent posts, revisions, authors, roles, status transitions, Quick Edit changes, dates, custom CSS changes, and moderation history.
- Inspect raw block markup for Post Content, Post Date, HTML-like attributes, unexpected style content, emoji settings elements, and encoded payload fragments.
- Compare block editor, classic editor, preview, published HTML, REST, feeds, email, AMP or print output, and CDN copies.
- Review role and capability plugins that may give contributors or authors more editing or unfiltered content access than expected.
- Correlate suspicious revisions with login, IP, session, plugin, browser, and publication evidence before cleanup.
Field notes
- Record post ID, revision ID, author, role, timestamp, and raw content before changing suspicious material.
- Use harmless markers in staging rather than public exploit strings.
- Review scheduled and private posts because risky content may not be visible on the public archive yet.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
wp core version --extra
wp post list --post_type=post,page --post_status=any --fields=ID,post_title,post_author,post_status,post_modified --format=csv
wp user list --fields=ID,user_login,roles,user_registered
# Export suspicious post content and revisions before sanitizing them.
Why this usually happens
- Stored input can pass through editor serialization, metadata, filters, and render callbacks before reaching a visitor.
- Role plugins and custom capabilities can quietly expand who reaches an affected path.
- Revisions, feeds, email, previews, and page caches can preserve old output after the current post is cleaned.
Decision rule
Escalate when suspicious content reached a published or privileged viewer, an account cannot be explained, raw revisions contain active payload material, or another persistence signal appears outside the edited post.
Production verification checklist
- Contributor and author fixtures cannot store executable markup through affected editor surfaces.
- Recent edits, revisions, role changes, and custom CSS changes map to approved users.
- Preview, published HTML, REST, feeds, email, and CDN copies contain no unsafe marker.
- Affected accounts, sessions, and content have documented cleanup and monitoring decisions.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Patch WordPress Core
- Inventory low-privilege edits
- Preserve suspicious revisions
- Clean unsafe content and sessions
- Purge outputs and retest roles
Mistakes to avoid
- Do not create a separate thin page for every closely related editor surface.
- Do not delete a suspicious revision before preserving attribution evidence.
- Do not test only as an administrator.
- Do not forget scheduled, private, feed, email, and cached copies.
Questions teams ask during testing
Why does this page group several fixes?
They share the same low-privilege editorial boundary and verification workflow, so one comprehensive owner is more useful than overlapping pages.
Can a contributor publish the payload directly?
Normal contributors cannot publish, but stored content can still reach editors, previews, workflows, or later publication.
Does removing the current post clean revisions?
Not necessarily. Revisions and external copies need their own review and retention decision.
What to tell the client or owner
Share the post and revision IDs, author and role, change timestamps, raw block or metadata sample, publication state, viewer state, output locations, account status, and cleanup record.
When HandL WP should help
HandL WP can patch Core, review role boundaries and revisions, inspect rendered copies, preserve evidence, clean unsafe content, and retest editorial workflows.
If this is active on a production site, audit WordPress editorial security.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Test custom roles at the action boundary
Run the WordPress 7.0.3 role and capability plugin regression test across wp-admin, REST, AJAX, object ownership, allowed controls, and denied controls.
Helpful references