WordPress security audit
A manual, evidence-led review of the WordPress application and the controls around it. The engagement identifies exploitable weaknesses, unsafe configuration, exposed information, and recovery gaps before they become an incident.
Never send credentials, private keys, backup archives, or confidential source code through this website.
What you receive
Controlled cross-site read and write between sites sharing one account.
One compromised site can reach the files and configuration secrets of three others.
Move each site into its own hosting account and PHP-FPM identity, with separate deployment and database credentials.
Open — staging migration passed; production separation still outstanding.
| Finding | Final disposition |
|---|---|
| VPS-01 · Root SSH password access | Resolved Acceptance checks passed |
| WP-01 · Public events backup | Resolved Acceptance checks passed |
| HOST-01 · Shared filesystem identity | Open Staging passed, production due 2 October |
| INFO-01 · Public version metadata | Accepted Named approver, review due 22 December |
From the 22-page sample report, a fully fictional worked example. Read the whole report
Scope
The exact scope is agreed before access is provided. A typical engagement examines the application, its extensions, the hosting boundary, and the operational controls needed to recover safely.
Core configuration, exposed files and endpoints, debug settings, scheduled tasks, update controls, and security-relevant defaults.
Installed, active, abandoned, duplicated, or unexpectedly modified components and their known vulnerability exposure.
Administrative accounts, role assignments, MFA, session handling, password controls, and access pathways.
Public entry points, forms, APIs, uploads, XML-RPC, administrative exposure, and information disclosure.
Relevant TLS, PHP, file-permission, database, backup, isolation, and web-server controls available within scope.
Backup separation, restoration evidence, logging, alerting, and the operational steps used when something goes wrong.
Method
Define the sites, environments, access, exclusions, testing window, and escalation contacts in writing.
Review external exposure and approved internal controls. Potential issues are manually checked before they are reported.
Document the affected component, sanitized evidence, practical impact, and a remediation path appropriate to the environment.
Implement agreed fixes or support the responsible team, then verify the result and update the report status.
Output
Findings are written so an owner, developer, host, or administrator can understand what matters and who should fix it.
How to start
No access, credentials, or commitment are needed to get a proposal. The sequence is the same for every audit.
Send the domain, whether WooCommerce or multisite is involved, how many sites there are, and what prompted the audit: an insurer form, a launch, a client question, or general assurance. No credentials.
The proposal states the scope, exclusions, deliverables, start date, and the exact fixed fee within the $150–$500 range. Scoping and the proposal are free and carry no obligation.
External review first, then credentialed checks through named, temporary, least-privilege access where the scope requires it. Each potential finding is validated by hand before it is reported.
A prioritized findings report in the sample-report format, a walkthrough with the responsible people, and a retest of the agreed fixes with each finding’s status updated.
Plugin or audit
Wordfence, Sucuri and MalCare do useful work continuously: they block known attacks and flag known malware in the WordPress files. An audit answers the questions a plugin running inside WordPress cannot.
Keep the plugin; add the audit once a year or before an insurer asks. The two answer different questions, and the audit report records what the plugin was already doing well.
| Area | What a plugin scan checks | What a manual audit checks |
|---|---|---|
| Server isolation | Nothing beyond the site it runs in, as that site’s PHP user | File ownership and permissions, PHP handler and isolation settings, and whether another account on the host can reach this site’s files |
| Roles and business logic | Lists administrators and enforces login rules such as 2FA | Who holds which role and why, custom capabilities, and whether forms, coupons, checkout and APIs enforce the rules they are meant to |
| Backup restore evidence | Not tested — a security scan does not restore anything | Where backups live, whether they are separate from the site, and when a restore was last proven |
| Exposed endpoints | Blocks known attack patterns against WordPress routes; flags some exposed files | Everything reachable from outside — XML-RPC, REST routes, admin paths, staging copies, backup archives — validated by hand |
| Third-party scripts | Files on disk; scripts loaded from other domains are largely outside a file scan | Every external script and tag, who controls it, and whether it runs on login, admin or checkout pages |
Choose correctly
Choose this service when you want preventive assurance, a structured control review, or an independent answer to whether a WordPress environment is configured and operated safely.
If the site is redirecting visitors, creating spam pages, showing unknown administrators, or repeatedly becoming infected, use the malware-removal service. If the objective is adversarial testing of custom functionality or business logic, use the penetration-testing service.
Common questions
No. Tools help with coverage, but potential findings are manually validated and explained in the context of the actual site. Scanner output is not presented as a confirmed vulnerability.
Not always. Work can begin from the external attack surface. Credentialed checks use named, temporary, least-privilege access agreed after scoping.
Yes, when they are explicitly included in scope. Their roles, integrations, data flows, and operational risk can materially change the assessment.
Yes. Remediation can be performed directly where agreed or delivered as guidance for the responsible team. Agreed changes can then be retested.
Typically $150–$500 for a single site, delivered in 2–4 business days from access to report. Site count, WooCommerce or multisite complexity, and reporting requirements move the figure — the pricing page explains the scope factors, and the proposal states the exact fixed fee.