CVE-2019-6340: Drupal Core field types fail to sanitize non-form data, enabling PHP code execution

Automated analysis

Generated by VULONE's analysis model from the NVD record, CISA KEV and EPSS data on 17 September 2026. Confidence: high.

critical priorityIt is in CISA KEV with public exploits and a very high EPSS score, and successful exploitation yields remote PHP code execution.

What it is

Some field types in Drupal 8.5.x before 8.5.11 and 8.6.x before 8.6.10 do not properly sanitize data arriving from non-form sources, which can lead to arbitrary PHP code execution. The flaw is only reachable on sites that expose a web services module accepting PATCH or POST requests, such as core REST, JSON:API, or the Drupal 7 Services/RESTful Web Services modules.

Impact

An attacker can execute arbitrary PHP code on the affected Drupal site, leading to full compromise of the web application and its data. Depending on the deployment, this can extend to the underlying host.

Attack surface

Reached over the network through enabled web services endpoints that accept PATCH or POST requests; no authentication or user interaction is required per the CVSS vector (AV:N/AC:H/PR:N/UI:N). Sites without such a module enabled are not affected.

Exploitation

CVE-2019-6340 is listed in CISA KEV with a 2022-03-25 addition date, and EPSS shows a 30-day probability of 0.92017 (99.8th percentile). Multiple public Exploit-DB entries are tagged as exploits, indicating weaponized code is available.

What to do

• Upgrade Drupal 8.5.x to 8.5.11 or later and Drupal 8.6.x to 8.6.10 or later, per the vendor advisory sa-core-2019-003.
• If immediate patching is not possible, disable or restrict the core REST, JSON:API, and other web services modules, or block PATCH/POST requests to their endpoints at the web server or WAF.
• Apply the contributed module updates referenced in the same Drupal advisory, including Services-related updates for Drupal 7 sites.
• Review Drupal 7 sites using Services or RESTful Web Services and confirm the associated contributed updates are applied.
• After patching, audit for signs of prior compromise given the long window since public exploits appeared.

Detection

• Monitor web server and Drupal logs for PATCH or POST requests to REST, JSON:API, or Services endpoints, especially from unexpected source addresses.
• Inspect for unexpected PHP files, modified core or contributed module files, and anomalous child processes spawned by the web server user.
• Alert on outbound network connections or new scheduled tasks originating from the Drupal host.
• Use file integrity monitoring on the Drupal codebase to catch post-exploitation changes.

This assessment is produced automatically and is not human-reviewed. Verify against the vendor advisory before acting on it.