"This is a lot worse than Heartbleed, Poodle and others."
There are many security vulnerabilities that have permitted full machine takeovers in an automated fashion for a long time now. Generally speaking though such attacks only work against very small fractions of the Internet, and, no matter how big Drupal may be in absolute terms, in relative terms, it is not that large. Heartbleed was so bad because it was so widespread. So many things use OpenSSL. That you could lose private keys was just icing on the cake; the arbitrary memory read was bad enough on its own, and the difficulty of detecting it also factored into its high rating. So, yes, I'd still rate Heartbleed far, far above this. Or the Ruby YAML attack.
(POODLE was by contrast well-named; annoying, yappy, ultimately not significant enough to warrant its own entry in the Great Security Vulnerability list. Enough to worry about and mitigate and it if helps bury SSLv3, hey, great, but not a thing for universal panic the way Heartbleed or Shellshock were.)
You have a good point, but I was looking at these two points:
1- Extent of the damage
2- Number of points vulnerable
Heartbleed had (has) a lot more servers vulnerable, but the impact is a lot lower and it is a lot harder to exploit to extract valuable data. In fact, I doubt you will see a compromise or a major issue because of heartbleed (despite the mass drama).
Compared to this problem with Drupal, that is used by the many of the top sites online, the overall damage can be a lot bigger.
I disagree, the type of information that was potentially leaked by services that use openssl is much more critical than the assets you can obtain by hacking servers via the Drupal vulnerability.
My reasoning is that it's obvious (at leas I hope it is!) to your system admin that the system has been compromised when he's actively looking for indicators of compromise. This is not the case with heartbleed, so yes you can steal keys if you hack the cms and you control the server for a brief while. But this is obvious, the keys are going to rescinded, the users are going to be alerted and your access to the server is going to be severed again.
In contrast the consequences of heartbleed may not be completely known even now. What if the private keys of a linux kernel dev were compromised? The attack surface was huge, and the sensitive information covers more than only cryptographic keys. There could have been all kinds of stuff in the memory of the vulnerable servers.
Drupal (in many/most setups) executes code out of its database. These machines could be told to hack internal networks and act as botnets as the result of a single POST. Definitely wormable.
There are many security vulnerabilities that have permitted full machine takeovers in an automated fashion for a long time now. Generally speaking though such attacks only work against very small fractions of the Internet, and, no matter how big Drupal may be in absolute terms, in relative terms, it is not that large. Heartbleed was so bad because it was so widespread. So many things use OpenSSL. That you could lose private keys was just icing on the cake; the arbitrary memory read was bad enough on its own, and the difficulty of detecting it also factored into its high rating. So, yes, I'd still rate Heartbleed far, far above this. Or the Ruby YAML attack.
(POODLE was by contrast well-named; annoying, yappy, ultimately not significant enough to warrant its own entry in the Great Security Vulnerability list. Enough to worry about and mitigate and it if helps bury SSLv3, hey, great, but not a thing for universal panic the way Heartbleed or Shellshock were.)