Summary
A race condition vulnerability allows a user to bypass the intended one-reaction-per-user restriction on blog comments. By sending multiple concurrent reaction requests, it is possible to register multiple "love" reactions from the same account on a single comment, artificially inflating its reaction count.
Vulnerability Type
Race Condition
Business Logic Bypass
Integrity Issue
Affected URL
https:
Affected Endpoint
POST /blog/ample_agent_pro_frontier_llm_access/comments/328/toggle_reaction
Description
The blog comment reaction feature is intended to allow a user to react only once to a comment. If the user has already reacted, subsequent requests should simply toggle or remove the existing reaction instead of creating additional reactions.
However, the reaction validation is vulnerable to a race condition. When multiple identical toggle_reaction requests are sent concurrently, each request verifies that the user has not yet reacted before the reaction record is committed.
Because these operations are not synchronized, several requests are processed simultaneously, resulting in multiple reactions being recorded for the same user on the same comment.
During testing, I successfully increased the reaction count on my own comment by sending concurrent requests.
Steps to Reproduce
Log in to an Amplenote account.
Navigate to:
https:
Create a comment (or use an existing comment you own).
Capture the following request after clicking the Love reaction:
POST /blog/ample_agent_pro_frontier_llm_access/comments/328/toggle_reaction
Example request body:
{
"reaction_em": "love"
}
Send multiple copies of the request simultaneously using Burp Suite Repeater (parallel requests) or Turbo Intruder.
Observe that several requests return successful responses.
Refresh the page and verify that the reaction count has increased beyond the expected single reaction from one user.
Proof of Concept
Expected behavior
A user should only be able to contribute a single reaction to a comment.
Repeating the request should toggle or remove the existing reaction rather than increasing the count.
Actual behavior
Multiple concurrent toggle_reaction requests are accepted.
The same account contributes multiple reactions.
The displayed reaction count is artificially inflated.
Impact
This vulnerability compromises the integrity of the blog's reaction system and can be abused to:
Artificially inflate the popularity of comments.
Manipulate community engagement metrics.
Mislead users regarding the popularity or relevance of content.
Undermine trust in the reaction and ranking system.
Enable automated reputation manipulation through concurrent requests.
Root Cause
The application checks whether the user has already reacted before recording the new reaction, but these operations are not executed atomically. Concurrent requests perform the validation simultaneously before the reaction state is updated, allowing duplicate reactions from the same account.
Remediation
Implement atomic handling of comment reactions by:
Performing the validation and reaction update within a single database transaction.
Enforcing a database uniqueness constraint on (user_id, comment_id, reaction_type) (or the appropriate unique relationship).
Applying row-level locking or equivalent synchronization during reaction processing.
Re-validating the user's reaction status immediately before committing the transaction.
CWE
CWE-362 – Concurrent Execution using Shared Resource with Improper Synchronization (Race Condition)
Severity
Medium
Although this vulnerability does not expose sensitive information or allow privilege escalation, it enables attackers to manipulate engagement metrics by bypassing the intended one-reaction-per-user restriction. If reactions are used to influence visibility, ranking, or perceived popularity of comments, the integrity impact can be significant.