WordSec – Malware Scanner & Removal, Web Application Firewall (WAF), and 2FA
| 开发者 | wordsec |
|---|---|
| 更新时间 | 2026年8月1日 22:44 |
| PHP版本: | 7.4 及以上 |
| WordPress版本: | 7.0 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
详情介绍:
WordSec is a complete WordPress security plugin. Eight modules cover the firewall, malware scanner, login security, live traffic, IP and country blocking, supply-chain intelligence, audit log and alerts, so you block attacks and harden your site from one dashboard instead of installing eight plugins.
If your site gets hacked you do not just lose the site. You lose customer trust, your search rankings, and days of work restoring backups. WordSec is built to stop that before it happens, and to help you recover if it already has: the scanner finds the malware, quarantine takes it out of the way, and modified core, plugin and theme files are repaired from their original copies.
Free, and no license key to enter. WAF firewall rules, malware and file-integrity scanning, brute force protection, two factor authentication, IP and country blocking, the audit log and one-click hardening all run locally on your own server.
Web Application Firewall (WAF)
- Custom rule builder with regex and wildcard matching
- Built-in rules for SQL injection, XSS, path traversal, PHP and command injection
- Learning and active modes, bot blocking, security headers, rate limiting
- 25+ hardening toggles for wp-config access, author enumeration and REST API
- Optional Extended Protection: pre-WordPress request inspection (opt-in, fully reversible)
- Malware detection rules across files, the database and scheduled tasks
- Core, plugin and theme file-integrity verification via the WordPress.org API
- Scheduled scans, one-click quarantine and restore
- Malware removal on a hacked site: quarantine a finding, or repair a modified core, plugin or theme file from its original copy
- Role-based two-factor authentication (RFC 6238 TOTP)
- reCAPTCHA, hCaptcha and Cloudflare Turnstile, plus a built-in math CAPTCHA
- Brute-force protection with progressive lockout, honeypot and login URL rename
- Leaked-password checking, session management, custom login page
- Real-time request logging with bot detection and CSV export
- Exclusion filtering by role, IP, country or URI
- Country and continent allow or block lists
- IP and CIDR blocking, temporary or permanent, with allow-list support
- Reputation scoring and abandoned-plugin detection
- Known-vulnerability alerts for core, plugins, themes and PHP
- Update-integrity verification with backups and an SBOM inventory
- Activity tracking across 11 object types and 14 actions
- 36 alert event types delivered by Email, Telegram or Slack Every feature runs locally with no license key. Optionally, the WordSec service at wordsec.net supplies threat-intelligence data that cannot be produced locally: managed WAF rule sets, the malware signature feed, IP-reputation lists, the GeoIP database and vulnerability records. Connecting is optional and every external service is documented in "External services" below.
安装:
- Upload the plugin files to
/wp-content/plugins/wordsec/, or install through the WordPress Plugins screen. - Activate the plugin through the Plugins screen in WordPress.
- Open the WordSec menu to start configuring.
屏幕截图:
常见问题:
Does WordSec slow down my site?
No. WordSec is built around minimal database queries, batch processing and smart caching so protection does not come at the cost of performance.
Do I need a license key to use WordSec?
No. WordSec installs and runs as a fully functional free plugin with local protection: the web application firewall (your own custom rules plus the built-in preset rules), brute-force and login protection, two-factor authentication, hardening, geo-blocking configuration, the audit log and more all work without any key.
Does it require any external service?
No, not to run. WordSec's core protection runs locally on your server, and with no license key it contacts no external WordSec service at all.
Can WordSec help with malware removal on a hacked site?
Yes. The security scanner examines your files, the database and scheduled tasks, and every finding can be quarantined with one click. A modified WordPress core, plugin or theme file can also be repaired straight from its original copy on WordPress.org, and the scan history keeps a record of everything that was found and changed.
Does WordSec include brute force protection?
Yes. Failed logins are rate limited with progressive lockout, so each further attempt from the same source waits longer. You can also add a honeypot field, rename the login URL, require a CAPTCHA on the login form, and restrict logins by IP, country or time of day.
Does WordSec support two factor authentication?
Yes. Two factor authentication uses RFC 6238 TOTP codes from any standard authenticator app, and you choose which roles have to use it. For the case where a device is lost and nobody can get in, a WORDSEC_DISABLE_2FA constant in wp-config.php provides emergency access.
What does the web application firewall actually block?
The built-in rule sets cover SQL injection, cross-site scripting, path traversal, and PHP and command injection. You can add your own rules with a multi-condition builder, run the firewall in learning mode before you enforce anything, and optionally enable Extended Protection so requests are inspected before WordPress loads.
Can I run WordSec next to another security plugin?
You can, but it is not recommended. Two firewalls inspecting the same request, or two scanners walking the same files, cost you performance and produce duplicate alerts. WordSec is built to own site security end to end, so the usual path is to deactivate the others first.
What are the minimum requirements?
WordPress 6.9+, PHP 7.4+, and MySQL 5.6+ / MariaDB 10.1+.
更新日志:
1.1.0
- Fixed: Uninstalling the plugin with a data-removal option and later reinstalling it could permanently lock two-factor authentication users out of the login, because the stored 2FA secrets survived the uninstall while their encryption key did not. Uninstall now removes the plugin's per-user data together with the key, and the "keep only the license key" option preserves the key material the stored license needs.
- Fixed: Uninstall left cached entries and the GeoIP/quarantine folders behind; everything under uploads/wordsec is now removed unless "keep everything" is selected.
- Changed: The optional ipwhois.io service is now contacted only when you open the "IP details" window in Live Traffic. Traffic logging never calls it anymore, so background visits can no longer spend the monthly lookup quota and leave the IP details window reporting "Rate limit exceeded".
- Changed: The Live Traffic log no longer stores a per-request city, and the unused city database column is removed. City is still shown in the IP details window.
- Fixed: The Blocked IP Address table loaded 25 rows after a page refresh even though 10 per page was selected. The rows-per-page choice, sorting and current page are now remembered like the other log tables, and the Clear button returns the time range to All.
- Fixed: Sorting the Alarm Log or Firewall Log table could flip the column arrow to the opposite of the order actually applied.
- Fixed: On sites where WordPress is installed in a subdirectory, Login URL Rename left no way in: the custom login address returned a 404 while wp-login.php and wp-admin stayed blocked. The custom address now works, and so do the /login, /admin and /dashboard shortcuts.
- Fixed: "Block Sensitive Files Access" blocked legitimate media library downloads (.zip, .sql, .log and similar) on subdirectory installations, because the exception for the uploads folder did not match. The exception now follows the real uploads location.
- Fixed: The Blackhole trap never triggered on subdirectory installations, and a request carrying a query string slipped past it everywhere.
- Fixed: The login IP and country whitelist did not cover a renamed login page on subdirectory installations.
- Fixed: Plugin and theme enumeration blocking did not run on subdirectory installations when the request reached PHP.
- Fixed: The Nginx and IIS rule examples shown for servers that ignore .htaccess now include the installation path, so they match on subdirectory installations.
- Fixed: An invalid custom login slug was silently replaced instead of reported, and on a site that had no slug yet it could become a predictable default. The value is now rejected with a message and the previous slug is kept.
- Fixed: When a stored two-factor secret could no longer be decrypted (for example after a security key rotation), login was refused even with the correct password and turning two-factor authentication off did not help. The 2FA toggle now fully disables the check, and a WORDSEC_DISABLE_2FA constant in wp-config.php provides emergency access.
- Fixed: "Hide Login Errors" no longer replaces two-factor and site-state error messages with the generic "credentials incorrect" text; only credential errors are masked.
- Improved: Two-factor secrets stored in older encryption formats are now re-encrypted to the current format in the background, so a future security key rotation can no longer invalidate them.
- Fixed: File Permission Hardening could make a site unreachable. It set the root .htaccess to mode 0440, which takes away read access for the web server on hosting panels where the web server runs as a different user than the file owner (Plesk, cPanel and similar). Apache then answered every request with 403 and logged "AH00529 pcfg_openfile: unable to check htaccess file". The root .htaccess is now set to 0644 so the web server can always read it, while wp-config.php still becomes read-only at 0440. Affected sites are repaired automatically the next time an admin page is opened with the option enabled.
- Fixed: The malware scanner recommended the same 0440 mode for the root .htaccess, so Fix All (and scheduled scans with automatic fixing) could re-apply it. The scanner now expects 0644 and reports a .htaccess the web server cannot read as an issue instead.
- Fixed: The Tools file permission check listed 0440 as the recommended mode for .htaccess and now recommends 0644.
- Fixed: The security score no longer expects the .htaccess file to be unreadable by the web server; only group or world write access counts against the score.
- Fixed: "Prevent User Enumeration" no longer blocks ordinary author pages. Only ID-based probes (such as /?author=1, which WordPress resolves into a username) are blocked; a visitor opening a known author archive like /author/name/ is served normally. The REST users endpoint and the users sitemap stay closed as before.
- Fixed: The scanner's "View matched content" dialog showed its content box in white while dark mode was active.
- Improved: The block page shown to blocked visitors carries the WordSec wordmark with a "WordPress Security Plugin" line beneath it.
- Improved: The block screen rendered by Extended Protection (the pre-WordPress firewall) is now identical to the one WordPress serves, instead of a near-copy with an extra error code and reference line.
- Fixed: Uninstalling with "keep only the license key" now also keeps this site's identifier, so reinstalling reuses the existing license binding instead of registering the site a second time.
- New: The scanner now reports unexpected extra files inside WordPress.org-hosted plugin and theme folders (files that are not part of the official release). Such files are a common hiding spot for dropped payloads that match no malware signature. Findings support quarantine and are covered by Fix All.
- Improved: Plugin and theme file repair now fetches the single original file directly from WordPress.org SVN (the same channel core repairs already use) instead of downloading and extracting the whole plugin/theme zip; the zip package remains as an automatic fallback.
- Fixed: Plugin and theme repair could report "the plugin may not be hosted on WordPress.org" for plugins that ARE hosted there, because the zip extraction step ran without an initialized WordPress filesystem.
- Fixed: Default themes bundled with WordPress (e.g. Twenty Twenty-Five) no longer produce false "Changed Theme File" findings. WordPress ships its own builds of these themes that can differ byte-for-byte from the theme-directory release of the same version; files matching the official core checksums are now recognized as genuine.
- Improved: The Scan History table shows a full severity breakdown (total, critical, high, medium, low, info) when hovering the Issues Found column.
- Fixed: The malware scanner no longer flags WordSec's own unmodified files. Files that byte-match the official WordPress.org release checksums for the installed WordSec version are excluded from signature matching; a modified or unknown file still fails the checksum and is scanned normally.
- New: Setup wizard. First activation now opens a guided, step-by-step setup: pick a Recommended, Standard or fully Custom configuration for the firewall, login security, blocking and settings, configure CAPTCHA, two-factor authentication, login URL rename and alarm delivery channels, and finish with the license step. Every data-sharing and server-file change is disclosed before it is applied, and the wizard can be re-run anytime from Settings.
- New: Choosing what happens to your data on uninstall (keep everything, keep only the license key, or delete everything) is now offered in a dialog when deactivating the plugin, in addition to the existing Settings control.
- Improved: Malware scanner detection and performance.
- Improved: Visual refinements across the admin interface.
- Fixed: Known issues reported since 1.0.3.
- WordPress 6.9 is now the minimum supported version.
- The pre-WordPress WAF bootstrap ("Extended Protection") is no longer installed on activation. It is an explicit opt-in on the Firewall page that lists every server change it makes, and disabling it (or deactivating the plugin) reverts them all.
- Hardening features that write to .htaccess, .user.ini or wp-config.php, change file permissions or delete files now default to off, and each toggle's description states exactly what it writes.
- Deactivation now restores the original wp-config.php debug constants and original file permissions, and removes every file and directive the plugin added; uninstall re-runs this cleanup as a safety net.
- IP geolocation fallback and the Live Traffic IP-details lookup switched from ip-api.com to ipwhois.io, always over HTTPS with certificate verification, and every request is now gated behind a new default-off "External IP Lookup Service" opt-in (Settings → Visitor IP Handling).
- Supply-chain reputation scores now work fully without a license key: public wordpress.org plugin/theme data is fetched directly when the service mirror is not available.
- The Live Traffic IP-details dialog shows the local request statistics (totals, blocked count, threat level) even while external lookups are disabled.
- Settings page reorganized: Usage Data moved to the top, the language and interface options merged into one Admin Interface card, and the Visitor IP section renamed to Visitor IP Handling.
- Tools page descriptions now name the external services each tool contacts (api.ipify.org, rdap.org, and the DNS blocklist providers).
- External services documentation expanded: DNS blocklist providers, all wordpress.org download hosts and the ipwhois.io service are now listed.
- Some known bugs have been fixed.
- Visual improvements have been made.
- All features are now fully functional locally with no license restrictions.
- A bug in the malware scanner has been fixed.
- Runtime data (WAF rules, blocklists, GeoIP, quarantine) now lives under the uploads folder (uploads/wordsec).
- Additional file/directory location and wp.org guideline compliance fixes.
- Inline scripts/styles moved to the WordPress enqueue API.
- Stronger input sanitization across request handling.
- Updated bundled libraries: ApexCharts 5.16.0, TCPDF 6.11.3.
- GeoIP database now stored under wp-content/wordsec-data/ instead of the plugin folder.
- Expanded the External services documentation in this readme.
- Initial public release.