Drupal Issues Highly Critical Patch: Over 1M Sites Vulnerable

Drupal developers are urged to patch a bug that allows attackers to take over a site simply by visiting it.

Drupal released a patch for a “highly critical” flaw in versions 6, 7 and 8 of its CMS platform that could allow an attacker to take control of an affected site simply by visiting it. Drupal also warned an unprivileged and untrusted attacker could modify or delete data hosted on affected CMS platforms.

The Drupal developers alert (SA-CORE-2018-002) estimates over one million sites running Drupal are impacted. Affected are Drupal CMS versions before 7.58, 8.x before 8.3.9, 8.4.x before 8.4.6, and 8.5.x before 8.5.1. Also impacted is Drupal 6 and 8.3.x and 8.4.x releases, said Drupal.

“This potentially allows attackers to exploit multiple attack vectors on a Drupal site, which could result in the site being completely compromised,” warned the MIRTE Common Vulnerabilities and Exposures description (CVE-2018-7600). There is no known public exploit code in the wild and no reports of the vulnerability being exploited.

The flaw is described as “an input validation issue where invalid query parameters could be passed into Drupal webpages,” said Tim Mackey, technology evangelist at Black Duck by Synopsys.

Meanwhile, several Drupal specific hosting providers, such as Pantheon, Acquia, Platform.sh and Amazee.io, are offering platform-level solutions tied to the Web Application Firewall (WAF) layer or the way they are hosting the sites. Also, at least two security oriented content delivery network services, CloudFlare and Fastly, have also rolled-out solutions to help protect customers.

“The only effective mitigation we are advising is to upgrade or second best is to put a rule into a WAF,” said Greg Knaddison, a Drupal security team member and product engineer and Card.com.

Knaddison said it’s not exactly clear what portion of Drupal sites are vulnerable because it depends on what features are enabled or not. He said, Drupal is not releasing any of the technical aspects of the vulnerability other than the patch acts as an input filter on web page requests.

Mackey described the vulnerability as a flaw that allows unsanitized data to enter the Drupal data space. “Under such circumstances a malicious user could cause Drupal to return data which the page authors never intended to be presented on the given page. Since the vulnerability is present within the bootstrap process, the best mitigation model is to convert the Drupal site to a pure HTML site. Administrative and maintenance pages are similarly impacted due to the issue being present in the bootstrap process,” he said.

Knaddison said the vulnerability has to do with the way Drupal interprets a value that begins with a hash as having a special meaning. “Generally, input filtering like this a blunt solution to the problem and not fixing the specific vulnerable code. But it gets rid of all kinds of input that might be a problem for code later in the code base,” he said.

Knaddison said there are a number of strong indicators that Drupal users are getting a jump on¬†patching. He estimates “hundreds of thousands” of sites immediately patched within the first 12 hours the patches were released. ¬†“I think that with this release, we will see a very fast update rate because it just seems like everybody was really prepared to update within hours of the release,” he said. Last week, Drupal forewarned of Wednesday’s release of a highly critical patch.

According to an analysis of Drupal sites by the firm SiteLock, only 18 percent of Drupal websites were found to be running the latest core updates. “This means that the vast majority of websites running Drupal are likely vulnerable to compromise because they are not being updated with the latest security patches,” according to the company.

Suggested articles

Discussion

  • Chris on

    1 million is probably an understatement
  • Drupalx on

    Drupal 7 Site Crashes Many Times I've had a site running on: Drupal 7.59 Database system MySQL, 5.7.22-0 ubuntu 16.04.1 PHP 7.0.30 PHP memory limit 128M It has crashed many times due to the running out of memory problem. Besides, this problem started a month ago. Another problem is in the cache database table (cache_menu), keeps growing bigger every time a when pages are loaded. Even if I change the "Expiration of cached pages" from the performance menu to 1 hour, the cache can become huge, which leads to major memory problems. Is there a way to safely disable cache_menu? But I'm not sure that the only reason is the cache menu. What could be causing this and how can I fix it? Any advice much appreciated.

Leave A Comment

 

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.