[OPEN] Mobit.Exchange Bug Bounty Campaign | Get Paid for Reporting Bugs

[ContentWriter]

Title: Backend Creates Active Orders Below Enforced Minimum Deposit Threshold


The

Code:

/init_tx

endpoint allows creation of active swap orders using amounts far below the documented minimum deposit requirement.


The application advertises a minimum BTC deposit threshold of approximately0.00062217 BTC. However, submitting a significantly smaller amount such as 0.00000001 BTC successfully results in:

• active order creation
  dedicated deposit address allocation
  order tracking initialization
  public order page generation

Observed server response:

302 Found
Location: /order/307eeae44e97452ca2a85c493239d735

The generated order page still displays the higher minimum amount requirement, indicating that minimum validation occurs only after backend resources and order state have already been allocated. It's obvious that an attacker can repeatedly generate dust-value orders below the intended minimum threshold, potentially causing:

• order spam
  unnecessary resource allocation
  deposit address exhaustion
  monitoring queue pollution
  operational overhead

Because each request generates a live order object and associated tracking resources, this behavior may enable low-cost automated abuse.

Expected Behavior:
Transaction amounts below the configured minimum threshold should be rejected before order creation, address allocation. tracking initialization and backend resource assignment

Recommendation:
Enforce minimum amount validation server-side within /init_tx before creating any order objects or assigning infrastructure resources.

[ContentWriter]

Title: Unrestricted Order Creation and Weak Abuse Controls in /init_tx

While testing the swap flow on Mobit Exchange, I noticed that the

Code:

/init_tx

endpoint allows repeated creation of swap orders without meaningful abuse prevention. I was able to send multiple requests in a short period of time without any rate limiting, IP blocking, or throttling being triggered.

During testing, I also observed that CAPTCHA enforcement does not behave as a strict single-use mechanism. The same CAPTCHA value could be reused across multiple successful requests, which makes automated order creation easier than expected.

What stood out most is that even very small or invalid transaction amounts (such as 0.00000001 BTC, below the stated minimum) still result in full order creation. Each request generates a valid order ID and a unique deposit wallet address, meaning backend resources are allocated immediately before strict validation of business rules is enforced.

Although the UI later displays the correct minimum deposit requirement, the order itself is already created and active at that point. This suggests that validation happens after order initialization rather than before it.

This allows repeated automated creation of swap orders and unnecessary allocation of backend resources per request. The main issue is the lack of proper rate limiting combined with weak CAPTCHA enforcement and premature order creation logic in the backend.