Plesk 10.4 is still supported. However, only most critical issues which impact a lot of customers are back ported from Plesk 11.0. This issue is not recognized as most critical. Sorry.
You realize this was reported long before version 11 was out correct? You have known about this bug for at least seven months, chose to ignore fixing it and now just tell people to upgrade. And that is the way it goes with quite a few issues; ignore, force upgrade, ignore, force upgrade. This is not a new thing for Parallels, I have been using Plesk for seven years, so I have plenty of experience with this process.
That is really pity. However, staying on older Plesk version is not a solution. Sooner or later you will have to go ahead and, you know, it will be much more difficult to step over several versions than moving to the next.
You should be aware of the
Technology Adoption Program.
You can come and get free assistance for adapting upcoming Plesk for your environment. We care.
So you're saying it's better to subject customers to small doses of pain frequently? Upgrading the Plesk version gets customers very angry because they don't like having to find where something got moved to or figuring out why something that used to work doesn't (example, removing domain administrators, and the replacement in Plesk 10 is either a security issue or doesn't work [we have tickets on both]).
Lately we are working with service providers who are moving hundreds servers per week from older Plesks to the latest.
You can do the same with our assistance. You just should want it. We care.
Please provide me references, either on here or private, I would like to talk to some other customers who have found a way to upgrade "hundreds of servers per week." Additionally, I'm going to guess they are not running the billing system. And on top of that, I guess they are doing the updates at times your servers haven't exceeded their daily traffic limits because we routinely upgrade a server only to get 10.4.4 installed and then find out the micro updates servers are down, leaving us with an unpatched server that we have to retry over and over waiting to get the patches.
http://forum.parallels.com/showthread.php?t=261206
Never got an official Parallels response in that thread, just a forum member telling me to pull patches from some unknown IP address.
I guess you mean
Remote vulnerability in Plesk Panel (CVE-2012-1557). You are incorrect a bit. We have fixed the issue and informed customers as soon as the issue had been discovered. Please take a look at the
8.6 MU#2,
9.5 MU#11 and
10.3 MU#6.
However, unfortunately, our customers have ignored the information and thought better of it when start getting compromised. We care.
Regarding how you "informed customers as soon as the issue had been discovered" that is a complete lie. You certainly did not notify customers as soon as the issue had been disocvered; that would imply that you sent out a notice prior to a fix being released. No, you did not. You did not send anything at all out before you knew about the issue and had created a patch; i.e. you let customers' remain vulnerable while working on a patch. And then calling what was sent a notification of a security issue would be stretching it quite a bit.
The date of the CVE you quoted is March 2012. Your own official article
http://kb.parallels.com/en/113321 is from February 2012. Your 'notification' to customers consisted of the following hidden deep within the release notes of 9.5.4 MU #11:
Parallels Plesk Panel 9.5.4 MU #11 [02-Sep-2011]
[-] SQL injection vulnerability fixed.
That's it, the above is what you sent out AFTER you had already known about the issue and released a fix. Are you telling me you feel that two lines of text buried within the release notes of a micro update is what Parallels feels is adequate notification of a remote root exploit?
The real notice came out five months later. Oh yeah, and it used some random third party service to send the emails, which likely means spam filters killed a good portion of the messages you sent; here's a thread on that:
http://forum.parallels.com/showthread.php?t=257240
You'll notice my question in July on how to test and confirm micro update application has been ignored.
I'll summarize this series of events for you. Parallels somehow came to know about a remotely exploitable vulnerability in a portion of the panel that most customers probably never use; in summer of 2011. At that point in time, you never sent an email to customers stating "Dear customer, you should immediately block access to, remove or otherwise render admin/plib/api-rpc/Agent.php inaccessible by untrusted requests because there is a SQL injection vulnerability in it that can be remotely exploited." If you had done so, users of your products could have prevented issues even before you had a patch. After not sending any notification, you created a patch. You did the absolutely bare minimum notification to cover yourselves by including two lines of text in the release notes of a micro update with no mention of whether it was remotely exploitable, what it affected, what could be accomplished by exploiting it, etc. You then let the issue sit for five months and finally put an official true notification out once your own customers began to be exploited.