WP-Safety
Docs

How WP-Safety actually works.

Every score, risk rating, and verified exploit on this site is produced by a pipeline I run myself - no black-box vendor feed, no hand-curated spreadsheets. These pages explain the methodology end-to-end so you can verify our work instead of taking it on faith.

The whole system in one diagram

Four layers, one pipeline

Each layer feeds the next but runs independently - a failure in one doesn't corrupt the others. The detail pages below walk through each layer's internals.

Layer 1 - external sources
WordPress.org
Plugin API · theme API · SVN source mirror
CVE feeds
Wordfence Intelligence · NVD · PatchStack Core
CommonCrawl
Monthly archives - billions of URLs per crawl
Layer 2 - analysis
AST taint tracking
Inter-procedural, WP-aware
LLM research pass
Lightweight LLM + frontier-LLM fallback
Deterministic scoring
Signals + weights → 0–100
Layer 3 - detection
Ecosystem scan
CommonCrawl corpus - billions of pages
Live audit
Any URL, on-demand, via residential proxy
Shared fingerprint corpus
Same matcher drives both paths
Layer 4 - delivery
Public site
Plugin / theme / CVE / provider pages
Public API
Bearer-token-authed, rate-limited
Safety Radar WP plugin
Install on any WordPress site
Each box below maps to the layer of the same color above.
Methodology

How the data gets produced

Security score methodology

How we turn CVE history, patch velocity, AST code signals, and developer trust into a single 0–100 number per plugin and theme.

Read the methodology

Plugin & theme detection

How we identify which WordPress plugins and themes are installed on any public site, using fingerprints drawn from CommonCrawl and direct crawls.

Read the methodology

PoC verification pipeline

How vulnerabilities in the database get verified by an autonomous agent that stands up a disposable WordPress, reproduces the exploit, and captures it on video.

Read the methodology
Deep dives

Individual subsystems, explained

One page per subsystem with the non-obvious design decisions called out. More land here as they're written.

Mika Sipilä
For nerds only

Hi - Mika here. I built WP-Safety solo, so the methodology below is genuinely how it works, not a marketing sketch. The deep-dives are where I go long on the non-obvious details. Strictly optional - the plugin and CVE pages carry the full story without any of this.

Mika Sipilä·Founder, WP-Safety.org
ARCHITECTURE → POC AGENT

PoC agent cascade

Autonomous CVE reproduction: lightweight-LLM → frontier-LLM cascade, ephemeral WordPress per task, independent frontier judge, Playwright evidence bundle, and the budget discipline that keeps the whole thing honest.

Read the deep-dive
DETECTION → PROVIDER

Hosting provider detection

Signal-first hosting attribution at CommonCrawl scale. Definitive vs supplementary fingerprints, confidence tiers, multi-signal resolution for edge-vs-origin ambiguity, and how the rule corpus is actually maintained.

Read the deep-dive
ARCHITECTURE → TAINT

Taint analysis

AST-level inter-procedural data-flow tracking across 7 superglobal sources, 31 sinks, and 47 sanitizers; the two-phase algorithm, the WordPress-specific special cases, and the edge cases it intentionally doesn't chase.

Read the deep-dive
DETECTION → CC PIPELINE

CommonCrawl pipeline

WAT-first narrowing, per-WARC-file byte-range indexing, co-located signing proxy, and the per-worker SQLite → merged DuckDB pattern that turn petabytes into tens of GB actually moved.

Read the deep-dive
Architecture

The system, end-to-end

System architecture

CommonCrawl ingestion, SVN mirroring, AST analysis, the two-tier LLM research pipeline, the PoC executor on ephemeral VMs, the public API, and the user-facing app. One diagram, the whole picture.

Open
Reproducibility

What you can check without trusting me

The methodology pages are worth reading, but a methodology you can't reproduce is just marketing. Here's what I ship so anyone can verify the pipeline's output independently. Weaponized material (full exploit payloads, full response bodies) is gated behind researcher verification - everyone else sees the non-weaponized skeleton that's enough to judge the method without publishing a working 0-click attack.

Playwright traces

Every verified CVE produces a ZIP trace openable in Playwright's own trace viewer. The public view shows timestamps, step names, and DOM state on benign surfaces; verified researchers get the full trace including exploit-payload frames and response bodies.

Partial public · full for researchers

Replay scripts

Every verified PoC also produces a standalone Playwright script that re-runs the exploit against your own WordPress install. Public readers see the non-weaponized skeleton (target, flow, setup); verified researchers get the full executable version including payloads.

Partial public · full for researchers

Fetched-at timestamps

Every plugin, theme, CVE, and provider page carries the timestamp its data was last refreshed. Staleness is legible; nothing claims to be fresher than it is.

Signal-level rationale

Every plugin-detection match on a site audit is accompanied by the exact signal (asset hash, REST route, generator tag) that triggered it. Scores enumerate every deduction. Detection is reviewable, not a black box.

Responsible disclosure, in plain words

Full exploit payloads and response bodies are only released to verified security researchers - the public view shows enough to evaluate the methodology without shipping a ready-to-paste 0-click attack for any CVE. Researcher access is free; verification is a lightweight identity check. If you're working on a legitimate engagement, email support@wp-safety.org with the subject "Researcher access request".

Roadmap

What's shipping next

A non-exhaustive view of the docs and methodology work that's in motion. These are the next deep-dives and dataset releases I'm actively working on.

  • WIP
    Full local SVN mirror of WordPress.org plugins
    Replaces the current on-demand svn export path on the analyzer. Unlocks bulk version-pair sweeps for the ecosystem-scale static-analysis preprint. Covered on the taint-analysis scale section.
  • WIP
    arXiv preprint: autonomous CVE reproduction at scale
    Methods section is roughly the PoC agent cascade deep-dive; results section will cover reproducibility rate, per-CVE cost, and judge-override ratio.
  • WIP
    arXiv preprint: passive hosting attribution at crawl scale
    Methods section is the provider-detection deep-dive; the dataset it describes will be published as the reproducibility artifact.
  • Next
    Plugin source mirror deep-dive
    Separate page covering the SVN mirror's own internals once it ships: sync cadence, storage layout, disaster recovery, historical revision queries.
  • Next
    OpenAPI spec + API reference page
    Machine-readable spec for /api/v1/* plus a generated reference page under /docs/api. Unblocks bearer-token integrations without handholding.
  • Idea
    Public bulk dataset downloads
    Monthly Parquet snapshots of the plugin_risk_assessments, observation, and provider-detection datasets for researchers who want to run their own analyses. Scoping what's safe to publish vs what needs aggregation first.
Why transparency

Three hard commitments

I won't paywall the core data

Every CVE, every plugin score, every developer profile stays freely accessible. Sponsors fund continuous monitoring, alerting, and deeper audits - never the base truth.

Vendor listings can't influence scoring

Plugin vendors can sponsor WP-Safety. What they can't buy is a score boost, a hidden CVE, or a reshuffled ranking. Product tiers are listed on /sponsors; the scoring engine doesn't know who's paying.

I won't hide my methodology

If I can't explain how a score was computed, I shouldn't publish it. These pages are the written-down version of that commitment.