A malicious service worker can persist in a visitor’s browser scope and intercept requests even after the visible WordPress payload has been removed. It is uncommon compared with ordinary injected JavaScript, but it matters when redirects or fake pages continue for previously affected visitors.
Symptoms
- Some visitors keep seeing redirects after the server-side infection appears clean.
- A service worker is registered for an unexpected path or script file.
- Browser developer tools show cached responses or request interception not explained by the site stack.
- The problem differs between fresh browser profiles and previously affected profiles.
Indicators of compromise
These indicators help investigation but should be interpreted in context. A single item does not automatically prove compromise.
How this threat persists
The service worker may be registered by injected JavaScript delivered through a compromised theme, plugin, database option or external script. Cleaning the server payload and unregistering the worker are separate steps.
Investigation and recovery
- Identify and remove the server-side script that registers the worker.
- Remove the malicious service-worker file from the website.
- Verify headers and paths so the worker cannot be re-registered.
- Document browser cleanup steps for affected administrators or testers.
- Re-scan WordPress for the original compromise and persistence.
WP•FIX treats security incidents as root-cause investigations. The goal is not only to remove the visible payload, but also to identify the persistence mechanism and the access path that allowed the compromise.
Prevention after cleanup
Prevention depends on the actual entry point. Common controls include verified software sources, prompt patching of vulnerable components, credential rotation after compromise, least-privilege administrator access, clean backups, file-change monitoring and review of hosting/CDN/security logs.
FAQ
Can a service worker survive a normal page refresh?
Yes. Service workers are designed to persist across visits until replaced or unregistered.
Does deleting browser cache remove a service worker?
Not always. Browsers manage service workers separately from ordinary HTTP cache.
Is every service worker malicious?
No. PWAs and performance features legitimately use them. The concern is an unexpected worker or one loading malicious content.
Why is WordPress cleanup still required?
Something on the site had to register or serve the malicious worker. That source must be removed or it can return.
Seeing signs of Malicious Service Worker?
Send the site URL and the exact behavior you or visitors see. Include screenshots or warning text when available.
Open a security incident