An infected service worker can keep redirecting or modifying requests in a browser after the WordPress files are clean because it has its own lifecycle and cache. Prove what script is registered, its scope and which origin response installed it before treating every persistent redirect as reinfection.
Inspect registration in an affected browser
Use browser application tools to record service-worker script URL, scope, state and caches. Compare with a clean profile to separate persisted client state from current server behavior.
Fetch the worker script from the network
Bypass browser cache and inspect the current script served at its URL. If the network version is clean but an old worker remains active, the recovery path is client lifecycle/cache.
Find what registered it
Search legitimate theme/plugin/PWA code and injected scripts for the registration URL. Removing the worker without removing an unauthorized registration source allows it to return.
Clear server and edge copies first
Ensure origin and CDN no longer serve the malicious worker or cache payload. A browser unregister is temporary if the same URL still returns compromised code.
Invalidate the client lifecycle
Unregister the unauthorized worker, clear its caches/site data as appropriate and reload under controlled conditions. Test both previously affected and fresh browser profiles.
Verify no reinstall occurs
Navigate representative pages and wait through update checks. Confirm the worker stays absent or matches the legitimate version and redirects do not return.
Compare server-side injection with unknown JavaScript on every WordPress page, then use post-cleanup verification.