Updated October 2026: This post has been expanded from its original 2013 version with a full account of the June 2013 Plesk "phppath" vulnerability, how hosts were affected, the fixes, what happened next, and server-maintenance lessons that still apply. It is a historical account; details describe the time it covers, not today.
In early June 2013, a researcher published attack code targeting Parallels Plesk Panel, one of the most widely used control panels for running shared web hosting. The flaw could let an outsider run commands on a vulnerable server without logging in. Press coverage at the time said the affected configuration was used by more than 360,000 websites, and the title of this post, first published here in 2013, repeated that figure (with the original typo in "critical" now corrected).
The underlying problem was not exotic. It traced back to a single line of web server configuration that had shipped as a default in older Plesk releases, combined with a known weakness in how PHP behaves in one particular setup. This post explains what the flaw was in general terms, which versions were affected, how hosts responded, and why the same pattern kept returning for years afterward.
What Plesk is, and why a bug in it mattered
Plesk is a hosting control panel. Hosting companies and server owners install it so they can manage websites, email accounts, databases and domains through a web interface instead of the command line. It was first developed in Novosibirsk, Russia, around 1999 and 2000. SWsoft bought it in 2003, and SWsoft renamed itself Parallels in 2008, which is why the product was called Parallels Plesk Panel in 2013.
A control panel holds a lot of power on a server. It writes the web server configuration, often for Apache, for every site on the machine. If the panel ships an unsafe default, every server installed with that default inherits the same weakness at the same moment. That is what made this bug serious: the problem was not something each site owner had done wrong, but a setting that came with the software.
What went wrong
The exploit was posted on June 5, 2013, to the Full Disclosure mailing list by a long-time exploit writer known as Kingcope. According to his write-up, older Plesk configurations included an Apache directive that mapped a web path called /phppath/ to the system location of the PHP program. The practical effect was that an ordinary web request could reach the PHP interpreter itself, rather than only the PHP scripts that make up a website. That was never supposed to be exposed to the public internet.
This connected to an older, separately tracked issue in PHP. In May 2012 the PHP project had disclosed CVE-2012-1823: in certain configurations where PHP runs as a CGI program, a crafted request could be misinterpreted so that parts of it were treated as settings for the interpreter. PHP's advisory at the time said the underlying behavior had gone unnoticed for at least eight years, and the project shipped fixes in versions 5.3.12 and 5.4.2, followed by a more complete fix in 5.3.13 and 5.4.3.
On a Plesk server with the exposed /phppath/ mapping and a PHP version that still had the 2012 weakness, those two problems reinforced each other. An attacker could reach the interpreter directly and influence how it ran, without needing any vulnerable PHP file to already exist on the site. CERT/CC's vulnerability note, published June 7, 2013, described the issue as a combination of CVE-2012-1823 and the Plesk phppath script alias, and said exploitation had already been seen in the wild. A remote, unauthenticated attacker could end up running code with the privileges of the web server account.
Two CVE numbers for one incident
The Plesk configuration flaw itself later received its own identifier, CVE-2013-4878, published in July 2013. That entry points to the default script-alias setup in Plesk 9.0.x and 9.2.x on Unix, and in Parallels Small Business Panel 10.x, as the root cause, and explicitly notes that it is a separate issue from the 2012 PHP bug. So two CVE numbers describe the same real-world incident from two angles: the PHP interpreter behavior (CVE-2012-1823) and the Plesk default that exposed it (CVE-2013-4878).
Which versions were affected
Sources at the time gave slightly different version lists, partly because the researcher tested more releases than the vendor formally listed. The table summarizes what each source said.
| Source | Versions named as affected | Notes |
|---|---|---|
| Kingcope exploit (Exploit-DB 25986, June 5, 2013) | Plesk 8.6, 9.0, 9.2, 9.3 and 9.5.4 | Tested on Red Hat, CentOS and Fedora Linux, 32- and 64-bit; Plesk 11.0.9 reported not affected; Windows untested |
| Press report (June 6, 2013) | Default 8.6, 9.0, 9.2, 9.3 and 9.5.4 | Linux and FreeBSD; Windows and other Unix systems not tested |
| CERT/CC VU#673343 (June 7, 2013) | Plesk Panel 9.0 through 9.2.3 | Linux; those versions already end-of-life, upgrade to at least 9.5.4 advised |
| CVE-2013-4878 (July 2013) | Plesk 9.0.x and 9.2.x on Unix; Small Business Panel 10.x on Unix | Rated 7.5 under CVSS v2; 9.8 critical when rescored under CVSS v3.1 |
Sources: Exploit-DB, Hack in the Box News (reprinting the original press report), CERT/CC, Tenable CVE database.
The common thread was age. Plesk 11 was the current product line in mid-2013, and CERT/CC noted that the 9.0 to 9.2.3 releases were already past end-of-life. The servers at risk were ones set up years earlier and never fully upgraded, which on shared hosting is not unusual.
Where the 360,000 figure came from
The 360,000 number came from the original June 6, 2013 news report, which said the vulnerable configuration was used by more than 360,000 websites. We could not find a published methodology for that count, so it is best read as a rough estimate of exposure rather than a verified tally of compromised sites. What is documented is that attacks were already happening: CERT/CC reported exploitation in the wild within days, and the SANS Internet Storm Center kept tracking exploit attempts weeks later.
How hosts were told to respond
Because the exploit went public before a tidy vendor statement, the first advice came from the researcher and the security community. Kingcope's own note suggested removing or commenting out the offending Apache directive and restarting the web server. Parallels published guidance in a knowledge base article (number 116241), which community members circulated on the official Plesk forum on June 7, 2013. The consistent recommendations were:
- Update PHP to a version that fixed CVE-2012-1823, removing the interpreter behavior the attack relied on.
- Upgrade Plesk off the end-of-life 9.x line. Advisories pointed to at least 9.5.4 as a minimum and newer releases as the real fix, since current versions did not ship the exposed mapping.
- Remove the exposed mapping for sites that could not upgrade immediately, following Parallels' patch or script.
- Restrict access so untrusted networks could not reach the control panel at all.
- Add a filter rule. SANS noted the malicious requests often arrived with no User-Agent header, which made them relatively easy to block with web server rules.
Notably, several forum users reported that the vulnerable directive was not present in their configurations, and Parallels representatives did not immediately comment publicly, which left admins comparing notes with each other in the first days.
- May 2012
PHP discloses CVE-2012-1823 and ships fixes in 5.3.12 / 5.4.2, then 5.3.13 / 5.4.3. - June 5, 2013
Kingcope posts the Plesk exploit to Full Disclosure (Exploit-DB 25986). - June 6, 2013
News report says more than 360,000 websites use the affected configuration. - June 7, 2013
CERT/CC publishes VU#673343; Parallels KB 116241 circulates on the Plesk forum. - July 18, 2013
CVE-2013-4878 is published for the Plesk default ScriptAlias. - July 30, 2013
SANS Internet Storm Center reports continuing exploit attempts.
What happened next
The immediate wave passed as hosts patched PHP, upgraded off the old Plesk releases, and filtered the tell-tale requests. Plesk itself kept evolving. In 2015, Parallels reorganized: the service-provider business was renamed Odin, and Plesk was separated out as a standalone company. Today Plesk is owned by the WebPros group, and the current release line is Plesk Obsidian, first released in June 2019. Measurement firm W3Techs has continued to rank Plesk among the most common hosting control panels for sites that use one.
The deeper story is that the PHP-CGI weakness behind the 2013 incident did not stay buried. In June 2024, researchers at DEVCORE disclosed CVE-2024-4577, which the PHP project and security vendors described as a bypass of the same 2012 fix, mainly affecting PHP running in CGI mode on Windows in certain configurations. It was rated 9.8, critical, and patched in PHP 8.1.29, 8.2.20 and 8.3.8. In other words, a class of bug first fixed in 2012, weaponized against Plesk in 2013, returned in a new form eleven years later. The specifics change; the lesson about CGI-mode PHP and exposed interpreters does not.
Lessons that still apply to anyone running a server
You do not need to run Plesk, or run an old version of anything, to take something useful from this episode.
- Upgrades are security work, not just features. The servers hit in 2013 were mostly running software that was already past end-of-life. Retire versions that no longer receive security updates.
- Know your defaults. The flaw lived in a setting that shipped with the product. When you install any platform, review what it exposes rather than assuming the defaults are safe.
- Keep the interpreter and the application layer patched together. This incident needed both a Plesk default and an unpatched PHP to work. Patching one layer limited the damage even if the other lagged.
- Do not expose management interfaces to the whole internet. A control panel or admin tool reachable only from trusted networks is a far smaller target.
- Watch for exploitation, not just advisories. Attacks here began before the vendor spoke. Logs and intrusion rules caught activity that a wait-for-the-patch approach would have missed.
The bottom line
The 2013 Plesk vulnerability was a textbook example of how a convenient default and an old, unpatched component can combine into a serious, internet-wide exposure. The fix was not complicated once it was understood: patch PHP, upgrade Plesk, remove the exposed mapping, and keep the panel off the open internet. The harder lesson is the one the 2024 follow-up drove home. Old classes of vulnerability come back, so keeping software current and knowing what your server exposes are never one-time tasks.
Sources
- CERT/CC Vulnerability Note VU#673343
- Hack in the Box News: More than 360,000 Apache websites imperiled by critical Plesk vulnerability
- Exploit-DB 25986: Plesk < 9.5.4 remote command execution (Kingcope)
- Tenable: CVE-2013-4878
- Red Hat: CVE-2012-1823
- php.net news archive, 2012 (CGI query string releases)
- SANS Internet Storm Center: exploit attempts against the Plesk phppath vulnerability
- HKCERT: Parallels Plesk Panel arbitrary PHP code execution vulnerability
- Plesk forum: critical Plesk vulnerability thread
- Wikipedia: Plesk
- Tenable: CVE-2024-4577 proof of concept
Top image: "Half filled server racks" by Alexis Lê-Quôc from New York, United States, CC BY-SA 2.0, via Wikimedia Commons (resized). Charts by Thank You Robot.
0 Comments