Plesk or its security extension reports malware under several subscriptions. The incident may involve separate vulnerable sites, a compromised administrator/reseller account, shared deployment access or a server-level process.
Do not assume subscription isolation worked merely because document roots differ.
Preserve the Plesk report
Export detection paths, signatures, timestamps, quarantine actions and subscription/system-user mapping. Record Plesk and security-extension versions.
Ask the host to retain panel authentication, service and file-change logs. Do not make the raw report public; it exposes usernames and server paths.
Keep quarantined samples inaccessible and unexecuted.
Determine the common boundary
Map each domain to subscription, system user, PHP handler, database user, SFTP account and deployment repository. Identify shared administrator, reseller, extension and backup credentials.
Check whether subscriptions use distinct filesystem ownership and whether custom permissions or symlinks bypass separation.
If only one system user is affected, scope can differ from a server-wide root compromise.
Contain without destroying attribution
Suspend or restrict affected subscriptions according to business impact while preserving files/databases/logs. Keep a known-clean status page where appropriate.
Revoke unknown Plesk sessions and secure the administrator/reseller email and multi-factor methods.
Do not restart or rebuild the entire server before collecting volatile/recent logs unless active harm requires emergency action.
Review server-level persistence
With authorised administrator/provider support, inspect scheduled tasks, additional administrator accounts, SSH keys, PHP auto_prepend_file, web-server includes and extensions.
Subscription owners should not attempt root-level commands beyond their authority. Ask the provider to verify package integrity and operating-system compromise indicators.
WordPress cleanup cannot remove a server cron running as a privileged user.
Clean by subscription
For each site, preserve a snapshot, rebuild trusted WordPress packages, review custom code and clean database/users/cron. Patch vulnerable components and retire forgotten roots.
Use clean per-subscription credentials. Do not copy one repaired installation over another with a different configuration.
Track a manifest and status for each domain to avoid reopening an unverified site.
Inspect backups and Plesk migration artefacts
Plesk backups can include subscription files, databases, mail and panel configuration. Record which repository created each archive, its date and whether the compromised administrator could alter it.
Restore a candidate only into an isolated subscription with outbound mail, cron and payment effects disabled. Review migration dumps and temporary directories that may sit outside ordinary document roots.
If a scheduled backup repeatedly restores or synchronises infected content, pause that job after preserving its definition. Rebuild the schedule to use the clean subscription and verify its remote-storage credentials have been rotated.
Repair isolation and access
Separate system/database/deployment users, remove shared FTP and correct ownership through Plesk-supported controls. Rotate panel, SFTP, database, WordPress and relevant API secrets.
Review Plesk extensions and update sources. A compromised deployment key or backup server can affect several otherwise isolated subscriptions.
Move high-risk staging away from production subscriptions.
Verify the server and sites
Rerun provider/Plesk scans plus independent package/database/user checks. Restore sites gradually and monitor write events, authentication and outbound requests.
Test forms, email and authorised WooCommerce flows per subscription. Confirm scheduled backups use the clean roots.
Observe beyond the previous recurrence and at least one full scheduled-task cycle.
Check Plesk’s event handlers as well. A custom handler can run after subscription, domain or certificate events and affect multiple system users. Export each handler, identify its owner and inspect referenced scripts offline before enabling normal panel automation again.
When server expertise is required
Request specialist/provider intervention when different system users change simultaneously, privileged tasks are suspicious or panel integrity is uncertain. Share redacted detection summaries, not root credentials.
The goal is verified server control and isolated clean subscriptions, not simply clearing the Plesk alert list.