PocketMine-MP server crash due to incorrect EC curve used for LoginPacket identityPublicKeyGHSA-79rc-jjh6-rc89
HIGHFix: pmmp/PocketMine-MP@4e646d1GHSA-79rc-jjh6-rc89 is a high-severity (CVSS 7.5) CWE-347 vulnerability in pocketmine/pocketmine-mp. A fix is available for pocketmine/pocketmine-mp — see the affected versions and patch details below.
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-79rc-jjh6-rc89.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
Real-World Exposure
pocketmine/pocketmine-mpReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
Impact
The server uses ECDH to calculate a shared secret for the symmetric encryption key used to encrypt network packets after logging in. ECDH requires that the keys used must both belong to the same elliptic curve. In Minecraft: Bedrock Edition, the curve used is secp384r1.
Using any other curve (for example secp256r1) to sign the LoginPacket JWTs would lead to successfully verifying the login chain, but would later crash due to an uncaught exception during ECDH key derivation due to the client-provided key belonging to a different curve than the server's key. It's also theoretically possible that a non-EC key could be used (e.g. RSA or DH), which would also pass login verification as long as SHA384 hashing algorithm was used for the JWT signatures, and also lead to a crash.
Patches
The problem was fixed in 4.23.1 and 5.3.1 in the following commit: 4e646d19a4a1e0d082bd4d1f5a58ae0182a268d9 While 4.x would not have crashed when this was encountered, the faulty validation code has also been corrected there.
Workarounds
A plugin could handle LoginPacket and check that all of the identityPublicKeys provided in the JWT bodies actually belong to secp384r1. This can be checked by verifying that openssl_pkey_get_details($key)["ec"]["curve_name"] is set and equal to secp384r1. Beware that this element may not exist if the key is not an EC key at all.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | pocketmine/pocketmine-mp | ≥ 5.2.0&&< 5.3.1 | 5.3.1composer require pocketmine/pocketmine-mp:^5.3.1 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for pocketmine/pocketmine-mp, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update pocketmine/pocketmine-mp to 5.3.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-79rc-jjh6-rc89 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
Frequently Asked Questions
Is GHSA-79rc-jjh6-rc89 in your dependencies?
Find it across Packagist, including transitive dependencies.