- Affected version
- 2.1.2
The
If this is on an end-point not protection by flood protection; this would allow for a race condition between the select entity and the delete & post-delete update queries. This is most obvious on the reaction API, as you can decrement a user's reaction score unexpectedly by hitting a post reaction API with a large number of queries.
This is more obvious under apache with pre-forking as the number of php workers can be unexpectedly very large allowing triggering the race condition easier.
Entity::delete() function does not check the return result of the $db->delete() call, meaning Entity::_postDelete() can potentially be called multiple times for content which has been deleted as XenForo generally does non-locking selects before deletes/updates. While most instances of _postDelete are safe to call repeatedly, a number of them adjust counters rather than recompute counters from scratch.If this is on an end-point not protection by flood protection; this would allow for a race condition between the select entity and the delete & post-delete update queries. This is most obvious on the reaction API, as you can decrement a user's reaction score unexpectedly by hitting a post reaction API with a large number of queries.
This is more obvious under apache with pre-forking as the number of php workers can be unexpectedly very large allowing triggering the race condition easier.
Last edited:
