dungsocool/cve-2018-7600Step-by-step lab walkthrough for exploiting CVE-2018-7600 (Drupalgeddon2) RCE in Drupal 8.5.0, covering attack surface analysis, version fingerprinting, and exploitation via Form API injection.
Start by listing the running containers:
docker ps
From the docker ps results, the container for this Lab is:
p1/lab09:latest
This container exposes port:
0.0.0.0:8011->80/tcp
This indicates that the service inside the container is listening on port 80/tcp, and is mapped to port 8011 on the host.
Port 80/tcp is the standard port for HTTP. Therefore, this target lab is highly likely an HTTP web application. To confirm the web service, I send an HTTP request using curl combined with accessing the web page's GUI.
curl -i http://192.168.3.137:8011/
Attack Surface Assessment
From the HTTP response and web interface, the following information was identified:
Web server: Apache/2.4.25 (Debian) Backend: PHP/7.2.3 CMS: Drupal Drupal version: 8.5.0 Install path: /core/install.php Public port: 8011 -> 80/tcp
This information serves as crucial fingerprints to correlate with CVEs. Specifically, Drupal 8.5.0 is the version directly related to CVE-2018-7600, also known as Drupalgeddon2.
According to the official Drupal advisory, SA-CORE-2018-002 / CVE-2018-7600 affects the following versions:
>= 8.5.0 < 8.5.1
The current target is running:
Drupal 8.5.0
therefore falling within the affected version range.
⇒ Thinking:
At this stage, Drupal version 8.5.0 is strong evidence to identify the suspected CVE. I reason as follows:
docker ps shows that the Lab exposes the HTTP service via port 8011.curl -i returns a valid HTTP response from Apache/PHP./core/install.php.Drupal >=8.5.0 <8.5.1 is affected by CVE-2018-7600.Drupal 8.5.0, making it eligible under the version criteria to test CVE-2018-7600.The target is Drupal 8.5.0 running on Apache/PHP. This version is within the range affected by CVE-2018-7600 according to Drupal's official advisory. The next step is to check the actual exploitation conditions to verify whether the target can be subjected to RCE.
From the previous fingerprinting step, the target clearly displays: Drupal 8.5.0. According to the official advisory from Drupal, the vulnerability SA-CORE-2018-002 / CVE-2018-7600 affects Drupal core versions:
>= 8.5.0 < 8.5.1. The current target runs exactly Drupal 8.5.0, placing it within the affected version range. According to the Drupal advisory, this is a Remote Code Execution vulnerability in Drupal core, which could allow an attacker to exploit multiple attack vectors and lead to the compromise of the entire site.
However, you can see that the target is redirecting to /core/install.php and the GUI displays the Drupal installation screen. This suggests that Drupal might be in an incomplete installation state. If the site setup has not been completed, common endpoints used to trigger Drupalgeddon2 like /user/register, /user/password, and /user/login might not function properly. Therefore, it is necessary to check these endpoints.
curl -i http://192.168.3.137:8011/user/register curl -i http://192.168.3.137:8011/user/password curl -i http://192.168.3.137:8011/user/login
It can be seen that the endpoints are still redirected to /core/install.php
Conclusion:
The target runs Drupal 8.5.0, falling within the version range affected by CVE-2018-7600 according to Drupal's official advisory. However, at the time of testing, the application is in an installer state and continuously redirects routes such as /user/register, /user/password, and /user/login to /core/install.php.
This shows that the endpoints commonly used to verify Drupalgeddon2 are not yet functioning as they would on a fully installed Drupal site. Therefore, the target currently only satisfies the version condition but does not yet meet the runtime conditions to demonstrate Remote Code Execution.
=> Thinking:
We need to further prove that Drupal in its runtime state can process the vulnerable routes/forms, that an attacker can access the endpoints without authentication, and that verification payloads like id can execute successfully.
On the current target, the endpoints redirect to the installer, so the next path is to assess whether the Drupal installation screen creates its own attack surface, instead of immediately concluding a Drupalgeddon2 RCE.
After checking that the Drupal runtime endpoints like /user/register, /user/password, and /user/login are all redirected to /core/install.php, I proceeded to analyze the installer screen.
Checking the database service supporting the installer
Since the Drupal installer is currently halted at the database configuration step, I checked if common database services are exposed externally:
nmap -sV -p 3306,5432,33060 192.168.3.137
The target currently exposes the Drupal installer externally, but no database services accessible directly from the attacker's machine have been detected.
Conclusion: The lab exposes the Drupal 8.5.0 installer and has information disclosure regarding the vulnerable version. CVE-2018-7600 is a valid suspected vector, but successful exploitation has not yet been proven.
CVE-2018-7600 exploits a vulnerability in the Drupal Form API - the form rendering system that utilizes the Render Array structure. When processing an AJAX request, Drupal uses the element_parents parameter to locate elements in the form tree without checking (sanitizing) keys starting with the # character. Attackers inject properties like #post_render, #markup, and #type via POST data to force the rendering engine to execute arbitrary PHP functions (e.g., exec, passthru, system).
Prerequisite condition: At least one endpoint using the Form API must return a valid response (not redirected, not blocked by access control) so that the attacker can send an AJAX request containing the payload.
Commonly used endpoints in public PoCs:
/user/register (registration form - no login required)/user/password (forgot password form - no login required)/user/login (login form - no login required)On the current target: All 3 above endpoints are redirected via 302 to /core/install.php ⇒ not yet satisfied
The vulnerability occurs within the AJAX processing pipeline of the Form API: FormBuilder → RenderArray → #post_render callback execution. This pipeline only operates when Drupal bootstraps all necessary subsystems (routing, form state, render engine).