nayem-m/drupalgeddon2-cliCLI rewrite of the Drupalgeddon2 (CVE-2018-7600) PoC — for authorised testing/education
A command-line rewrite of the Drupalgeddon2 (CVE-2018-7600) proof-of-concept, built as a study exercise while working through the Hack The Box Academy Attacking Common Applications module.
[!WARNING] For authorised security testing and education only. Running this against systems you do not own or have explicit written permission to test is illegal in most jurisdictions. See Legal & responsible use.
[!NOTE] Implementation written with AI assistance. See A note on authorship.
Drupal is one of the "common applications" covered in HTB Academy's Attacking Common Applications module, and CVE-2018-7600 ("Drupalgeddon2") is the canonical unauthenticated-RCE example for it. Rather than copy-paste a one-shot script and move on, I wanted to actually understand the Form API injection that makes the bug work — so I rebuilt the public PoC from the ground up as a learning exercise.
The widely-referenced original, a2u/CVE-2018-7600 by Vitalii Rudnykh, is great for demonstrating the bug, but it expects you to edit the payload in-place for each run. In a lab/CTF workflow — re-running against different targets, wanting a repeatable foothold — that gets tedious. This version turns it into a proper CLI tool instead:
cmd=It's deliberately scoped to a known, long-patched vulnerability (disclosed in 2018). The goal was understanding the technique and producing a clean, documented reference implementation — not novel offensive capability.
The code in this repository was written with AI assistance (Anthropic's Claude) while I worked through the HTB module. I set the design goals and requirements — CLI ergonomics, auto-deploy of the web shell, interactive mode, randomised shell name and parameter — and I reviewed and tested the result. I'm disclosing this because it's the honest thing to do, and because the value here is in the understanding and the engineering decisions rather than authorship of every line.
--cmd, or drop into an interactive pseudo-shell with --shell.CVE-2018-7600 affects:
This implementation targets the Drupal 8 Form API vector (the user/register AJAX endpoint). Drupal 7 is exploitable through a different endpoint/payload and is not handled here.
Patched releases (7.58 / 8.5.1 and later) are not affected.
requestspip install requests
# one-off command
python3 drupalgeddon2.py -u http://target/ -c id
# interactive pseudo-shell
python3 drupalgeddon2.py -u http://target/ --shell
# just plant the shell, run nothing
python3 drupalgeddon2.py -u http://target/ --deploy-only
# route through Burp, ignore the proxy's self-signed cert
python3 drupalgeddon2.py -u http://target/ -c id --proxy http://127.0.0.1:8080 -k
| Flag | Description |
|---|---|
-u, --url | (required) Target base URL, e.g. http://target/ |
-c, --cmd | Single command to run on the target |
--shell | Drop into an interactive pseudo-shell |
--deploy-only | Only plant the web shell, run nothing |
--shell-name | Filename for the planted shell (default: random .php) |
--param | GET parameter name for the shell (default: random md5) |
--proxy | Proxy URL, e.g. http://127.0.0.1:8080 |
-k, --insecure | Disable TLS verification (for self-signed proxy certs) |
--timeout | Per-request timeout in seconds (default: 15) |
CVE-2018-7600 is an input-sanitisation failure in Drupal's Form API. Drupal represents forms as nested renderable arrays, and array keys beginning with # are treated as special render properties rather than user data. The patch (SA-CORE-2018-002) added sanitisation to strip these #-prefixed keys out of user-supplied input.
Before the patch, an unauthenticated attacker could inject render properties into a form element that gets processed by Drupal's AJAX handler. Submitting properties such as:
#post_render — a list of callables Drupal invokes after rendering, and#markup — the argument passed to themagainst the user-registration form's mail element causes Drupal to call an arbitrary PHP function (here, exec) with attacker-controlled input during the render step — i.e. remote code execution, with no authentication required.
This PoC uses that primitive to base64-encode a one-line PHP shell locally, have the server decode it to a file in the webroot, and then interact with that file over normal GET requests.
If you're on the defending side of this:
Remediation
Detection ideas
#post_render, #markup, #type, #lazy_builder, etc. Legitimate form submissions don't contain these.…/user/register?element_parents=…&_wrapper_format=drupal_ajax carrying suspicious parameters..php file in the webroot.system($_GET[...]) shells).This tool is published for education and for authorised security testing — your own lab environments, HTB/CTF targets, or systems you have explicit written permission to assess. Unauthorised access to computer systems is a crime under laws such as the UK Computer Misuse Act 1990, the US Computer Fraud and Abuse Act, and equivalents elsewhere. You are solely responsible for how you use it. The author accepts no liability for misuse or for any damage caused.
MIT