Why a vulnerability published as CVSS 9.8 can be shown as an estimated 4.4 on your site — what that second number is, how it is produced, and the things it deliberately never claims.
A CVSS base score describes a vulnerability in the abstract, assuming the vulnerable code is reachable by an attacker. On a site serving a static release with WordPress isolated, most vulnerable PHP paths are not reachable from the public internet at all.
Showing a bare 9.8 CRITICAL beside a plugin that no public request can reach trains people to ignore the number — and the day a genuinely reachable 9.8 appears, it looks exactly the same as the fifteen that didn't matter. Static Shield Mitigation exists to keep that distinction visible.
In both the plugin and the Tulapp panel, an advisory shows the published score and the site-specific estimate side by side:
| Advisory | Severity | Score | Shield mitigation |
|---|---|---|---|
| CVE-2021-24376 | Critical | 9.8 → 4.4 | Substantial ~55% Vault Mode (sealed) |
Read it as: "published 9.8; roughly 4.4 as actually deployed here" — never as "this is a 4.4 issue". The published score is never replaced, only annotated.
Posture is the single value describing how this site currently serves and isolates WordPress. It is derived from the security fingerprint your site reports on each build, and it is what every mitigation figure is calculated from.
| Posture | Mitigation | A 9.8 becomes |
|---|---|---|
| Hybrid | 10% | 8.8 |
| Static + Bridges | 20% | 7.8 |
| Full Shield | 30% | 6.9 |
| Zero-WordPress Mode (on, unverified) | 35% | 6.4 |
| Zero-WordPress Mode (verified) | 45% | 5.4 |
| Vault Mode (sealed, unverified) | 45% | 5.4 |
| Zero-WordPress Mode (lockdown) | 70% | 2.9 |
| Vault Mode (sealed, verified) | 70% | 2.9 |
| Vault Mode (access grant open) | 0% | 9.8 |
Serving statically on its own tops out at 30%, because WordPress is still installed
and still answering. Pages render from disk, but wp-login,
wp-admin, REST, admin-ajax and XML-RPC remain doors. Static serving
removes the front-end execution path, not the vulnerable code. Zero-WordPress and Vault Mode
are what close the door — which is why they start where static serving stops.
The ladder is graded by evidence, not by which feature you enabled. A sealed Vault and Zero-WordPress lockdown score identically. What separates 45% from 70% is whether an external check from Tulapp Cloud has actually confirmed the isolation, rather than the mode merely being switched on. A setting you believe is working and a setting proven to be working are not the same claim.
Scored the same at equal evidence, but they differ in a way worth understanding:
So for the same nominal protection, Zero-WordPress lockdown is the more durable posture, and a sealed Vault's real-world protection is only as good as how rarely and briefly you open it.
These are constraints built into the model, not editorial caution:
The most important reason is easy to miss: a payload already baked into the static build is served by the static site itself. For a stored-XSS-class flaw, static serving mitigates nothing — and because the build is a snapshot, it can outlive the fix. Beyond that: administrators still reach WordPress, postures get changed, and a rule that was right last month may not be right today.
Two paths, and the interface tells you which was used:
Until a build reports its security fingerprint to Tulapp Cloud, there is no posture on file and scores are shown unadjusted. The interface says "Shield posture not reported to Tulapp Cloud yet" — which means unknown, not unprotected. Run a build to report it.
A site that has stopped reporting keeps its last known posture, with the date it was observed. That is deliberate: silently forgetting would make a well-protected site suddenly look unprotected and overstate every one of its risks. Staleness is a fact to show, not a reason to forget what was true.
Tulapp