Interaktiv Security Scanner

Interaktiv Security Scanner checks installed plugins and themes for known vulnerabilities and monitors unexpected file integrity changes. Vulnerability Intelligence uses the Wordfence Intelligence v3 feed (object-map, array, and NDJSON formats; gzip-aware streaming) as its data source. The plugin is not affiliated with Wordfence.

This plugin is designed to be:

• Lightweight – uses the Wordfence feed API and official WordPress core and plugin checksum services.

• Privacy-friendly – no tracking or telemetry; vulnerability matching happens locally on your site.

• Memory-safe – supports streaming large NDJSON and gzip feeds without exhausting server memory.

• Fully configurable – email notifications, severity levels, scheduled scans, and more.

Perfect for agencies, freelancers, and site owners who want proactive security visibility without complexity.

Key Features

• Scan installed plugins and themes for known vulnerabilities.

• Supports NDJSON, array JSON, and object-map JSON feed formats.

• Handles gzip-compressed feeds automatically.

• Match detection for:

• severity levels (critical, high, medium, low)

• patched versions

• remediation steps

• Customizable email notifications with templates.

• Optional scheduled scans (hourly, daily, or custom).

• “Only notify on new issues” mode.

• Supports the current Wordfence Intelligence V3 API with API key authentication.

• Debug mode with detailed logs.

• No tracking or telemetry.

• Matching and reporting logic runs locally on your site.

• File integrity checks for WordPress core checksums, unexpected server-side files in uploads,.htaccess and critical files, plus selected custom components.

File Integrity

org checksums in bounded background jobs. A confirmed file mismatch is VERIFICATION_FAILED. VERIFIED_OFFICIAL means all manifest-listed files match and no unexpected files were observed during a completed check.

Manifest completeness is not independently established. Unavailable checksums and interrupted checks are UNVERIFIED with distinct details. These results describe current files; they do not establish update origin, time, or freedom from malicious code.

FIM findings remain visible and baseline acceptance is manual.

org slug and the installed plugin version. It strictly checks manifest files, including readmes, and reports extra files. Legitimate local additions or readme differences can therefore produce a failure; investigate before deciding whether a file is malicious.

Custom, premium, unsupported, or unavailable versions may have no official manifest and remain unverified. Verification has file, response-size and time limits and does not create an atomic filesystem snapshot. It cannot rule out concurrent changes after a file was checked.

A manifest that omits both an official file and its missing local copy cannot be identified as incomplete without an independent reference.

0 adds local change detection. It is not a malware signature scanner and does not remove, quarantine, or repair files. WordPress core files are compared with official checksums for the installed version and locale.

If that service is unavailable, the result says verification was unavailable; files are not labeled compromised. Executable extensions in uploads include PHP, PHP3/4/5/7/8, PHTML and PHAR, case-insensitively.

Unexpected executable files in uploads are reported by relative path. For this uploads check, notification change detection uses the observed file modification time rather than a content hash; a content change that keeps the same path and modification time will not generate a new uploads-only notification. Detection does not imply that a file is malicious.

php after optional leading UTF-8 BOM and surrounding whitespace. Files with comments or additional code remain findings. The check reads at most 65 bytes from candidates no larger than 64 bytes and saves no trust state.

Administrators can allow known executable files in uploads by entering one exact relative file path per line on the FIM settings tab. The list is empty by default and accepts only paths under wp-content/uploads/; wildcard and directory rules are not supported. An allowed path suppresses only that file’s uploads:UNEXPECTED finding.

Removing it makes the file reportable again on the next scan. Add only files intentionally created by trusted plugins.

The admin page has separate Vulnerability Intelligence and File Integrity tabs. 11 until explicitly enabled on its tab. Each module has its own manual scan, status and scheduled hook.

Disabling FIM retains its baseline and results but stops new FIM scans and emails. The administrator saves plugin/theme selections in FIM settings, separately from explicitly creating or accepting a SHA-256 trusted baseline. Newly selected components remain pending until baseline acceptance; unselected components stop being compared without false deletion findings.

A baseline trusts the current state; it does not prove the site is clean. No baseline is created during upgrade. htaccess change findings require a trusted baseline.

Normal scans never update or recreate the baseline. Rebuilding requires an administrator, nonce and confirmation checkbox, and is refused during an active scan. A failed or incomplete traversal cannot replace the existing baseline.

A separate confirmed Reset FIM baseline action removes the trusted baseline, all baseline storage parts and previous FIM scan results without changing plugin settings, vulnerability results or schedules; a new baseline must be created explicitly.

The File Integrity tab starts with an overview, scan action and grouped findings. Monitoring scope and trusted baseline controls are together; scan scheduling, notifications, templates and the uploads allowlist follow in separate sections. Component selection is searchable and shows unsaved changes.

Save all FIM settings saves the monitoring scope and the other FIM settings together; baseline acceptance and reset remain separate confirmed actions using the saved scope. The baseline is a record of an explicitly trusted state, not proof that files are clean.

Both tabs edit the same notification email address. FIM has its own notification switch, finding categories, only-new-or-changed option, subject template ({site}, {count}, {time}) and plain-text body template ({site}, {count}, {time}, {status}, {affected}, {context}, {counts}, {list}, {warnings}).

The default body summarizes scan completeness, affected files, findings, selected category counts, up to 20 relative paths and up to 10 warnings; it omits the Warnings section when there are none and never includes file contents. In a custom body template, an empty {warnings} becomes an empty string; any heading written by the administrator remains.

Manual and scheduled FIM scans share one notification history: a new or changed finding sends one aggregate email, unchanged unresolved findings do not resend by default, and a clean scan resolves the incident so a later recurrence can notify again. A failed delivery remains eligible for retry on the next scan. A separate FIM test-email button renders the saved templates, marks the message as a test and does not change scan or notification history.

The admin page checks saved state by AJAX and updates FIM results while scheduled plugin verification is active. Polling is bounded; if WP-Cron does not run or polling stops before verification finishes, refresh the page to check the saved results.

The plugin scans the WordPress root without following symlinks. git and node_modules directories are skipped entirely. htaccess and uploads executable files, but their other files are excluded from selected-component hashing.

In selected components, log, archive, SQL and temporary file extensions are also excluded. The traversal is capped at 100,000 visited entries and 120 seconds. The trusted map is capped at 20,000 tracked files, 256 MiB per tracked file and 8 MiB of path/hash data.

At most 200 example findings are stored for the UI. On an unreadable path, a limit, or a timeout, the scan is marked incomplete and baseline DELETED findings are suppressed. Custom uploads directories outside the WordPress root are reported as uninspected.

Paths in results are relative; file contents are never stored.

FIM notifications use a separate state from vulnerability notifications. On a complete scan, an aggregate email is sent when the incident fingerprint (type, change, relative path and observed hash or uploads mtime) changes. On an incomplete scan, the plugin emails the first incomplete transition or eligible finding/warning change detected within the scanned area; unvisited files cannot be verified.

An unchanged unresolved incident does not resend on every scan. A clean completed scan clears the incident state so a recurrence notifies again. Manual and scheduled FIM scans both use this policy.

FIM and vulnerability scans run independently. On feed failure, the previous successful vulnerability result remains visible with a stale warning and its last successful timestamp.

How It Works

The plugin fetches the Wordfence Intelligence feed, streams it in a memory-safe way, and compares each entry with your installed plugins/themes.

You can trigger scans:

• manually from the WP Admin panel

• or automatically via the scheduled scan option

The results include severity, details, patched versions, and links to advisories.

External services

This plugin connects to the Wordfence Intelligence vulnerability feed provided by Defiant, Inc. to download vulnerability data used for scans.

org for the installed WordPress version and locale. The request does not upload local file contents or the baseline. It sends the version, locale and normal HTTP connection metadata.

If the checksum API cannot be reached, core verification is marked unavailable; local uploads and baseline checks continue.

org/plugin-checksums/ using each plugin’s directory slug and installed version. These values are included in the request URL, along with normal connection metadata such as the server IP address. org.

Valid manifests are cached by slug and version for one day. org/about/privacy/.

The request is sent when you run a manual scan, when a scheduled scan runs, or when the cached feed expires and the plugin needs a fresh copy. The request sends your configured Wordfence API key in the Authorization header and standard web request metadata from your server such as your server IP address and user agent. The plugin does not send your installed plugin/theme inventory, scan results, or site content to Wordfence.

Service provider: Defiant, Inc.

com/terms-of-service/

com/privacy-policy/