GHSA-2JX3-65F3-XR8R

spomky-labs/otphp: Mass-assignment in Factory::loadFromProvisioningUri lets a hostile provisioning URI corrupt OTP state or leak an uncaught TypeError

use OTPHP\Factory;

// State corruption
$otp = Factory::loadFromProvisioningUri(
    'otpauth://totp/Alice?secret=JBSWY3DPEHPK3PXP&parameters[foo]=bar',
    $clock
);
$otp->getProvisioningUri(); // ParameterNotFoundException: Parameter "period" does not exist

// Uncaught TypeError
Factory::loadFromProvisioningUri(
    'otpauth://totp/Alice?secret=JBSWY3DPEHPK3PXP&issuer_included_as_parameter=notabool',
    $clock
); // TypeError escapes InvalidProvisioningUriException

The Factory is documented as the entry point for third-party provisioning URIs (e.g. QR codes from Microsoft 365 / Google Authenticator). An application that loads such a URI is exposed to:

• State corruption. A URI such as otpauth://totp/Alice?secret=JBSWY3DPEHPK3PXP&parameters[foo]=bar overwrites the whole internal $parameters array that createFromSecret() primed (period, algorithm, digits, epoch). The resulting object is silently unusable: getProvisioningUri(), getDigits(), at(), verify() then throw ParameterNotFoundException.
• Uncaught TypeError escaping the documented exception type. A URI such as otpauth://totp/Alice?secret=JBSWY3DPEHPK3PXP&issuer_included_as_parameter=notabool assigns a string to a typed bool property and raises a TypeError. The try/catch in loadFromProvisioningUri() only wraps Url::fromString(); createOTP() and populateOTP() run outside it, so the TypeError (and Error on the readonly clock) escapes past the documented InvalidProvisioningUriException, breaking callers that catch only the documented type.
• Label/issuer validation bypass. parameters[label]=hijacked stores a label into the parameters array without running the label validation callback (keyed on label, not parameters). getLabel() and getParameter('label') then disagree, a confused-deputy risk.

Kodem intelligence

Already deployed Kodem?

Restrict the keys accepted from a provisioning URI to a known allow-list of public OTP parameters, and never let a URI key resolve to an internal object property via property_exists. Route all URI-sourced values through the validated parameter map only.

1. What is GHSA-2JX3-65F3-XR8R? GHSA-2JX3-65F3-XR8R is a medium-severity security vulnerability in spomky-labs/otphp (composer), affecting versions < 11.4.3. It is fixed in 11.4.3.
2. Which versions of spomky-labs/otphp are affected by GHSA-2JX3-65F3-XR8R? spomky-labs/otphp (composer) versions < 11.4.3 is affected.
3. Is there a fix for GHSA-2JX3-65F3-XR8R? Yes. GHSA-2JX3-65F3-XR8R is fixed in 11.4.3. Upgrade to this version or later.
4. Is GHSA-2JX3-65F3-XR8R exploitable, and should I be worried? Whether GHSA-2JX3-65F3-XR8R is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
5. What actually determines whether GHSA-2JX3-65F3-XR8R is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
6. How do I fix GHSA-2JX3-65F3-XR8R? Upgrade spomky-labs/otphp to 11.4.3 or later.

Other vulnerabilities in spomky-labs/otphp