A scanner flags eval, base64 text or unreadable variable names inside a plugin. Obfuscation is suspicious in ordinary WordPress code, but some commercial plugins protect licensed logic and some harmless libraries contain encoded data.
Do not execute or “decode” the file on the live server. Establish provenance and compare it with a verified package first.
Quarantine a copy and preserve metadata
Record plugin name, version, source, file path, owner, permissions and modification time. Hash the installed file and copy it outside the web root with restricted access.
Preserve the complete plugin directory. A single flagged line may call or be called by another file.
Do not rename the live plugin directory during a busy checkout without checking dependencies. If active malicious behaviour is likely, use a controlled maintenance state and documented rollback.
Verify the plugin’s origin
Check whether the plugin came from WordPress.org, the vendor account, a developer repository or an unknown ZIP. Compare version and package checksum or signature where the source provides one.
Download a fresh package only from the official source using a clean administrator device. Hash and compare corresponding files offline.
An exact match does not guarantee the vendor package is safe, but it distinguishes local modification from shipped code and supports escalation to the vendor.
Inspect without evaluating
Use text tools on the offline copy to locate suspicious functions and long encoded strings. Review surrounding control flow: when the code runs, what input reaches it and what filesystem, database or network actions follow.
Do not feed the encoded value into PHP eval, a browser console or an online decoder. Static decoding, if necessary, should occur in an isolated environment without network access and without invoking the result.
Keep the decoded output as untrusted evidence.
Look for behaviour, not one keyword
Malicious patterns can include hidden remote requests, creation of administrator users, executable writes, dynamic includes, cron persistence and condition-based redirects.
Legitimate code can also use base64 for icons, certificates or compact data. eval and remote code loading deserve stronger scrutiny, but context and provenance decide the finding.
Search for external domains, writable paths and hooks used by the suspicious block. Do not browse attacker infrastructure.
Compare timestamps and account activity
If the installed file differs from the verified package, determine when it changed and whether other files changed around the same time. Check deployment, update, SFTP and hosting logs.
A modified plugin can be the payload location without being the original vulnerability. Review WordPress users, application passwords, panel access and neighbouring installations.
Preserve logs before rotating credentials or restoring backups.
Replace safely when trust is lost
Take a database/files backup and export legitimate plugin settings. Remove the compromised directory completely, then install a verified clean package at a patched version.
Do not copy unknown files from the old directory into the new one. Manually migrate only reviewed custom templates or configuration.
If no trustworthy source or maintained replacement exists, leave the plugin disabled and plan a functional alternative.
Verify the whole site
Search for related hashes, strings and domains across files and database. Inspect scheduled tasks, uploads and must-use plugins for persistence.
Test the plugin’s required feature, forms and checkout after clean installation. Monitor file integrity and outbound requests for reappearance.
When expert review is warranted
Request an assessment when the package source is unknown, code differs from the vendor version or the plugin handles payments, uploads or authentication. Provide name, version, path and hash—never the live payload through a contact form.
A reliable finding explains provenance, behaviour, replacement and the wider compromise route rather than labelling every encoded string as malware.