GHSA-h38w-h2gf-6qv2: 
PHP vulnerability analysis and mitigation

Summary

OTP::validateLabel() must refuse a label whose issuer or account name contains a colon (:, %3A or %3a) besides the single separator. Before it looks for that second colon, it strips the optional leading %20 of the account name with ltrim($accountPart, '%20'). ltrim() takes a list of characters, not a prefix, so it removes every leading %, 2 and 0. For Provider:%3Aname the check sees 3Aname and accepts the label, while Provider:x%3Aname is rejected.

Impact

A label like this can be stored instead of being refused with the documented InvalidLabelException (or InvalidProvisioningUriException from the factory). That applies to whoever supplies a provisioning URI to Factory::loadFromProvisioningUri(), with label=Provider%3A%253Aname in the query or Provider%253A%253Aname in the path. It also applies to whoever supplies an account name that the application passes to setLabel() or withLabel(). Inside the library the effect is nil. The %3A is never decoded. getProvisioningUri() and getQrCodeUri() refuse any label that contains a colon. at(), now() and verify() do not use the label. An application is affected only if it percent-decodes the value returned by getLabel() and relies on the library's colon rule to split the issuer from the account name.

Affected component

• src/OTP.php:464 in 11.4.3, src/OTP.php:489 in 11.5.0: the ltrim($accountPart, '%20') call in OTP::validateLabel() Introduced in 11.4.0 (commit d3593de, "Fix label validation to comply with Google Authenticator spec (#248)").

Proof of concept

use OTPHP\HOTP;
$otp = HOTP::createFromSecret('JBSWY3DPEHPK3PXP');
$otp->setLabel('Provider:x%3Aname'); // InvalidLabelException, as expected
$otp->setLabel('Provider:%3Aname');  // accepted

Remediation

Fixed in 11.4.4 and 11.5.1: the account part is now checked without the trim. Labels that were valid, such as Provider:%20name or Provider:2020, are still accepted.

Workarounds

Do not percent-decode the label returned by getLabel(), or validate the decoded value in the application.

Credits

Reported by Anthropic's OSS Scanner (finding ANT-2026-A3E01AZK).