WordPress Vulnerability Scan: Turn Software Inventory Into Actionable Security Risk
Aegisify Vulnerability Scan combines WordPress software inventory, known-vulnerability correlation, hardening and exposure review, integrity signals, API visibility, operational health, recovery readiness, and dependency-audit evidence when the related capability and local tooling are available.
The scan is designed to explain what is installed, what is exposed, which components or dependencies have risk evidence, what defensive controls appear weak or changed, and where the team should investigate first.
From an Authorized WordPress Site to a Prioritized Finding
This is the high-level path used by Aegisify Vulnerability Scan. It intentionally omits scanner signatures, private route mechanics, and exploit-oriented implementation detail.
Click a stage to expand
01Scopeexample.com
02InventoryAgent metadata
03Local AuditComponent + dependency evidence
04EnrichVulnerability intelligence
05CorrelatePosture + exposure
06OperateAssign + remediate + verify
What Aegisify Means by “Vulnerability Scan”
This is a consolidated WordPress defensive review—not merely a public CVE lookup.
Aegisify Vulnerability Scan combines WordPress vulnerability correlation with broader software-risk visibility, hardening drift, exposure review, integrity evidence, and operational-readiness checks.
The scan is intended to be the recurring starting point for broad WordPress defensive review. It asks several connected questions: Is WordPress core current? Which plugins and themes are installed and active? Are known vulnerabilities associated with those versions? Are unsupported or inactive components increasing the attack surface? Do supported package manifests reveal dependency risk? Are critical hardening settings drifting? Are there public REST/API or login conditions that deserve review? Is the site operationally ready to recover?
How to Use Vulnerability Scanning as a Recurring WordPress Security Baseline
The public workflow emphasizes repeatable coverage, background processing, current inventory, and verification rather than reproducing authenticated application controls.
Know the WordPress Components Before You Judge Their Risk
A vulnerability match is only useful if the product identity and version context are trustworthy.
Core Version and Update State
The Agent records WordPress core version context and whether an update is available. The assessment uses that evidence to distinguish a current installation from one that may be operating behind the available release state.
Active, Inactive, and Must-Use Plugins
The inventory includes active and inactive plugins plus must-use plugins. This matters because inactive software can still remain on disk, while must-use components may affect the site without appearing in the normal active-plugin workflow.
Active and Installed Theme Context
The Agent captures theme inventory and version state so the scan can correlate installed themes with vulnerability, update, integrity, and support-status evidence instead of evaluating only the active presentation layer.
Inactive, Abandoned, and Unsupported Signals
The assessment looks beyond known CVEs to identify software-hygiene conditions such as inactive components and indicators that a plugin may be abandoned or unsupported. These findings help teams reduce unnecessary attack surface.
Correlate WordPress Versions With Current Risk Evidence
The recurring assessment includes WPVulnerability-backed correlation for WordPress core, plugins, and themes.
Aegisify correlates WordPress software inventory with WordPress-focused vulnerability intelligence. When advisory data is available, WordPress core, plugin, or theme versions can be associated with vulnerability evidence and fixed-version guidance for further review.
The Agent also performs a local WordPress component-risk review, including update state and other software-hygiene signals. Local results include coverage status so Aegisify can distinguish collected evidence from a source that was unavailable or could not complete.
Look Beyond WordPress Plugins to the Packages They Bring With Them
Modern WordPress applications can contain PHP, Python, and JavaScript dependencies that are not obvious from the plugin list.
The current Agent inventory can discover supported dependency manifests and lockfiles for Composer, Python, npm, Yarn, and pnpm. It extracts package metadata and records tooling capabilities. When the required local tooling and manifests are available, the Agent can run package-manager or dependency-audit workflows and return normalized advisory evidence for the assessment.
Aegisify keeps software-vulnerability evidence and dependency-risk context distinguishable so teams can understand where each signal originated. Where supported, dependency intelligence can be enriched with package advisories and exploit-priority context. Coverage varies by component type, available manifests, local tooling, and external-source availability, so an unavailable source should never be treated as a clean result.
Known Vulnerabilities Are Only One Part of WordPress Risk
The assessment also reviews defensive conditions that can change the likelihood or impact of a security issue.
Login, Registration, and Account Posture
The baseline reviews login exposure and hygiene, open-registration posture, user-enumeration signals, high-privilege account inventory, suspicious administrator conditions, and other account-related defensive indicators.
HTTPS, Headers, Artifacts, and Public Hints
Aegisify checks broad categories such as HTTPS/TLS state, certificate health, security headers, installation/readme artifacts, directory-listing conditions, public robots hints, mixed-content indicators, and related browser-facing hardening evidence.
Critical Files and Settings Drift
The defensive baseline reviews critical-file permissions and writability, configuration-hardening posture, selected database/default settings, core-settings drift, and evidence that important local settings have changed from the expected defensive baseline.
REST APIs, Routes, and Browser Assets
The assessment inventories REST namespaces and public route exposure, highlights sensitive-route conditions, reviews browser-facing scripts/assets, and correlates that surface with other defensive evidence instead of assuming WordPress risk lives only in plugins.
Identify Signals That Software or Files May Not Match the Expected State
Integrity evidence helps teams distinguish an outdated component from a potentially altered environment.
The assessment includes high-level checks for plugin and theme integrity mismatch indicators, suspicious newly observed files in upload areas, unexpected executable-code posture in locations that should be tightly controlled, basic file-change correlation, writable critical files, malware-signature signals, and obfuscated-code indicators.
These checks are intentionally presented as signals for investigation. A signature or mismatch is not automatically proof of compromise, and the marketing documentation does not expose the underlying signatures, paths, or scanner expressions. The purpose is to give administrators evidence that deserves validation through normal incident-response and file-integrity procedures.
Security Includes the Ability to Detect Change and Recover
Aegisify connects vulnerability review with operational conditions that affect resilience.
WordPress and Application Health
The scan can incorporate Site Health warnings, missed or unhealthy scheduled events, application error conditions, and other runtime indicators that may reveal broken maintenance, failed background work, or security-relevant operational drift.
Backup and Restore Readiness
The assessment checks for backup and recovery evidence because remediation without a credible rollback or restore path can create additional operational risk. Presence is not treated as proof that a restore test has succeeded.
Security Plugin and WAF Visibility
The scan records visibility into installed security controls and firewall/edge protection posture. This helps Aegisify correlate findings with the defensive environment without claiming that the presence of a tool guarantees protection.
External Trust and Blocklist Signals
Basic blacklist, reputation, SSL validity, and application-health signals add external context. They are supporting evidence, not substitutes for the internal WordPress inventory and vulnerability analysis.
How Vulnerability Evidence Is Fetched From the Aegisify Audit Agent
The long-running Agent work is asynchronous so the WordPress browser session does not have to carry the scan.
Aegisify Starts the Background Assessment
For an authorized site such as example.com, Aegisify establishes the vulnerability-assessment scope and identifies the evidence categories required for the review.
The Connected Agent Queues Local Vulnerability Work
Agent-assisted vulnerability work uses the authorized connection to perform local inventory and supported dependency analysis. The Agent builds current WordPress evidence and prepares normalized results for the Aegisify service without requiring public exposure of internal WordPress data.
Aegisify Correlates and Enriches the Evidence
Aegisify correlates the Agent evidence with supported vulnerability intelligence, preserves source and coverage context, and produces a normalized view that can be reviewed, prioritized, remediated, and compared with later assessments.
Reduced Coverage Is Reported Instead of Hidden
If an intelligence source or Agent-side capability cannot complete, Aegisify can preserve a coverage notice and status. That allows the operator to distinguish a clean result from an incomplete source of evidence.
What Sensors Add—and What Telemetry Access Controls
A vulnerability scan primarily uses inventory and scan evidence, while sensors and telemetry can add change and operational context.
The Agent’s WordPress Activity Log sensors can record supported events across users, settings, plugins, themes, core, files, posts, categories, tags, comments, media, menus, options, and Aegisify Audit itself. Most sensor definitions are enabled by default, while four noisy option-level sensors are disabled by default. These local events can help explain changes such as plugin activation, administrator activity, or configuration updates around a finding.
Telemetry Access Control is separate. The current Agent defaults the master telemetry control and every category to off. Administrators decide whether SaaS may receive supported metadata such as versions, integrity hashes, administrative inventory, cron/event data, backup/restore evidence, snapshot differences, file-drift history, or privileged configuration state. Optional log-fetch permissions are also separately controlled.
How to Interpret Vulnerability Findings Without Treating Every Match the Same
Aegisify separates known software vulnerabilities, dependency risk, local defensive findings, and provider coverage so teams can investigate with context.
The assessment can combine local Agent component coverage, dependency findings, WordPress vulnerability correlation, package advisory evidence, and fixed-version guidance. Findings remain tied to the relevant site and assessment context rather than appearing as untraceable global warnings.
Teams can triage findings, assign ownership, document accepted risk, remediate through normal change control, and verify again. Supported high-priority findings may also be eligible for focused verification so fresh evidence can be collected for the specific issue after remediation.
Common Questions About Aegisify Vulnerability Scan
Does Vulnerability Scan only check plugins?
No. Aegisify Vulnerability Scan covers WordPress core, plugins, themes, must-use plugins, dependency evidence, hardening, REST/API exposure, integrity and file-change signals, Site Health, scheduled events, recovery readiness, security-tool visibility, reputation, and other defensive posture categories.
What kind of vulnerability intelligence does Aegisify use?
Aegisify combines WordPress-focused vulnerability intelligence with supported dependency and package advisory sources when available. Coverage can vary by component type, available local manifests, enabled capabilities, and provider availability, so missing coverage should never be interpreted as proof that no risk exists.
What happens if the Agent or a provider is unavailable?
The workflow tracks provider and tooling status and can complete with reduced coverage rather than representing unavailable evidence as a clean check. Agent-assisted local inventory and dependency evidence require the connected Agent and the relevant local capabilities.
Does a vulnerability match prove my site is exploitable?
No. A version/advisory match is evidence that requires context. Exploitability can depend on configuration, reachable code paths, authentication, mitigations, affected features, and other conditions. The scan helps prioritize investigation; it does not replace analyst validation or dynamic testing.
Where does SAST fit?
Vulnerability Scan focuses on software and defensive risk. Use Static Code Analysis when you need code-level inspection. For the overall defensive workflow, return to the Static Security Scan overview.