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

[Little Mouse]

[Little Mouse]

Reserved

[CONVOAI]

BTC Address: bc1qvms54vmvvxklw7tz82ny8mdejvc8xu7s7tqgz9



The footer is not displaying properly on mobile devices. Some parts of the footer are being cut off. Due to which I am not able to click on all the nav items. The footer should be made more responsive.



The table on the API Documentation page has a UI glitch. The table is not responsive. It looks ugly. If there is a table like this, users will lose interest in reading it.

[bitbollo]

Please find some elements identified, this is my address for payment = bc1qm9wnwsgy52jdefvm5g4w72lxqep5d9ks4gq62p

[1]
On the main page the comment "check out our official Telegram bot here” 
Has not URL valid click to link

[2]
On the page About Terms of Service
If You have any questions regarding these Terms or the Services, please contact [Support](support) .
Has not URL valid click to link

[3]
In Privacy Policy Page
“keeping our Users safe” Has the word User with capital letter since it should be “our users”

[Italian Panic]

BTC address: bc1qfeeh736r2hktk59r6vusmhsn0sys489jygamsf

Bug: in tor window the link below don't open the telegram page. Maybe you must use a proxy socks5 with localhost address

[Italian Panic]

Bug 2: CSFR token is not enough against bot.

An analysis of the devtool in HTML revealed the presence of CSRF tokens designed to prevent cross site req forgery, but these have been shown to be ineffective against automated bot. A bot can load the page, extract the token and submit the form (for ex Puppeteer).

[Italian Panic]

Bug 3: Static captcha is weakness.

The captcha image is generated dynamically, but it is unclear whether it is based on re-captcha or hCAPTCHA, the line:

Code:

refresh page for new Captcha

This suggests that it is not securely bound to the session, if the captcha token

Code:

captcha_token

is predictable or reusable, it can be bypassed and a bot using ocr or captcha solving can easily bypass the control.

[Italian Panic]

Bug 4: Lack of rate limiting when creating orders

system allows Order ID to be generated indiscriminately without any restriction on the frequency of requests (rate limit). A malicious user could automate the creation of thousands of orders per minute. This is visible in the endpoint init_tx

The risk is DOS at the application level, database saturation and potential exhaustion of unique deposit addresses

[Italian Panic]

Bug 5: no address validation - acceptance of burn address, well know scam address or improbable address.

I try various type of btc address:

   - 1HQ3Go3ggs8pFnXuHVHRytPCq5fGG8Hbhx (Silk road relate address OFAC sanctioned)
   - bc1qxy2kgdygjrsqtzq2n0yrf2493p83kkfjhx0wlh (Twitter hack 2020)
   - 1AjZPMsnmpdK2Rv9KQNfMurTXinscVro9V (Samsam ransomware associated)
   - 1BoatSLRHtKNngkdXEeobR76b53LETtpyT (vanity address best know for scam in 2013)
   - 1CGA4srJbPWhtJb7ezgY6GQf4PKhFuzD9w (Bitfinex 2016 hack - hacker address)

Code:

<input type="text" class="copyable-input" value="1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa" readonly>

The system accepts improbable address (satoshi genesis address) and scam address as valid destinations. This indicates that the backend does not query the blockchain or a blacklist before generating the letter of Guarantee.

[Italian Panic]

Bug 6: Timestamp token is predictable and manipulated

The timestamp is a simple encoded Unix value, making it easy for an attacker to predict or forge the validity of a request.

from html code we obtain:

Code:

MTc3ODU3NTAyMC4yNDE2ODAx.agLmrA.1pdXWRyyN3esl_MmeyidShgqGZQ

this is a simple base64 by decoding we obtain the timestamp (only for ex.)

Code:

1778575020.2416801

easily to report at utc time.

The final paart of the string in base64 is not a cryptographic signature that concatenate the timestamp with server private key. An attacker can generate a valid token simply altering the base64 encoded date, bypassing the timeout and can use the old session.

[Italian Panic]

Bug 7: Honeypot can be bypassed via analysis and DOM attribute

honeypot and anti spam mechanism is not good enough. The input field

Code:

input name="website"

can be easily identified as a false by knowing the attribute

Code:

tabindex="-1"

to:

Code:

<input id="website" name="website" tabindex="-1" type="text" value="">

With this structure an automated bot can distinguish real field from false field rendering the protection eneffective. If we combine this bug with bug 4 (no rate limiting) we obtain an massive spam order.

[ContentWriter]

Bech32 address: bc1qw5jnk6ncv4k0625fu7xy4lq73cf09kfmwmyjcv

Report Title: Business Logic Flaw Allows Unlimited BTC-XMR Conversion Exceeding Total Circulating Supply

Report Detail: Using the conversion functionality on mobit.exchange's user interface, I could convert up to 1,000,000,000 BTC to XMR in a single transaction. Since we all know that the total circulating supply of Bitcoin is capped at 21,000,000 BTC, this should be a mathematically impossible action and represents a critical business logic vulnerability.


Delving further in, I could exploit this flaw to artificially inflate exchange balances,  and even try triggering unauthorized withdrawals if I find further logic flaws, or destabilize the platform's internal accounting. An immediate server-side validation should be implemented to reject any conversion amount exceeding the global maximum supply of the asset.

[Italian Panic]

Bug 8: No kyc is not guaranteed by reserve accuracy


decimal accuracy is reported directly in html code:

Code:

<div class="reserves-box">
    <span class="reserve-item">BTC : 2.2194788</span>
    <span class="reserve-item">XMR : 309.29281269</span>
    <span class="reserve-item">ETH : 70.91978262</span>
    <span class="reserve-item">USDT : 193087.32735873</span>
</div>

a no kyc exchange this precision is a technical error, i can track a TX with this effective decimal accuracy and search this in blockchain and I can know his time and can link the web session.
A bot can refresh this page every 10 second, as the code contains the

Code:

<meta http-equiv="refresh" content="10">

and record every single change. This allows us to know exactly how much money is coming in and going out, thereby compromising corporate and user.

[ContentWriter]

Report Title: Negative Amount Accepted in Currency Conversion Leading to Invalid Swap Calculations

Report Details: The exchange calculator accepts negative input values (e.g -2 BTC) and processes them into negative output amounts (e.g -XMR). This indicates a lack of proper input validation and allows mathematically invalid or logically inconsistent conversions.

Steps to Reproduce
Go to the swap/calculator page
Enter a negative value in “From Amount” (e.g -2 BTC)
Select any valid destination currency (e.g Monero)
Submit or calculate the swap

[Italian Panic]

Bug 9: Session token persistence

I try a random TX using satoshi genesis address and randomic Monero address to evaluate the situation of cookies session, the session never fall

on devtools --> application tab --> cookies, as the page refreshes the value of the session cookie does not change. In this case the server is keeping our session to base64 token for the entire duration of observation (30 minutes) and never expired.

An attacker who steal that cookie can monitor the order from another pc becouse the session is not regenerater whilst the order is being monitored exposing the user to long session of hijacking.

[Italian Panic]

Bug 10: Logical flaw in PGP guarantee duration

PGP guarantee duration is set for only 20 minutes, bitcoin blockchain network is often slow, so a user may find that a transaction is received after the guarantee has expired, even before the exchange has received the funds. This is a logical flaw that protects the exchange but not the user.

Code:

Order ID: c65e0315d2fd48958630ebdf2b7f0043
Rate Type: flat
Timestamp: 2026-05-12 11:51:54.582566+00:00
Expires: 2026-05-12 12:11:54.582566+00:00

[Italian Panic]

Bug 11: Inadequate cache management and session persistence

server does not implement 

Code:

Cache Control: no-store

directive, allowing sensitive order data to be retrieved in full by browser "back button" function. Furthermore, the failure to invalidate or rotate the session cookie after the order has been viewed allows automatic monitoring to be restored (10 sec refresh), violating security principles for No-KYC financial platforms."

[Italian Panic]

Bug 12: Application level DOS via concurrent request flooding (race condition)

I was trying to see if i could trigger a race condition to get multiple orders instead i ended up crashing the service:

Code:

[FAILED] Thread 2: Status 400
[FAILED] Thread 9: Status 400 
[FAILED] Thread 7: Status 400 
[FAILED] Thread 4: Status 400 
[FAILED] Thread 0: Status 400 
[FAILED] Thread 5: Status 400 
[FAILED] Thread 6: Status 503 
[FAILED] Thread 8: Status 503 
[FAILED] Thread 3: Status 503
[FAILED] Thread 1: Status 503

While testind the endpoint init_tx I discovered that the backend fails to handle the requests. When multiple requests are sent simultaneously using the same captcha and token session, the server logic seem break down.

The server instead of processing the first request and rejecting the others with a standard

Code:

400 bad request

it frequently crashes or time out returnig a

Code:

HTTP 503 service temporarily unavailable

for large attempts.

I ran a synchronization test using a python script with 15 concurrent threads and the 40% triggered a 503 error from linux nginx server. This is a clear DOS vulnerability, a maliciuos don't need a botnet to disrupt your service they only need a simple script to flood init_tx eendpoint with handful comcurrent requests. This effectively leading to direct financial loss and service downtime.

[ContentWriter]

Server-Side Processing of Negative Transaction Amounts in /init_tx

The /init_tx endpoint accepts and processes negative cryptocurrency amounts server-side instead of rejecting invalid financial input during transaction calculation.

A POST request containing a negative value in the from_amnt parameter is accepted by the backend application and results in a successful redirect response.

Example request parameter:

from_amnt=-2

Observed server response:

302 Found
Location: /?calc=1&from_currency=bitcoin&to_currency=monero&from_amnt=-2&rate_type=dynamic

The application then renders the calculation page using the negative amount value instead of returning a validation error.

Impact:
Although no transaction order was ultimately created, the backend still processes invalid negative financial input. This may lead to:

• inconsistent transaction calculation behavior
  undefined accounting states
  unreliable downstream processing
  future logic abuse if additional functionality is introduced

Expected Behavior:
The server should reject any transaction amount less than or equal to zero before calculation or redirect logic occurs.

Recommendation:
Implement strict server-side numeric validation on all transaction amount parameters and return an explicit validation error for invalid financial values.

[iqbal26]

i have deepscan all api and now site error 503  

Critical API Issues Found:
Internal Server Errors (500) on /api/v1/status
Endpoint crashes with concurrent requests
Returns: {"error":"internal-server-error","error_msg":"Server encountered an error, contact support.","result":null}
Impact: Potential DoS vulnerability, poor error handling


Service Unavailable (503) Under Load
API becomes unstable with multiple concurrent requests
Switches between 500 and 503 responses

Session Security Issues:
Insecure Session Cookies
Missing Secure flag (cookies sent over HTTP possible)

Missing SameSite attribute (CSRF vulnerability)
Impact: Session hijacking, CSRF attacks possible

Missing Cache Controls
No Cache-Control, Pragma, or Expires headers
Impact: Sensitive content could be cached by proxies/browsers

Rate Limiting Absence
No apparent rate limiting on API endpoints
Risk: Brute force attacks, abuse