[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.

[ContentWriter]

Order Timeout Severely Delayed (20 Minutes Specified, ~2 Hours Actual)

Orders on mobit.exchange remain active and executable beyond the 20-minute expiration time specified in the signed order message. Although the signed payload includes a valid expiration field, the system fails to validate this to constrain user during execution. I observed that an order was active more than 2 hours after it was created. The consequence of this is that stale orders could be filled after their intended timeframe has passed. This could potentially lead to unintended trades or unfavorable pricing for MM.

The expected behavior is that the order should become invalid after the 20 minutes order window.

[ContentWriter]

Letter of Guarantee Modal Closes Unexpectedly Before User Finishes Reading

LoG modal window closes prematurely, interrupting user reading flow. Letter of Guarantee (LoG) modal popup is triggered by clicking the downpointing arrow on an element or but closes without warning. When a user clicks the downpointing arrow on the designated element or button, a modal window opens displaying the Letter of Guarantee (LoG). However, this window is unstable and frequently closes automatically. This sometimes happens within seconds and before the user has finished reading the content. This behavior forces the user to repeatedly reopen the modal. This could be a frustrating user experience.

Steps to Reproduce:

Navigate to the screen containing the element/button with the downpointing arrow for viewing the LoG.

Click the downpointing arrow to open the LoG modal window.

Begin reading the content inside the modal. You may not be done before it closes
.

[ContentWriter]

Title: Ambiguous Refund and Cancellation FAQ May Mislead Users About Order State and Refund Eligibility

While reviewing the FAQ section, I noticed that the wording around transaction cancellation and refunds is somewhat unclear and could easily confuse users about when refunds are actually possible.
The current explanation mixes together multiple order states (queue, received, confirmed and refund queue) without clearly defining them. As written, users may incorrectly assume that any confirmed transaction is still refundable even after processing may have already started.

Furthermore, the flow for reopening an order and initiating a refund is not explained very clearly, especially for users who already left the order page. The wording also implies that users are automatically redirected to the refund queue, which may not accurately describe the actual process.
This appears more like a usability and trust issue than a direct security vulnerability, but on a financial platform handling crypto transactions, unclear refund logic can create misunderstandings, support disputes, and accidental loss of funds.

I would recommend simplifying the wording and clearly separating:

• pending orders
   confirmed deposits
   processing state
   refund eligibility
   refund request procedure

I suggest something like this:

Can I cancel a transaction or request a refund?

Yes. Refunds are available for orders that have not yet been completed.

If your deposit has already been received but the exchange has not yet been finalized, you may request a refund directly from your order page by providing a valid refund address. If you closed the order page, you can reopen it anytime using your Order ID on the Track Order page.

Please note that completed exchanges cannot be reversed once the payout transaction has been sent.

If you experience any issues requesting a refund, contact our support team within 15 days of creating the order and include your Order ID for assistance.

[ContentWriter]

Title: Production-Looking API Key Exposed in Public API Documentation

While reviewing the public API documentation, I noticed that the example requests include what looks like a realistic API key value:

Code:

`X-Mobit-Api-Key: c31a9cdc-7178-43ff-b043-f12fbd2097f4`

Although this may only be intended as a placeholder, its format is similar to a valid production-style UUID token rather than a fake example value. Using realistic-looking credentials in public documentation can create confusion for users and may encourage unnecessary automated probing or accidental reuse if the key was ever active in another environment.

Best practice entails that documentation examples use non-functional placeholders such as:

Code:

`YOUR_API_KEY_HERE`

or intentionally invalid example formats that cannot be mistaken for live credentials.

[ContentWriter]

Misspelled JSON Response Field in /api/v1/exchange API Documentation

While checking the API documentation, I noticed that the example response for POST

Code:

/api/v1/exchange

contains a typo in the JSON field name.

Current example:

"recieving_address": "0x1234567890abcdef1234567890abcdef12345678"

The correct spelling should be:

"receiving_address": "0x1234567890abcdef1234567890abcdef12345678"

This may seem minor, but developers often copy response structures directly from documentation. Using the wrong field name could lead to broken integrations or parsing errors in client applications.

[ContentWriter]

Title: Invalid JSON Syntax in `/api/v1/status` API Response Examples

While reviewing the API documentation, I found several response examples that are not valid JSON and may cause confusion for developers integrating with the API.

Issues identified in the `

Code:

GET /api/v1/status

` examples include:

• Missing comma after the `"txid"` field
  Trailing commas before closing braces
  Use of invalid field names such as:

```json
"amount_received | amount_sent"
```

The pipe (

Code:

`|`

) syntax inside a JSON key is not valid for real API responses and makes it unclear which field should actually be returned.

Because many developers directly copy documentation examples into test environments or SDKs, these formatting problems could lead to parsing failures and integration bugs.

[ContentWriter]

Title: Inconsistent Data Types Used in API Response Examples

In the API documentation, I noticed several numeric values are returned as strings instead of integers or booleans.

Here are some examples:

Code:

```json
"confirmations": "0"
"confirmations_required": "10"
"success": "true"
```

These values would be more consistent and developer-friendly as:

Code:

```json
"confirmations": 0
"confirmations_required": 10
"success": true
```

Returning numbers and booleans as strings can create unnecessary type handling issues for API consumers. It may lead to validation or serialization problems in strongly typed languages.

[ContentWriter]

Title: Ambiguous Parameter Logic in `/api/v1/estimate` Documentation

While looking at the estimate endpoint documentation, I noticed the explanation for

Code:

send_amount

,

Code:

receive_amount

, and

Code:

rate_type

is unclear and potentially misleading.

The document states that:

“Rate type is required when providing send_amount, otherwise it will be flat when providing receive_amount.”

This makes it difficult to understand how the API behaves when `

Code:

receive_amount

` is used and whether `

Code:

rate_type

` is ignored or automatically forced to

Code:

flat

.

Furthermore, the documentation lists:

receive_amount | send_amount

as if it were a single parameter name, instead of documenting them as separate mutually exclusive parameters.This is clearly ambiguous and may cause incorrect API integrations or unexpected exchange calculations.

Code:

send_amount

and

Code:

receive_amount

should be documented as two separate parameters instead of combining them into a single field name using pipe (

Code:

|

) notation.

It should be made clear that:

• Only one of these parameters should be provided per request
  The parameters are mutually exclusive
  Supplying both should return a validation error

A clarification such as:

Code:

Either send_amount or receive_amount must be provided, but not both in the same request.

would remove the potential of incorrect API intrgration or inconsistencies in calculation.

[ContentWriter]

Title: Spelling Error in `/api/v1/status` API Description

Mobit.exchange API documentation has a spelling mistake in the description for `GET /api/v1/status`.

The text says:

Retrieves the status of an order along with relavant data.

Suggested correction:

Retrieves the status of an order along with relevant data.

Although minor, documentation spelling mistakes can reduce professionalism. It creates avoidable confusion for developers relying on the API reference.

[ContentWriter]

Title: Ambiguous Response Field for Refunded Orders in `/api/v1/status`

While reviewing the `GET /api/v1/status` documentation, I noticed a potential ambiguity in the response example for:

 

Code:

Response (complete, refunded)

here:

Code:

{
  "result": 
    {
      "status": "complete | refunded",
      "txid": "0x1234567890abcdef1234567890abcdef12345678",
      "to_currency": "tether | bitcoin | ethereum | monero | usd-coin | dai",
      "from_currency": "tether | bitcoin | ethereum | monero | usd-coin | dai",
      "amount_sent": "100.000",
    },
  "error": null
}
      

As we can see in the same field:

"

Code:

amount_sent

"

is used for both completed and refunded orders.

For refunded transactions, this naming may be misleading because the funds are being returned rather than sent to the intended exchange destination. A more explicit field such as:

"

Code:

amount_refunded

" would make the response clearer and easier for developers to interpret correctly.

Minimun API requirement is that the documentation should be clear enough for us to know whether `

Code:

amount_sent

` in a refunded state refers to the refunded amount or the originally intended outgoing amount.

Here's a correct code for a refunded order:

Code:

{
  "result": {
    "status": "refunded",
    "txid": "0x1234567890abcdef1234567890abcdef12345678",
    "to_currency": "monero",
    "from_currency": "bitcoin",
    "amount_refunded": "100.000"
  },
  "error": null
}

[ContentWriter]

Title: Vague Refund Response Example in API Documentation

The "success" response in the `POST /api/v1/refund` documentation uses a string instead of a boolean value:

"success": "true"

A more standard API response would be:

"success": true

Using strings for boolean states can create unpredictability across integrations and could force unnecessary type conversions for API consumers.

[ContentWriter]

Title: Inconsistent Data Types in API Response Examples

The API documentation presents several numeric values as strings instead of integers.

For example:

Code:

"confirmations": "0",
"confirmations_required": "10",
"position": "1"

should be:

Code:

"confirmations": 0,
"confirmations_required": 10,
"position": 1

Using numeric values as strings can create parsing and validation issues for developers. This is especially so in strongly typed languages and automated integrations.

I also noticed the documentation uses pipe notation such as:

Code:

"1 | 2 | 3 | ..."

inside example values. Developers may be confused into thinking the literal string is returned by the API rather than that being an example of possible numeric outputs.

[ContentWriter]

Title: Trailing Comma in JSON Response Example Causes Invalid JSON

While reviewing the `GET /api/v1/status` documentation, I observed that Response examples contain a trailing comma before the closing brace.

Here it is:

Code:

"amount_received | amount_sent": "100.000",
},

Trailing commas are not valid in standard JSON and may cause parsing failures in strict parsers, validators or automated tooling.

Suggested correction:

Code:

"amount_received": "100.000"
}

I believe I have already recommend separating `

Code:

amount_received

` and `

Code:

amount_sent

` into distinct example responses rather than combining them using pipe (`

Code:

|

`) notation. This incorrect combination can create additional ambiguity for developers integrating with the API.

[HasanHandy]

BTC Address: bc1qxl52cgc446jthut9g0fwvx5u3g0k4n29w448ag

List of cookies with missing, inconsistent or contradictory properties:
https://mobit.exchange/

Cookie was set with:
Set-Cookie: session=eyJjc3JmX3Rva2VuIjoiYjlkNjk4OWE5ZTM1NmNkNTEyOTM0ZjRiYzQ3MzBhZGI2ZjMwYWNlMyJ9.agR-Rw.J3E-Lm2vFs-shla0jUuvFVRvxJo; HttpOnly; Path=/

This cookie has the following issues:
 - Cookie without SameSite attribute.
When cookies lack the SameSite attribute, Web browsers may apply different and sometimes unexpected defaults. It is therefore recommended to add a SameSite attribute with an appropriate value of either "Strict", "Lax", or "None".

Vulnerability Description:
At least one of the following cookies properties causes the cookie to be invalid or incompatible with either a different property of the same cookie, of with the environment the cookie is being used in. Although this is not a vulnerability in itself, it will likely lead to unexpected behavior by the application, which in turn may cause secondary security issues.

Discovered by Detect misconfigured cookies

The impact of this vulnerability:
Cookies will not be stored, or submitted, by web browsers.

How to fix this vulnerability:
Ensure that the cookies configuration complies with the applicable standards.

[HasanHandy]

BTC Address: bc1qxl52cgc446jthut9g0fwvx5u3g0k4n29w448ag

Cookies without Secure flag set:
https://mobit.exchange/

Set-Cookie: session=eyJjc3JmX3Rva2VuIjoiYjlkNjk4OWE5ZTM1NmNkNTEyOTM0ZjRiYzQ3MzBhZGI2ZjMwYWNlMyJ9.agR-Rw.J3E-Lm2vFs-shla0jUuvFVRvxJo; HttpOnly; Path=/


Vulnerability Description:
Cookies does not have the Secure flag set. When a cookie is set with the Secure flag, it instructs the browser that the cookie can only be accessed over secure SSL/TLS channels. This is an important security protection for session cookies.

Discovered by Session Cookie without Secure flag set.

The impact of this vulnerability:
Cookies could be sent over unencrypted channels.

How to fix this vulnerability:
If possible, you should set the Secure flag for these cookies.

[HasanHandy]

BTC Address: bc1qxl52cgc446jthut9g0fwvx5u3g0k4n29w448ag

URL:
https://mobit.exchange/

Attack Details:
The TLS/SSL certificate (serial: 06ba378a54ee279c3de76afe109c528647a0) will expire in less than 60 days. The certificate validity period is from Mon Mar 23 2026 09:46:48 GMT+0600 (Bangladesh Standard Time) to Sun Jun 21 2026 09:46:47 GMT+0600 (Bangladesh Standard Time) (38 days left)


Vulnerability Description:
One of the TLS/SSL certificates used by your server is about to expire.

Once the certificate has expired, most web browsers will present end-users with a security warning, asking them to manually confirm the authenticity of your certificate chain. Software or automated systems may silently refuse to connect to the server.

This alert is not necessarily caused by the server (leaf) certificate, but may have been triggered by an intermediate certificate. Please refer to the certificate serial number in the alert details to identify the affected certificate.

Discovered by TLS/SSL audit.

The impact of this vulnerability:
If an application server detects an expired certificate with a system it is communicating with, the application server may continue processing data as if nothing happened, or the connection may be abruptly terminated.

How to fix this vulnerability:
Contact your Certificate Authority to renew the SSL certificate.

[ContentWriter]

Invalid JSON Structure and Unclear Field Definitions in Status Response API

 GET /api/v1/status API documentation, specifically at the Response (receiving, sending, refunding) example, I identified multiple structural and semantic issues that could lead to parsing errors and incorrect integrations.

The response example is not valid JSON due to missing syntax elements. It also contains unclear field definitions that may confuse developers implementing strict parsers or SDK generators.

Let's just look at this:

Code:

{
  "result": {
    "status": "receiving | sending | refunding",
    "txid": "0x1234567890abcdef1234567890abcdef12345678"
    "confirmations": "0",
    "confirmations_required": "10",
    "to_currency": "tether | bitcoin | ethereum | monero | usd-coin | dai",
    "from_currency": "tether | bitcoin | ethereum | monero | usd-coin | dai",
    "amount_received | amount_sent": "100.000",
  },
  "error": null
}

The missing comma after "txid" field is a critical JSON syntax error
The trailing comma after "

Code:

amount_received | amount_sent

" field is an invalid JSON standard
the "

Code:

amount_received | amount_sent

" written as a single key is invalid and unclear and should be two separate fields depending on the transaction direction
"

Code:

status

", "

Code:

to_currency

", and "

Code:

from_currency

" is a multi-value field formatted incorrectly. The documentation as pipe-separated values instead of actual enumerated values is clearly wrong
"confirmations" and "confirmations_required" should be integers instead of strings

The correct response in this API document section should be:

Code:

{
  "result": {
    "status": "receiving",
    "txid": "0x1234567890abcdef1234567890abcdef12345678",
    "confirmations": 0,
    "confirmations_required": 10,
    "to_currency": "monero",
    "from_currency": "bitcoin",
    "amount_received": "100.000"
  },
  "error": null
}

These issues may lead to:

• JSON parsing failures in controlled environments
  Broken SDK generation
  Incorrect type inference in TypeScript, Go, Rust, etc
  Misinterpretation of API response structure by developers

[ContentWriter]

Report Title: Invalid JSON and Incorrect Data Type Example in Queued API Response

While reviewing the API documentation, I noticed that the `Response (queued)` example contains two issues that may confuse developers integrating with the API.

Here:

Code:

{
  "result": 
    {
      "status": "queued",
      "position": "1 | 2 | 3 | ...",
    },
  "error": null
}

Issues observed:

1. The JSON, like the preceeding report contains a trailing comma after the `position` field making the example technically invalid JSON.

2. The `position` value is shown as a string containing pipe-separated examples (`"1 | 2 | 3 | ..."`), which may incorrectly suggest that the API returns a literal string instead of a numeric queue position.

Suggested corrected example:

Code:

{
  "result": {
    "status": "queued",
    "position": 1
  },
  "error": null
}