Active WordPress incident? Initial assessment within 4 hours. (Mon–Fri 8am–8pm, Sat 9am–2pm (CET/CEST))

Resources

Why deleting an infected WordPress plugin is not enough

Paths of compromise after a vulnerable WordPress plugin

A vulnerable or modified plugin may have been the entry point, but successful code execution can already have changed other files, database values, accounts, or scheduled jobs. Deleting the plugin therefore rules out neither persistence nor stolen credentials. Reliable recovery requires preservation, scope review, clean replacement, credential rotation, and controlled verification.

What code execution may change

  • create or modify PHP files elsewhere
  • add administrators or application passwords
  • inject database content and redirects
  • schedule recurring tasks
  • read configuration and credentials

The plugin may be the entry point, payload, or merely one discovered location. Timestamps, logs, and known vulnerabilities help with attribution but may be incomplete.

Grenze / Limit

The disappearance of a scanner warning does not prove that no second backdoor remains.

Replace the affected component from a verified source or remove it permanently. Then review files, database, accounts, and schedulers; rotate secrets; and test the application.

Was the plugin the entry point or only the location?

Version history, known vulnerabilities, requests, file changes, and surrounding evidence are needed to tell. An attacker with valid administration access can write malware into an arbitrary plugin directory. Conversely, a vulnerable extension may be the entry point while the later webshell sits elsewhere.

Preserve the plugin version, source, hashes, timestamps, and relevant requests. “Plugin X caused the incident” is defensible only when the timeline supports the exploitation path. A published vulnerability alone is not proof of exploitation.

What else needs inspection?

Review core, other plugins, themes, must-use plugins, uploads, caches, database options, administrators, application passwords, and scheduled tasks. Include parent hosting directories and other sites in the same account. Secrets in wp-config.php, deployment, and hosting deserve attention because executed PHP may have read them.

The guide to webshells and persistence maps these layers.

What makes the replacement trustworthy?

Reinstall the required version from the official directory or a verified vendor source. Do not carry unknown files out of the compromised directory. Custom code needs a controlled repository or reviewed baseline.

After replacement, perform functional checks, search again for the indicators, and rotate affected secrets. If the cause remains uncertain, record that limitation and monitor accordingly.

Sources

  1. WordPress: Hardening WordPress
  2. WordPress: FAQ My site was hacked

Site affected? We assess it for free.