Technical Details

This article describes how VMP Security works under the hood. It is intended for developers, system administrators, and operators who need a precise mental model of the plugin’s internals — for compliance reviews, integration work, or just for the general satisfaction of knowing what your security plugin is actually doing.

In This Article

• Plugin architecture
• Firewall internals
• Scanner internals
• Data storage
• Scheduling and background work
• Network traffic

Plugin architecture

VMP Security is structured as four loosely-coupled modules that share a common configuration store:

• Firewall. Per-request evaluation of incoming traffic. Loads as early as possible (see Optimizing the Firewall) and evaluates each request before it reaches WordPress logic.
• Scanner. Periodic file and database integrity checks. Runs as a background worker, divided into stages.
• Login Security. Two-factor authentication, brute-force lockout, and login-form hardening. Hooks into WordPress’s authentication flow.
• Reporter. Aggregates events, decides what to alert on, and emits notifications. Talks to the email subsystem locally and to Portal for remote routing.

The modules are deliberately decoupled. The firewall does not depend on the scanner; the scanner does not depend on Login Security. This makes it possible to have parts of the plugin disabled or unavailable without bringing down the rest.

Firewall internals

When Extended Protection is active, every PHP request that reaches the server runs the firewall loader (vmp-waf.php, placed at the WordPress root) via an auto_prepend_file directive in .htaccess. The loader runs before WordPress is initialized and:

1. Reads its configuration from the firewall storage (file-based by default, MySQLi if configured).
2. Evaluates the request against the rule set in order. Rules are organized into categories (SQLi, XSS, etc.); each rule is a regex or structural pattern with metadata (severity, category, ID).
3. Checks the allowlist for matches. If the request matches an allowlist entry, the firewall waives the relevant rule and continues.
4. If no rule matches, the request is allowed and PHP continues into WordPress as normal.
5. If a rule matches and is not allowlisted, the firewall logs the event, returns a 403 with the configured block page, and exits.

Rule evaluation is short-circuit: as soon as a request is judged blocked, no further rules are checked. The cost of running the firewall on a clean request is sub-millisecond on most hosts.

Scanner internals

A scan is divided into stages. Each stage is a discrete unit of work designed to fit inside the host’s PHP timeout. Stages are coordinated by the scan worker, which:

1. Reads the scan configuration (which checks are enabled, which paths are excluded).
2. Plans the work: a list of files to inspect, a list of database queries to run, a list of remote API calls to make.
3. Executes the next stage. Each stage works on a chunk of the planned work.
4. Records progress and exits.
5. Schedules the next stage as a WordPress cron event.

This design lets scans run for as long as they need without exceeding any single PHP request’s timeout. The trade-off is that a scan’s wall-clock duration depends on how often the cron events fire; on low-traffic sites without a real cron job, a scan can take hours of wall-clock time even though the actual CPU work is small.

Data storage

The plugin stores data in three places:

• WordPress options table. Configuration: every setting you set on the options pages, the license key, alerts configuration, etc. This is the data covered by Import/Export.
• Plugin-specific tables. Operational data that does not fit cleanly into options. This includes the scan-progress state, the audit log, the rolling Live Traffic data, the malware signatures, and (when MySQLi storage is enabled) firewall data.
• Plugin working directory. wp-content/uploads/vmpfence/ — used for debug logs, temporary scan artefacts, and similar non-critical state. The directory inherits WordPress’s upload-dir protection (no direct PHP execution).
• WAF backups. wp-content/vmpfence-backups/ — .htaccess backups created by the WAF Optimizer, kept so REMOVE EXTENDED PROTECTION can restore the original.

Data sensitivity classification:

• The license key and API tokens are validated against the API every dashboard load and stored in WordPress options.
• User-related data (Live Traffic captures, audit log entries) is stored in plaintext but is subject to the privacy controls described in the relevant articles.
• Firewall rules and signatures are public knowledge and stored in plaintext.

Scheduling and background work

The plugin uses WordPress’s built-in cron system (WP-Cron) for all background work. Scheduled events include:

• Periodic firewall rule and signature updates.
• Vulnerability database refresh.
• Scheduled scans.
• Scan-stage continuation events.
• Daily audit-log compaction.
• Live Traffic retention pruning.
• Connection check-in to Portal (when connected).

WP-Cron is the right choice for sites of all sizes, but it has a known limitation: events only fire when someone visits the site. On low-traffic sites this can starve the cron. The Diagnostics page surfaces the last-cron-run timestamp; if it is consistently old, install a real cron job (see the Scan Troubleshooting article).

Network traffic

The plugin makes outbound HTTPS connections to:

• The VMP Security API — our main backend. Used for license validation, firewall rule updates, malware signature updates, vulnerability data, and the Real-Time IP Blocklist sync (Premium). If your environment requires explicit hostname allowlisting, contact support for the current endpoints.
• vmpsecurity.com (Portal endpoints) — only when the site is connected to Portal.
• api.wordpress.org, downloads.wordpress.org, core.svn.wordpress.org, raw.githubusercontent.com — for downloading official WordPress, plugin, and theme files for integrity checks.
• safebrowsing.googleapis.com — URL reputation lookups during scan.
• IP-lookup services (api.ipify.org, ifconfig.me, icanhazip.com, ip-api.com, ipwhois.app, download.ip2location.com) — server-IP discovery, geolocation, and country blocking.
• Threat-intel sources (api.urlvoid.com, www.virustotal.com, checkurl.phishtank.com) — URL reputation validation.
• Vulnerability databases (services.nvd.nist.gov, wpscan.com, cvedetails.com, cve.mitre.org) — CVE matching during the vulnerability scan.

All connections use TLS with certificate verification. None of these endpoints receive your file content or database content — the heavy scanning work happens on your server.