The stack we audited
A small-business WordPress site came in for a security audit, and the findings were the ordinary kind that quietly put a site one automated scan away from compromise. The page builder, Elementor, was pinned at version 3.11.1, carrying four critical CVEs including SQL injection and stored cross-site scripting. Contact Form 7 was running 5.8, exposed to CVE-2023-6449, an arbitrary file upload. Nothing exotic, just outdated plugins, which is the dominant way WordPress sites get breached.
The uncomfortable part is how normal this is. The site worked. It looked fine. The owner had no reason to suspect anything, because outdated plugins do not show symptoms until they are exploited. The audit existed to find the gap before someone else did.
Outdated plugins are the attack surface
A plugin is safe while it is patched. The moment a vulnerability is published as a CVE and you have not updated, the exploit is public knowledge and your installed version is a named target for automated scanners. Attacks on WordPress are overwhelmingly blind and automated, bots sweep for known-vulnerable versions of popular plugins, so running an old Elementor or Contact Form 7 is not an abstract risk. It is an advertised one.
On this site:
- Elementor 3.11.1 carried four critical CVEs (SQL injection and stored cross-site scripting among them), while the patched line had already moved to 3.17.3. Every one of those four was live.
- Contact Form 7 5.8 was exposed to CVE-2023-6449, a drag-and-drop file-upload flaw that let an authenticated user with editor rights upload arbitrary files, a direct path toward remote code execution.
Neither plugin was unusual. Both are on a huge share of WordPress sites. That is exactly why their known vulnerabilities are worth a scanner’s time.
What the audit checks
A security audit is methodical rather than clever. The core of it:
- Inventory every installed plugin and theme, and cross-check each version against its known CVEs and minimum-safe version. This is what surfaced the Elementor and Contact Form 7 exposure here.
- Test custom and theme code for the WordPress security basics: nonce and capability checks on actions, input sanitised before it reaches the database, output escaped before it reaches the page, and endpoints that require authorisation.
- Check server-level exposure: an open
xmlrpc.php, PHP errors displayed on production leaking paths, missing security headers. - Review the update and backup posture, because an unmaintained site drifts back into this state within months.
The version cross-check is the unglamorous part that catches the most, because the most common WordPress vulnerability is not a clever zero-day. It is a popular plugin three versions behind its patch.
Where AI-assisted builds make it worse
This audit was about outdated third-party plugins, the neglect pattern. AI-assisted builds add a second layer on top. They install plugins fast, often without setting up any update routine, so versions drift behind their patches even faster. And AI-generated custom code frequently omits the nonce, capability, and sanitisation checks WordPress expects, so you inherit both an outdated-plugin problem and a generated-code problem at once. That is why this kind of audit is part of our broader AI-built website rescue work, and why a standalone WordPress security audit starts with the boring version cross-check before anything else.
What fixing it looks like
The remediation order is risk-first, not convenience-first:
- Patch or remove the plugins with live CVEs immediately, starting with the file-upload and injection paths, because those are the highest-severity.
- Remove plugins that are abandoned or no longer needed, shrinking the surface permanently.
- Close server-level exposure (
xmlrpc.php, production error display, missing headers). - Put a real update and backup routine in place, so the site does not drift back to four-live-CVEs within a year.
Glossary
- CVE - a Common Vulnerabilities and Exposures identifier, a public catalogue entry for a specific known vulnerability.
- SQL injection - an attack that smuggles database commands through unsanitised input.
- Stored cross-site scripting - malicious script saved on the site and served to other users.
- Nonce / capability check - WordPress mechanisms that confirm a request is intentional and the user is allowed to make it.
The takeaway
A WordPress site does not have to be interesting to be attacked. It has to be running a known-vulnerable version of a popular plugin, which describes a large share of sites that have not been audited. The good news is that the dominant risk is also the most boring to fix: cross-check every plugin version against its CVEs, patch or remove the offenders, and put a maintenance routine in place so the gap does not reopen. The site in this audit was one scan away from trouble and did not know it. Most sites in that position do not.
