Infected files and the website cache
Two things that live next to each other on a server that scans for malware and caches pages: what the scanner found in your files, and how to clear the cache of your website when a change is not showing up.
Written for: Customer, Reseller, Administrator
Two things that live next to each other on a server that scans for malware and caches pages: what the scanner found in your files, and how to clear the cache of your website when a change is not showing up.
Neither of them needs a support ticket.
What the scanner found
Servers running the CoreCP malware scanner watch every website's document root and every mailbox store, all the time. When a file matches a known signature it is written down as a detection: the path, why it matched, and what has happened to it since.
You see only your own paths. Another customer on the same server sees theirs, and neither of you sees the other's — the server resolves who owns a file from its own record of your account, not from a name the scanner wrote.
Reading the list
corectl cpguard detections --account <your-account>ID ACCOUNT REASON STATUS PATH
1041 demo virus found /home/demo/domains/example.com/public_html/x.phpThe columns:
| column | what it means |
|---|---|
| Reason | virus (a known signature), suspicious (looks like obfuscated code), binary (an executable where there should not be one) |
| Status | found — nothing has happened to it yet · quarantined — moved out of the way · disabled — still there, no longer readable by the web server · deleted · cleaned — the malicious part was removed and the file kept |
--status open shows only the ones nobody has dealt with.
Doing something about one
corectl cpguard act quarantine --id 1041 --account <your-account>Four actions, in order of how much they undo:
- Quarantine — the file is moved out of your website into the scanner's own store. Your site stops serving it. This is the one to use when you are not sure: it is reversible.
- Restore — put a quarantined file back where it was. Use it when the scanner was wrong about a file you recognise.
- Disable — leave the file where it is and make it unreadable. Useful when something else on the site expects the path to exist.
- Delete — gone. There is no undo, and there is no copy: take a backup first if the file might matter.
A word about false positives. A minified JavaScript library and a packed malware dropper look alike to a signature scanner. If you recognise the file and know where it came from, restore it — and if it keeps being flagged, ask your provider to whitelist the path rather than restoring it every week.
After you clean up
Ask for a fresh scan of your own space, so the list reflects what is true now:
corectl cpguard scan start --account <your-account>A scan of a whole account takes a few minutes and runs in the background. One website is quicker:
corectl cpguard scan start --domain example.comClearing a website's cache
Servers running LiteSpeed keep a copy of pages they have already built, so the next visitor gets one without the work. That is why a change sometimes does not show up: you are looking at the copy.
corectl litespeed purge example.com --account <your-account>It answers with how much it dropped:
purged the LSCache for example.com: 214 file(s), 3.1 MBNothing is lost. The next visit to each page builds it again — the first one is a little slower, and every one after that is not.
When to use it
- After changing a template, a stylesheet or an image and seeing the old one.
- After a plugin or theme update on any kind of site.
- After changing something that only some visitors see (a price, a banner) and wanting everybody on the new version now.
What it is not
- Not a WordPress thing. This is the web server's own cache, so it works for a plain HTML site, a Laravel application or anything else. A WordPress cache plugin is a second cache on top of it; clearing one does not clear the other.
- Not a fix for a broken page. If a page is wrong after a purge, it is wrong in the code — the cache was showing you a correct copy of a broken page.
- Not something to do on a schedule. A cache that is emptied every hour is a cache nobody benefits from.
Where this lives on a server that has neither
Both features depend on what the server carries. A server without the malware scanner has no detections to show, and one that runs nginx has no LiteSpeed cache to purge — the commands say so plainly rather than pretending. Your provider decides which servers carry what.
When something is not right
"Unknown action" or "no scanner on this server". Then this server does not run the malware scanner. Ask your provider which server your account is on.
A detection keeps coming back after you restore it. The scanner recognises the file again every round. Ask your provider to whitelist the path rather than restoring it every week.
Clearing the cache did not help. Check whether your site has a cache plugin of its own — that is a second layer and has to be cleared separately:
corectl litespeed purge example.com --account <your-account>If the page is still wrong after that, it is in the code and not in the cache.