Claude Code turned a published Drupal patch into a working exploit in 51 minutes

Patch diffing is old work. By the column's account, Drupal's published patch revealed clues about what had been fixed ^[2]. In its telling, Claude Code isolated those changes, recreated the vulnerable environment and helped turn the clues into a working attack ^[3]. Elapsed time from publication to functional exploit was 51 minutes ^[4].

That clock starts late. Drupal pre-announced the critical release in May and asked operators to prepare patching during its scheduled release window ^[1]. The column's team used the notice to watch the relevant branches and line up its research before the patch existed. The columnist wrote that the pre-announcement "offered enough credible information for the team to prepare its research before the patch appeared", which let them "set a trap" ^[9].

The column's own hand-work baseline is at least a couple of days for an expert familiar with CMS platforms, PHP and advanced SQL injection ^[6]. Against that, the run is about 56 times faster: 48 hours is 2,880 minutes, and 2,880 divided by 51 is 56.5 ^[15]. Both figures come from the same author. The estimate is the columnist's, the run is self-reported, and the column does not name the CVE or the specific Drupal release ^[17]. It also records that Claude got stuck and a human researcher had to intervene ^[5].

The ordering problem holds whatever the exact minute count. A production change may still require dependency checks, staging, backups, rollback preparation, approvals and a maintenance window, and most organizations cannot safely change production inside 51 minutes ^[7]. The columnist argued that unpatched and exposed and unpatched and mitigated need to be treated as meaningfully different states ^[8]. Interim mitigation is a bridge to the patch. The argument is that when attackers can act autonomously and production changes still need human review, many organizations cannot deploy a permanent fix as quickly as exploitation can begin ^[19].

The interim controls the column lists are ordinary: restricting access to the vulnerable endpoint or functionality, a narrowly scoped WAF rule, or temporarily disabling an affected feature ^[11]. The column then asks teams to validate the control against the known exploit where possible, test relevant variants, confirm the vulnerable path is actually blocked, and confirm that legitimate application behavior still works ^[12].

CISA's Binding Operational Directive 26-04 already requires federal agencies to use more context when prioritizing vulnerabilities, including reachability, exploitability and potential impact ^[13]. The column applies the same logic to response measurement. Take two companies that each need four days to test and deploy the permanent patch. One implements and validates an access restriction within four hours; the other leaves the path exposed the whole time. Mean-time-to-patch scores them identically ^[14]. The distance between those two outcomes is 92 hours of exploitable exposure ^[16].