GHSA-g274-c6jj-h78p
MEDIUMPocketMine-MP allows malicious client data to waste server resources due to lack of limits for explode()
Blast Radius
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
Due to lack of limits by default in the explode() function, malicious clients were able to abuse some packets to waste server CPU and memory.
This is similar to a previous security issue published in https://github.com/pmmp/PocketMine-MP/security/advisories/GHSA-gj94-v4p9-w672, but with a wider impact, including but not limited to:
- Sign editing
- LoginPacket JWT parsing
- Command parsing
However, the estimated impact of these issues is low, due to other limits such as the packet decompression limit.
Patches
The issue was fixed in 5.25.2 via d0d84d4c5195fb0a68ea7725424fda63b85cd831.
A custom PHPStan rule has also been introduced to the project, which will henceforth require that all calls to explode() within the codebase must specify the limit parameter.
Workarounds
No simple way to fix this.
Given that sign editing is the easiest way this could be exploited, workarounds could include plugins pre-processing BlockActorDataPacket to check that the incoming text doesn't have more than 4 parts when split by \n.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | pocketmine/pocketmine-mp | all versions | 5.25.2 |
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. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update pocketmine/pocketmine-mp to 5.25.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-g274-c6jj-h78p 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.
How O3 protects you
O3 pinpoints whether GHSA-g274-c6jj-h78p is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-g274-c6jj-h78p. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-g274-c6jj-h78p in your dependencies?
O3 detects GHSA-g274-c6jj-h78p across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.