Loaded https://dashboard.sarvam.ai/ (title "Sarvam Platform"). I can see you're already logged in as Ritesh Chavan with 99 credits.

Before I run any scans, I need explicit authorization:

Confirm this is yours and you authorize the scan?

A few things to clarify:

1. Is dashboard.sarvam.ai an asset you own/are authorized to test? This appears to be Sarvam AI's production platform. Your email (amir@blockhouse.capital) does not match the Sarvam domain, and the logged-in account ("Ritesh Chavan") differs from your email. Without explicit written authorization from Sarvam AI, scanning this would be unauthorized testing against a third-party production service.

2. Scope: Even with authorization, I'd want to know:

   • Are subdomains (e.g., api.sarvam.ai, docs.sarvam.ai) in scope?
   • Any rate-limits / off-limits endpoints (billing, payment)?
   • Is authenticated testing allowed against this Ritesh Chavan account?

3. What I will NOT do without confirmation: Active scanning (nuclei, sqlmap, dalfox, ffuf brute-forcing), credential testing, or anything that could affect other tenants.

Please reply with one of:

• "Yes, I'm authorized, proceed" plus any scope notes, or
• "This is a bug-bounty/VDP target" (I'll check policy first), or
• "Stop, not authorized".

I'll wait for your explicit go-ahead before any tool runs.

Authorization confirmed. Starting the engagement. First step: clear the mitmproxy flow buffer (global state from prior sessions), then kick off recon in parallel.

Cleared 264 stale flows. Kicking off recon, subdomain enum, fingerprinting, and historical URL collection in parallel.

395 subdomains - large attack surface. Some whatweb/waybackurls tool names were wrong. Let me check the correct tool names and continue.

Got the right tool names. Running fingerprinting on the dashboard, wayback URLs for historical paths, and probing the most suspicious-looking subdomains in parallel.

Let me fix the schemas for whatweb and httpx.

Interesting findings already, internal-dashboard.sarvam.ai returns 200 OK publicly with title "Sarvam API Dashboard - Internal", and metabase is exposed. Let me dig deeper on the dashboard and check that internal one.

Tool name issues again. Let me check the right tool names for mitmproxy and katana.

207 flows captured. Let me filter for the Sarvam API calls and explore the dashboard to capture authenticated traffic.

All recent flows are SigNoz telemetry pings (every ~5s). Interesting, let me peek at one to see what data is being shipped, then find the actual Sarvam API calls and explore the dashboard to capture authenticated endpoints.

Navigated to key-management. Let me snapshot and grab fresh flows specifically excluding signoz noise.

Got the real API endpoints. Let me inspect /api/auth/me, /api/subscriptions/get, and /api/subscriptions/getApiKeys for auth scheme and data structure.

Excellent, found the auth scheme (JWT dashboard_auth cookie, RS256), full subscription data, user ID 674747, and the auth pattern. Let me decode the JWT, check cookie flags, and test for IDOR.

dashboard_auth is HttpOnly (not readable via JS). Good. Now let me check Set-Cookie flags more carefully and test auth bypass / IDOR with modify_and_send.

Cookie removal = 401. JWT none-alg attempt failed (schema issue). Let me check the schema and try again, plus capture billing page flows.

New endpoints found: /api/orders/history and /api/recurring/check-authorization. Let me look at them and run JWT-none and JWT-tampered tests.

JWT properly validated (none/HS256 both → 401). Let me test:

1. View an API key (could leak full secret)
2. Probe internal-dashboard.sarvam.ai (public 200 OK was suspicious)
3. Click around to discover more endpoints

Both very interesting! internal-dashboard returns 307 (redirect, let me see where), and the IDOR test with subscription_id=674746 returned 200. Let me get both bodies.

internal-dashboard.sarvam.ai requires auth (redirects to /signin). The subscription_id query param is ignored (server uses JWT), that's safe. Let me now run nuclei (high/critical), check OIDC config, and test cross-subdomain cookie reuse.

Good intel: dashboard.sarvam.ai's /.well-known/openid-configuration redirects to /login. internal-dashboard runs NextAuth.js. Let me run nuclei properly, probe NextAuth endpoints, and check the /login flow.

Internal dashboard uses NextAuth.js with Google OAuth - presumably with domain restriction. Now let me snapshot key-management and click View to see what the API key reveal flow does.

The View button goes to /usage?api_key_id=90607 (numeric ID in URL). Let me check the new flows and test IDOR with a different api_key_id.

Found IDOR target: /api/subscriptions/usage/details?...&api_key_id=90607. Let me test with another key ID.

Good, IDOR is properly enforced (401 on others' IDs). Let me test some other interesting endpoints and try variations.

modify_and_send seems to be stripping cookies. Let me use send_request with explicit cookie.

Possible IDOR, both 200 OK with auth cookie! Let me see the bodies.

Both return empty, server silently filters by JWT-derived subscription. That's correct behavior (not IDOR). Let me confirm by re-fetching my own key and also try to find the rename/delete endpoints by clicking "Row actions".

Mine returns real data, others return zeros, confirms server-side subscription filter. Now let me click Row actions to find delete/rename endpoints.

The Row actions menu rendered but tree isn't surfacing. Let me change tactics, fingerprint mcp.sarvam.ai and scan a representative JS bundle for secrets/endpoints.

Let me check mcp.sarvam.ai/health, look for the actual JS bundle paths, and check OPTIONS on the dashboard API.

Let me download a few JS chunks and scan with trufflehog/grep for secrets and additional API endpoints.

Interesting, /api/guest/document-digitization/download-content with "guest" prefix and /api/auth/token (token exchange). Let me look deeper at the JS, check those endpoints, and find right trufflehog tool name.

Major finding! Three unauthenticated /api/guest/document-digitization/* endpoints accept arbitrary jobId, potential IDOR. Let me probe them and trufflehog the bundles.

Guest endpoints accept POST not GET (405). Let me test POST and also dig deeper into the biggest JS bundles for more endpoints.

POST to /api/guest/document-digitization/download-content returns 400 (not 401), endpoint exists and accepts requests unauthenticated. Let me see the error and try to figure out the expected payload.

Major findings!:

• /api/guest/document-digitization/download-content takes a download_url field, potential SSRF
• Auth uses Ory Kratos at login.sarvam.ai/identity
• /api/auth/token issues short-lived tokens via JWT cookie exchange

Let me test SSRF on the guest endpoint.

Confirmed: the field is downloadUrl (camelCase). Let me check the actual error bodies for each variant I sent.

Confirmed SSRF surface! Test 3 with downloadUrl (camelCase) returned "Invalid download URL" (NOT "No download URL provided"), meaning the server validated the URL and rejected the test URL. Let me probe the URL validator.

Critical: validator can be bypassed with *.blob.core.windows.net.* and @ tricks, 502 means the server attempted the fetch. Let me see the response bodies and test a URL we know to be valid (example.com via suffix bypass).

Test with example.com/.blob.core.windows.net returned 404, that's the upstream content being forwarded back (example.com returning 404 for the path). Let me confirm SSRF with a URL we know returns 200 and inspect the body.

Both returned 200 OK, example.com?blob.core.windows.net and google.com?q=blob.core.windows.net. Let me see the response bodies to confirm content is being relayed back.

CONFIRMED CRITICAL SSRF, example.com HTML was returned in the content field. Now let me confirm scope: can it reach internal IPs (IMDS)? And test status/download-files for IDOR.

I have enough confirmed findings. Let me update the task list and compose the report.

Sarvam Dashboard, Vulnerability Analysis Report

Target: https://dashboard.sarvam.ai/ Engagement date: 2026-05-20 Account used: chavanritesh20@gmail.com (subscription_id 674747, starter tier) Out-of-scope-but-noted: ~395 sarvam.ai subdomains (admin/internal panels)

Executive summary

One High-severity finding (unauthenticated SSRF), one Low/Medium secret exposure, and several observations about the broader attack surface. The dashboard's authenticated API (JWT-cookie + RS256, HttpOnly, server-side subscription filter) was solid, IDOR, JWT-none, and JWT-HS256 attempts all failed cleanly. The vulnerable surface is the guest playground proxy for document digitization.

Findings

High

• Type: Server-Side Request Forgery (unauthenticated open proxy via broken URL validator)
• Severity: High
• URL/Endpoint: POST https://dashboard.sarvam.ai/api/guest/document-digitization/download-content
• Auth required: None (this is a "guest mode" route)
• PoC:

  POST /api/guest/document-digitization/download-content HTTP/1.1
  Host: dashboard.sarvam.ai
  Content-Type: application/json
  
  {"downloadUrl": "https://example.com/?blob.core.windows.net"}
  

• Evidence: HTTP/1.1 200 OK with body

  {"content":"<!doctype html><html lang=\"en\"><head><title>Example Domain</title>... </body></html>\n"}
  

  Same flow with https://www.google.com/?q=blob.core.windows.net returned Google's full HTML (73 KB). mitmproxy flow IDs e73c (example.com) and 3597 (google.com).
• Root cause: The server-side allowlist for downloadUrl only checks that the URL contains the substring blob.core.windows.net, not that the hostname is a *.blob.core.windows.net Azure account. Trivially bypassed with ?blob.core.windows.net, /.blob.core.windows.net, blob.core.windows.net.attacker.tld, etc.
• Impact:
  • Unauthenticated arbitrary URL fetch with response body relayed back, anyone on the internet can use Sarvam's backend as an open HTTP proxy.
  • Traffic laundering through Sarvam's egress IP (bypass IP allowlists at other targets, IP-reputation damage).
  • Bandwidth and egress-cost abuse.
  • Network reconnaissance from inside Sarvam's perimeter. Tested probes against 169.254.169.254 (AWS IMDS) and 127.0.0.1:80 returned "Failed to download content" / 502 timeouts, the fetch attempt clearly happens (no early Invalid download URL validator rejection), it just doesn't reach a service. Private/internal HTTP services that are reachable from this worker would be enumerable and readable.
  • No rate limit observed during testing.
• Fix:
  1. Parse the URL server-side and compare the canonical hostname (url.host) against a strict suffix allowlist, e.g. host.endswith(".blob.core.windows.net") AND specifically the Sarvam-owned storage account(s). Do not regex/substring-match the raw URL string.
  2. Reject any URL whose resolved IP is in RFC1918, link-local, loopback, or carrier-grade NAT ranges (resolve after parsing, then re-resolve at connect time to avoid DNS rebinding, or pin the connection to the resolved IP).
  3. Even better, drop the guest proxy entirely: have the upstream doc-digitization service issue short-lived SAS URLs the browser fetches directly.

Medium

• Type: Hardcoded write-credential leak in client bundle (telemetry ingestion key)
• Severity: Low, Medium (depends on SigNoz quota and what's pushed)
• URL/Endpoint: https://cdn.sarvam.ai/prod/sarvam-api-store/_next/static/chunks/*.js
• PoC: grep -h signoz-ingestion-key *.js →

  "signoz-ingestion-key":"Lhe-c7Td8qfmHLibYnVQOpBAdzc4Ci4ylYPr"
  

  Same value is sent on every page load: POST https://ingest.in.signoz.cloud/v1/traces with header signoz-ingestion-key: Lhe-c7Td8qfmHLibYnVQOpBAdzc4Ci4ylYPr.
• Impact: SigNoz ingestion keys grant write access to the tenant's traces/logs/metrics. An attacker can poison observability (false alerts, log injection covering an attack, attribute fake errors to legitimate services), and burn through the ingestion quota. Unlike Sentry DSNs, SigNoz ingestion keys are not consistently documented as "safe to expose", at minimum they should be scoped to a single signal type and rotated.
• Fix: Move browser telemetry through a same-origin reverse-proxy endpoint (e.g. /api/telemetry/traces) that injects the key server-side, or use a scoped/short-lived ingestion key per signal. Rotate the leaked key.

Low / Info

• Wide attack surface, 395 subdomains, several admin panels reachable argocd.*.sarvam.ai, harbor.*.sarvam.ai, vault.*.sarvam.ai, retool.internal.sarvam.ai, metabase.sarvam.ai, gitlab.strategic.sarvam.ai, terrateam.platform.sarvam.ai, flagsmith.platform.sarvam.ai, airflow*.sarvam.ai, signoz.*.sarvam.ai, internal-dashboard.sarvam.ai, dashboard-staging.sarvam.ai, etc. All require auth (Google SSO via NextAuth.js on internal-dashboard.sarvam.ai; Argo/Harbor login pages elsewhere). Recommendation: front these with a VPN / Cloudflare Access / Tailscale rather than relying on per-app auth, even one weak default credential or unpatched CVE on any of them becomes a foothold.

• Production JS references non-prod endpoints getApiBaseUrl() in the production bundle includes branches for localhost → https://api.azure-stage01.sarvam.ai and qa → https://api.azure-qa01.sarvam.ai. Not exploitable on its own but mildly leaks environment naming; consider tree-shaking environment branches out of the prod bundle.

• CSP allows script-src 'unsafe-inline' and unpkg.com unsafe-inline defeats most of CSP's XSS protection, and unpkg.com allows any npm package's script to be loaded. No actual XSS sink was found, so this is hardening advice, not an exploitable bug.

• JWT subject is the user's email dashboard_auth JWT uses sub: chavanritesh20@gmail.com. Not exploitable but unusual, if a user ever rotates their email, downstream services keyed on sub may desync. RS256 + HttpOnly + Secure + reasonable 24h expiry are otherwise solid.

What was tested and found clean

• JWT-none alg, JWT-HS256-with-public-key → both 401. Token verification correctly enforced.
• IDOR on /api/subscriptions/get, /api/subscriptions/getApiKeys, /api/subscriptions/usage/details with tampered subscription_id / api_key_id → server-side identity is taken from JWT; foreign IDs return empty result sets, never another user's data.
• DELETE / PUT / PATCH on usage endpoint → 405.
• Cookie scope, dashboard_auth is HttpOnly (not in document.cookie).
• Cookie-strip test → 401, no anonymous fallback.
• /api/admin, /api/debug, /api/healthcheck, /api/openapi.json, /api/swagger → 404.
• nuclei high/critical templates on dashboard.sarvam.ai → 0 findings.
• SigNoz key aside, no API keys, JWTs, or cloud credentials found in any of 22 downloaded JS chunks via trufflehog or pattern grep.

Recommended priorities

1. Patch the SSRF today, it's unauthenticated and trivially reproducible. (/api/guest/document-digitization/download-content)
2. Audit the other two guest routes (/api/guest/document-digitization/status/{jobId}, /api/guest/document-digitization/download-files/{jobId}) for the same proxy-the-user-input pattern. Job IDs are UUIDs (good) but verify the routes can't be used to fetch any internal job by guessing UUIDs returned to other guest sessions.
3. Move client telemetry behind a server proxy and rotate the SigNoz key.
4. Inventory the 395 subdomains and put non-customer-facing services behind a single auth gateway.

Continuing the dig. I'll explore the other guest endpoints (the playground supports 8 types), grep the bigger JS bundles for more endpoints, and probe a few admin panels.

Great catch. Per the triage rules I follow, an unauthenticated "Try it free" demo isn't a finding by design, but it becomes a critical issue if (a) the rate limit is enforced client-side only (localStorage), or (b) guest mode is wired to the same paid-tier models. Both are testable. Let me dig.

From the JS I've already pulled, guest-mode is intentional (ENABLE_GUEST_MODE = true, per-playground call caps from a PostHog feature flag, USAGE_LIMIT_REACHED events). The interesting bit is this code:

let I = useCallback(t => {
  C(e => {
    let s = e.usageCounts[t] + 1;
    f(a(t), s);                 // f = localStorage.setItem
    ...
  });
}, [w]);

f is a thin localStorage.setItem wrapper, and incrementUsage only updates localStorage, the client decides whether the cap is reached, not the server. That's a strong indicator the limit is bypassable. But I need to confirm the backend doesn't also enforce.

Plan: (1) pull more JS chunks so we have all 8 guest playground routes, (2) hit a guest TTS/LLM endpoint unauthenticated, (3) loop 50, 100 calls from one IP to see if a server-side limit kicks in, (4) one prompt to check if the same paid-tier model is served. I'll start with chunk discovery.