Title: SecureLite Security
Author: Naveen Kumar
Published: October 15, 2026
Last modified: October 15, 2026
---
Search plugins
# SecureLite Security
By [Naveen Kumar](https://profiles.wordpress.org/naveenfriendly/)
[Download](https://downloads.wordpress.org/plugin/securelite-security.0.2.14.zip)
* [Details](https://wordpress.org/plugins/securelite-security/#description)
* [Reviews](https://wordpress.org/plugins/securelite-security/#reviews)
* [Installation](https://wordpress.org/plugins/securelite-security/#installation)
* [Development](https://wordpress.org/plugins/securelite-security/#developers)
[Support](https://wordpress.org/support/plugin/securelite-security/)
## Description
Most security plugins give you a list of switches and leave you hoping they work.
SecureLite adds a button that finds out.
**Run Attack Simulation** fires thirteen real but harmless checks at your own site
over loopback — SQL injection, XSS, directory traversal, user enumeration, brute
force, malicious and executable uploads, XML-RPC abuse, scanner signatures, a planted
malware sample, PHP execution in your uploads folder, and whether your .git directory
or readme.html can be downloaded by anyone — then reports, per protection, whether
it actually blocked, is switched off, or failed. Where a setting would fix it, an
Enable & re-test button is right there. The result is a printable report you can
hand to a client.
Everything runs on your site. There is no reverse proxy in front of your domain,
so your caching, your CDN and your visitors’ real IP addresses all keep working
exactly as they did.
#### Protection
* **Firewall** — inspects query strings, POST bodies, cookies, URLs and user agents
for SQL injection, XSS, directory traversal and known scanner tools. Monitor
mode first, then block when you’re confident. Editors and authors can save a
post that explains `javascript:` links or quotes an `onclick=` attribute without
the firewall refusing it.
* **Malicious upload blocking** — a virtual patch for the executable-upload vulnerability
class, including PHP disguised with an image extension.
* **Brute-force lockout** — persistent per-IP and per-username, surviving cache
flushes. Addresses that keep coming back are locked for longer each time, up
to 24 hours. Guesses at “admin” count double. Login errors never disclose whether
a username exists. A locked username still opens for the right password, so nobody
can lock you out of your own account by knowing your login name.
* **Two-factor authentication** — scan a QR code with any authenticator app (TOTP,
RFC 6238). The QR code is drawn on your own server, so your key never leaves
it. You cannot switch it on until you have entered a code your app actually produced,
each code signs you in only once, and ten single-use recovery codes are issued
at the same time.
* **Hidden login URL** — serve wp-login.php at a secret slug and 404 the default.
The new address is tested before it is kept, and emailed to you.
* **Malware and injection scanning** — every WordPress core file is compared with
the official release, so a web shell dropped into wp-includes or the site root,
or a changed core file, is reported as Critical with certainty. PHP, JavaScript
and HTML elsewhere get signature and heuristic scanning for backdoors, web shells
and packed payloads, and matches in wordpress.org plugins are checked against
the official release so unmodified library code is not reported as malware. The
database is scanned for injected fake-captcha and redirect scripts that a file
scanner would never find.
* **File-integrity monitoring** — event-driven, with a lightweight sweep over the
paths attackers actually touch: wp-config.php, .htaccess, mu-plugins, dropins,
theme functions.php, and any PHP appearing in uploads.
* **Rate limiting** — caps requests per IP before the page renders, with a tighter
budget for unauthenticated admin-ajax.
* **Uploads PHP check** — the exact rule, for Apache/LiteSpeed (.htaccess) or nginx,
that stops PHP executing in your uploads folder, and an Attack Simulation check
that confirms your server enforces it. SecureLite never edits .htaccess or any
other server configuration file itself.
* **Posture scoring** — a local security score with prioritized findings and one-
click fixes.
* **Notifications** — a daily summary and two immediate alerts, sent by your own
site. Never one email per blocked request.
* **Post-hack recovery** — log everyone out, regenerate salts, reset passwords,
rename the user 1 account.
* **Trusted IPs** — exempt your own address or office range from the lockout and
rate limiter, so you can’t shut yourself out.
* **Works behind Cloudflare and proxies** — a Cloudflare preset and a trusted-proxy
list, so lockouts see each visitor’s real address. Forwarded IP headers are only
believed when the connection really comes from a trusted proxy, so they cannot
be forged to dodge a lockout.
* **Clean removal** — the only file SecureLite writes is wp-config.php, and only
when you switch a setting that lives there (the file editor, your trusted-IP
line, regenerating keys and salts). Deactivating gives those lines back and reactivating
restores them; uninstalling removes them, its tables and its settings entirely.
Nothing of this plugin outlives it.
#### What’s coming next
SecureLite is new, and these are planned — no dates promised, and nothing already
in the plugin will ever move behind a paywall:
* An emailed unlock link on the lockout screen, so getting back in never needs
FTP.
* Optional alerts when an installed plugin has a known vulnerability, clearly disclosed
and off unless you turn it on.
* A dashboard for agencies looking after many sites.
Tell us what you’d like next in the support forum.
#### What this plugin is not
A PHP plugin cannot stop a volumetric DDoS, and SecureLite does not claim to. For
that you want Cloudflare or server-level rate limiting in front of the site. SecureLite
owns the depth on the site itself.
#### Need help?
**Free support** is on the WordPress.org support forum, answered by the people who
build SecureLite. Every feature is free, so you never need to buy anything to get
help.
**Need hands-on help?** SecureLite is made by PixelGravitas, a website maintenance
and security team.
* Site already hacked? We remove the malware and close the way in, for a fixed
fee agreed before work starts: [WordPress malware removal](https://pixelgravitas.com/website-maintenance/malware-removal/)
* A check needs server-level changes, or you would rather someone looked after
the site: [WordPress maintenance and support](https://pixelgravitas.com/website-maintenance/wordpress/)
### External Services
SecureLite does not send telemetry and does not require an account or an API key.
All processing happens on your own server and all security data stays in your own
database.
**WordPress.org checksums.** During a malware scan, SecureLite requests the official
file checksums for your WordPress release from `https://api.wordpress.org/core/checksums/
1.0/` (sending the WordPress version and locale), and for wordpress.org plugins
that matched a scanner pattern from `https://downloads.wordpress.org/plugin-checksums/`(
sending the plugin’s folder name and version). When core files do not match the
installed release, it also asks `https://api.wordpress.org/core/version-check/1.7/`
for the newest WordPress version (nothing is sent) so it can recognise files from
a half-finished update. No site address, user data or file content is sent. Responses
are cached for seven days, the newest-version answer for twelve hours. These are
WordPress.org services: [Terms of Service](https://wordpress.org/about/terms-of-service/),
[Privacy Policy](https://wordpress.org/about/privacy/).
## Screenshots
[⌊Security Verification — thirteen real checks fired at your own site, with an honest
pass, not-enabled or failed result for each, and a printable report.⌉⌊Security Verification—
thirteen real checks fired at your own site, with an honest pass, not-enabled or
failed result for each, and a printable report.⌉[
Security Verification — thirteen real checks fired at your own site, with an honest
pass, not-enabled or failed result for each, and a printable report.
[⌊Dashboard — posture score, recent firewall blocks, and current malware scan findings.⌉⌊
Dashboard — posture score, recent firewall blocks, and current malware scan findings
.⌉[
Dashboard — posture score, recent firewall blocks, and current malware scan findings.
[⌊Firewall — blocked requests with the rule that matched and the parameter it matched
on.⌉⌊Firewall — blocked requests with the rule that matched and the parameter it
matched on.⌉[
Firewall — blocked requests with the rule that matched and the parameter it matched
on.
[⌊Login protection — lockout thresholds, two-factor, hidden login URL and trusted
IPs.⌉⌊Login protection — lockout thresholds, two-factor, hidden login URL and trusted
IPs.⌉[
Login protection — lockout thresholds, two-factor, hidden login URL and trusted
IPs.
[⌊Recovery — log out all sessions, regenerate salts, reset passwords, rename the
user 1 account.⌉⌊Recovery — log out all sessions, regenerate salts, reset passwords,
rename the user 1 account.⌉[
Recovery — log out all sessions, regenerate salts, reset passwords, rename the user
1 account.
## Installation
1. Upload the `securelite-security` folder to `/wp-content/plugins/`, or install the
zip through Plugins > Add New > Upload.
2. Activate through the Plugins screen.
3. Go to **SecureLite > Verification** and click **Run Attack Simulation**. Whatever
is not yet protecting you gets an Enable button right there.
4. Optionally visit **SecureLite > Settings** to tune thresholds, hide your login
URL, or add your own IP as trusted.
The firewall starts in Monitor mode so you can watch what it would have blocked
before enforcing.
## FAQ
### I’m locked out of my own site. How do I get back in?
Any one of these works without logging in:
1. **Wait.** Login pauses for 15 minutes by default, then opens again. An address
that keeps getting locked waits longer, up to 24 hours. The lockout message shows
how long is left.
2. **Trust your address.** Add this line to wp-config.php, above the line that says“
That’s all, stop editing!”, using your own IP address: `define( 'SECURELITE_ALLOW_IP','
203.0.113.45' );`
3. **Switch SecureLite off.** Rename the `wp-content/plugins/securelite-security`
folder to `securelite-security-off` using FTP or your host’s file manager. The
normal login page returns immediately.
4. **With SSH access**, run `wp plugin deactivate securelite-security`.
To be ready before it happens, use **Add my IP to wp-config.php** under Settings
> Login protection. Your own address is then never locked out.
Forgot your hidden login address? It was emailed to the site administrator when
you set it. Otherwise, option 3 restores the normal login page.
Lost the phone with your authenticator app? See the next question.
### How do I set up two-factor, and what if I lose my phone?
Go to **Users > Profile** and scroll to **SecureLite Two-Factor**. Scan the QR code
with an authenticator app (Google Authenticator, Microsoft Authenticator, Authy,
2FAS) by pointing your phone at the screen, type the 6-digit code it shows, tick
the box and click **Update Profile**. If you cannot scan, open “Can’t scan?” and
type the key into the app instead. The QR code is drawn by the plugin on your own
server; your key is never sent anywhere.
SecureLite does not send codes by SMS or email. Your app makes a new code every
30 seconds, even offline, and each code signs you in once.
When two-factor turns on you get ten recovery codes, shown only once. Copy, download
or print them and keep them somewhere other than your phone. If you lose your phone,
type any one of them in the **Authentication code** box on the login page. Each
works once, and you can make a new set from your profile at any time.
Lost your phone and your recovery codes? Any of these gets you back in:
1. **Another administrator** opens Users, edits your account and ticks “Turn off two-
factor authentication for this account”.
2. **Switch SecureLite off** by renaming the `wp-content/plugins/securelite-security`
folder over FTP or your host’s file manager. Sign in with your password, rename
it back, and set up two-factor again.
3. **With SSH access**, run `wp user meta delete securelite_totp_enabled`.
### Will this lock me out of my own site?
Two-factor cannot be switched on until you have proved it works, and it issues ten
single-use recovery codes when you do. Changing your login URL is tested before
the change is kept, and switches itself back off if the new address does not answer.
Lockouts are the remaining case, the same as with any plugin that limits login attempts—
and there are three ways back in. Lockouts expire on their own after the window
you set (15 minutes by default). Adding your IP under Settings > Trusted IPs exempts
you in advance. And if you are already locked out and cannot reach the settings
screen, add this to wp-config.php:
```
define( 'SECURELITE_ALLOW_IP', '203.0.113.45' );
```
You can also rename the `wp-content/plugins/securelite-security` folder over FTP,
or run `wp plugin deactivate securelite-security`. Better still, set it up before
you need it: under Settings > Login protection, **Add my IP to wp-config.php** writes
that line for you, checking the result and putting the original back if anything
goes wrong. If the file is locked by your host, it tells you why and gives you the
exact line to paste. All three ways back in are also on the Support screen and emailed
to you once, the first time you save with login protection on.
### My site is behind Cloudflare. Do I need to change anything?
Yes — turn on **Behind a proxy/CDN** and the **Cloudflare** preset under Settings
> General. Without them every visitor arrives from a Cloudflare address, so a lockout
aimed at one attacker would lock out everyone sharing that edge. The settings screen
tells you when it sees Cloudflare traffic with proxy mode off, and shows which address
SecureLite believes you are connecting from.
That address is then trusted immediately, with every protection still active for
everyone else. File access alone is enough — you never need database access to recover.
One case is deliberately not a lockout at all. If someone attacks your account from
many addresses, your username gets locked — but entering the correct password still
lets you in and clears it. Knowing your login name is not enough to keep you out
of your own site.
### What happens if I deactivate or delete it?
Everything goes back. Outside its own database SecureLite only adds lines to wp-
config.php — DISALLOW_FILE_EDIT and, if you asked for it, your trusted-IP line —
and deactivating hands them back, while activating again restores them. Your settings,
trusted IPs and security log survive deactivation untouched, because deactivating
a plugin is how people troubleshoot.
Deleting the plugin removes all of it: the wp-config.php lines above, both database
tables, every setting, the two-factor secrets and recovery codes, and the scheduled
jobs. It only ever removes its own work — a DISALLOW_FILE_EDIT line that was already
in your wp-config.php is put back the way you had it, and one that another plugin
manages is never touched.
### Does it slow my site down?
The firewall inspects the request before WordPress renders anything and adds well
under a millisecond in normal use. Scanning is scheduled, budgeted and never runs
during a page load. Logged-in administrators are never filtered or rate limited.
### Will the firewall block legitimate traffic?
It ships in Monitor mode precisely so you can find out on your own site before enforcing.
Logged-in administrators are exempt entirely. If something legitimate is caught,
the dashboard shows exactly which rule matched and on which parameter.
### Does it phone home?
No. Nothing about your site, your users or your security events ever leaves your
server. There is no account, no API key, no telemetry and no third-party service.
The one outbound request is to WordPress.org itself, the same servers WordPress
uses for its own updates: the malware scan downloads the official checksums for
your WordPress version and for any wordpress.org plugin it needs to verify, so it
can tell an added or altered file from a genuine one. The request names only the
WordPress version and locale, or the plugin’s folder name and version — not your
site address — and the answer is cached for a week. If WordPress.org cannot be reached,
the scan still runs and says that core could not be compared.
Two commitments come with that, and they are permanent. Nothing in this plugin will
ever require an account or a key to keep working. And no protection will ever behave
differently because you have not connected the plugin to anything — the firewall,
the scanner, the lockout and two-factor do exactly the same job either way, forever.
Every protection runs on your own server, which also means no outage anywhere else
can affect your site, and nobody but you can see your security events.
### Does it write files on my server?
Only wp-config.php, and only when you change a setting that lives there. It is edited
in place — never copied — checked to be valid PHP before saving, read back afterwards,
and restored from memory if the write did not land exactly. SecureLite never writes.
htaccess or other server configuration, and keeps no files in your uploads folder:
for blocking PHP in uploads it shows you the rule to add and checks that your server
enforces it.
### What does it store on my site?
Security events are written to a table in your own database: login attempts, account
and role changes, plugin and theme lifecycle, and firewall matches, each with the
client IP and user agent. The table is a rolling buffer capped at the most recent
entries, so it cannot grow without bound. Uninstalling the plugin drops it completely.
### Is it compatible with WooCommerce, Elementor and page builders?
Yes. Logged-in administrators bypass request filtering, so builder and checkout
traffic is unaffected. If you do hit a false positive, Monitor mode and the firewall
log will show you the rule involved.
## Reviews
There are no reviews for this plugin.
## Contributors & Developers
“SecureLite Security” is open source software. The following people have contributed
to this plugin.
Contributors
* [ Naveen Kumar ](https://profiles.wordpress.org/naveenfriendly/)
[Translate “SecureLite Security” into your language.](https://translate.wordpress.org/projects/wp-plugins/securelite-security)
### Interested in development?
[Browse the code](https://plugins.trac.wordpress.org/browser/securelite-security/),
check out the [SVN repository](https://plugins.svn.wordpress.org/securelite-security/),
or subscribe to the [development log](https://plugins.trac.wordpress.org/log/securelite-security/)
by [RSS](https://plugins.trac.wordpress.org/log/securelite-security/?limit=100&mode=stop_on_copy&format=rss).
## Changelog
#### 0.2.14
* Two-factor setup shows a QR code: point your authenticator app at the screen
instead of typing a 32-character key. The code is drawn by the plugin on your
server; your key is never sent to an outside QR service. Typing the key by hand
is still there under “Can’t scan?”, with a Copy button, plus a Copy setup link
button for password managers.
* Recovery codes can be copied, downloaded as a .txt file or printed. The browser
asks before you leave the page until you tick “I have saved these codes”, and
a notice at the top of your profile points to them.
* Security: an authenticator code now signs you in only once. Before, the same
six digits could be used again for about a minute and a half.
* On the login page, after you enter your password, your username stays filled
in on the code step. WordPress cleared it, so you had to type everything again.
* New FAQ: how to set up two-factor and how to get back in if you lose your phone.
* Where you are already looking at a problem — malware the scan found, or a check
that needs a server change — one line now says where to get hands-on help. If
you have set a Support contact (for example the agency that looks after the site),
it names them instead. Nothing is sent anywhere; these are ordinary links.
* Readme: a Need help? section — free support on the forum, and where to get hands-
on help.
#### 0.2.13
* Settings > Notifications has a “Send test email” button, so you can confirm your
site delivers SecureLite’s email now instead of waiting for the first summary.
If sending fails, it shows the mailer’s error.
* The daily summary now separates what was stopped from what was only logged. Requests
seen while the firewall or rate limiting is in Monitor mode are no longer reported
under “no action is needed”; the email says they were not blocked and where to
switch to Block.
* Fixed: in WordPress Playground (and setups that pass your login cookie to the
site’s own requests), Attack Simulation reported the firewall, user-enumeration
and upload checks as failed, because each test arrived logged in as you and administrators
are never filtered. Test requests are now always treated as an anonymous visitor.
The bot and user-enumeration checks also work where requests go through a browser,
which cannot send a custom User-Agent and follows redirects itself.
* Attack Simulation’s uploads check now recognises a hosting firewall that refuses
PHP in uploads with a code other than 403 (such as LiteSpeed’s 444): a harmless
control request in the same folder tells a real PHP block apart from the host
briefly blocking the test.
#### 0.2.12
* SecureLite no longer writes .htaccess files. The uploads protection now shows
the exact rule for Apache/LiteSpeed and for nginx to add yourself (or hand to
your host), and recognises it — or an equivalent your host added — once it is
there. Rules applied by an earlier version are left in place.
* Attack Simulation’s “PHP execution blocked in uploads” check writes nothing:
it requests a .php address in uploads that does not exist and reports whether
the server refused it before WordPress ran.
* Every file and folder location is now resolved from WordPress functions (get_home_path(),
plugin_dir_path(), wp_upload_dir(), content_url() and others) instead of internal
constants, so sites with WordPress in its own subdirectory or a moved content
folder are scanned and reported correctly. The site root’s .htaccess and index.
php are watched in the home folder, where WordPress keeps them.
* The folder earlier versions kept in uploads (Attack Simulation samples) is removed
on update.
#### 0.2.11
* Malware scan now compares every WordPress core file with the official checksums
from WordPress.org. Any PHP file added to wp-admin or wp-includes, and any changed
core file, is reported as Critical; an unknown PHP file in the site root is reported,
and Critical if it also matches a malware pattern. Found on a real hacked site:
nine web shells in the site root and in wp-includes/js that the previous scan
never looked at.
* Scanner hits in wordpress.org plugins are checked against that plugin’s official
release. Files identical to the release are cleared (stock elFinder, phpunit
and similar library code was being reported as a backdoor); changed or added
files are raised to Critical. Premium and custom plugins are marked as not verifiable.
* Genuine WordPress files from another release are no longer reported as malware.
When new WordPress files were copied over an old install, an update stopped half
way, or PHP’s OPcache is still running the old version, core files are compared
with the version written on disk, then with the newest release and the releases
this site ran before; matching files are grouped into one plain finding (“an
update did not finish”, “left over from WordPress X”) instead of one Critical
per file. A file at a genuine WordPress path with altered content is still Critical.
* PHP files with unusual extensions (.php56, .php8, .PhP7 …) are now scanned.
* Packed payloads wrapped in another call before the decoder, such as eval(implode(…,
gzinflate(base64_decode(…)))), are now Critical instead of Suspicious.
* The dashboard says when a scan stopped at its time or file limit, so a partial
scan is never read as an all-clear.
* Attack Simulation on hosts with their own firewall (LiteSpeed, Imunify360, ModSecurity):
WordPress now tags its answers to the simulation’s probes, so an answer from
the host is recognised. A probe the host refused (for example HTTP 444) is reported
as blocked by your hosting server instead of failed; a dropped connection or
a page-cache answer is reported as could not be tested, with the reason, and
no longer shows an Enable & re-test button that could not change anything. Previously
these hosts showed three failures on first run.
* Attack Simulation’s brute-force check now still tests the lockout when the host
refuses its test logins, cuts them off early, or this site’s own address is a
trusted IP. It runs SecureLite’s lockout inside WordPress instead, from a reserved
documentation address (192.0.2.0/24) so your own address is never locked, and
confirms the lock trips at your limit and holds against a different username
and against a correct password. Previously this check was skipped on those hosts,
and its message suggested the host was already blocking bots, which a host filter
only partly does.
* A failed brute-force check no longer offers Enable & re-test when login protection
is already on.
#### 0.2.10
* Fixed: Regenerate keys and salts could write a key containing “$” followed by
a digit in a way that broke wp-config.php with a syntax error, taking the site
offline. Keys are now written literally, and every wp-config.php change is checked
to be valid PHP before it is saved — an edit that would not parse is refused.
* Security: SecureLite no longer copies wp-config.php anywhere. Edits to it (the
file-editor switch, the trusted-IP line, Regenerate keys and salts) are written
in place, read back and checked, and the original is restored from memory if
the write did not land exactly. Every backup copy left by earlier versions —
beside wp-config.php, under wp-content/securelite-backups or under uploads —
is deleted on update.
* Attack Simulation never writes a PHP file. The malware-scanner check tests the
real signatures and scan coverage against samples held in memory; the uploads
check confirms SecureLite’s rule is present and proves the server obeys .htaccess
in uploads using a plain-text file. The configuration-backup check is removed,
as there are no backups to expose.
* Rate-limiter and crawler-cache transients now use the plugin’s full prefix.
* The “recovery codes running low” notice appears only on the Dashboard, your profile
and SecureLite’s screens.
#### 0.2.8
* Security: the per-address lockout did not hold. WordPress’s own password check
replaced SecureLite’s refusal, so a locked address saw the “too many failed attempts”
message but could still sign in with the right password, or keep guessing under
a different username. A locked address is now refused for the whole lockout window,
whatever the password or username. The per-username lock is unchanged: the right
password from another address still gets in.
* “PHP execution blocked in uploads” can now be fixed from the Verification screen
with Enable & re-test, which writes the uploads rule and re-runs the check. If
the rule is already there but PHP still runs, the result says your server is
ignoring .htaccess and what to change, instead of sending you back to apply it
again.
* Fixed: an uploads .htaccess holding only an empty SecureLite block, left behind
after deactivating an older version, counted as protection. The check then blamed
the server for ignoring .htaccess and hid the fix button. SecureLite now looks
for the actual rule, and deactivating no longer leaves an empty block (or an
empty file) behind.
* Fixed: the uploads rule included “Options -Indexes”, which returns a 500 error
for every image in uploads on hosts that don’t allow that directive. It is removed,
the rule now also works on Apache 2.2, and sites that already applied the old
rule get the new one automatically.
* Attack Simulation now runs live: each attack goes out one at a time and you watch
every protection answer, with a progress bar and the result appearing on each
row. When it finishes the results stay on screen in the same design, with Enable&
re-test on anything that can be fixed and a print/save button; the saved report
uses the same layout. Enable & re-test now re-runs the same live view, so you
watch the fix turn green.
* Repeat offenders are locked out longer. An address locked again within a day
waits at least 1 hour, and after that at least 24 hours, so a bot that returns
whenever a lock lifts gets a handful of guesses a day instead of hundreds. A
person who mistypes once still waits only the normal window, and signing in successfully
clears the address’s history. Username locks never escalate.
* A repeat offender posting to the login form is refused with HTTP 429 and a Retry-
After header before WordPress does any login work, which saves server resources
under a sustained attack. A first-time lockout still shows the normal login screen.
* The lockout message now says how long login is paused, instead of “try again
later”, and links to a help page on getting back into your own site. It shows
no recovery details itself, because attackers see it too, and it reads the same
for an address lock and a username lock.
* Attack Simulation’s brute-force check now also tries a fresh username from the
locked address, and fails if that attempt is not refused, so this kind of gap
cannot pass the check again.
* Security: with “Behind a proxy/CDN” on, a forwarded IP header was believed from
any connection, so an attacker could send a fake X-Forwarded-For and dodge the
lockout, or claim a trusted IP. Forwarded headers are now only read when the
connection comes from a trusted proxy: your private network, Cloudflare’s edges(
new preset), or addresses you list. X-Forwarded-For is read from the right, so
the address a client claims for itself is never taken on trust.
* Sites that already had proxy mode on get the Cloudflare preset switched on during
the update, so visitors keep their real addresses.
* The settings screen shows which address SecureLite sees you connecting from and
where it read it, and warns when Cloudflare traffic arrives with proxy mode off.
Both problems also appear as posture findings.
* Fixed: in block mode the firewall could refuse an editor’s or author’s post that
mentioned `javascript:`, `onclick=` or `document.cookie`, losing the draft. Content
saved through wp-admin, admin-ajax or the REST API by users who can edit posts
is no longer signature-matched; their URLs, cookies and uploads still are.
* Fixed: any form field containing the text “wp-config.php” was treated as a traversal
attack. It now only matches when the whole value is a path to the file.
* Firewall log entries now record the role of the user who tripped them.
* One click to add your IP to wp-config.php as the lockout escape hatch. wp-config.
php is backed up first, the change is read back to confirm it landed, and an
existing SECURELITE_ALLOW_IP line is added to rather than duplicated. If the
file cannot be written, the message says why — locked permissions, the file not
found, or a definition SecureLite should not rewrite — and gives you the line
to add by hand. Deactivating removes the line and reactivating puts it back,
like SecureLite’s other wp-config.php changes.
* SecureLite refuses to trust a Cloudflare address, whether from that button or
typed into Trusted IPs, because it is shared by huge numbers of visitors. It
tells you to set up proxy mode instead.
* Three ways back in after a lockout — a wp-config.php line with your current IP
already filled in, a folder rename, and a WP-CLI command — are now on the Support
screen and one click away under Login protection. They are also emailed to you
once, the first time you save with a lockout feature on, and the save message
tells you it was sent.
* SecureLite now shows an admin notice and stops loading, instead of causing a
fatal error, if the server is later moved to a PHP or WordPress version older
than it supports.
* Recovery Reset passwords now shows exactly whose passwords it will reset, with
a count and the usernames in the confirmation. When you are the only administrator
it says so instead of reporting “Reset 0 password(s)”, and links to your profile
to change your own password.
* Security: resetting a password now also signs that account out everywhere and
deletes its application passwords, which keep working for the REST API after
a password change. It can email each account a link to choose a new password,
and says plainly if the server could not send mail.
* Requires WordPress 6.2 or newer.
#### 0.2.7
* SecureLite now removes what it added. Deactivating the plugin takes back the
two changes it makes outside its own database — the rule in your uploads .htaccess
and the DISALLOW_FILE_EDIT line in wp-config.php — and activating it again puts
them back exactly as they were. Uninstalling removes them for good.
* It only ever undoes its own work. A DISALLOW_FILE_EDIT line that was in wp-config.
php before you installed SecureLite is restored to its original text rather than
deleted, and one that another plugin manages is not touched at all.
* Your settings, trusted IPs and security log are never touched by deactivation.
Deactivating a plugin is how people troubleshoot, and it should not cost them
their configuration.
* Security: the per-username lockout could be used against you. Anyone who knew
an administrator’s username could hold that account shut for everyone not on
the trusted-IP list — including the real administrator, on mobile data, who then
could not log in to add their address. The username lock is now decided after
the password has been checked: a wrong password is refused exactly as before,
and a correct one gets in and clears the lock. Guessing gains an attacker nothing,
and someone who already has your password was never what this counter was protecting
you from.
* A per-username lock is now capped at 30 minutes however long your lockout window
is set. It is the one counter a stranger can drive up deliberately, so its duration
is not theirs to choose.
* The system report now shows both lock durations.
#### 0.2.6
* The system report on the Support screen now answers “why was I not locked out?”—
it shows your own address and whether it is trusted, the live failure counts
against their thresholds, when the current window opened, and when any active
lock expires.
* The report also lists every plugin that has a hand in your login, in the order
they run. A second security plugin answering the login before SecureLite is the
quiet cause of half the reports that a lockout does nothing, and it was previously
invisible.
* Added a Common problems entry for the same question, with the four causes in
the order they turn out to be true.
* Fixed: the report still quoted the old rate-limiting defaults (block mode, 120
requests a minute) rather than the ones shipped since 0.2.2.
#### 0.2.5
* Settings switches are now toggles rather than checkboxes, so the state of each
protection reads at a glance.
* The theme and plugin file editor setting now detects when another plugin already
controls it. Rather than showing a switch that would change nothing, it locks,
shows what is actually true on your site, and explains where to change it.
#### 0.2.4
* Added email notifications, sent by your own site with no external service involved.
A daily summary plus an immediate email for two findings only: malware detected,
or a watched file changed.
* SecureLite never sends one email per blocked request. That traffic is counted
and summarised, never itemised, and the summary reports numbers of addresses
rather than lists of them.
* On a quiet day, no summary is sent. An email that says nothing happened is how
people learn to ignore a sender.
* Immediate alerts are limited to one per hour and only fire for a finding that
is new — a condition that is still true tomorrow is not a new alert.
* Notifications can be set to summary-plus-alerts, alerts only, or off entirely.
The local security log keeps recording either way.
#### 0.2.3
* Two-factor authentication can no longer be switched on by ticking a box. You
must enter a code your authenticator app produced, and if it is not accepted
nothing changes and you stay signed in.
* Two-factor now issues ten single-use recovery codes at setup, shown once, stored
hashed. Any of them will sign you in if you lose your phone, and you are warned
when three or fewer remain.
* The setup secret is now kept between page loads, so scanning the QR code and
then reloading the page no longer silently invalidates it.
* Changing your login URL is now proved before it is kept: the new address is requested
over loopback, and if it does not return a login form the setting switches itself
back off and tells you why. The new address is also emailed to the site administrator.
* Login slugs that collide with an existing page, post or category are refused,
along with slugs under three characters.
* Attack Simulation gained a fourteenth check: it plants an inert file in the configuration
backup directory, asks the server for it, and fails if the server hands it over.
#### 0.2.2
* Security: wp-config.php backups were written next to wp-config.php in the site
root, where a default server configuration serves them as plain text. They are
now kept under wp-content in a protected directory with an unguessable filename,
only the three most recent are retained, and any backup left in the site root
by an earlier version is deleted automatically on update.
* Fixed: being asked for a two-factor code counted as a failed login, so users
with two-factor enabled could be locked out of their own site while entering
the correct password. Wrong authenticator codes now have their own, more forgiving
budget.
* Fixed: retrying while locked out extended the lockout by the full window each
time.
* Verified search-engine crawlers (Google, Bing, Yandex, Baidu, DuckDuckGo, Apple)
are no longer rate limited. Each is confirmed by forward-confirmed reverse DNS,
so a spoofed user-agent gains nothing. robots.txt and sitemaps are always served.
* Rate limiting now ships in monitor mode, and the default allowance is 240 requests
per minute rather than 120. A per-IP cap also counts everyone sharing one address,
so the log should be reviewed before it starts turning requests away.
* SecureLite now refuses to edit wp-config.php at all if it cannot write a backup
first.
#### 0.2.1
* SecureLite now runs entirely on your own site. The optional cloud transport has
been removed along with its settings, so the plugin makes no outbound connections
of any kind.
* Added a trusted-IP allowlist (exact address or CIDR, IPv4 and IPv6) exempting
the brute-force lockout and rate limiter.
* Added the SECURELITE_ALLOW_IP wp-config constant so an administrator who is locked
out can recover with file access alone.
* Added a tenth verification probe that plants an inert malware sample and confirms
the scanner flags it, then removes it.
* Fixed: the rate limiter accepted an unvalidated authentication cookie name as
proof of login.
* Admin interface refinements and cache-busted stylesheets.
#### 0.2.0
* Added the request firewall (SQL injection, XSS, directory traversal, scanner
signatures) with monitor and block modes.
* Added malware, JavaScript-injection and database scanning.
* Added the executable-upload virtual patch.
* Added rate limiting and Heartbeat API throttling.
* Added the hidden login URL, uploads hardening, post-hack recovery toolkit and
Run Attack Simulation.
#### 0.1.0
* Initial release: login hardening, TOTP two-factor, signal collection, file-integrity
monitoring, posture scoring, heartbeat.
## Meta
* Version **0.2.14**
* Last updated **3 hours ago**
* Active installations **Fewer than 10**
* WordPress version ** 6.2 or higher **
* Tested up to **7.1.3**
* PHP version ** 7.4 or higher **
* Tags
* [Brute Force](https://wordpress.org/plugins/tags/brute-force/)[firewall](https://wordpress.org/plugins/tags/firewall/)
[malware scanner](https://wordpress.org/plugins/tags/malware-scanner/)[security](https://wordpress.org/plugins/tags/security/)
[two factor](https://wordpress.org/plugins/tags/two-factor/)
* [Advanced View](https://wordpress.org/plugins/securelite-security/advanced/)
## Ratings
No reviews have been submitted yet.
[Your review](https://wordpress.org/support/plugin/securelite-security/reviews/#new-post)
[See all reviews](https://wordpress.org/support/plugin/securelite-security/reviews/)
## Contributors
* [ Naveen Kumar ](https://profiles.wordpress.org/naveenfriendly/)
## Support
Got something to say? Need help?
[View support forum](https://wordpress.org/support/plugin/securelite-security/)