spomky-labs/otphp: Unbounded digits parameter in a provisioning URI triggers an uncaught DivisionByZeroError in OTP generationGHSA-g7m4-839x-ch6v
GHSA-g7m4-839x-ch6v is a remote code execution vulnerability in spomky-labs/otphp. A fix is available for spomky-labs/otphp — see the affected versions and patch details below.
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.3composer require spomky-labs/otphp:^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, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
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
Stop feeding it untrusted input: reject or quarantine files and payloads from unverified sources until you can upgrade, restrict accepted formats to the ones you actually need, and run the parsing or decoding step in a least-privileged sandbox or short-lived worker so a crash or corrupted read cannot reach the rest of the process.
Frequently Asked Questions
Is GHSA-g7m4-839x-ch6v in your dependencies?
Find it across Packagist, including transitive dependencies.