[CRITICAL] Persistent Infrastructure Metadata Leak & Regional Edge-Cache Bypass (arn1/fra1)
| Severity | INFORMATIONAL |
| CVSS | 9.3 CVSS:3.1/AV:N/PR:N/UI:N/S:C/C:H/I:L/A:N/AC:L |
| Vulnerability Type | Information Disclosure |
| Asset | *.jup.ag - Jupiter Domain |
| Endpoint | https://jup.ag/ |
Description
Steps to Reproduce
Impact
This exposure creates a "Shadow Admin" lateral-movement vector. It allows an attacker to map backend environment groups and target staging-internal build environments by bypassing the production Cloudflare Worker pipeline.
Attachments (2)
Activity
Hi @0x_audit, Thanks for taking the time to submit this report. We've reviewed the findings and wanted to walk through our assessment. The `x-vercel-id` header is a standard response header included by Vercel on all deployments - the value is a regional routing/trace identifier, not a build secret or internal credential. Its presence doesn't expose anything beyond which edge region served the request, which is already observable via standard network inspection. `cf-cache-status: DYNAMIC` indicates the response wasn't served from cache. This is expected behavior for certain content types and does not represent a cache bypass vulnerability. Regarding the accessible `.vercel.app` deployment URL - this follows Vercel's default naming convention for branch deployments and serves the same publicly available content as the production domain. No staging-only or internal content is exposed through this endpoint. We don't see a demonstrated path from these observations to the described "Shadow Admin" lateral-movement scenario. Knowing a Vercel region identifier and a branch deployment URL does not provide access to internal environments, backend infrastructure, or privileged functionality. For these reasons we're closing this report as **Informational**. The CVSS score of 9.3 doesn't align with the actual impact - no sensitive data is disclosed and there's no cross-boundary impact. We appreciate you flagging it and encourage you to keep looking. If you find a scenario where this information can be chained into concrete unauthorized access, we'd be happy to take another look. Best, Jupiter Security
