Quick summary
A WordPress security note about preserving forensic evidence, tracing a browser warning to injected database JavaScript, and validating the rest of the installation before closing the incident.
The problem
A production WordPress site had been flagged for deceptive pages even though the obvious infected files had already been neutralized, which meant the remaining payload could be hiding outside the normal theme and plugin paths.
What I checked
- Production database options, page-builder content, revisions, snippets, and user metadata
- WordPress core files against official checksums
- Supported plugins against version-specific file manifests
- Premium plugins, themes, must-use plugins, uploads, and external script domains
- Administrator access, registration settings, server rules, and local malware scans
What I changed
- Preserved an untouched database export and hashed forensic file copy before remediation
- Removed the obfuscated JavaScript payload from the affected database option
- Deactivated an unnecessary file-manager plugin and disabled dashboard file editing
- Produced a cleaned local database while retaining the original evidence separately
- Documented the sweep, validation results, and remaining monitoring steps
Result
The hidden database payload was removed, core and supported plugin files were validated, and the cleanup retained enough evidence to explain the warning without making destructive guesses in production.
Where this fix usually leads next
This kind of work usually connects back to WordPress Support and Production Debugging so the fix note can lead into a clearer support path instead of staying as an isolated one-off task.
What I'd watch next
- Whether the external warning clears after the provider reviews the cleaned site
- Whether monitoring detects the same option or script pattern returning
- Whether access logs reveal the original entry point