The expandArguments function in the database abstraction API in Drupal core 7

CVE-2014-3704 is the original Drupageddon bug in Drupal core 7.x. The flaw sits in the expandArguments path of Drupal's database abstraction layer and affects Drupal 7.0 through 7.31; upstream fixed it in 7.32, while distros such as Debian backported fixes into their own package versions. Because the injection is reachable through normal web requests and can be hit by anonymous users, the attacker does not need credentials, prior foothold, or social engineering.

The vendor-ish HIGH label from GHSA understates operational reality. This is not a finicky post-auth SQLi buried in an admin panel; it is a pre-auth internet-facing compromise primitive with well-documented public PoCs, automated exploitation within hours of disclosure, and practical routes to admin creation, arbitrary PHP execution, persistence, and full site takeover.

Why this verdict

• Vendor baseline was too low: GHSA says HIGH, but the actual attack starts from unauthenticated remote access on a web-facing CMS and does not require user interaction or prior foothold.
• Exploit friction is minimal: the prerequisite is basically 'public Drupal 7.0-7.31 site.' There is no MFA gate, no internal-network requirement, no authenticated role requirement, and no chaining with another bug.
• Weaponization was immediate and durable: Drupal's own PSA says attacks started within hours, while public PoCs and the Metasploit module made repeatable mass exploitation realistic.
• Blast radius exceeds database theft: public exploit paths create admins, alter modules/config, and reach arbitrary PHP execution, which turns a web app bug into a server-compromise problem.
• Exposure was historically massive and remains non-zero: Drupal had a huge install base at disclosure, and official usage data still shows a stubborn tail of ancient 7.x deployments.

Why not higher?

It is not a perfect 10.0 only because the vulnerable population in 2026 is much smaller than it was in 2014, and some modern estates have already isolated or retired legacy Drupal. Also, not every SQLi hit will cleanly produce code execution if the site is unusually hardened or fronted by aggressive request filtering.

Why not lower?

This is not a post-auth edge case or a low-reliability parser bug. The chain is pre-auth, remote, internet-facing, publicly weaponized, and historically mass-exploited, which is exactly the pattern that should stay at the top of a patch queue whenever vulnerable assets still exist.

1. Block public reachability — Put vulnerable Drupal 7 sites behind VPN, IP allowlists, maintenance pages, or temporary reverse-proxy ACLs immediately, within hours. For this CVE, removing anonymous internet access is the single most effective compensating control because the exploit chain begins with public HTTP requests.
2. Deploy a request-filtering rule — Add WAF or reverse-proxy rules that reject suspicious array-key parameter patterns and known Drupageddon request shapes immediately, within hours. This is not as trustworthy as fixing code, but it is valuable if change control delays the patch or if you need time to rebuild safely.
3. Assume compromise and hunt — For any site that was exposed while vulnerable, review for rogue admin users, PHP-enabled content paths, modified modules, file drops, cron persistence, and unexplained DB changes immediately, within hours. Drupal's own follow-up guidance is blunt: patching later does not evict backdoors already planted.
4. Segregate shared hosting risk — If the Drupal host shares credentials, databases, or filesystem access with other apps, isolate it from peers immediately, within hours. This limits the common real-world failure mode where a web compromise becomes a multi-app or same-host incident.

Run this on the target Drupal host as a local auditor or through your config-management agent. Invoke it with the Drupal web root, for example: sudo bash verify-cve-2014-3704.sh /var/www/html ; root is not strictly required for a readable web root, but package checks on Debian-based systems work best with normal local shell access.

#!/usr/bin/env bash
# verify-cve-2014-3704.sh
# Determine whether a local Drupal installation appears vulnerable to CVE-2014-3704.
# Outputs exactly one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

TARGET_ROOT="${1:-}"

ver_lt() {
  [ "$(printf '%s
%s
' "$1" "$2" | sort -V | head -n1)" != "$2" ]
}

ver_ge() {
  [ "$(printf '%s
%s
' "$1" "$2" | sort -V | head -n1)" = "$2" ]
}

print_result() {
  local status="$1"
  case "$status" in
    PATCHED) echo "PATCHED"; exit 0 ;;
    VULNERABLE) echo "VULNERABLE"; exit 1 ;;
    *) echo "UNKNOWN"; exit 2 ;;
  esac
}

# 1) Debian package backport check, if applicable.
if command -v dpkg-query >/dev/null 2>&1; then
  if dpkg-query -W -f='${Status} ${Version}\n' drupal7 2>/dev/null | grep -q '^install ok installed '; then
    PKG_VER="$(dpkg-query -W -f='${Version}' drupal7 2>/dev/null)"
    # Debian tracker fixed wheezy in 7.14-2+deb7u7 and unstable in 7.32-1.
    if dpkg --compare-versions "$PKG_VER" ge '7.14-2+deb7u7'; then
      print_result PATCHED
    else
      print_result VULNERABLE
    fi
  fi
fi

# 2) Try to locate Drupal root if not provided.
if [ -z "$TARGET_ROOT" ]; then
  for d in /var/www/html /var/www/drupal /usr/share/drupal7 /srv/www /opt/drupal; do
    if [ -f "$d/CHANGELOG.txt" ] || [ -f "$d/includes/bootstrap.inc" ]; then
      TARGET_ROOT="$d"
      break
    fi
  done
fi

if [ -z "$TARGET_ROOT" ] || [ ! -d "$TARGET_ROOT" ]; then
  print_result UNKNOWN
fi

# 3) Parse version from CHANGELOG.txt if present.
if [ -f "$TARGET_ROOT/CHANGELOG.txt" ]; then
  VER="$(grep -Eom1 'Drupal [0-9]+\.[0-9]+' "$TARGET_ROOT/CHANGELOG.txt" | awk '{print $2}')"
  if [ -n "${VER:-}" ]; then
    MAJOR="${VER%%.*}"
    if [ "$MAJOR" != "7" ]; then
      print_result PATCHED
    fi
    if ver_ge "$VER" '7.32'; then
      print_result PATCHED
    else
      print_result VULNERABLE
    fi
  fi
fi

# 4) Fallback: inspect Drupal VERSION constant if readable.
BOOTSTRAP="$TARGET_ROOT/includes/bootstrap.inc"
if [ -f "$BOOTSTRAP" ]; then
  VER="$(grep -E "define\('VERSION'" "$BOOTSTRAP" 2>/dev/null | sed -E "s/.*'([0-9]+\.[0-9]+[^']*)'.*/\1/" | head -n1)"
  if [ -n "${VER:-}" ]; then
    MAJOR="${VER%%.*}"
    if [ "$MAJOR" != "7" ]; then
      print_result PATCHED
    fi
    if ver_ge "$VER" '7.32'; then
      print_result PATCHED
    else
      print_result VULNERABLE
    fi
  fi
fi

print_result UNKNOWN

Sources

1. Drupal advisory SA-CORE-2014-005
2. Drupal PSA-2014-003 follow-up
3. GitHub Advisory GHSA-f9cm-c972-9975
4. Rapid7 Metasploit module entry
5. SektionEins PoC write-up
6. Debian security tracker
7. Drupal core usage statistics
8. Malwarebytes Drupal compromise research