Drupal powers a large share of the world's government, university, and enterprise websites, so when the Drupal security team pre-announces a "highly critical" release a week in advance and tells administrators to clear their calendars, the internet pays attention. That is exactly what happened with CVE-2018-7600, the flaw the community nicknamed Drupalgeddon2. It is an unauthenticated remote code execution vulnerability in Drupal core, and the NVD rates it CVSS 3.1 9.8 (Critical). A single unauthenticated HTTP request could result in complete compromise of the Drupal installation and, frequently, the server hosting it.
Timeline and impact
On March 28, 2018, the Drupal security team published advisory SA-CORE-2018-002 along with patched releases. They had warned days earlier that a highly critical fix was coming, which gave defenders a narrow head start, but attackers moved fast. Within roughly two weeks, public proof-of-concept exploits appeared and mass exploitation began.
The scale was enormous. Compromised Drupal sites were conscripted into cryptomining operations (dropping Monero miners), enrolled in botnets such as Muhstik, and used as staging infrastructure for further attacks. Because Drupal underpins so many high-value public-sector and education sites, the blast radius was wide. A follow-up flaw, CVE-2018-7602 ("Drupalgeddon3"), was disclosed the following month in the same general area, reinforcing that this was a systemic design problem rather than a one-off mistake.
Root cause
Drupal renders pages using nested associative arrays called renderable arrays. Within those arrays, specially named keys prefixed with a hash character carry rendering metadata, for example properties that name a callback function and the arguments to pass it, so that Drupal can defer or transform how a piece of content is rendered. These properties are powerful by design: they let the rendering system invoke callable functions.
The vulnerability was that user-supplied input reaching certain form and AJAX code paths was not stripped of these special properties before it entered the render pipeline. An attacker could smuggle a renderable-array property, naming a PHP callable and its arguments, into a request parameter. When Drupal rendered the resulting structure, it dutifully invoked the attacker-chosen function with attacker-chosen arguments, turning a form submission into arbitrary command execution. The fix introduced a sanitization layer (the RequestSanitizer) that strips the dangerous hash-prefixed keys from incoming request data before it is processed.
The following is a conceptual sketch of the vulnerable pattern, not a working exploit:
POST to an AJAX-enabled form endpoint with a crafted parameter such as:
<field>[#post_render][]=<php_callable>
<field>[#type]=markup
<field>[#markup]=<attacker_supplied_argument>
The unsanitized render array then invokes the named callable.
Which versions were affected
CVE-2018-7600 affected Drupal 7.x before 7.58, Drupal 8.3.x before 8.3.9, Drupal 8.4.x before 8.4.6, and Drupal 8.5.x before 8.5.1. Because the flaw sat in core's Form API rather than a contributed module, essentially every default Drupal deployment on those branches was exposed regardless of which modules were enabled.
Detection
- Determine your exact Drupal core version and compare it against the patched releases below. This is the single most reliable check.
- Review web server access logs for suspicious POST requests to AJAX form endpoints (paths under user registration and other forms), particularly parameters containing hash-prefixed keys.
- Look for indicators of post-exploitation: unexpected PHP files in the webroot, unfamiliar cron entries or scheduled tasks, outbound connections to mining pools, and unexplained CPU load.
- Run a composition scan that identifies Drupal core and contributed modules by version so vulnerable installs are flagged automatically rather than found by hand.
Remediation and patched versions
Upgrade Drupal core to a fixed release: 7.58, 8.3.9, 8.4.6, or 8.5.1 (or any later version on a supported branch). If you could not patch immediately when the advisory dropped, Drupal also published standalone patches that could be applied to core.
Two cautions matter here. First, given how quickly exploitation began, any site that was internet-facing and unpatched for more than a few days after March 28, 2018 should be treated as potentially compromised and investigated, not just patched. Patching closes the door but does not evict an attacker who already walked through it. Second, Drupal 7 reached end of life, so sites still on the 7.x branch should plan a migration to a supported major version rather than relying on legacy patches.
How Safeguard helps
Drupalgeddon2 is a textbook software composition problem: a critical vulnerability in a widely deployed open-source component, exploitable the moment your version falls below the fixed release. Safeguard's software composition analysis resolves the PHP and Composer dependencies in your projects, including the CMS core and its modules, and raises a finding the instant a component drops below its patched version, with KEV and exploit intelligence used to push actively exploited flaws to the top of the queue. When a safe release exists, autonomous auto-fix opens a tested pull request that bumps the vulnerable component so the upgrade is a review-and-merge rather than a fire drill. Developers can run the same analysis before code ever lands using the Safeguard CLI, and policy gates can block a deploy that ships a known-vulnerable core version. If you are comparing options, the Safeguard vs Snyk comparison covers how the two approaches differ.
A CVSS 9.8 core CMS flaw should be caught by tooling, not by an incident. Get started free or read the documentation.
Frequently Asked Questions
What made Drupalgeddon2 so severe?
It combined three of the worst properties a vulnerability can have: unauthenticated (no login required), remote (exploitable over the network), and reliably leading to full remote code execution, all through a single crafted HTTP request against default Drupal installations. Because it lived in Drupal core's Form API rather than an optional module, nearly every site on the affected branches was exposed, which is why it earned a CVSS score of 9.8.
Which Drupal versions fix CVE-2018-7600?
Upgrade to Drupal 7.58, 8.3.9, 8.4.6, or 8.5.1, or any later release on a supported branch. These versions added a request-sanitization layer that strips the dangerous hash-prefixed render-array keys from incoming request data before it is processed, closing the code path the exploit relied on.
Should I assume my site was compromised if it was unpatched?
If your Drupal site was internet-facing and remained unpatched for more than a few days after the March 28, 2018 disclosure, you should treat it as potentially compromised and investigate, not simply patch. Exploitation began within about two weeks and was heavily automated. Look for web shells, unexpected cron jobs, cryptominers, and unfamiliar outbound connections, then rebuild if you find evidence of intrusion.
What is the difference between Drupalgeddon and Drupalgeddon2?
The original Drupalgeddon (CVE-2014-3704) was a 2014 SQL injection flaw in Drupal 7's database abstraction layer. Drupalgeddon2 (CVE-2018-7600) is the unrelated 2018 Form API remote code execution flaw described here. A third issue, CVE-2018-7602 or Drupalgeddon3, followed a month later in the same rendering area. The shared naming reflects that each was a critical, widely exploited flaw in Drupal core.