Tailored WordPress penetration testing.
A WordPress security audit means testing your site as it actually exists: the core, but above all the plugins, the custom theme, the roles, and everything the years have stacked on top. That is the way in, and a security plugin does not see it.
The problem is almost never WordPress.
The WordPress core is read by a lot of people and patched fast. That is not where I find flaws, and it is not where attackers find them either.
The risk comes from what gets added. A free plugin written six years ago by an author who stopped maintaining it. A custom theme delivered by an agency, never reviewed since, with a contact form that builds its query by hand. An AJAX action registered for logged-in users that forgets to check which capability the caller actually holds. An old plugin deactivated but still sitting on disk, and still reachable directly by its URL.
These flaws exist only on your installation. No signature database contains them, so no scanner will report them. They are found by reading and by manipulating, which is exactly the work I do.
What I test.
A WordPress site has entry points of its own. These are the ones I cover every time.
- Installed plugins: known vulnerable versions, but above all flaws specific to your configuration and your combination of plugins.
- Custom theme: hand-built queries, unescaped output, PHP files callable directly.
- Roles and capabilities: what a subscriber, contributor or author can really reach, beyond what the menu shows them.
- AJAX actions and hooks: missing capability or nonce checks on the entry points plugins register.
- REST API and XML-RPC: endpoints exposed by default or by plugins, user enumeration, uncontrolled writes.
- Media library and uploads: accepted file types, possible execution, overwriting existing files.
- File exposure: reachable backups, debug logs, configuration files left on the server, Git repositories published by mistake.
- WooCommerce where present: checkout flow, discount rules, payment webhooks, access to customer data.
How an engagement runs.
Scoping
We identify the site, the roles in use, whether there is a custom theme or plugins developed specifically for you, and what is excluded. Testing agreement and NDA signed before any access.
Inventory
A census of plugins and their versions, the theme, the exposed entry points, and anything sitting on the server that is referenced nowhere. This step alone regularly turns up surprises: an old staging site still reachable, a downloadable backup, a deactivated plugin still accessible.
Role testing
I log in with each role and try to reach what is not meant for me: admin actions, other authors' content, site settings, restricted AJAX actions. Privilege escalation in WordPress almost always comes from a capability check that a plugin got wrong.
Custom code review
The code written for you gets the most sustained attention, since it is the only code nobody else in the world has ever reviewed. Forms, queries, rendering of user-supplied data, file handling.
Report, debrief, retest
A report prioritized by real severity, with a reproducible proof of concept and concrete remediation for each finding, written so your agency or developer can act on it. A debrief, then a retest of every fix, included.
What this looks like in practice.
Types of findings encountered on real installations. Client identities and perimeters are never disclosed.
What it costs.
Quoted per engagement, on the same variables as anywhere else. On WordPress, three things account for most of the spread.
The volume of custom code first: a site built from official-repository plugins and an off-the-shelf theme takes far less time than one where the agency wrote half the features. Then the number of plugins, and above all their nature: those that add forms, member areas, permissions or payments count for much more than one that manages a cache. Finally, whether WooCommerce or a customer area is present, which adds an entire layer of business logic to test.
A small brochure site goes quickly. A store with customer accounts, discounts and integrations is a real engagement. The first conversation is there to find out which one you are.
Common questions.
Is WordPress an insecure CMS?
The WordPress core is audited constantly and patched quickly. The risk comes from the ecosystem: plugins written by authors of very uneven quality, custom themes nobody ever reviewed, and sites that accumulate years of dependencies. In practice, nearly every compromise I see comes through something that was added, not through the core.
Is a security plugin not enough?
A security plugin blocks known, generic attacks, which is useful. It will not detect that a plugin registers an AJAX action without a capability check, or that a custom form written by your agency allows an injection. Those flaws are specific to your installation, so they appear in no signature database.
Does the audit run against the live site?
Yes in most cases, with no service interruption. Destructive tests are excluded by default. If you have a faithful staging copy we can work there for the more intrusive tests, then confirm the sensitive points in production.
Do I need to give you an administrator account?
One account per role used on the site is recommended, including an administrator account if privilege escalation is in scope. That is what makes it possible to verify that a subscriber or a contributor cannot reach capabilities that are not theirs.
Do you test WooCommerce as well?
Yes. A WooCommerce store adds a checkout flow, discount rules, payment webhooks and customer data, which is a substantial business logic surface. It is often the most interesting part of a WordPress site to test.
The other services.
Get your WordPress audited.
Tell me how many plugins your site runs, whether it has a custom theme, and whether there is a customer area or a store. I come back with a scope and a quote. First conversation carries no commitment, full confidentiality.