Had Claude trace the permission model on the delete action, and it found the actual DELETE isn't scoped to the post the moderator is viewing:
$edit_id_list = $this->request->variable('option', array(0=>0));
...
$sql = 'DELETE FROM ' . $this->table . ' WHERE ' . $this->db->sql_in_set('edit_id', $edit_id_list);
$this->db->sql_query($sql);The permission check earlier in handle(), $this->auth->acl_get('m_delete_editlog', $forum_id), only confirms the moderator can delete edit-log entries in the forum the current $post_id belongs to. The compare action's queries do add AND post_id = {$post_id} when reading old text, but this delete has no equivalent post_id clause, it deletes by whatever edit_id values got submitted, with no check that they belong to the post being viewed at all.
edit_id is a small sequential integer, and phpBB's own request-typing already forces the submitted option[] array to int (verified against type_cast_helper::recursive_set_var() in real phpBB core, so no SQL injection there), which just makes the values easy to enumerate. A moderator with m_delete_editlog in even one forum can open that forum's edit-log page, then submit edit_ids belonging to edit-log entries for posts in a different forum, one they have no delete permission in, and erase them.
That matters more than it might for other extensions since the entire point of this tool is preserving an audit trail for moderators to review. Letting a moderator erase edit history outside their own granted authority undermines exactly what it's for.
A fix would add AND post_id = {$post_id} to the DELETE's WHERE clause (matching the pattern the compare action's SELECTs already use), so a moderator can only ever delete entries belonging to the post they've been authorized against.
Had Claude trace the permission model on the delete action, and it found the actual
DELETEisn't scoped to the post the moderator is viewing:The permission check earlier in
handle(),$this->auth->acl_get('m_delete_editlog', $forum_id), only confirms the moderator can delete edit-log entries in the forum the current$post_idbelongs to. The compare action's queries do addAND post_id = {$post_id}when reading old text, but this delete has no equivalentpost_idclause, it deletes by whateveredit_idvalues got submitted, with no check that they belong to the post being viewed at all.edit_idis a small sequential integer, and phpBB's own request-typing already forces the submittedoption[]array toint(verified againsttype_cast_helper::recursive_set_var()in real phpBB core, so no SQL injection there), which just makes the values easy to enumerate. A moderator withm_delete_editlogin even one forum can open that forum's edit-log page, then submitedit_ids belonging to edit-log entries for posts in a different forum, one they have no delete permission in, and erase them.That matters more than it might for other extensions since the entire point of this tool is preserving an audit trail for moderators to review. Letting a moderator erase edit history outside their own granted authority undermines exactly what it's for.
A fix would add
AND post_id = {$post_id}to the DELETE's WHERE clause (matching the pattern the compare action's SELECTs already use), so a moderator can only ever delete entries belonging to the post they've been authorized against.