WordPress 7.0.3 fixes information disclosure involving the Latest Comments block on password-protected posts and disclosure of notes in comment feeds. The useful verification is broader than opening one post because feeds, REST responses, widgets, blocks, caches, email, and third-party readers may each preserve a separate copy.
Use this for editorial sites, membership communities, support portals, private project updates, moderated comments, password-protected announcements, and any site where comment notes or protected-post discussion may contain personal or confidential information.
Quick answer
Patch Core, create a disposable password-protected post with clearly fake comment and note markers, then check the post, Latest Comments block, site and comment feeds, REST endpoints, search, archives, page cache, CDN, feed readers, email, and logged-out browser output. Remove the fixture and purge all copies after the result is recorded.
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 |
|---|
| Protected post | Fake password and unique content marker | Protected content stays behind the intended access boundary |
| Latest Comments | Approved fake comment on protected post | Logged-out block output reveals no protected comment details |
| Comment feed | Synthetic moderation note and email | Public feed contains no internal note or private identity field |
| Cache | Warm public page and feed before update | Origin and edge stop serving the old disclosure after 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 | Create synthetic markers for protected post content, approved comment text, pending comment text, moderation note, author identity, and email address. | Anonymous HTML, block output, feeds, REST, search, archives, and embeds contain no protected marker. |
| Create a synthetic privacy fixture | Fetch Latest Comments output, post comments, global feed, comment feed, REST responses, search, archives, embeds, and sitemaps while logged out. | Authorized users retain the expected moderation and discussion workflow. |
| Test every public representation | Compare authenticated, anonymous, private-browser, origin, CDN, mobile, and feed-reader variants. | Origin, CDN, page cache, object cache, and feed output agree after purge. |
| Purge stored copies | Inspect notification and moderation email for data that is expected by recipients but must not appear in public output. | The synthetic fixture and every cached copy under site control are removed after testing. |
What to check first
- Create synthetic markers for protected post content, approved comment text, pending comment text, moderation note, author identity, and email address.
- Fetch Latest Comments output, post comments, global feed, comment feed, REST responses, search, archives, embeds, and sitemaps while logged out.
- Compare authenticated, anonymous, private-browser, origin, CDN, mobile, and feed-reader variants.
- Inspect notification and moderation email for data that is expected by recipients but must not appear in public output.
- Purge page, object, CDN, feed-reader, and prerender caches after patching and after removing the fixture.
Field notes
- Use fake data only so the test itself does not create a reportable disclosure.
- Save response headers and the exact visitor state with each result.
- Check feed-reader copies separately because the origin cannot purge a subscriber's stored history.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
curl -sS https://example.com/feed/ | grep 'PRIVACY-FIXTURE'
curl -sS https://example.com/comments/feed/ | grep 'PRIVACY-FIXTURE'
curl -sS 'https://example.com/wp-json/wp/v2/comments?search=PRIVACY-FIXTURE'
curl -sS https://example.com/ | grep 'PRIVACY-FIXTURE'
# An empty result is expected for public protected markers.
Why this usually happens
- A block or feed can query comments independently of the access check used on the single post template.
- Feeds and REST responses expose machine-readable fields that may be absent from the visible page.
- CDN, object, page, and reader caches can retain a privacy leak after the source code is fixed.
Decision rule
Treat any protected marker, moderation note, private email, or internal identifier in anonymous output as a privacy incident until scope, recipients, cache duration, and removal are established.
Production verification checklist
- Anonymous HTML, block output, feeds, REST, search, archives, and embeds contain no protected marker.
- Authorized users retain the expected moderation and discussion workflow.
- Origin, CDN, page cache, object cache, and feed output agree after purge.
- The synthetic fixture and every cached copy under site control are removed after testing.
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
- Create a synthetic privacy fixture
- Test every public representation
- Purge stored copies
- Remove the fixture and retest
Mistakes to avoid
- Do not use real customer or employee data in the fixture.
- Do not stop after checking the protected post page.
- Do not assume a plugin cache purge clears CDN and feed-reader copies.
- Do not publish internal moderation notes in screenshots or tickets.
Questions teams ask during testing
Why combine Latest Comments and feed testing?
Both issues cross the normal post-page boundary, so one synthetic fixture can test the related public representations efficiently.
Does a feed returning 200 mean it is private?
No. Inspect its fields and content while logged out.
Can a site remove copies stored by feed readers?
Not reliably. That is why exposure scope and notification decisions may still be needed after the origin is fixed.
What to tell the client or owner
Share the protected URL, synthetic marker, output surface, visitor state, response headers, cache status, first and last observed times, recipients, purge actions, and final retest.
When HandL WP should help
HandL WP can build a privacy-safe fixture, inspect public and authenticated output, trace cache copies, document exposure, and verify cleanup after the WordPress update.
If this is active on a production site, test WordPress privacy boundaries.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references