Vercel disclosed CVE-2025-46332, a medium-severity information-disclosure flaw in its Flags SDK that exposed feature-flag definitions to unauthenticated requests. The CVSS 6.5 vulnerability let anyone enumerate flag names, descriptions, options, and defaults through a well-known discovery endpoint. Vercel patched it in flags@4.0.0 and deployed an automatic network-level mitigation on its platform, but the mitigation leaves gaps for Pages Router deployments and custom endpoint paths. Less than a week before this writing, a separate Vercel CLI token-leak CVE (CVE-2026-44479) surfaced, making two credential-and-metadata exposure bugs in the same vendor’s toolchain within a short window.
What the endpoint exposed
The Flags SDK serves a discovery endpoint at /.well-known/vercel/flags (and /api/vercel/flags under Pages Router). Prior to the patch, the verifyAccess function in the SDK did not adequately enforce authentication on that endpoint. According to Vercel’s security advisory (GHSA-892p-pqrr-hxqr), a malicious actor could enumerate all flags and read:
- Flag names
- Descriptions
- Available options with labels (for example,
true/false) - Default values
The advisory is careful to note that flag providers and customer data were not accessible. The exposed surface was metadata: the schema of the flag system, not the runtime evaluation of individual user sessions.
OpenCVE rates this CVSS v3.1 6.5 Medium (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N), classified as CWE-200, with an EPSS probability of 0.3%. No authentication, no user interaction, network-adjacent. CISA’s ADP assessment rates it automatable but with no confirmed exploitation as of the disclosure date.
Why flag metadata is reconnaissance-grade material
Vercel’s advisory characterizes the exposure as “limited to flag names, descriptions, options, default values.” That framing is technically accurate but understates the second-order risk. Feature-flag systems in production use encode operational decisions that teams often treat as private:
- Unreleased products. A flag named
new_payment_flow_enabledwith a description and rollout percentage tells an observer what is being built and how far along the rollout is. - Gradual-rollout cohorts. Flags that gate features by user segment, geography, or plan tier reveal the segmentation logic itself.
- Security kill switches. Flags like
disable_legacy_authorenforce_rate_limiting_v2expose which security controls exist and, by absence, which ones do not.
The assumption behind server-evaluated feature flags has been that the evaluation logic stays on the server. The client receives a boolean or variant value, not the decision tree that produced it. CVE-2025-46332 breaks that assumption: the decision tree’s schema was served alongside the result, to anyone who asked the well-known endpoint.
This is a reconnaissance problem, not a data-exfiltration problem. An attacker does not get customer records or session tokens. They get a map of the product’s nervous system: what it controls, what it is testing, and where the switches are. For a targeted attacker performing recon against a Vercel-hosted application, that map is high-value intelligence that costs almost nothing to collect.
Where the automatic mitigation falls short
Vercel deployed an automatic network-level mitigation that blocks the default discovery endpoint (/.well-known/vercel/flags) on its platform. That mitigation covers the common case for App Router deployments. According to Vercel’s changelog, it does not cover:
- Pages Router deployments, which use
/api/vercel/flagsas the endpoint path. - Custom endpoint paths, for teams that configured the SDK with a non-default route.
Self-hosted deployments or any setup that does not sit behind Vercel’s edge network gets no benefit from the automatic block. For those cases, the only remediation is upgrading the SDK package itself.
The advisory also notes that Flags Explorer UI is disabled and displays a warning notice until teams upgrade to flags@4.0.0, which further reduces the exposure surface for developers who use the UI tool.
The fix and the package migration
The patch lives in flags@4.0.0, which hardens the verifyAccess function to properly enforce authentication before serving flag definitions. The advisory instructs users of the older @vercel/flags package (≤ 3.1.1) to migrate to the unified flags package. A major-version bump signals breaking changes, so teams upgrading should expect possible API adjustments beyond the security patch itself.
The affected version range is flags ≤ 3.2.0 and @vercel/flags ≤ 3.1.1. Teams still on either of those packages and running on Pages Router, custom endpoints, or self-hosted infrastructure should treat this as an active exposure rather than a theoretical one.
The architectural lesson: flag definitions are secrets
The pattern here is not unique to Vercel. Feature-flag systems across vendors tend to treat flag metadata as configuration data rather than sensitive data. Access controls on flag definitions are often weaker than access controls on the features those flags gate. The result is a consistent gap: a flag that controls whether a user sees a paywalled feature or passes through an authentication check may itself be described in a schema that anyone can read.
CVE-2025-46332 makes that gap visible. So does CVE-2026-44479, the Vercel CLI vulnerability disclosed June 4, 2026 that leaked plaintext --token values in JSON suggestedCommand payloads during non-interactive runs, patched in CLI v52.0.1. Two different mechanisms, two different CVSS scores, but the same class of problem: tooling that handles credentials and operational metadata assumed those values would not be observed in transit.
The fix for CVE-2025-46332 is specific and straightforward: upgrade the package. The broader remediation is to audit what your flag system exposes at its discovery endpoints, and to apply access policies to flag definitions that match the sensitivity of the features they control. If a flag name would be embarrassing or dangerous in an attacker’s hands, it should not be served without authentication, regardless of what the SDK’s defaults permit.
Frequently Asked Questions
Is there evidence of active exploitation for CVE-2025-46332?
No confirmed exploitation exists as of disclosure. The CVE is absent from CISA’s Known Exploited Vulnerabilities catalog, and CISA’s ADP assessment rates exploitation as ‘none’ and technical impact as ‘partial,’ despite flagging it as automatable. The EPSS probability sits at roughly 0.3 percent, in the low-prediction tier. Automatable means the barrier to weaponization is low, though: a single unauthenticated GET request to the discovery endpoint is sufficient to enumerate the full flag schema.
How does the Flags SDK disclosure differ from CVE-2026-44479, the Vercel CLI token leak?
They leak different asset classes through different mechanisms. CVE-2025-46332 (CVSS 6.5) exposes flag metadata schemas through an unprotected discovery endpoint. CVE-2026-44479 (CVSS 5.5) leaks plaintext authentication tokens via JSON suggestedCommand payloads when the CLI runs in non-interactive mode, patched in CLI v52.0.1. One hands an attacker a map of your product’s feature controls; the other hands them the credentials to act on it. Both stem from the same assumption that tooling intermediaries would not expose sensitive values in transit.
What can teams do if upgrading to flags@4.0.0 requires a longer migration window?
Block the discovery endpoint paths at the WAF or reverse-proxy layer: both /.well-known/vercel/flags and /api/vercel/flags should return 403 for unauthenticated requests. Rename flags whose identifiers directly reference security controls, unreleased features, or internal project codenames. Audit flag descriptions for information that would aid reconnaissance. The Flags Explorer UI is already disabled for vulnerable versions, which removes one internal exposure surface during the transition.
Does the low EPSS score mean teams can safely deprioritize this patch?
EPSS predicts the probability of observed exploitation within 30 days, not the consequences of exploitation. A 0.3 percent score is low for broad internet scanning but says nothing about targeted attacks against a specific organization. CISA ADP rates the vulnerability as automatable, meaning exploitation requires no special access or user interaction once an attacker identifies a target. Teams whose flag definitions expose security controls or unreleased product plans face higher operational risk than the EPSS score reflects, because the value of the disclosed information is specific to the target, not generic.