Round#2 [OPEN] Omnisee 🚨 Bug Hunt Campaign – Help To Improve & Get Rewarded! 🐞

[Italian Panic]

Report Title: Ok, this is not a bug but an improvement

Report Details: It would be nice if the Bitcoin current value icon (top right of the page) could include more major currency pairs, such as EUR, CNY, ETH, XMR, etc.

[ContentWriter]

Report Title: Fit Button is Non-Functional in Javascript Graph

Report Details: Unlike other buttons that turn blue when clicked, the "Fit" button neither turns blue nor produce any changes in the graph. There is practically no visual feedback and the graph does not repond to this button. I think the button may be unbound from any Javascript function.

A fit button shoud automaticall scale and center the graph. This doesn't happen.

[ContentWriter]

Report Title: JavaScript Graph Freezes Completely on Hops 2 After Excessive Loading Time

Report Details: When the JS graph is set to Hops 2, the platform freezes after a long loading time. Even the loading indicator stops completely showing that the system is no longer producing the updated graph. At this point, it neither loads or returns a timeout error. The user is unable to click any buttons on the graph interface because other buttons become unresponsive.

This is possibly a resource exhastion, infinite loops or unhandled asynchronous operations that lock up JS event loop.

[ContentWriter]

Report Title: JS Graph Freezes Completely On Hops 3

Report Details: The Hops 3 feature of the JS graph is completely unusable. The graph generation system freezes completely after a short time, even though the progress indicator was rotating, no progress was made in production of the graph. The graph doesn't load and no error message is displayed to show the user what could have gone wrong. It is obvious that the system cannot handle exponential increase in data complexity beyond Hops 1. This may be due to memeory exhaustion or infinite recursive queries.

I think the Omnisee team should limit graph queries to Hops 1 in the meantime pending the resolution of this issue.

[albon]

Bech32 address: bc1qnpx002096kd62g3d7gzyac7qwtnu2q2ayjzkt4

[UPDATED]

Report Title: Missing Input Sanitization Report on page parameter

Vulnerable URL: https://omnisee.io/api/address/1A1zP1eP5QGefi2DMPTfTL5SLmv7Divf/export.csv

Vulnerable Parameter: page

Issue Details: The server reflects raw input in the response when an integer parsing error occurs. This indicates a lack of server-side sanitization for special characters and HTML tags.

Proof of Concept:
The input is reflected in the JSON response as shown below:




Recommendation: You should Implement proper server-side validation and Filter and encode the page parameter to remove any HTML or any special characters before using or reflecting it.

[ContentWriter]

Report Title: Full Graph with Hops 2 Returns Cloudflare 504 Gateway Timeout Error

Report Details: While using the Full Graph option, choosing Hops 2 redirects to the Cloudflare 504 Gateway Timeout error. It means the backend is taking too long to process the request. This is the cause of the termination by the Cloudflare gateway prior data loading.

[ContentWriter]

Bech32 address: bc1qnpx002096kd62g3d7gzyac7qwtnu2q2ayjzkt4

Report Title: Critical Security Vulnerability Report - Reflected Cross-Site Scripting (XSS)

Report Details:

Vulnerable URL: https://omnisee.io/api/address/1A1zP1eP5QGefi2DMPTfTL5SLmv7Divf/export.csv

Vulnerable Parameter: page

Impact: An attacker can run malicious JavaScript in the user’s browser which could allow him to steal session and access sensitive data or fully control the page as shown in the PoC.

Proof of Concept: You can verify the vulnerability by visiting the following link (ensure DevTools allow pasting for the full visual effect):

[Injection Link]




----------------------------
I hope the platform team takes a look at the severity of the discovered vulnerability, as $50 for an issue like this does not seem fair at all compared to the time spent finding it and the impact of the bug, which allows full control over the DOM.  

This is not a valid bug. If it was, I'd have reported it in the first bounty. To start with, the endpoint accepts no

Code:

page

parameter. You can check

Code:

/api/address/.../export.csv

to confirm that the vulnerability you just reported doesn't exist there. That endpoint accepts no query perimeter and you can test it by adding 

Code:

?page=<script>alert(1)</script> 

to the URL. The server simply ignores or rejects the parameter.

Even if an attacker could inject a payload into the CSV output, you should have noticed that the

Code:

Content-Type

is

Code:

ext/csv

(or

Code:

application/csv

). You should know that web browsers DO NOT execute JS inside downloaded CSV files. For you to get through an XSS attack, the browser response must be rendered in HTML.

To confirm, you should test if the server returned

Code:

Content-Type: text/html

while reflecting the unescaped payload within an HTML context which as you can see, this endpoint does not do.

[ContentWriter]

Report Title: Hops 3 on Full Graph Triggers Cloudflare 504 Gateway Timeout Error

Report Details: The platform returns a Cloudflare 504 Gateway Timeout error when the Full graph is set to Hops 3. This happens even within a short period of loading activity and the user is left with no graph visualization. This confirms that the backend server cannot handle exponential complexity of Hops 3 within Cloudflare's limits before timeout error. Query performance should be optimized.

[irfan_pak10]

Bech32 address: bc1qgr7l8a7jymuymkdm7v6fmkhf3twg9s9fatsfe3

Report Title: AI Detective analysis shows raw Markdown (## headings & bullets) rather than formatted text

Steps to Reproduce:
Open omnisee.io.
Click one of the quick‑link examples (e.g., Example P2SH), or search any busy address (3FZbgi29cpjq2GjdwV8eyHuJJnkLtktZc5).
On the address page, click AI Detective at the top.
Wait ~1 minute for the AI analysis to finish and display results.
Observe the AI Detective panel.



Observed Behavior: When the analysis completes, the result displays raw Markdown in the panel. Headings are prefixed with ## and bullet lists start with -, as shown in the screenshot omnisee.io. The text is not rendered into proper sections or lists, making it hard to read.

Expected Behavior: The AI Detective report should render cleanly formatted text with proper headings and bullet points. For example, “Verdict”, “Key Factors”, “Activity Pattern”, and “Recommendation” should appear as bold or clearly separated headings, and lists should be indented bullet points without Markdown syntax characters.

Impact: This is a usability and presentation issue. Users may find the analysis difficult to read or think the site is broken because the markup is exposed. While the information is still present, the professional look and clarity of the platform are compromised.
Severity: Minor (cosmetic/formatting)

[albon]

This is not a valid bug. If it was, I'd have reported it in the first bounty. To start with, the endpoint accepts no

Code:

page

parameter. You can check

Code:

/api/address/.../export.csv

to confirm that the vulnerability you just reported doesn't exist there. That endpoint accepts no query perimeter and you can test it by adding  

Code:

?page=<script>alert(1)</script> 

to the URL. The server simply ignores or rejects the parameter.

Even if an attacker could inject a payload into the CSV output, you should have noticed that the

Code:

Content-Type

is

Code:

ext/csv

(or

Code:

application/csv

). You should know that web browsers DO NOT execute JS inside downloaded CSV files. For you to get through an XSS attack, the browser response must be rendered in HTML.

To confirm, you should test if the server returned

Code:

Content-Type: text/html

while reflecting the unescaped payload within an HTML context which as you can see, this endpoint does not do.

I have already updated my report to reflect the actual behavior of the server thank you. I hope you update your previous quote to align with my latest findings.

The main issue here is missing server-side input sanitization which allows raw HTML/special characters to be reflected in the response as you know, the secure system should not reflect user input directly.

The screenshots also show that the page parameter was processed by the server and reflected in the response, which resulted in an int_parsing error. This should be addressed to avoid similar issues with HTML input handling.

Even if this link isn’t directly exploitable as XSS ,it could still be relevant in other contexts.

I used the Console just to demonstrate the impact and how the DOM could be manipulated if this issue were exploited.

[ContentWriter]

This is not a valid bug. If it was, I'd have reported it in the first bounty. To start with, the endpoint accepts no

Code:

page

parameter. You can check

Code:

/api/address/.../export.csv

to confirm that the vulnerability you just reported doesn't exist there. That endpoint accepts no query perimeter and you can test it by adding  

Code:

?page=<script>alert(1)</script> 

to the URL. The server simply ignores or rejects the parameter.

Even if an attacker could inject a payload into the CSV output, you should have noticed that the

Code:

Content-Type

is

Code:

ext/csv

(or

Code:

application/csv

). You should know that web browsers DO NOT execute JS inside downloaded CSV files. For you to get through an XSS attack, the browser response must be rendered in HTML.

To confirm, you should test if the server returned

Code:

Content-Type: text/html

while reflecting the unescaped payload within an HTML context which as you can see, this endpoint does not do.

I have already updated my report to reflect the actual behavior of the server thank you. I hope you update your previous quote to align with my latest findings.

You still don't get it,

The main issue here is missing server-side input sanitization which allows raw HTML/special characters to be reflected in the response as you know, the secure system should not reflect user input directly.

The only thing sanitization would do here is break functionality. This is unnecessary since CSV files don't execute JS.

The screenshots also show that the page parameter was processed by the server and reflected in the response, which resulted in an int_parsing error. This should be addressed to avoid similar issues with HTML input handling.

It is normal for error messages to reflect input. It doesn't infer vulnerability.

Even if this link isn’t directly exploitable as XSS ,it could still be relevant in other contexts.

I used the Console just to demonstrate the impact and how the DOM could be manipulated if this issue were exploited.

Console manipulation proves nothing since an attacker has no way of forcing the victim to open Console. Just bear in mind that hypothetical future exploit scenarios are not bugs. You cannot prove otherwise without a working URL that automatically triggers an alert.

[ContentWriter]

Report Title: AI Detective Returns Inconsistent Token Count Data From Different Browsers

Report Details: I analyzed the same Bitcoin address across three different browsers, Chrome, Edge and Firefox. What I found out is that the AI Detective returned inconsistent token count across these browsers despite the fact that the analysis was done within the same period. Token output counts varied Token output counts varied across all three browsers: 164, 173, and 168 respectively.

It is possible that the AI Detective is sampling different time windows or reading from unsychronized data sources.

[Italian Panic]

Report Title: Information disclosure via verbose API error message

Report Details: The API response exposes internal details of the framework (FastAPI/Pydantic), including validation types, parameter structure and internal stack.

URL: https://omnisee.io/api/address/.../export.csv?page=test
Response: exposes "type", "loc", “msg”, "input" from the internal validation system.

In production, these errors should return only a generic "Invalid parameter".

[ContentWriter]

Report Title: Wording and Descriptive Inconsistency Pattern By AI Detective

Report Details: While analyzing the same Bitcoin address across different browsers, the AI Detective returns different descriptive texts from the browsers. Isn't it possible that such non-deterministic natural language pattern could confuse users?

In browser one, the Ai stated:"... appears to be used as a collection point for a fake investment scheme, receiving deposits from victims before moving the funds elsewhere."
In browser two, it stated: "... used to receive deposits from victims of the "Plano de Riqueza Infinita" investment fraud, likely as part of an ongoing scam operation."
In browser three, it stated: "... used to receive deposits from victims of an investment fraud, likely part of a larger fake project operation. The pattern of high volume and rapid emptying suggests a disposable wallet for the scam."

[Italian Panic]

Report Title: Critical Admin panel exposed

Report Details: from my last report we know the Admin use FastAPI and now I check some critical endpoint of the framework. Url: https://omnisee.io/openapi.json obtained the full openapi.json:

https://pastebin.com/gTxZHrCx


we obtain the secret path of Admin:

/4b09f6d9d5355bb1/login
/4b09f6d9d5355bb1/logout
/4b09f6d9d5355bb1  (dashboard)
/4b09f6d9d5355bb1/parsing
/4b09f6d9d5355bb1/llm
/4b09f6d9d5355bb1/limits
/4b09f6d9d5355bb1/mixing

[irfan_pak10]

Report Title: Unresponsive “Change” and “Labels” buttons in the Interactive Graph

Steps to Reproduce
Go to omnisee.io and open any address page (e.g., click Example P2WPKH on the home page).
On the address page, click JS Graph to open the interactive transaction graph.
Once the interactive graph loads, locate the control bar above the graph. It contains buttons such as Rebuild, Fit, Layout, Force (CoSE), Change, Labels, and a square icon.
Click Change, Labels, or the square icon.

Observed Behavior
None of these buttons do anything, there is no visible change to the graph layout, labels, or any indication that the controls are working. The graph remains the same even after repeated clicks, as shown in the screenshot.



Expected Behavior
These buttons should perform actions consistent with their labels. For example:
Change should switch the graph’s layout or reload data.
Labels should toggle the visibility of node labels or open a menu to adjust label settings.
The square icon (which typically indicates a full-screen or view toggle) should expand or shrink the graph’s view.

Impact
This renders part of the graph UI non-functional. Users might think the interface is broken or incomplete, and they cannot customize the graph view or labels.

Severity
Minor/functional UI bug – it does not break core functionality but reduces usability and may confuse users.

[irfan_pak10]

Major Bug – Block pages do not display transaction lists

Steps to reproduce:
Navigate to any block by entering its URL directly (e.g., omnisee.io/block/948068) or clicking a block from the Latest Blocks list.
Observe the block detail page.

Observed behavior:
The page displays only the block metadata (height, hash, timestamp, size, weight, version, etc.). It shows the number of transactions in the summary (e.g., 2,930 transactions) but there is no transaction list or pagination, and scrolling does not reveal any further content.



Expected behavior:
A block page should list all transactions (with pagination or lazy loading) so that users can inspect individual transactions.

Impact:
Users cannot view or analyze transactions within a block, which is a core feature of a blockchain explorer. This affects usability and trust in the site’s completeness.

[Italian Panic]

Report Title: Information disclosure on /api/health

Report Details: the response from /api/health reveals too much internal information:

Code:

{
  "status": "healthy",
  "version": "1.0.0",
  "providers": {
    "blockstream": "up",
    "mempool": "up",
    "blockchain_info": "up",
    "blockcypher": "up"
  },
  "redis": "up",
  "circuits": {
    "primary": {"name": "blockstream", "failures": 0, "state": "closed"},
    "fallback": {"name": "mempool", "failures": 0, "state": "closed"},
    ...
  }
}

from this we know: software version, internal architecture, redis, failover structure, every single provider (a cyber attacker knows exactly which service to target in order to compromise the system!!!!)

[irfan_pak10]

Major Bug  – JSON export returns “Invalid address” instead of data

Steps to reproduce:
Open any address page (e.g., via a quick link such as Example P2WPKH).
Click the JSON export button at the top of the transaction history.
Alternatively, manually navigate to

Code:

https://omnisee.io/api/address/<address>/export.json?page=1

with a valid address.

Observed behavior:
Clicking JSON does not trigger a download. Visiting the export URL directly results in a plain white page displaying “Invalid address”. The URL remains at the

Code:

/api/address/…/export.json

path.



Expected behavior:
The JSON export should return a valid JSON file containing the address’s transactions (similar to the CSV export).

Impact:
Users are unable to export transactions in JSON format. This limits data portability and makes it harder to integrate with other tools.

[irfan_pak10]

Critical Bug – Visiting the root domain sometimes yields a blank “Invalid address” page

Steps to reproduce:
After visiting any /api or export path (e.g., the JSON export link above), type https://omnisee.io (without trailing slash) in the address bar and press Enter.

Observe the page that loads.

Observed behavior:
Instead of loading the home page, the site returns a white screen with the message “Invalid address”. The page remains blank until a trailing slash (/) is added or the back button is used.



Expected behavior:
Navigating to https://omnisee.io should always load the home page regardless of previous pages.

Impact:
This routing error causes confusion and may lead users to think the site is unavailable or broken. It also exposes internal error messages to end users, indicating a misconfiguration of the route resolver.