Attacking a CMS

A large share of the web runs on a handful of content-management systems, WordPress, Joomla, Drupal and friends. When recon tells you the target is one of them, you get a shortcut: instead of hunting for a brand-new bug, you check whether this well-known platform, in this configuration and version, has weaknesses that are already documented. This lesson is that workflow, and it is exactly what an exam means by "identify and exploit vulnerabilities in content-management systems."

Why a CMS is a different kind of target#

A custom app is unknown territory; a CMS is a known quantity with a public map. The core code, the admin paths, the login URL, the file layout, and crucially the known vulnerabilities are all documented, for the core and for every plugin, theme and extension. That changes the game: your first questions are not "what does this do?" but "which CMS, which version, and which add-ons, and what is already known to be broken about exactly that?"

The weak point is rarely the mature core. It is the third-party plugins, themes, and extensions, written by many hands at varying quality, often out of date, and each adding new code and new endpoints. "The site runs WordPress" is mildly interesting; "the site runs WordPress with this plugin at this old version" is often a direct route to a finding.

Step 1: identify the CMS, version, and components#

Lean on the fingerprinting lesson, then go deeper into the CMS's own tells:

• The CMS and version from paths (/wp-content/, /administrator/, /sites/default/), meta generator tags, readme files (/readme.html), and default login pages (/wp-login.php, /user/login).
• Plugins/extensions and their versions from the HTML (asset URLs include the plugin folder and often a ?ver= query), from known plugin paths, and from plugin readme files that state the version.
• Users: many CMSes leak usernames through author archives (/?author=1), APIs (/wp-json/wp/v2/users), or login error differences.

Dedicated scanners automate this: WPScan for WordPress, droopescan/JoomScan for others. They enumerate version, plugins, themes, and users, and cross-reference known vulnerabilities. Run them where authorised; understand what they check so you can verify the results.

Step 2: match versions to known vulnerabilities#

With a precise inventory, core X.Y, plugin Z at version N, search the public record:

• CVE databases and the vendor changelogs (a changelog entry "fixed a SQL injection in the search widget" tells you the prior version has one).
• Exploit archives (Exploit-DB and similar) for a working proof-of-concept.
• The CMS's own security advisories and the plugin's release notes.

A hit gives you a candidate: "this exact plugin version has a documented stored XSS / SQLi / auth bypass / file upload". It is a lead, not a guaranteed win, you still have to confirm the vulnerable code is present and reachable in this installation, and that the site has not partially mitigated it.

Step 3: confirm and exploit, carefully#

Reproduce the known issue against the target the way the advisory describes, using the gentlest confirmation. Many CMS bugs are just the vulnerability classes you already learned, delivered through a specific plugin: a plugin's search box with SQL injection, a comment field with stored XSS, an upload feature that allows a script file (the Server-side path covers upload-to-RCE), an admin action missing an authorisation check. So your skills transfer directly, the CMS context just tells you where to point them.

Two CMS-specific classics worth knowing:

• Weak/default admin credentials on the CMS login (the auth lesson), since CMS logins are a constant target.
• Outdated core or plugin with a public RCE: the highest-impact case, where a known exploit for that version yields command execution. Confirm the version precisely before claiming it.

The honesty gate, sharpened for known bugs#

Two traps are specific to CMS testing:

• Version ≠ vulnerability. A version number matching a CVE is evidence, not proof. Report "confirmed exploitable" only if you actually reproduced it; otherwise report it honestly as "running a version with a known issue, likely affected" and say what you did and did not verify.
• Duplicates. Because these bugs are public, they are heavily reported. On a bug bounty, a known-CVE-in-an-outdated-plugin finding is often already known to the program or explicitly out of scope, check the program's rules and prior disclosures before spending effort. The Engagement path covers the duplicate check in full.

And the usual rule, which matters doubly for public exploits: run them only against authorised targets, and never a destructive proof against a live system.

No lab for this one, on purpose#

There is no attached lab here, because this lesson is a method, fingerprint, match to known issues, confirm, rather than a single new bug class, and its real practice is applying the SQLi and XSS skills you already have to a platform you identified. Your exercise: on this Academy, fingerprint any lab or public site you are authorised to test, and practise the identify-and-match workflow, name the platform, find its version, and locate what is publicly known about it, without exploiting anything you are not permitted to.

You have finished the injection path#

You can now recognise the one shape all injection shares, find and exploit SQL injection three ways (UNION, boolean-blind, time-blind, past filters), land all three forms of XSS, and turn a fingerprinted CMS into targeted, known findings. Between this path and Access, you hold the two bug families that make up the bulk of real web findings. The next path, Server-side attacks and the file system, goes after the server itself: making it fetch, read, upload, and execute things it should not.