Parse Dashboard CVE-2026-27608

Exploitation requires the dashboard to have the optional agent configuration block enabled (POST /apps/:appId/agent must exist) - dashboards without an agent config are not affected at all. The attacker must hold a valid authenticated dashboard session (PR:L), but only at low privilege: either a user scoped to a different app, or a read-only user. Given those, no further conditions apply - the attacker simply changes the app ID in the URL for cross-tenant access, or supplies write permissions in the request body to escalate read-only access to write/delete. Limiting factors that reduce real-world risk: the agent feature must be explicitly configured, the attacker needs existing authenticated access, and all affected builds are alpha pre-releases rather than stable releases.

Signals conflict in an instructive way. The CVSS 4.0 base score is 9.3 (Critical) with AV:N/AC:L/AT:N/PR:L/UI:N and high vulnerable- and subsequent-system confidentiality/integrity impact, reflecting easy network exploitation by a low-privileged authenticated user with cross-tenant (scope-changing) reach. Against that, EPSS is only 0.03% (7th percentile), the CVE is not on CISA KEV, and no public exploit code is identified, so there is no evidence of active or imminent mass exploitation. The reconciling factor is the precondition: only dashboards that have the optional agent configuration block enabled are affected, which sharply narrows the exploitable population and explains the low EPSS despite the high CVSS. This is a genuine high-priority issue for any multi-tenant or read-only-delegated Parse Dashboard deployment using the agent feature, but a non-issue for the majority of deployments that never enable agent. Note also that all affected versions are alpha pre-releases, further limiting real-world exposure.

A low-privileged or read-only user who has legitimate dashboard access to one Parse app (or a tenant in a shared dashboard) sends a POST to /apps/{otherAppId}/agent, swapping in an app ID they should not control. Because the endpoint skips authorization and provisions the full master key, the request executes against the targeted app, and by including write permissions in the body the attacker reads, modifies, or deletes other tenants' data despite their read-only role. No public proof-of-concept is identified, but the attack requires only standard authenticated access and a trivial URL/body change (AC:L, UI:N).