CVE-2021-47987: Parse Server Supply Chain Incident – Unauthorized Git Tags and Code Integrity Risk

Technical summary

CVE-2021-47987 involves a supply chain compromise in Parse Server where incorrect version tags (e.g., 4.9.3) were pushed to the official repository pointing to a personal fork rather than the main codebase. These tags referenced code that bypassed the project's normal review and approval process. While security analysis did not identify confirmed malicious payloads, the lack of code review meant potential security vulnerabilities could not be excluded. The vulnerability is classified as CWE-494 (Download of Code Without Integrity Check), reflecting the core risk of consuming unvetted dependencies.

Business impact

Organizations relying on Parse Server via git-based dependency specifications face potential compromise of their infrastructure and data. The incident affects build pipelines and application integrity, not just running instances. Supply chain incidents of this nature erode trust in infrastructure dependencies and require incident investigation to determine whether compromised tags were actually pulled into production builds. Remediation involves both identifying affected deployments and re-securing repository access controls to prevent recurrence.

Affected systems

Parse Server versions prior to 4.10.0 are technically affected. However, actual risk is limited to projects that explicitly defined git-based dependencies referencing the compromised tags (e.g., parse-server#4.9.3 in package.json or equivalent). Organizations pinning to released versions via npm or other package managers, or using version ranges that exclude the affected tags, are not exposed. The lack of published releases with these tags significantly limits the blast radius.

Exploitability

Exploitation was not a requirement for harm; the risk model is passive consumption of unreviewed code. An attacker with write access to a contributor's fork could have injected vulnerabilities before tags were pushed. The CVSS score of 7.5 (HIGH) reflects network-accessible impact and the combination of confidentiality, integrity, and availability risks, though exploitation depends on whether developers actually fetched the malicious tags. The requirement for user interaction (UI:R in the vector) likely refers to developer actions such as running builds with the affected dependency.

Remediation

Immediately audit your build configurations and dependency manifests to identify any references to the affected Parse Server tags. If your project uses git-based pinning to Parse Server, migrate to a fixed release version (4.10.0 or later) as specified in the vendor advisory. Conduct a code review of any builds that may have pulled from the compromised tags. Additionally, verify repository security settings: ensure contributor write access is monitored, enforce code review requirements before merging, and consider using branch protection rules to prevent tag manipulation.

Patch guidance

Upgrade Parse Server to version 4.10.0 or later. If using git-based dependencies, update your dependency specification (e.g., in package.json) from a tag reference to an explicit version constraint or a specific commit hash on the main branch post-remediation. Verify the upgrade in your development environment and re-run your build pipeline to ensure no cached compromised artifacts remain. Check the Parse Server security advisory for any additional remediation steps or monitoring recommendations.

Detection guidance

Search your git history and build logs for any fetch or clone operations from the affected Parse Server tags (e.g., 4.9.3). Review npm-shrinkwrap.json, yarn.lock, or package-lock.json files for resolved URLs pointing to the git repository with those tags. Monitor your artifact repository for builds generated between the tag push and the discovery of this incident. If you use software composition analysis (SCA) tools, ensure they flag git-based dependencies and alert when upstream repositories experience access control changes or unexpected tag pushes.

Why prioritize this

This vulnerability warrants rapid assessment despite its supply chain nature. The HIGH CVSS score reflects the potential for wide-ranging impact if malicious code was injected. However, practical risk depends on whether your organization actually used the affected tags—many teams will be unaffected. Prioritize auditing your build configurations and dependency locks first; if you do not reference the specific tags, remediation is straightforward. For those who do, immediate upgrade and code review of built artifacts is critical.

Risk score, explained

The CVSS 3.1 score of 7.5 reflects a network-accessible attack vector with high confidentiality, integrity, and availability impact. The 'AC:H' (Attack Complexity High) component accounts for the dependency on a specific build configuration or developer action. The 'UI:R' component indicates reliance on user interaction—in this case, a developer choosing to fetch and use the malicious tag. The score appropriately captures the severity of code injection at build time while acknowledging that actual exposure is limited to projects with direct references to the compromised tags.

Frequently asked questions