Summary
A vulnerability exists in the API application request submission endpoint that allows an authenticated user to create unlimited support/API request tickets by replaying a captured request.
Although the UI enforces a restriction of “one ticket per user,” this restriction is not enforced server-side. By re-sending the same request, a new ticket is created each time with a different ticket ID.
Additionally, there is no rate limiting, enabling mass ticket creation.
Affected Endpoint
POST /api_application_requests HTTP/2
Host: www.amplenote.com
Vulnerability Details
The application is designed to allow only a single API access request (ticket) per user. However:
The restriction is enforced only on the frontend/UI
The backend does not validate existing tickets
Replaying a captured request results in:
A new ticket being created
A new ticket ID assigned each time
Even though:
Only the latest ticket remains accessible
Previously created tickets cannot be accessed
They are still successfully created and stored on the backend.
Proof of Concept (PoC)
Step 1: Submit a Ticket Normally
Navigate to:
https:
Fill out the form and submit
Step 2: Capture Request
Using Burp Suite or similar tool, capture the request:
POST /api_application_requests HTTP/2
Host: www.amplenote.com
Content-Type: application/x-www-form-urlencoded
authenticity_token=XXXX&
api_application_request[company_name]=test&
api_application_request[company_url]=test&
api_application_request[application_name]=test&
api_application_request[redirect_uri]=test&
api_application_request[alternate_redirect_uri]=test&
api_application_request[application_description]=test&
commit=Submit
Step 3: Replay Request
Send the same request multiple times
Result:
Each request creates a new ticket
Ticket ID changes every time
No validation or blocking occurs
Observed Behavior
Unlimited ticket creation is possible
No rate limiting or abuse protection
Only the latest ticket is accessible
Older tickets become inaccessible but still exist
Impact
This vulnerability can lead to:
🚨 Abuse Scenarios
Ticket flooding / spam
Backend resource exhaustion (DB/storage)
Potential denial of service on support systems
Log pollution and operational overhead
⚠️ Business Impact
Increased infrastructure cost
Support workflow disruption
Potential abuse for automation or bot-based attacks
Root Cause
Missing server-side validation for:
Existing ticket per user
Absence of:
Rate limiting
Duplicate request detection (replay protection)
Recommendations
Enforce Server-Side Validation
Restrict users to a single active ticket
Implement Rate Limiting
Limit requests per user/IP (e.g., 5/minute)
Add Replay Protection
Use nonce or one-time tokens
Ticket Deduplication Logic
Reject identical submissions within a time window
Audit Existing Tickets
Clean up spam/duplicate entries
Conclusion
The application fails to enforce ticket submission limits at the backend level, allowing attackers to bypass restrictions and create unlimited tickets through request replay. This introduces a clear abuse vector that can impact system performance and operational stability.