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

[irfan_pak10]

MAJOR   /block/{invalid_format} returns HTTP 503 'Service Unavailable'

Garbage block-id input crashes the backend, surfaced as an alarming 503 'Service Unavailable' page instead of a graceful 400 / 404. Users hitting a typo see a scary error suggesting site outage.

Reproducer

Code:

$ for h in abc notablock -1 0x123 999999999; do
    curl https://omnisee.io/block/$h
  done
[HTTP 503] /block/abc        → <title>Service Unavailable — OmniSee</title>
[HTTP 503] /block/notablock  → <title>Service Unavailable — OmniSee</title>
[HTTP 503] /block/-1         → <title>Service Unavailable — OmniSee</title>
[HTTP 503] /block/0x123      → <title>Service Unavailable — OmniSee</title>
[HTTP 404] /block/999999999  → <title>Block Not Found — OmniSee</title>   (correct) 

Impact
•   Users see 'Service Unavailable' for any malformed block id, suggesting site outage.
•   Pollutes monitoring (each garbage hit looks like a real outage).
•   Same root cause as Bugs #7 and #8 — unhandled exception in the block-id type sniffer.

Fix
Wrap the block-id parser in a try/except, return 400 on parse failure (or 404 if you treat it as not-found). Never let an exception bubble to a 5xx for input you can validate.

[irfan_pak10]

MAJOR   /api/transaction/{nonexistent_txid} returns 500 instead of 404

Valid 64-hex-format but nonexistent txids trigger an unhandled backend exception. API returns bare 'Internal Server Error' (text/plain, 21 bytes). The HTML route /tx/{nonexistent} correctly returns 200 with a 'Transaction Not Found' page — handlers diverge.

Reproducer

Code:

$ for tx in 1111...1111 ffff...ffff 0123...cdef 2cca...47ce; do
    curl https://omnisee.io/api/transaction/$tx
  done
[HTTP 500] tx=1111...      → "Internal Server Error"
[HTTP 500] tx=ffff...      → "Internal Server Error"
[HTTP 500] tx=0123...cdef  → "Internal Server Error"
[HTTP 500] tx=2cca...47ce  → "Internal Server Error"

Impact
•   Reveals an unhandled exception path on the API.
•   Wrong status code (500) confuses any client doing 'if 404 then ... else error' control flow.
•   Pollutes error metrics / SRE dashboards with fake outages.

Fix
Wrap the upstream provider call in try/except; return 404 + JSON {"error":"Transaction not found","code":"TX_NOT_FOUND"} when no provider returns the tx.

[irfan_pak10]

MAJOR   /api/block/{invalid} returns 500 instead of 400/404

/api/block crashes the handler for negative integers, alphabetic, hex-prefixed, and out-of-range integers. /api/block/0 (genesis) and valid heights work fine. Same root cause class as previous 2.

Reproducer

Code:

$ for h in -1 abc xyz 999999999 0x1234; do
    curl https://omnisee.io/api/block/$h
  done
[HTTP 500] -1         → "Internal Server Error"
[HTTP 500] abc        → "Internal Server Error"
[HTTP 500] xyz        → "Internal Server Error"
[HTTP 500] 999999999  → "Internal Server Error"
[HTTP 500] 0x1234     → "Internal Server Error"

Impact
•   Reveals an unhandled exception path on the API.
•   Wrong status code (500). Clients can't distinguish bad input from real outage.
•   Pollutes error metrics.

Fix

@app.get("/api/block/{hash_or_height}") async def get_block(hash_or_height: str):     try:         if hash_or_height.isdigit():             n = int(hash_or_height)             if n < 0 or n > current_tip(): raise HTTPException(404, "Block not found")             return await fetch_by_height(n)         if re.fullmatch(r"[0-9a-f]{64}", hash_or_height):             return await fetch_by_hash(hash_or_height) or HTTPException(404, "Block not found")         raise HTTPException(400, "Invalid block id")     except UpstreamError:         raise HTTPException(404, "Block not found")

[irfan_pak10]

/api/health leaks internal architecture

The health endpoint returns the full provider fallback chain, Redis status, circuit-breaker states, and the application version. Useful to plan provider-targeted DoS so the fallback chain exhausts.

Reproducer

Code:

$ curl -s https://omnisee.io/api/health | python -m json.tool
{
  "status": "healthy",
  "version": "1.0.0",
  "providers": {"blockstream":"up", "mempool":"up", ...},
  "redis": "up",
  "circuits": {
    "primary":   {"name": "blockstream", ...},
    "fallback":  {"name": "mempool", ...},
    "tertiary":  {"name": "blockchain_info", ...},
    "quaternary":{"name": "blockcypher", ...},
    "local":     {"name": "local_esplora", ...}
  }
}

Impact
•   Reveals the provider fallback order so an attacker can target the chain.
•   Reveals presence of Redis and a private/local Esplora node.
•   Reveals application version (1.0.0).

Fix
Public /api/health should return only {"status":"ok"}. Move the rich payload to /api/health/internal gated behind an admin token or Cloudflare Access policy.

[irfan_pak10]

Backend nginx 1.29.8 version disclosed via /metrics 404

Cloudflare normally rewrites the Server header, but the upstream nginx default 404 body still renders the version in the page footer.

Reproducer

Code:

$ curl -s https://omnisee.io/metrics
<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.29.8</center>
</body>
</html>

Impact
•   Identifies the exact upstream nginx version for CVE targeting.

Fix
On the upstream nginx set server_tokens off; and provide a custom 404 page that does not leak the version.

[irfan_pak10]

HEAD / returns 405 Method Not Allowed (RFC 7231 violation)

RFC 7231 §4.3.2 requires that any resource that supports GET MUST also support HEAD. Currently CDN edge probes, link checkers, monitoring tools, and HEAD-based prefetch fail.

Reproducer

Code:

$ curl -I https://omnisee.io/
HTTP/1.1 405 Method Not Allowed
allow: GET
 
$ curl -s -o /dev/null -w "%{http_code}\n" https://omnisee.io/
200

Impact
•   Breaks monitoring tools, link checkers and CDN edge probes that issue HEAD.

Fix
On Starlette/FastAPI, add a HEAD route that mirrors GET (use methods=["GET","HEAD"]), or have nginx synthesise HEAD by stripping the body from GET.

[irfan_pak10]

Duplicate Strict-Transport-Security headers

Two HSTS headers are emitted on every response, identical value but different case. Indicates two layers of middleware/proxy both injecting the header.

Reproducer

Code:

$ curl -sI https://omnisee.io/ | grep -i strict-transport-security
strict-transport-security: max-age=31536000; includeSubDomains
Strict-Transport-Security: max-age=31536000; includeSubDomains

Impact
•   Wastes ~70 bytes per response.
•   Hints at uncoordinated header injection sources — worth auditing.

Fix
Pick one place to emit HSTS. If FastAPI's SecurityHeadersMiddleware sets it and Cloudflare also injects via Transform Rules, drop the upstream one.

[irfan_pak10]

/docs/ 307 redirect downgrades scheme to http://

HTTPS request gets a 307 with Location header pointing to plain http://. HSTS protects browsers, but the server emits an unsafe scheme — root cause: upstream FastAPI does not trust X-Forwarded-Proto.

Reproducer

Code:

$ curl -sI https://omnisee.io/docs/
HTTP/1.1 307 Temporary Redirect
location: http://omnisee.io/docs

Impact
•   Non-HSTS clients (older bots) can be downgraded to plaintext.

Fix
•   Configure Starlette with ProxyHeadersMiddleware so X-Forwarded-Proto is honoured:

Code:

from uvicorn.middleware.proxy_headers import ProxyHeadersMiddleware
app.add_middleware(ProxyHeadersMiddleware, trusted_hosts="*")

•   Or run uvicorn with --proxy-headers --forwarded-allow-ips '*'.

[irfan_pak10]

/analyze response leaks LLM token counts and eval rate

The JSON returned by /api/address/{addr}/analyze contains a 'metrics' field with tokens_in, tokens_out, duration_ms, eval_rate. Internal observability data should not be sent to clients.

Reproducer

Code:

$ curl -X POST https://omnisee.io/api/address/{addr}/analyze | jq .metrics
{
  "tokens_in":   1857,
  "tokens_out":   187,
  "duration_ms": 7483,
  "eval_rate":  27.43
}

Impact
•   Lets attackers measure cost-per-call and tune token-drain attacks (Bug #1).
•   eval_rate ≈ 27 tok/s fingerprints a small local LLM (e.g., Llama-3 8B on a single GPU).

Fix
Strip the 'metrics' field from the public response. Log it server-side only.

[irfan_pak10]

Homepage HTML comment leaks raw Python data structure

An f-string interpolation in a header HTML comment rendered a Python list-of-dicts (single quotes, not JSON). Confirms backend is Python and exposes the internal price-badge data shape.

Reproducer

Code:

$ curl -s https://omnisee.io/ | grep -A2 "server-rendered from"
           is server-rendered from [{'cur': 'USD', 'sym': '$', 'formatted': '$80,856'},
           {'cur': 'EUR', 'sym': '€', 'formatted': '€68,779'}, ...]. 

Impact
•   Confirms tech stack (Python).
•   Leaks internal data shape used by the price-badge component.

Fix
Remove the comment, or move the explanation server-side, or strip comments at render time.

[irfan_pak10]

/api/graph/{addr}/timeline ignores hops parameter

Negative, zero, very large, alphabetic, null, and even <script> values for ?hops= all return 200 with the same body. The parameter is unused or schema validation is missing.

Reproducer

Code:

$ for hops in -1 0 999 abc null '<script>'; do
    curl -s "https://omnisee.io/api/graph/{addr}/timeline?hops=$hops" | head -c 80
  done
# All six produce HTTP 200 with the same body. 

Impact
•   If the parameter is meant to do something, the feature is broken.
•   If unused, the OpenAPI is misleading clients.
•   Risk of a silent logic bug if the parameter is later wired up without re-checking validation.

Fix

Code:

from typing import Annotated
from pydantic import conint
hops: Annotated[int, conint(ge=1, le=10)] = 1

[irfan_pak10]

/analyze accepts arbitrary 100 KB body silently

POST body is parsed but ignored at the application layer. Combined with Bug #1, an attacker can stuff huge bodies to amplify resource use.

Reproducer

Code:

$ python -c 'import json; print(json.dumps({"data":"A"*100000}))' > big.json
$ curl -X POST -H "Content-Type: application/json" --data @big.json \
    https://omnisee.io/api/address/1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa/analyze
HTTP/1.1 200 OK   (request: 100,012 bytes) 

Impact
•   Wastes memory/CPU parsing 100 KB of unused JSON.
•   Combined with no rate limit (Bug #1), amplifies bandwidth + parser DoS.

Fix
•   Reject request bodies on /analyze — the path parameter drives the work.

Code:

@app.post("/api/address/{address}/analyze")
async def analyze(address: str): ...   # no body parameter at all

•   Plus a size limit at the proxy: client_max_body_size 4k; for this route.

[irfan_pak10]

Genesis transaction confirmations = 0 (off-by-N)

The famous Bitcoin genesis transaction returns confirmations=0 even though it has hundreds of thousands of confirmations. Block-100000 control case computes correctly. Likely an explicit special-case for block_height==0.

Reproducer

Code:

$ curl -s https://omnisee.io/api/stats/tip-height | jq .height
948311
 
$ curl -s https://omnisee.io/api/transaction/4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b | jq '{block_height,confirmations}'
{"block_height": 0, "confirmations": 0}     # BUG — expected 948,312
 
$ curl -s https://omnisee.io/api/transaction/8c14f0db3df150123e6f3dbbf30f8b955a8249b62ac1d1ff16284aefa3d06d87 | jq '{block_height,confirmations}'
{"block_height": 100000, "confirmations": 848312}   # control: correct = tip - height + 1

Impact
•   Most-viewed Bitcoin transaction in the world reports an incorrect 0 confirmations.
•   Any client logic that uses 'confirmations >= N' will treat the genesis tx as unconfirmed.
•   Suggests a stale special-case: while True the genesis coinbase was 'unspendable', confirmations math has nothing to do with spendability.

Fix
Use confirmations = tip_height - block_height + 1 universally. Drop any special-case for height 0.

[irfan_pak10]

/api/graph/{addr}/expand ignores depth and direction parameters

Identical responses for depth=-1, depth=99999, depth=abc, direction=up, direction=evil. Parameters not validated by Pydantic.

Reproducer

Code:

$ for q in '' '?depth=-1' '?depth=99999' '?depth=abc' '?direction=up' '?direction=evil'; do
    curl -s "https://omnisee.io/api/graph/{addr}/expand$q"
  done
# All six produce identical 200 OK responses. 

Impact
•   If parameters are meant to do something, the feature is broken.
•   If unused, the OpenAPI is misleading clients.

Fix
depth: Annotated[int, conint(ge=1, le=10)] = 1 direction: Literal["incoming","outgoing","both"] = "both"

[irfan_pak10]

Cytoscape custom-wheel-sensitivity warning spam on /graph/{addr}/interactive

Custom wheelSensitivity makes mouse-wheel zoom feel unnatural for most users (Cytoscape author warns against it). Warning fires 11 times per single page load.

Reproducer

Code:

Console captured during page load on https://omnisee.io/graph/{addr}/interactive:
 
[warning] You have set a custom wheel sensitivity.  This will make your app
zoom unnaturally when using mainstream mice.  You should change this value
from the default only if you can guarantee that all your users will use the
same hardware and OS configuration as your current machine.
 
(repeated 11 times during a single page load) 

Impact
•   Mouse-wheel zoom feels off on most user hardware.
•   Pollutes DevTools console of any user inspecting the page.

Fix
Remove the wheelSensitivity option from cytoscape() init, or test the default behaviour first.

[irfan_pak10]

No /.well-known/security.txt (RFC 9116)

RFC 9116 standard for vulnerability disclosure missing. Both /.well-known/security.txt and /security.txt return 404. Researchers cannot find a way to report responsibly outside of this bitcointalk thread.

Reproducer

Code:

$ curl -I https://omnisee.io/.well-known/security.txt
HTTP/1.1 404 Not Found
 
$ curl -I https://omnisee.io/security.txt
HTTP/1.1 404 Not Found

Impact
•   Good-faith researchers can't find a contact channel.
•   Unprofessional for an AML / blockchain-security product.

Fix
# /.well-known/security.txt Contact: mailto:security@omnisee.io Contact: https://bitcointalk.org/index.php?topic=5582193.0 Expires: 2027-05-07T00:00:00Z Encryption: https://omnisee.io/.well-known/pgp.asc Preferred-Languages: en Canonical: https://omnisee.io/.well-known/security.txt Policy: https://omnisee.io/security-policy

[irfan_pak10]

Google Fonts CSS link lacks Subresource Integrity (SRI)

External stylesheet from fonts.googleapis.com is loaded without integrity= or crossorigin= attribute. If fonts.googleapis.com is compromised (or the certificate is stolen), an attacker can serve malicious CSS that exfiltrates data via background-image URLs or input[type=password] selectors. Detected by nuclei [missing-sri].

Reproducer

Code:

$ curl -s https://omnisee.io/ | grep "fonts.googleapis"
<link href="https://fonts.googleapis.com/css2?family=Space+Mono:wght@400;700&family=Syne:wght@400;600;700;800&display=swap" rel="stylesheet">
# no integrity=, no crossorigin=

Impact
•   If fonts.googleapis.com is compromised, attackers can run a CSS-injection attack to keylog passwords or exfiltrate data via background-image URLs.
•   Modern browsers will not block the load without SRI.

Fix
•   Google does not publish a stable SRI hash for fonts CSS, so the correct mitigation is one of:
•   (a) Self-host the font CSS via google-webfonts-helper.herokuapp.com, then add SRI hash + crossorigin.
•   (b) Drop fonts.googleapis.com and serve everything from /static/ with proper integrity= attribute.

[irfan_pak10]

Missing Cross-Origin-Opener-Policy / Embedder-Policy / Resource-Policy

Modern cross-origin isolation headers (COOP / COEP / CORP) are absent. Page is exposed to Spectre-class side-channel attacks and cannot use SharedArrayBuffer or high-resolution timers safely.

Reproducer

Code:

$ curl -sI https://omnisee.io/ | grep -iE "cross-origin"
(no Cross-Origin-* headers in response) 

Impact
•   No defence against Spectre v1 side-channel attacks via cross-origin embeds.
•   Cannot use SharedArrayBuffer for any future performance-critical work.
•   Compliance auditors flag this as a baseline gap.

Fix
Cross-Origin-Opener-Policy: same-origin Cross-Origin-Embedder-Policy: require-corp Cross-Origin-Resource-Policy: same-site

[irfan_pak10]

/api  /static  /ws  emit 301 → trailing-slash → 404 (useless chain)

Three URL paths emit '301 Moved Permanently' redirecting to a trailing-slash variant that immediately 404s. The 301 chain wastes a round-trip and confuses crawlers.

Reproducer

Code:

$ curl -sI https://omnisee.io/api      → HTTP 301  Location: /api/
$ curl -sI https://omnisee.io/api/     → HTTP 404
$ curl -sI https://omnisee.io/static   → HTTP 301  Location: /static/
$ curl -sI https://omnisee.io/static/  → HTTP 404
$ curl -sI https://omnisee.io/ws       → HTTP 301  Location: /ws/
$ curl -sI https://omnisee.io/ws/      → HTTP 404

Impact
•   Wastes a round-trip per request (already a 301 cost).
•   Search-engine crawlers cache the 301 → 404 chain as a permanent dead end.

Fix
Either drop the redirect (answer 404 directly) or make the trailing-slash variant useful (a real index, an OpenAPI redirect, etc.).

[irfan_pak10]

/api/address/{addr}/scam-check leaks cache state via response timing

Timing differential between cached/uncached scam-db lookups (0.5 s for cache hit vs 2-3 s for first-time uncached). Side-channel oracle on whether an address has previously been queried.

Reproducer

Code:

addr=satoshi (cached, in scam db):     1.4s, 0.7s, 0.7s
addr=bech32 not in scam db (1st call): 3.1s
addr=bech32 not in scam db (2nd call): 0.5s

Impact
•   Attacker can probe whether your scam-database has been queried for an address.
•   Combined with no rate limit, lets an attacker enumerate the cache state cheaply.

Fix
Constant-time response: delay short responses to a common floor (e.g., always 1.5 s minimum), or pre-warm the cache asynchronously.