Previewing an unapproved comment triggers do_blocks() on the entire event page

Both chains start from the same design decision: The Events Calendar processes unapproved comments as Gutenberg blocks ^[4]. The first one then works because the plugin signs the attacker's payload for him. is_safe_widget_instance() decides whether widget instance data is safe by unserializing it and asking contains_object() whether an object came back. Data with malformed trailing bytes makes that preliminary unserialize() return false, contains_object(false) reports no object, and the check returns true ^[7]. The plugin computes a valid wp_hash() over the attacker-specified data and passes it to the next deserialization stage ^[8].

That stage gets further into the same string. Object restoration begins, fails again on the trailing data, and on the way through invokes an array_map() callback in existing code, which runs OS commands with web server privileges ^[9].

The second chain needs no object at all. A plain PHP array passes the object check and gets a valid hash, and the template's extract() call turns attacker-controlled data into a local classes variable ^[10]. parse_array() then takes values from tec_classes() and calls functions that pass is_callable(); the advisory notes that is_callable() does not itself execute the function ^[11]. From there the published proof of concept resets the administrator password, and neither prior credentials nor comment approval are needed at the entry point ^[12].

Version numbers are where this gets missed. CVE-2026-78006 affects 6.17.4 and earlier; CVE-2026-78159 affects 6.17.3 and earlier ^[13]. A site sitting on 6.17.4 is outside the second range and inside the first, so it is fixed for 78159 and still exposed to 78006 ^[22]. Both are fixed in 6.17.4.1 or later ^[15].

Two conditions have to hold for any of it. Comments must be enabled and displayed on the event post, and the attacker must be able to open the preview URL for their own unapproved comment ^[14]. Turning off event comment submission and display removes those prerequisites, and Wordfence adds that existing unapproved comments must not be processed either ^[16]. On filtering, the writeup's own note is that a WAF blocking crafted comments may hinder attempts but depends on detectable patterns, and it labels that an inference ^[17].

The detection guidance is labelled inference too: preview requests carrying unapproved and moderation-hash are the clue, shell execution from PHP is what to check on the first path, and administrator password changes, suspicious logins and plugin installations on the second ^[18].