WordPress penetration testing, from theme to plugins.
A WordPress security audit, or WordPress pentest, tests your site as it actually exists: the core, but above all the plugins, the custom theme, the roles and everything the years have piled on top. Our in-house tools go through every plugin, and our hands-on expertise looks for what a security plugin cannot see.
At a glance
- ScopeThe core, the plugins, the custom theme, and the WooCommerce checkout if there is one.
- What we look forCapabilities that are never checked, AJAX actions left open, a chatty REST API, uploads and forgotten files.
- What we need from youOne account for every role actually used on the site.
- What you getA report with proof and a fix for every finding, a debrief with your team and a retest within 60 days.
Vulnerabilities found across these sectors
- Public services (.gouv.fr)
- CAC 40 groups
- Luxury leaders
- National media
- Local authorities
The problem is almost never WordPress. It is what got added on top.
A plugin its author walked away from, a vulnerable custom theme, an AJAX action that forgets to check who is calling. A scanner only catches some of them.
The WordPress core is reviewed by a lot of people and patched fast. That is almost never where we find flaws, or where attackers find them.
The risk comes from what gets added: a free plugin its author stopped maintaining, a contact form that builds its query by hand, an old plugin that was deactivated but is still on the server, and still reachable at its address.
A vulnerability scan only knows flaws that have already been published. These ones are found by reading and handling the site, which is what our in-house tools and our hands-on expertise do.
Before the fix
A plain subscriber triggers the export of every account: the plugin never checks the caller's capability.
After the fix
The action checks the capability on every call: a subscriber gets turned away.
The same action, a plain subscriber. Flip the card to see the fix.
When to audit your WordPress.
A WordPress site never stops changing: every plugin added, every update, every redesign moves its attack surface.
Before going live
Before a new site, or one rebuilt by an agency, gets indexed and swept by bots.
After adding a plugin
A form, a members area or a payment module adds surface that has not been tested yet.
Before opening a store
WooCommerce brings a checkout, discounts and customer data: real business logic to test.
Once a year
Your plugins change versions, sometimes owners, and you do not always know what comes with them.
After a hack or an alert
Cleaning up is not enough: you need to know which plugin let them in, and close that door.
What we test.
Six families of WordPress flaws we look for on every audit, and where each one hides on your site.
Plugins
Known vulnerable versions, and also the flaws specific to your configuration and your combination of plugins.
Custom theme
Queries built by hand, unescaped output, PHP files that can be called directly.
Roles, capabilities and AJAX
What a subscriber, contributor or author can really reach, and the AJAX actions that forget to check their capability or The one-time token WordPress attaches to an action to prove it really comes from your site..
REST API and XML-RPC
Routes exposed by default or by plugins, user enumeration, unchecked writes.
Files and media
File types accepted on upload, possible execution, backups, debug logs and Git repositories left online.
WooCommerce
Checkout, discount rules, payment The call your payment provider sends your site to confirm an order: if nobody checks it, it can be faked. and access to customer data, when the store is in place.
How a WordPress audit runs.
Six steps, from scoping to retest, built for everything added on top of the core.
Read the full methodology- 01
Scoping
We agree on the scope with you: the site, the roles in use, what was built for you and what is excluded. NDA as soon as we get into technical details, penetration test authorization agreement once the quote is signed, before any access.
- 02
Inventory
Every plugin and its version, the theme, the exposed entry points, and anything lying around on the server without being referenced anywhere. This step alone regularly turns up surprises: an old staging site still online, a downloadable backup, a deactivated plugin that can still be reached.
- 03
Role testing
We log in with every role and try to reach what is not meant for it: admin actions, other authors' content, site settings, restricted AJAX actions. Privilege escalation in WordPress most often comes from a capability a plugin forgot to check.
- 04
Custom code review
The code written for you gets the closest attention, because no public vulnerability database covers it: forms, queries, display of user input, file handling.
- 05
Report and debrief
A report ranked by real severity, with a reproducible proof of concept and a concrete fix for every flaw, written for whoever maintains your site. Then a debrief with your team. See a sample report.
- 06
Retest & close
Once the fixes are in place, we replay every flaw. An updated plugin does not always fix the problem: the retest, included, makes sure.
Black, grey or white box.
What you give us up front determines how far the audit can reach. On WordPress, our advice: one account for every role actually in use.
Black box: just the URL
- You provide
- The site's address. No accounts, no access to the files.
- The test reaches
- What a visitor can reach: exposed plugins and versions, the REST API, xmlrpc.php, forgotten files. The login stops the rest, unless a flaw gets us past it.
- Choose it when
- You want to know what a bot or a stranger finds on your site from the internet.
Grey box: one account per role Our advice
- You provide
- An account for every role actually in use: subscriber, customer, author, editor, and an administrator if privilege escalation is in scope.
- The test reaches
- Everything each role reaches, and above all what it should not: AJAX actions, settings, other people's content.
- Choose it when
- In almost every case: this is how privilege escalation gets found.
White box: the accounts and the code
- You provide
- The accounts, plus read access to the theme and plugins built for you.
- The test reaches
- Everything above, plus the logic written in your custom code, which no scanner covers.
- Choose it when
- When a good share of the site's features was custom built.
What this looks like in practice.
Real flaws found on WordPress sites, all fixed since.
reports sent with a critical vulnerability
Out of more than 485 reports sent, in penetration tests and bug bounty.
reports sent in total
In penetration tests and bug bounty.
Active in bug bounty
Researchers on YesWeHack and Intigriti, two European bug bounty platforms where every flaw is checked before it is accepted.
- CriticalFixed
Privilege escalation
A plugin's AJAX action registered without any capability check, reachable by a plain subscriber.
- CriticalFixed
SQL injection
A custom theme's search filter building its query by concatenation.
- CriticalFixed
File exposure
A full database backup left downloadable at a guessable address.
- HighFixed
Stored XSS
A plugin form field displayed without escaping in the admin interface.
We never disclose a client's name, nor any detail that would let anyone recognize them.
The report you receive.
Every flaw proven, explained and tied to the plugin or file behind it: readable for your leadership, applicable for your team or your provider.
An action reserved for administrators, which a plain subscriber could trigger: that is, anyone able to create an account on the site.
SeverityCritical, from a subscriber account
Requests, screenshots and reproduction steps: redacted in this sample. Your report contains every one of them, ready to replay.
Check the caller's capability and the nonce in every registered AJAX action, and deny by default.
PriorityImmediate, retest included
The theme's search filter built its query by concatenation: the site's database, readable from a simple search box.
SeverityCritical, one search box
Requests, screenshots and reproduction steps: redacted in this sample. Your report contains every one of them, ready to replay.
Run every query in the theme through WordPress prepared statements, and never concatenate user input.
PriorityImmediate, retest included
A full database backup, downloadable at a guessable address: accounts, content and customer data in a single file.
SeverityCritical, one guessed address
Requests, screenshots and reproduction steps: redacted in this sample. Your report contains every one of them, ready to replay.
Move backups out of the public directory, store them off the site and block archive downloads.
PriorityImmediate, retest included
Prioritized report
Every flaw on the site ranked by real severity: what an attacker would actually get, not a theoretical score.
Reproducible proof of concept
The exact requests, which your team or your provider replays on a copy of the site to see the flaw for itself.
Business impact
Which accounts, which data, which orders are exposed, spelled out plainly for your leadership.
Precise fixes
The update, setting or code change expected, written for whoever maintains your site.
Retest included
Once the fixes are in place, every flaw is replayed: it is closed only when the proof no longer works.
Debrief with your team
A session with you and your technical team to walk through the findings and prioritize the fixes.
What it costs.
Every engagement is quoted, and here is why: two WordPress sites that look alike can hide very different amounts of code. To get your bearings, here is our pricing by kind of engagement.
From€2,700 incl. tax
Brochure site or store
Four to six days. A WordPress site, its plugins, its forms and, if there is one, its WooCommerce store.
From€7,500 incl. tax
Business application or SaaS
Ten to fifteen days or more. A WordPress that has grown into a platform: members areas, several roles, custom development.
From€3,200 incl. tax
Focused API
Four to eight days. The REST API of a WordPress that powers an app or a headless front end.
What moves the price
First, the amount of custom code: a site assembled from plugins in the official directory and an off-the-shelf theme takes far less time than one where half the features were custom built.
Then the number of plugins, and above all what they do: the ones that add forms, members areas, permissions or payments count far more than a caching plugin. Finally, whether there is WooCommerce or a customer area, which adds a whole layer of business logic.
The first call, with no commitment, is there to work out which case you are in. If your site needs less than you thought, we will tell you.
25capability checks
Should be grantedShould be refused
Every square is a check. Does this role have this capability, and does every plugin really check it?
Is WordPress an insecure CMS?
The WordPress core is audited constantly and patched fast. The risk comes from the ecosystem: plugins written by authors of very uneven skill, vulnerable custom themes, and sites that pile up years of dependencies. In practice, almost every compromise we see comes through something added, not through the core.
Isn't a security plugin enough?
A security plugin blocks known, generic attacks, which is useful. It will not notice that a plugin exposes an AJAX action without a capability check, or that a custom-built form allows an injection. Those flaws are often specific to your installation, so they are missing from signature databases.
Do you audit the live site?
Yes in most cases, with no downtime. Destructive tests are excluded by default. If you have a faithful staging copy, we can run the most intrusive tests there, then confirm the sensitive points in production.
Do you need an administrator account?
One account for every role used on the site is recommended, including an administrator if privilege escalation is in scope. That is how we check that a subscriber or a contributor cannot reach capabilities that are not theirs.
Do you test WooCommerce too?
Yes. A WooCommerce store adds a checkout, discount rules, payment webhooks and customer data, so a sizable amount of business logic. It is often the most interesting part to test on a WordPress site.
The other services.
Is your WordPress only part of what you expose? Another engagement can round it out.
Website security audit
Brochure site, online store or CMS: the security of what your visitors see, hosting included.
See the serviceWeb penetration testing
For an application that does not run on WordPress, or to go further than the CMS: user flows, roles and business logic.
See the serviceAPI security audit
If your WordPress is the back office of an app or a headless front end, its API deserves an audit of its own.
See the serviceAuthentication and access control
Login, sessions, SSO and roles: who can get in, and how far.
See the serviceGet your WordPress audited.
Your WordPress site is a target.
Tell us how many plugins your site has, whether it has a custom theme, and whether there is a customer area or a store. We'll get back to you with a scoping proposal and a quote. The first call commits you to nothing.