Stillward Security

Stillward Security follows one rule: protect, don’t disturb.

Most security plugins break sites by aggressively filtering requests, stripping

form data, whitelisting file types, or forcing strict policies. Stillward ships

with only non-breaking hardening enabled by default. Anything that can affect

how your site works is turned OFF until you knowingly enable it.

Enabled by default (safe on any site):

• Security headers — X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy

• WordPress hardening — hide version, generic login errors, disable the file editor, remove head meta leaks

• Block username enumeration — stops?author=N probes and the public REST users list

• Brute-force login protection — IP lockout after too many failed logins

• Upload protection — blocks executable uploads (.php,.exe…) and disables PHP execution in /uploads (normal media and documents still upload)

Opt-in (off by default — enable knowingly):

• Disable XML-RPC (leave off if you use Jetpack or the WP mobile app)

• HSTS header (HTTPS-only sites)

• Content-Security-Policy (test carefully)

• Strict MIME whitelist

• Custom (hidden) login URL

• Request firewall — SQLi/XSS/traversal detection. It NEVER edits your submitted

data, runs in log-only mode by default, and only blocks if you switch it to

Block mode.

• Auto-clean for the Malware Shield. Scanning is on and reports what it finds;

removing anything automatically is your decision. You can also clean once, on

demand, with the “Scan & clean” button.

Malware Shield — and why it will not eat your files

php /

php drop-ins, vapor-* / host-*-bridge mu-plugins, injected

php, sc_* options and cron). Deleting a legitimate file is

worse than the malware, so three gates must all pass before anything is removed:

• Confidence — only an exact marker unique to this malware family can lead

to a removal. The generic “obfuscated code” heuristic is report-only, because

licence loaders, packers and minified libraries look exactly like that.

• Location — removal is limited to the places this family actually drops

files: the three wp-content drop-ins, mu-plugins, PHP files in /uploads,

the wp-content/cache staging copy, filenames it is known to plant, and any

file in wp-includes / wp-admin /the web root that the official WordPress

checksum manifest says WordPress does not ship.

A file that IS part of a real plugin, theme or WordPress itself is never

deleted — it is reported instead, because an infected real file needs

reinstalling, not erasing. php is never deleted under any

circumstance.

• Protected paths — this plugin’s own folder and other security/backup

plugins (which legitimately ship malware signatures in their source) are

skipped entirely.

Everything that is removed is copied into the plugin’s own database table

first — never into another file on the server, because a copy of malware on

disk is still malware on disk. If a removal turns out to be a mistake, download

the copy from the Malware Shield tab and put it back. Removed options and cron

events are backed up the same way and restore in one click. An infected theme

php is never modified or deleted: it is reported, so you can

reinstall a clean copy of the theme.

Developers can force report-only behaviour for any path with the

wpss_malware_auto_removable and wpss_malware_protected_paths filters.

Database Audit — the things a file scanner cannot see

A file scanner is blind to a compromise that never writes a file, and that is

not a hypothetical: an SEO-cloaking campaign ran for four months across eight

sites on one hosting account while hourly scans reported clean, because its code

lived in a plugin’s database table, its configuration in an option, its spam in

wp_posts, and its administrators were inserted straight into wp_users.

The audit runs alongside the file scan and asks three questions that have exact

answers:

• Is there an option named after this site’s own hostname? The malware names

its configuration row md5(sha1($host)), so the name is different on every

site and no blocklist can list it — but the same name can be computed here and

looked up. There is no false-positive surface at all. Autoloaded 32-hex option

names in general are raised as a warning.

• Was any administrator created by something other than WordPress?

WP_User::add_role() assigns a boolean, so WordPress only ever writes

s:13:”administrator”;b:1. A row built by hand in SQL writes a string

instead. That single difference found four rogue administrators across those

eight sites and produced no false positives. Duplicate user_login values are

treated the same way — WordPress will not create one.

• Does any content belong to a user that does not exist? And were large

batches of posts written within a single second? A legitimate import looks

identical to an injection here, so both are warnings with a one-click “It was

me” that stops that exact fact being reported again.

Nothing found in the database is ever changed automatically. A confirmed rogue

administrator can be demoted to Subscriber with its sessions ended and password

reset — never deleted — and the previous role, capabilities and password hash go

into quarantine first so Restore puts the account back exactly as it was.

Critical findings are e-mailed the moment they are recorded: once per distinct

finding per day, at most twelve an hour, and only for findings that mean

something got in. Routine lockouts and firewall blocks are logged but never

mailed, because an alert that is always noise teaches people to ignore alerts.

Safety guarantees

• The firewall only reads requests — it never modifies or strips POST data, so

it cannot break form nonces or submissions.

• Deactivating the plugin is non-destructive: it does not touch wp-login.php,

htaccess, your options or logs.

• No per-request database writes — only real security events are logged.