Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐘 Packagist
Not in CISA KEV

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

Published
Jun 18, 2026
Updated
Jun 18, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Jun 18, 2026 · OSV.dev, FIRST.org (EPSS)

Real-World Exposure

1 pkg affected
🐘spomky-labs/otphp

Real-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-357digits parameter 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

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐘Packagistspomky-labs/otphpall versions11.4.3

Detection & mitigation playbook

Open-source dependency
  1. Detect

    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.

  2. 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.

  3. 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.

  4. 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

## 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(
O3 Security · Impact-Aware SCA

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.

GHSA-g7m4-839x-ch6v: spomky-labs/otphp… | O3 Security