The WordPress 7.0.3 release fixes a pre-authentication reflected cross-site scripting vulnerability on the login screen that WordPress says could lead to PHP code execution. Because an attacker does not need an account to reach the affected boundary, patching and evidence review should happen together.
Use this for public WordPress login pages, customer portals, membership sites, multisite networks, agency fleets, and installations where wp-login.php is exposed through a CDN, WAF, reverse proxy, or custom authentication flow.
Quick answer
Update Core immediately, preserve login request logs, compare core and writable PHP files against a known-good baseline, inspect recently created administrators and application passwords, rotate exposed credentials where evidence warrants it, and verify that suspicious input is returned as harmless encoded text or rejected. Do not replay a weaponized payload on production.
What to check first
- Collect wp-login.php requests with timestamp, query string, status, referrer, user agent, source network, WAF action, and upstream request ID.
- Search Core, mu-plugins, plugins, themes, uploads, cache, and temporary directories for recently changed PHP or executable files.
- Review new administrators, password resets, application passwords, sessions, scheduled tasks, options, and unexpected plugin activation.
- Compare the affected public login response at the origin and CDN after installing WordPress 7.0.3 and purging cache.
- Separate ordinary scanner traffic from evidence of execution by correlating requests with file, process, outbound network, and authentication changes.
Why this usually happens
- Reflected XSS places attacker-controlled input into a response without the encoding required for that context.
- A login boundary is reachable before authentication and may be copied through proxies, logs, or security products.
- File integrity alone misses account, session, option, scheduled-task, and outbound-network persistence.
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 core verify-checksums
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp user application-password list USER_ID
find wp-content -type f -name '*.php' -mtime -14 -print
# Preserve matching proxy and WAF request IDs before log rotation.
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 | Collect wp-login.php requests with timestamp, query string, status, referrer, user agent, source network, WAF action, and upstream request ID. | The running site reports WordPress 7.0.3 and core checksums are understood. |
| Preserve login request evidence | Search Core, mu-plugins, plugins, themes, uploads, cache, and temporary directories for recently changed PHP or executable files. | A benign reflected-input fixture cannot create executable login-page markup. |
| Audit files and identities | Review new administrators, password resets, application passwords, sessions, scheduled tasks, options, and unexpected plugin activation. | Recent privileged identities, sessions, files, scheduled tasks, and application passwords are approved. |
| Contain confirmed compromise | Compare the affected public login response at the origin and CDN after installing WordPress 7.0.3 and purging cache. | CDN, WAF, origin, and audit evidence is preserved for the defined monitoring window. |
Decision rule
Escalate to a full incident when a suspicious login request correlates with changed executable files, an unknown privileged identity, unexplained outbound traffic, modified scheduled tasks, or another persistence signal.
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 |
|---|
| Anonymous login request | Benign marker containing encoded special characters | Response contains no executable marker and security headers remain intact |
| Core integrity | Checksum and deployment manifest comparison | No unexplained Core modification or writable executable appears |
| Identity | Admin users, sessions, resets, and application passwords | Every recent security-sensitive change maps to an approved person or workflow |
| Network | Outbound DNS and HTTP evidence around suspicious requests | No unexplained callback or internal service access is present |
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
- Preserve login request evidence
- Audit files and identities
- Contain confirmed compromise
- Retest login and monitor
Production verification checklist
- The running site reports WordPress 7.0.3 and core checksums are understood.
- A benign reflected-input fixture cannot create executable login-page markup.
- Recent privileged identities, sessions, files, scheduled tasks, and application passwords are approved.
- CDN, WAF, origin, and audit evidence is preserved for the defined monitoring window.
What to tell the client or owner
Share the public hostname, Core version, suspect request IDs and timestamps, WAF result, changed-file list, admin and application-password changes, outbound connections, containment steps, and backup reference.
Mistakes to avoid
- Do not replay public exploit code on production.
- Do not delete suspicious files before recording evidence.
- Do not assume a WAF block means every variant was blocked.
- Do not rotate logs before preserving the relevant request window.
Questions teams ask during testing
Does the attacker need a WordPress account?
The WordPress release describes the login-screen issue as pre-authentication, so an account is not required to reach the affected boundary.
Does a suspicious request prove code execution?
No. Correlate it with file, process, identity, outbound-network, and application evidence.
Is patching enough after evidence of compromise?
No. A confirmed compromise requires containment, credential review, persistence removal, recovery, and monitoring.
When HandL WP should help
HandL WP can correlate CDN, WAF, login, file, identity, and outbound-network evidence, then patch, contain, recover, and verify a WordPress site without destroying the incident trail.
If this is active on a production site, investigate a WordPress security incident.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Reconcile user email changes after account review
Use the WordPress 7.0.3 email confirmation and user contact audit to join recent address changes with authorization, mail delivery, sessions, and account alerts.
Helpful references