GHSA-g7m4-839x-ch6v
GHSA-g7m4-839x-ch6v is a remote code execution vulnerability in spomky-labs/otphp. O3 Security confirms whether GHSA-g7m4-839x-ch6v is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
spomky-labs/otphp: Unbounded digits parameter in a provisioning URI triggers an uncaught DivisionByZeroError in OTP generation
Real-World Exposure
spomky-labs/otphpReal-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
Summary
The digits parameter parsed from a provisioning URI is validated only with a lower bound ($value > 0) and has no upper bound (src/OTP.php:353-357). OTP generation computes $code % (10 ** $this->getDigits()) (src/OTP.php:283). When digits is large enough that 10 ** digits overflows PHP's integer range and the (int) cast yields 0 (around digits >= 40 on 64-bit PHP 8.x), the modulo operand becomes 0 and PHP raises a DivisionByZeroError.
Impact
OTPHP\Factory::loadFromProvisioningUri() forwards the attacker-controlled digits query value to setParameter('digits', $value), so a hostile URI such as otpauth://totp/Alice?secret=JBSWY3DPEHPK3PXP&digits=50 produces an OTP object whose at(), now(), and verify() all throw DivisionByZeroError. Because DivisionByZeroError extends Error (not Exception), callers that guard OTP generation with a catch (\Exception) do not catch it, turning a malformed URI into an unhandled fatal error (denial of service of the verification path).
Measured threshold on PHP 8.3: digits = 30 works, digits >= 40 throws DivisionByZeroError: Modulo by zero.
Affected component
src/OTP.php:353-357—digitsparameter callback (no upper bound)src/OTP.php:283—$code % (10 ** $this->getDigits())
Proof of concept
use OTPHP\Factory;
use OTPHP\InternalClock;
$otp = Factory::loadFromProvisioningUri(
'otpauth://totp/Alice?secret=JBSWY3DPEHPK3PXP&digits=50',
new InternalClock()
);
$otp->at(0); // DivisionByZeroError: Modulo by zero (escapes catch (\Exception))
Remediation
Enforce a sane upper bound on digits in the parameter validation callback (e.g. reject values above 8–10, the practical range for OTPs) so that an out-of-range value is rejected with a documented exception instead of producing an object that fails later with an uncatchable Error.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | spomky-labs/otphp | all versions | 11.4.3 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for spomky-labs/otphp. 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 spomky-labs/otphp to 11.4.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-g7m4-839x-ch6v 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-g7m4-839x-ch6v 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-g7m4-839x-ch6v. 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-g7m4-839x-ch6v in your dependencies?
O3 detects GHSA-g7m4-839x-ch6v across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.