An outdated plugin ran our code
Content management
A public marketing site ran on a common content platform with third-party plugins. We were asked whether the site could be used as a way onto the server behind it.
Web application penetration test, Marketing website, severity HIGH, reported 2023
At a glance
- Challenge. A third-party plugin with a published fix left unapplied ran code on the server behind an otherwise healthy marketing site.
- Approach. We inventoried the platform, its plugins and versions, matched them to known fixes, and confirmed a component acted on input it should reject.
- Result. The components were updated, an update process put in place, the web process reduced in privilege and the server segmented, then retested.
- Impact. An attacker could run code on the server behind the marketing site, a foothold inside the same network as systems that are not low risk.
- Classification. CWE-1395 Dependency on Vulnerable Third-Party Component, OWASP Top 10 (2021): A06 Vulnerable and Outdated Components. Component: Outdated CMS plugin.
The challenge
A plugin is code you did not write, running with the site's privileges, on a schedule you do not fully control. When a known flaw in a plugin has a published fix and the fix has not been applied, the gap between disclosure and patching is an open invitation that anyone reading the release notes can accept.
The site itself can look completely healthy. The pages load, the content is correct, nothing on the surface signals that a component three layers down is a known way in. The weakness is not in what the site does, it is in what it is built from and how current those parts are kept.
A marketing site is often treated as low risk because it holds little data. But the server it runs on sits inside the same network as things that are not low risk, and code execution on it is a foothold like any other.
Our approach
We identified the platform and its plugins and their versions, matched them against known fixed issues, and confirmed in a controlled way that a reachable component would act on input it should have rejected, without disrupting the live site.
Around that we checked the surface that shared the assumption:
- Whether components were on supported, patched versions
- Whether the web process ran with more privilege than it needed
- Whether the server was segmented from more sensitive systems
- Whether an update process existed to close the next gap without a test
Delivered with the component and version identified and the behaviour confirmed, so the finding could be reproduced in a staging copy without taking our word for it.
From finding to fix
- Inventoried the platform and its plugins
- Matched a plugin to a known fix
- Confirmed code ran on the server
- Updated and segmented, retested
The outcome
The vulnerable components were updated and an update process was put in place so a published fix is applied rather than noticed. The web process was reduced to the privileges it needs and the server was segmented from more sensitive systems.
We retested the site and the update process after the fix. Reported as HIGH in 2023. Retest included in the engagement.
Check your own system
- Inventory every platform component and plugin with its version and match it against known fixed issues.
- Put an update process in place so a published fix is applied rather than noticed.
- Run the web process with the least privilege it needs, so code execution gains little.
- Segment the web server from more sensitive systems so a foothold there does not spread.
Read more case studies, see Web Application Penetration Testing, or write to hello@yaamlabs.com.