Nightly Malware Scans
Every live website on Oxyforge has its files scanned automatically each night. Staging copies are not scanned. You do not switch it on and there is nothing to configure.
That is useful, and it is worth being clear about what it is and is not. A scan is a net that catches known bad files. It is one layer among several, and the layers that matter most are the ones you control.
What The Nightly Scan Does
Each night the scanner reads through the files of every website and compares them against known malware and web shell signatures, checks every WordPress core and plugin file against its official checksum, and looks for the usual patterns of injected code. In practice most findings are files that no longer match what WordPress or the plugin author shipped. The usual catches are a backdoor dropped into the uploads folder, obfuscated PHP added to the top of a theme file, a fake plugin folder with a plausible name, and spam content written into files that should only contain code.
If something is found, it is flagged to our team the same night, and a person looks at it before anyone acts. Nothing is deleted or quarantined automatically, because a scanner cannot safely pull files out of a working site without risking breaking it. If your site needs attention a person contacts you, and the decision on what to do is yours.
What The Scan Cannot Promise
A scan finds known bad files. It is not a guarantee. New malware, a clever enough obfuscation, or an attack that lives in your database rather than in a file can all pass a signature scan. Treat a clean scan as reassuring, not as proof.
The real defence is unglamorous and it is almost entirely in your hands:
- Keep WordPress, your theme and your plugins updated. The overwhelming majority of compromised WordPress sites were running a version of something with a publicly known hole, often one that had been patched months earlier.
- Use strong, unique passwords for your WordPress administrators and for your Oxyforge account. Reused passwords are how a leak somewhere else becomes a problem here.
- Delete plugins and themes you do not use. A deactivated plugin still has its files on disk and can still be reachable. Deactivating is not removing.
- Keep the number of administrators small. Every administrator is another way in.
Nothing on the platform substitutes for those four. They are the difference between a site that gets compromised and a site that does not.
The Platform Side
Several things are in place around your site to limit what an attacker can do if they do get in.
XML-RPC answers Jetpack only by default. XML-RPC is an old WordPress interface that is useful to very few sites and extremely useful to attackers, because it lets them attempt many password guesses in a single request and can be abused to flood other servers. Here it answers Jetpack and nothing else, which blocks bulk password guessing while Jetpack keeps working. If an app genuinely needs it, such as an older mobile publishing tool or a specific integration, it can be opened fully for a single website from that site’s Tools tab. Open it only if something you use actually requires it.
Each website runs in its own isolated container with its own system user. Nothing on the platform can read another customer’s files. A compromise on one website cannot walk across into another, not even another of your own.
Every site has a ceiling on how fast it can send data out. This is traffic the site itself sends, such as a plugin calling another server, not what visitors download. This is the quiet one that matters. Most of the damage a compromised site does is outbound: serving spam, attacking other servers, exfiltrating data. A hard limit on outbound speed caps how much harm a site can do before anyone notices, and it also caps the bill. See bandwidth explained.
| Layer | What it protects against | Who controls it |
|---|---|---|
| Nightly file scan | Known malware already on disk | Us |
| XML-RPC restricted to Jetpack | Password guessing at volume | Us, overridable per site |
| Container isolation | One site reaching another | Us |
| Outbound rate ceiling | Damage from a compromised site | Us |
| Updates and passwords | Getting in at all | You |
| Backups | Everything, after the fact | Both |
If A Site Is Compromised
Work in this order. Doing it out of order is the usual reason a site gets reinfected within a week.
Restore a backup from before the infection. This is the first move, not the last. Cleaning malware out of a live site by hand means finding every file an attacker touched, and you only need to miss one. A restore replaces the whole set. See restore a backup. If you are unsure when the infection started, go back further than you think you need to.
Then update everything. WordPress core, every theme, every plugin. You have restored a site that still has whatever hole let them in, so this step is not optional and it has to happen immediately.
Then change passwords and keys. Every WordPress administrator, your Oxyforge account, and the password on any service the site connects to. Remove and re-add your SSH keys on the SFTP tab. Your database credentials are managed by us; open a ticket if you want them rotated. Assume anything stored on the site was read.
If you cannot find a clean backup, or the site is reinfected after a restore, open a ticket from the members area and tell us what you have already tried.
What To Expect Day To Day
For most sites the answer is nothing. The scan runs overnight, finds nothing, and you never hear about it. If you want to shut a site away from the public entirely while you work on it, you can put it behind a password instead. See password-protect a website.
Did this answer it? If not, open a ticket from the members area and someone who runs the platform will pick it up.
Open A Ticket