Every file scan is clean, yet public pages still load an unfamiliar script. The injection may live in post content, a Custom HTML block, widget, reusable pattern or page-builder record. WordPress then serves it legitimately from the database.
Do not run a global search-and-replace across the database. Builder data and WordPress settings can be serialised or structured, and legitimate analytics code may resemble the injection.
Preserve the affected response and database
Save the logged-out HTML, affected URLs, script hostname and timestamp. Export a consistent database backup and restrict it because it can contain users, form entries and customer data.
Record whether the script appears on every page, one template or a small set of posts. A global footer widget has a different owner from one compromised article.
Do not click or request the payload domain beyond capturing your own page’s network evidence.
Locate the database source
Search for a distinctive hostname, filename or code fragment using a WordPress-aware tool. Review posts, post meta, options, widgets, reusable blocks, navigation and builder-specific tables.
A read-only SQL search can help on a copy, but table prefixes and storage formats vary. Do not paste malicious code directly into a shell command where quoting could execute or corrupt the search.
Search for encoded and decoded indicators only within an isolated working copy.
Map the record to a visible owner
Identify post ID, type, status, language and editor. For options, determine the plugin/theme that owns the key. For page builders, find the template or global section that renders it.
Check revision history and audit logs to establish when and by whom the value changed. An unknown administrator session may have used normal editing rather than a file exploit.
Preserve the malicious revision before removing it, but keep it inaccessible to public visitors.
Remove the smallest confirmed payload
Use the WordPress editor or the owning plugin’s supported interface where possible. For structured builder content, remove the exact widget/block and regenerate its output.
If direct database work is necessary, use a staging copy and WordPress APIs that preserve serialisation. Export the row and record before/after values with sensitive content redacted.
Never use a blanket SQL REPLACE across wp_posts and wp_options. It can alter legitimate text and break serialised string lengths.
Check cached and generated copies
The injected value may have been compiled into a page-builder CSS/JS file, minification bundle, full-page cache or CDN response.
After the database source is clean, regenerate only affected builder assets and purge targeted page/CDN URLs. Clear opcode/object cache through supported controls where relevant.
Do not purge first if the cached response is needed as incident evidence.
Find how the database changed
Review administrators, application passwords, editor roles, plugin vulnerabilities, SFTP/panel and database access. Check audit and web logs around the saved revision.
Patch vulnerable editing or API endpoints, remove unknown users and rotate affected credentials after securing administrator devices.
Inspect scheduled tasks and snippet plugins that could reinsert the script.
Verify all render paths
Search the clean database and public HTML for the old hostname. Test desktop/mobile, logged-out, languages, email templates and WooCommerce pages that reuse global blocks.
Monitor record changes and administrator actions beyond the previous recurrence interval. Confirm legitimate editors can still update the affected content.
When specialist cleanup is useful
Request help when builder data is serialised, the script appears globally or account attribution is unclear. Send affected public URLs and the external hostname, not the database dump.
A complete cleanup removes the stored payload, compiled copies and the access route that inserted it.