Horizon Alert
Summary of the vulnerability and why it matters
This advisory concerns a critical vulnerability in MongoDB Server's replication component, potentially allowing for unexpected server termination or code execution. The issue arises during the catch-up process of a newly elected primary in a replica set, and it can be triggered by unauthenticated requests. While standalone instances are unaffected, this vulnerability impacts replica set members within sharded clusters, including shard and config servers. The main concern is confirming relevance and exposure given that MongoDB is typically run in protected internal networks.
- Software can unexpectedly stop or execute code.
- Affects MongoDB replica sets, not standalone systems.
- Confirm relevance and potential impact within your environment.
Attack Path
How an attacker could exploit the issue
An attacker could reach a vulnerable MongoDB Server through network requests that do not require authentication. If a replica set primary is in the process of catching up, these requests could trigger a use-after-free condition within the replication component. This may lead to the server crashing or, in some scenarios, arbitrary code execution.
- Network access required.
- Triggered during primary catch-up.
- May cause server termination or code execution.
Live Threat
Current exploitation, exposure, and threat context
A use-after-free vulnerability in MongoDB Server's replication component could lead to unexpected server termination or, in supported configurations, arbitrary code execution. This occurs when a newly elected replica set primary performs a catch-up operation, potentially triggered by unauthenticated requests. Only replica set members are affected, not standalone instances.
- Replica set members could be terminated.
- Unauthenticated requests may trigger the flaw.
- Arbitrary code execution is possible.
Operational Fix
Recommended remediation, mitigation, and detection steps
The replication component of MongoDB Server is susceptible to a use-after-free vulnerability when an elected primary completes catch-up, potentially leading to unexpected termination or arbitrary code execution. Given that replica set members are affected, including sharded cluster components, the primary owners are likely the database administration or platform teams responsible for MongoDB deployments. The initial step should be to inventory all MongoDB replica sets, confirm network reachability and business criticality, identify the accountable owner, and then plan remediation, coordinating with vendor management if necessary.
- Database or platform teams should own.
- Verify replication set reachability and criticality.
- Plan remediation based on identified risk.