99.8% of attacks detected. 0 real visitors blocked.
Every figure below was measured in a sealed lab on the released product (plugin 1.25.0), on WordPress and, through the Gateway, on any web stack, then confirmed on live production sites.
At a glance
| Measure | Result |
|---|---|
| OWASP CRS 4.30 attack tests detected (WordPress, default level) | 1,661 of 1,665 (99.8%) |
| Same tests blocked end to end on a live WordPress site | 1,551 of 1,646 (94.2%); only 17 (1.0%) served normally |
| Command, PHP and code injection, file inclusion, session fixation, protocol attacks | 100% blocked |
| Real-visitor requests blocked within the tested corpus, all four paranoia levels | 0 of 101 observed (23 live requests, 78 in the corpus) |
| Vulnerable plugin attacked by API or by direct file request | Blocked (403) until updated |
| Gateway, same attack tests, on HTML, Java, PHP, Rust and Node | 94.9% blocked; 0 of 17 tested normal requests blocked, on every stack |
| Host Scanner, planted vulnerabilities across 5 languages and 6 Linux distributions | All found, with fixed version and command; 0 false alarms on up-to-date systems |
| Live fleet | 32 production sites on 1.25.0, all serving normally |
Scope of these figures. Detection rates refer to the OWASP Core Rule Set 4.30 regression suite under the stated configuration, not to every possible real-world attack. False-positive results are what we observed in the tested traffic (101 WordPress requests, 17 per Gateway stack), not a guaranteed zero rate across all sites. This is an engineering validation by Cyber Securitise, not an independent audit; the suite is published by OWASP, and the release hash, configuration, command sequence and per-test results are available to customers and reviewers on request.
How it was tested
All tests ran in a sealed lab with no internet access, using the industry's own test suite, real-visitor traffic and a real vulnerable plugin.
- Isolation: Linux with Docker; the sites sit on an internal network with no internet (verified), behind a single front door that only the test machine can reach. No client data or real keys were used.
- WordPress site: WordPress on PHP 8.3 and Apache, MariaDB 11.4, posts in English and Japanese.
- Other stacks: static HTML, Java (Spring Boot), PHP, Rust (Axum) and Node (Express), each behind the Gateway.
- Attack suite: the OWASP Core Rule Set 4.30 regression tests, about 5,100 attack and benign cases written by the CRS project. Scored in the rule engine (did the right rule detect it?) and live through the web server (was the request blocked?).
- Real-visitor traffic: 23 requests with genuine browser headers (English and Japanese pages and searches, consent and shop cookies holding JSON, tracking links, feeds, REST API, log-in, comments with apostrophes, AJAX calls, search-engine crawlers), plus a 78-request corpus from real WordPress traffic. Pass = not blocked.
- Vulnerable plugin: Really Simple Security 9.1.1, which has a published critical flaw (CVE-2024-10924).
WordPress firewall
The plugin runs the full OWASP Core Rule Set inside WordPress and catches every application-attack category at 98.9% or better, with no real visitor blocked.
| Attack category (CRS) | Detected at the default level |
|---|---|
| Remote command execution (932) | 100% |
| PHP injection (933) | 100% |
| Generic code injection, SSRF (934) | 100% |
| Local file inclusion (930) | 100% |
| Remote file inclusion (931) | 100% |
| Session fixation (943) | 100% |
| Protocol attacks, request smuggling (921) | 100% |
| Scanner detection (913) | 100% |
| SQL injection (942) | 320 of 322 (99.4%) |
| Cross-site scripting (941) | 186 of 188 (98.9%) |
| All rules | 1,661 of 1,665 (99.8%) |
The four tests the engine does not detect disguise quotes as curly apostrophes; treating those as quotes would block ordinary WordPress text, so they are left out by design.
Detection versus blocking
The 99.8% is measured in the rule engine. Sent live through the web server, the same suite resolves as follows; only 1.0% of the tests were served normally, and none of those is an application attack.
| Live outcome, 1,646 attack tests at level 1 | Tests | Share |
|---|---|---|
| Blocked by the firewall (403) | 1,551 | 94.2% |
| Refused by rate limiting (429): the suite fires about 5,000 attacks from one address, which trips the per-address limit | 55 | 3.3% |
| Not found, nothing served (404) | 19 | 1.2% |
| Rejected by the web server before WordPress (400 or connection closed) | 4 | 0.2% |
| Served normally (200): 16 HTTP-protocol checks, 1 initialisation test | 17 | 1.0% |
SQL injection by structure. A pure-PHP port of libinjection, the detector used by ModSecurity and Coraza, recognises injection by its grammar: tautology tricks such as ' OR 1=1 are blocked at the default level, while names like O'Brien, contractions and Japanese text pass. Checked against the reference implementation on 101,467 inputs; about 0.2 ms per request.
Paranoia levels
Site owners can raise rule strictness from level 1 to 4. Higher levels start in watch-only mode, so nothing is blocked until the owner has seen what would be.
| Level | Attack tests detected | Real visitor requests blocked |
|---|---|---|
| 1 (default) | 99.8% | 0 |
| 2 | 92.2% of a larger, stricter set | 0 |
| 3 | 91.1% | 0 |
| 4 | 90.8% | 0 |
Virtual patching
When an installed plugin has a published vulnerability, Cyber Securitise closes every route to it until the plugin is updated, with no action from the site owner. API routes are refused, and the web server itself refuses PHP files in that plugin's folder, the pattern behind the WP File Manager mass exploitation. Payment callbacks and other entry points stay open, and every rule lifts the moment the plugin is updated.
| Test, Really Simple Security 9.1.1 | Result |
|---|---|
| Vulnerable REST route, before patch | Reachable |
| Same route, patched | Blocked |
| Plugin PHP file requested by URL, patched | 403 |
| Home page and 23 normal requests while patched | 200, 0 blocked |
| After update to a fixed version | Rule removed, file reachable again |
Any stack: the Gateway
The Gateway brings the same OWASP-grade firewall to sites that are not WordPress, and blocked 94.9% of the attack suite on all five stacks with zero false blocks.
| Stack | Attack tests blocked | Normal requests blocked (of 17) | Added delay |
|---|---|---|---|
| Static HTML | 94.9% | 0 | 3–7 ms |
| Java (Spring Boot) | 94.9% | 0 | about 8 ms |
| PHP | 94.9% | 0 | about 4 ms |
| Rust (Axum) | 94.9% | 0 | about 5 ms |
| Node (Express) | 94.9% | 0 | about 7 ms |
| Gateway alone, no proxy in front | 95.6% | – | – |
- What it is: a single 30 MB container on OWASP Coraza 3.8.1 and CRS 4.30.0, with libinjection, the plugin's false-positive tuning, AI-crawler and scraper control, rate limits and security headers. Apache, MIT and BSD licensed dependencies only.
- HTTPS: own or free automatic certificates, HTTP/2, HTTPS redirect, HSTS; old TLS refused.
- Scales out: rate limits shared across servers; if the shared store is down, visitors are let through, never locked out.
- Response checks: blocks pages that leak database errors or contain a web shell; large downloads and live streams pass untouched.
- Reporting: blocks reach the Cyber Securitise dashboard over the same signed protocol as the plugin.
Below the application: server software
Cyber Securitise also finds the holes a firewall cannot see, in PHP, the web server, the Linux kernel, OpenSSL, Node and the database, and gives the exact fix. The plugin reads installed versions from files, never running a command, and the dashboard checks them against OSV.dev, CISA's list of exploited vulnerabilities and end-of-life dates. Distribution packages are matched against the distribution's own advisories, so backports are never reported as vulnerable from the version number alone; where the build cannot be identified, as on managed hosting, the finding is a "check with your host" warning.
Host Scanner
The scanner reports the version that clears every known advisory on a package, not just the first fix for one CVE: for Log4Shell, 2.15.0 fixed the original flaw but later advisories need 2.25.4. Per-advisory fixed versions are in its machine-readable output.
One read-only file that needs nothing installed and can run fully offline. It checks OS packages, Docker images, hand-installed runtimes and application lock files, and sends only package names and versions when online.
| Planted in the lab | Found | Upgrade target (clears every advisory) |
|---|---|---|
| log4j-core 2.14.1 (Java), incl. Log4Shell | Yes, flagged "being exploited now" | 2.25.4 |
| lodash 4.17.20 (Node) | Yes | 4.18.0 |
| guzzlehttp/psr7 1.8.3 (PHP) | Yes | 2.12.3 |
| urllib3 1.26.4 (Python) | Yes | 2.8.0 |
| smallvec 1.6.0 (Rust) | Yes | 1.6.1 |
| Node 22.0.0 installed by hand | Yes, 9 security releases missing | 22.23.4 |
| Go 1.21 toolchain | Yes, end of life plus advisories | 1.26.10 |
| System checked | Result |
|---|---|
| Old images: Debian 12.0, Rocky 9.0, AlmaLinux 9.0, UBI 9.0, Alpine 3.18 | Real fixable findings on each (Rocky 9.0: 36) |
| Current Rocky and AlmaLinux 9 | Exactly the vendor's own dnf security list |
| Up-to-date Ubuntu 24.04, Debian 12, UBI 9, Alpine | 0 findings |
| Bare Ubuntu 22.04/24.04, Debian 12, Rocky 9 with no Python | Runs from the single file; leaves nothing behind |
Tamper watch
If anyone switches protection off or alters the plugin, the site owner is told, so an intruder cannot quietly disable the firewall. Every release is signed, and legitimate updates do not raise false alarms.
| Event | Dashboard response |
|---|---|
| Site stops reporting for 30 minutes (adjustable) while still online | Alert |
| Plugin files differ from the signed release | Alert |
| Firewall, rule set, paranoia level or virtual patching lowered by someone other than the owner | Critical alert |
| An unknown PHP auto-prepend file appears | Critical alert |
| Plugin deactivated | Alert, from a signed last report |
| Owner lowers protection from wp-admin | Logged, no alarm |
Found and fixed during testing
The lab is part of the release process: every issue it found was fixed, re-tested and shipped within days.
| Found | Fix | Shipped |
|---|---|---|
| Virtual patching missed plugins whose API name drops the dashes of the plugin name | All name forms matched | 1.23.11 |
| Full test of every plugin function: 8 defects | All 8 fixed, with tests | 1.24.0 |
| Paranoia levels 2–4 blocked pages with consent and shop cookies | Stricter SQL rules no longer read cookies | 1.24.0, before release |
| libinjection port flagged XML declarations, CSS values and one plain sentence | Three narrow, documented exceptions | 1.24.1, before release |
| Levels 2–4 blocked XML in parameters, CSS values, inch and foot marks, JSON in AJAX fields | Per-field exceptions; detection unchanged | 1.24.3 |
| Crawlers sending a Content-Type header on page requests were blocked | Content type ignored on requests without a body, on every server type | 1.24.2, 1.24.4 |
In production
- Fleet: 32 production WordPress sites in Japan, Singapore and the US, all on 1.25.0 and serving normally, checked after each release.
- Dashboard: sites report status, findings and blocks continuously; 31 sites were sending tamper-watch heartbeats within an hour of the 1.25.0 rollout.
- Network blocks, 19–23 October 2026: about 2,250 requests from Spamhaus DROP networks and about 2,100 from data-centre networks on log-in and admin pages.
- Rapid response: when PHP disclosed new code-execution flaws on 21 and 23 October 2026, the fleet was patched or mitigated within days.
The lab is scripted and can be rebuilt and re-run on any Linux machine with Docker, using the OWASP CRS 4.30.0 regression tests and the product's own test suites. Download the full report (PDF).