# What the scanner checks

Shieldlume Security combines local observations with optional reference and intelligence sources. Free and Pro use the same detection engine. Pro adds investigation, scheduling and repair workflows; it does not turn an uncertain finding into a confirmed infection.

| Check | What the result means | Coverage limits |
| --- | --- | --- |
| Local PHP and JavaScript analysis | Looks for supported relationships between inputs, decoding, execution and executable writes; also flags PHP in verified upload locations. | Bounded structural checks, not complete program analysis. Legitimate custom code can trigger a finding; indirect or unfamiliar behavior can be missed. |
| File integrity | Compares eligible WordPress files and supported repository components with version-matched references. | A mismatch is evidence of a difference, not proof of malware. Missing references, custom/premium components and changed versions can leave files unassessed. |
| Site changes and content observations | Records supported administrator, execution-surface and injected-content observations for review. | The first observed state is not a trusted-clean baseline. Normal maintenance can explain a change. |
| Optional vulnerability information | Matches supported installed components and versions to the connected advisory provider. | Requires a permitted feed connection; unsupported or stale information is labelled. An affected version does not prove exploitation. |
| Optional local ClamAV | Streams eligible files to a host-managed local engine and records its definition freshness. Definitions older than 48 hours are refused. | Off unless the host configures it and the administrator enables it. Eligible files are at most 2 MiB; host limits and definitions control additional coverage. |
| Optional signed indicators | Compares safely read whole-file SHA-256 hashes, including eligible streamed files up to 16 MiB, with a signature-authenticated bundle from an operator-trusted publisher. | No maintained WordPress-malware indicator service or corpus is bundled. Signatures authenticate the source; they do not prove comprehensive or accurate classification. No match applies only to the checked bundle. |

## Supported file paths

File scanning requires canonical absolute paths on a local POSIX filesystem, without symlinked roots or path components. Windows drive and UNC paths are unsupported. A readable directory alone does not establish scanner eligibility; diagnostics checks the same path guard used for scanning. Rejected paths remain unassessed.

## Processing limits and incomplete work

Structural analysis and optional local ClamAV assessment remain limited to 2 MiB per file. Eligible larger files can be read in bounded chunks, up to 16 MiB and a two-second read deadline. The completed, stable snapshot supplies whole-file hashes for eligible official-reference comparisons and separately configured signed SHA-256 indicators; caller-supplied claimed hashes are not accepted. A file that changes during the read, cannot be read safely or exceeds the bounds remains unassessed. A completed hash or reference comparison does not mean structural or ClamAV analysis ran. No match against a bundle is not a guarantee of safety.

The coverage view groups retained size-limit details and lists large files with their separate hashing, official-reference and signature statuses when recorded. Older scans may lack these fields; missing data is labelled as not recorded rather than inferred from a zero finding count. A reference match is correspondence with that release, not proof that the original release is safe.

Pro can separately compare observations from two finished broad scans with identical recorded size-related structural gaps, matching assessed paths and unchanged rules, settings, references and gap content hashes. This is labelled a partial comparison; the scans remain incomplete. Other unassessed or incompatible coverage prevents that comparison.

## How saved scans progress

Start a scan explicitly or enable a schedule. While its dashboard page is visible, the browser can continue that exact already-started scan through authenticated administrator POST requests. Read-only status refreshes do not advance work or start a scan. Existing permissions still govern optional reference and intelligence requests; foreground continuation grants no new service permission.

File-processing batches request at most 200 work units, such as file checks or directory entries, with an eight-second loop budget. These are work units, not a promised file count or total request duration: a bounded operation already begun can finish after the loop deadline, and reference/network phases have their own timeouts. Shared locks and retry state prevent foreground tabs and background workers from processing the same batch concurrently. With JavaScript unavailable, **Continue scanning** uses the same guarded batch path.

Hiding or closing the page stops new browser work; a request already in flight may still finish and save its progress. WordPress cron remains the fallback and depends on site traffic unless the host runs a regular cron worker. A tab being visible or a wake-up being scheduled does not prove that a batch ran. Progress and terminal states come from saved evidence.

**Stop** saves a request for the exact scan even while its current batch holds a lock. That batch can finish; the plugin's foreground, cron and CLI runners handle the saved stop before starting another batch. External integrations that call the Scanner API directly retain the existing API and may finish already-running work; they must coordinate their own later calls. Stopping retains partial evidence and does not establish a clean result.

## Finished scans and coverage gaps

**Scan finished with limited coverage** means the work queue finished but some checks remain unassessed. The underlying result remains incomplete. No findings recorded means no findings in the checks performed, not a clean-site verdict. Interrupted, failed and cancelled work is kept distinct from a finished queue.

**Latest finished site scan** records the broad scan that reached its finished phase, including one with coverage gaps. An older **site scan without recorded coverage gaps** is shown separately only when one is recorded and its time differs. An absent history entry is not a failed scan. Stopped and failed scan timestamps are labelled separately from finished queues. Targeted verification covers the selected finding and does not replace broad-scan history. Missing counters are unknown, not zero.

## Progress and file counts

The dashboard shows the saved scan stage and file counts. Discovery is incremental: enumerated entries include directories and unsupported files, whereas checked counts eligible processed files. Dividing checked by enumerated would not give a reliable percentage or ETA. Configured paths, exclusions and count definitions are unchanged by the 1.1.6 continuation changes and 1.1.7 display improvements. Counts on different runs depend on the actual site contents, selected scope and settings; a larger count alone does not establish broader detection.

## Local scan-report downloads

**Download scan report JSON** is available beside the saved dashboard result, together with a link to findings and evidence exports, as well as in Scan details. It is a separate administrator POST action protected by the action nonce. It reads the exact retained scan without advancing it. The `local_scan_report` document is bounded to 256 KiB and includes allowlisted scope, timestamps, counters, coverage, limitation references, skipped details and summary history. At most 100 skipped details, 100 large-file details and 100 limitation references are included; retained history may already have expired. If the selected scan changes during preparation, reload and request a new report. Over-budget preparation produces no partial attachment.

The report declares `findings_included: false`. Use the existing all-retained-findings or filtered-findings JSON export for finding evidence; their contracts are unchanged. Scan reports use reason codes and correlation references instead of raw error messages, and exclude source code, database contents, credentials, settings, account data, site URLs and absolute paths. Valid relative file names can still identify private components. Review and protect downloaded copies before sharing; they are not site backups or proof of cleanup.

## Who maintains each source

The bundled structural checks change with Shieldlume Security releases. WordPress reference checks rely on eligible official reference data, while the optional vulnerability feed comes from Wordfence Intelligence. A host enabling ClamAV is responsible for installing the engine and maintaining its definitions. An operator configuring signed indicators is responsible for the publisher and its maintenance. Review the recorded source, check time and freshness inside the plugin; unavailable or expired coverage must not be treated as current protection.

## What testing has established so far

In a limited compatibility check on 25 September 2026, the structural engine assessed 7,459 eligible files from official WordPress 7.1.2, WooCommerce 9.9.0 and Contact Form 7 6.1.2 archives without raising an alert. Fourteen files were not assessed because size or analysis limits were reached. A 28 September rerun with beta14 assessed 7,467 files without alerts after correcting avoidable nested-closure analysis limits. Six files still exceed the 2 MiB structural-analysis limit. Neither narrow benign-software check establishes a real-world false-positive rate.

For release 0.1.7 on 4 October 2026, the same fixed benign corpus was rerun on PHP 8.3.33, 8.4.26 and 8.5.4. Each run assessed 7,467 eligible files with no alerts and left the same six oversized files unassessed. These are the named historical software versions, not a survey of current websites or all plugins. Harmless synthetic cases separately checked supported detection relationships, safe reads, size limits and concurrent-file changes on all three PHP versions; samples were never executed.

Local WordPress view checks also ran at a 64 MiB PHP memory limit with disk-space, file-owner and file-flush functions individually disabled. The interface rendered and explained missing host capabilities instead of treating them as successful checks. These bounded compatibility checks do not establish full scan capacity at 64 MiB, repair eligibility on every host, or shared-host performance.

A separate local integration check recognized the harmless standard EICAR test using genuine ClamAV definitions and accepted ordinary plain content. That demonstrates the adapter working with that engine; it does not measure WordPress-malware detection effectiveness.

A representative malware evaluation and independent false-positive assessment have not been completed. No detection percentage, independent certification or guarantee of a clean site is claimed. False positives remain possible, especially for legitimate custom code or intentionally modified files; unknown and unsupported threats can be missed.

## From an observation to a decision

Read the explanation, inspect the recorded evidence and consider the suggested next check. Local analysis is available without an AI service. Optional Pro AI Advisor explains selected finding metadata when the connected license includes AI, the service is available and the administrator separately consents. It does not receive source files or inspect file contents. Local guidance remains available without a connection. Eligible Pro repairs continue through preview, explicit approval and verification, with protected recovery records. Retain an independent backup: restoring an original file may also restore the original problem.