Parse Server CVE-2025-67727

Exploitation requires the target repository (parse-community/parse-server, or any public fork with GitHub Actions enabled) to run the vulnerable ci-performance.yml workflow that is triggered by 'pull_request_target' and granted pull-requests:write / issues:write permissions plus secret access. An attacker must be able to open a pull request from a fork whose code or lifecycle scripts are then executed within the base-repository context. Limiting factors: the impact is confined to the repository's CI/CD infrastructure and secrets - it does NOT affect runtime Parse Server deployments; it depends on the specific workflow configuration present only before version 8.6.0-alpha.2; and it requires the workflow to actually execute untrusted fork-supplied code under the elevated trigger.

This is a CI/CD supply-chain weakness, not a flaw in deployed Parse Server instances. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) with low confidentiality and integrity impact (VC:L/VI:L) yields a MEDIUM score of 6.9, which is consistent with the description: a GitHub Actions workflow (ci-performance.yml) triggered via 'pull_request_target' runs with the base repository's elevated GITHUB_TOKEN (pull-requests: write, issues: write) and secrets while potentially executing code supplied by a fork's pull request. EPSS is low at 0.42% (34th percentile) and the CVE is NOT in CISA KEV, indicating no evidence of mass exploitation. There is no POC referenced - only patch commits and the GHSA advisory - so exploitation status is: no public exploit identified at time of analysis. The 'RCE' tag overstates the real impact: this does not grant code execution on production Parse Server deployments, only on the project's own CI runners. Net priority is LOW-to-MEDIUM and essentially nil for anyone merely consuming Parse Server as a dependency; it is relevant only to maintainers/forks of the parse-community/parse-server repository. One signal to verify: the vendor rated confidentiality as only VC:L despite the workflow exposing repository secrets, which could arguably justify higher confidentiality impact - defenders mirroring this CI pattern should treat secret exposure as a serious outcome regardless of the rated metric.

An attacker forks the parse-server repository and opens a pull request containing malicious lifecycle scripts or code. Because the ci-performance.yml workflow uses the 'pull_request_target' trigger, it executes in the context of the base repository with write-scoped GITHUB_TOKEN and access to secrets, allowing the fork-supplied code to steal those secrets or push changes. No public exploit code is referenced, but the pull_request_target misconfiguration class is well-documented and trivially reproducible.