← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-46473 · CWE-331 · Disclosed 2026-05-21

Authen::TOTP versions before 0

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

Like using a cheap bike lock factory key instead of cutting a unique key for each user

CVE-2026-46473 affects Authen::TOTP for Perl before 0.1.1. The issue is not in TOTP math or verification; it is in *secret generation* during enrollment. Vulnerable releases generate new shared secrets with Perl's built-in rand, and 0.1.1 replaces that with Crypt::PRNG::random_string_from(). Practically, only secrets *created* by vulnerable versions are suspect; already-enrolled users remain at risk until those secrets are rotated or the users are re-enrolled.

The vendor's HIGH 7.5 score overstates operational risk by treating this like an unauthenticated network bug. In the real world, this is a library flaw that requires the target app to use the vulnerable module, rely on its default secret generation path, and expose an attacker to enough enrollment context to predict or narrow the generated secret. That is a meaningful security defect for MFA workflows, but it is *post-architecture* risk, not broad internet worm food.

"This is a real MFA-weakening bug, but it is not a remotely exploitable host-takeover event."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Find an application that actually uses Authen::TOTP for enrollment

The attacker first needs a target service built in Perl that includes Authen::TOTP and uses the module's secret-generation routine during MFA setup. There is no generic network fingerprint for this library, so this step usually depends on source disclosure, package inventory, SBOMs, stack traces, or prior knowledge of the application.
Conditions required:
  • Target application is written in Perl
  • Application imports Authen::TOTP
  • Application uses module-generated secrets instead of a stronger app-side generator
Where this breaks in practice:
  • This is a library, not a bannered network service
  • Shodan/Censys-style discovery is largely blind to module versioning
  • Many apps may set their own secrets and never call the vulnerable path
Detection/coverage: External scanners are weak here; SBOM/SCA, package inventory, or host-level Perl module enumeration are the reliable detection paths.
STEP 02

Observe or influence MFA enrollment timing with a bespoke PRNG-analysis script

A real exploit path needs more than the CVE text: the attacker must model or constrain the output of Perl rand at the time a victim secret was created. With no public exploit kit found in authoritative sources, this likely means a custom script derived from the patch diff and Perl PRNG behavior, plus telemetry such as enrollment timestamps, process behavior, or repeated self-enrollment attempts.
Conditions required:
  • Attacker can observe enrollment events or create many enrollments
  • Attacker can approximate seed/state inputs well enough to shrink the search space
Where this breaks in practice:
  • No authoritative public PoC or turnkey exploit was found
  • Seed/state recovery is app- and environment-dependent
  • Modern deployments often add noise via worker pools, containers, and concurrent requests
Detection/coverage: Likely invisible to vulnerability scanners. Watch for abnormal MFA enrollment bursts, repeated account self-registration, or repetitive TOTP validation failures around newly enrolled users.
STEP 03

Recover or brute-force candidate TOTP seeds

Once the attacker narrows the PRNG space, they generate candidate shared secrets and derive matching TOTP codes. The impact is limited to accounts whose seeds were minted by the vulnerable code path; this is not a universal break of all TOTP implementations.
Conditions required:
  • Victim account enrolled while vulnerable code was active
  • Predicted secret candidate set is small enough to test
Where this breaks in practice:
  • Older or externally provisioned secrets are out of scope
  • Rate limiting and anomaly detection on OTP validation can kill online testing
  • Any secondary control such as WebAuthn backup requirements reduces payoff
Detection/coverage: Authentication telemetry can catch repeated OTP guesses, but purely offline seed reconstruction has no direct network signature.
STEP 04

Use the recovered seed to bypass the MFA factor

If the correct secret is recovered, the attacker can produce valid TOTPs for the affected account and defeat that second factor. From there, impact depends entirely on what the compromised account can reach; the CVE does not itself grant code execution or lateral movement.
Conditions required:
  • Attacker already has or can obtain the victim's first factor, session, or another way to reach MFA step-up
  • Recovered seed belongs to a useful account
Where this breaks in practice:
  • This often still requires credential theft, session theft, or a password reuse path
  • Blast radius is account-level, not host-level
  • Organizations using phishing-resistant MFA for privileged users blunt the worst-case outcome
Detection/coverage: Identity logs, impossible travel, new device enrollment, and MFA-method analytics are more useful than network IDS here.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo evidence of active exploitation found in the supplied intel, and CVE-2026-46473 is not in CISA KEV.
PoC availabilityNo authoritative public PoC or weaponized repo was found in the vendor advisory, patch, or MetaCPAN references; expect bespoke exploit development if anyone pursues this.
EPSS0.00014 from the supplied intel — effectively basement-level probability compared with internet-facing mass-exploitation CVEs.
KEV statusNot KEV-listed per the supplied intel; no CISA exploitation urgency signal.
CVSS vector reality checkVendor vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N assumes a clean unauthenticated network path. That misses the real prerequisites: vulnerable app usage, enrollment-path reachability, and seed predictability.
Affected versionsAuthen::TOTP before 0.1.1. MetaCPAN shows 0.1.1 released on 2026-05-18 and prior vulnerable versions including 0.1.0 and earlier.
Fixed versionUpgrade to 0.1.1 or later. The fix swaps insecure secret generation for Crypt::PRNG::random_string_from().
Exposure/scanning realityThis is not directly internet-fingerprintable. Shodan/Censys/FOFA-style exposure counts are not meaningful because the vulnerable component is a Perl library inside an application, not a standalone service banner.
Disclosure timelineSecurity disclosure landed on 2026-05-21 via oss-security; MetaCPAN changelog shows the patch was released on 2026-05-18.
Reporter / maintainer trailReported via the CPAN Security Group on oss-security by Robert Rothenberg; patch authored by Athanasios Chatziathanassiou in the upstream repository.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (4.6/10)

The decisive downgrading factor is attacker position and exploit friction: this is a weak-secret-generation bug in a Perl library, not a generic unauthenticated remote exploit against a widely fingerprintable service. It matters because it can undercut MFA enrollment, but the reachable population is narrow and the attacker still needs a realistic path to predict or capitalize on those generated secrets.

HIGH Affected version range and fixed version
MEDIUM Real-world exploitability assessment
HIGH Downgrade from vendor CVSS network framing

Why this verdict

  • Downward adjustment: requires actual library usage — the vulnerable component is a Perl module embedded in an app, so only deployments that both include Authen::TOTP and use its secret generator are exposed.
  • Downward adjustment: poor external reachability — this is not broadly internet-discoverable like a VPN, appliance, or web server banner; exposure depends on internal package inventory, not internet census data.
  • Downward adjustment: exploit chain needs more than the CVE — an attacker must model or constrain Perl rand output around enrollment time, and no authoritative public PoC or mass exploitation evidence was found.
  • Downward adjustment: blast radius is account-scoped — success compromises TOTP seeds for affected enrollments, not the host or application stack directly.
  • Upward adjustment: it targets MFA trust — if a high-value internet-facing application uses this module for user enrollment, the bug can silently weaken second-factor protection for newly enrolled accounts.

Why not higher?

It is not higher because the vendor vector treats the bug as if the network itself exposes a one-click exploit path. In practice, the attacker usually needs a specific Perl application, the vulnerable enrollment flow, enough context to predict secrets, and then another path to benefit from the recovered seed. That is too much compounded friction for HIGH or CRITICAL.

Why not lower?

It is not lower because this can directly weaken MFA, and MFA seed quality is a security boundary, not a cosmetic issue. If the vulnerable generator issued secrets for externally accessible user accounts, successful prediction can translate into real account compromise rather than a harmless code-quality defect.

05 · Compensating Control

What to do — in priority order.

  1. Inventory every consumer of Authen::TOTP — Use SBOMs, SCA, package inventory, or host checks to identify where the module is installed and whether the application calls module-generated enrollment secrets. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but do the inventory early so you can separate dormant libraries from real MFA exposure.
  2. Prioritize internet-facing enrollment workflows — Review customer, partner, admin, and workforce portals that let users enroll or reset TOTP. If those apps used vulnerable versions to mint secrets, plan re-enrollment or secret rotation for impacted accounts within the same 365-day remediation window, with privileged and externally reachable populations first.
  3. Enforce stronger MFA for privileged users — Move admins and high-impact roles to phishing-resistant methods such as WebAuthn/FIDO2 where possible, so a predictable TOTP seed is not the last line of defense. This is risk reduction, not a substitute for patching, and it should be rolled into the normal remediation program for this MEDIUM issue.
  4. Monitor MFA enrollment and validation anomalies — Alert on bursts of TOTP enrollments, unusual reset activity, repeated OTP failures, and successful logins from new devices right after enrollment changes. That will not fix the bug, but it gives you a chance to catch exploitation attempts while you work through the remediation window.
What doesn't work
  • A WAF does not solve this because the flaw is in server-side secret generation, not HTTP payload parsing.
  • An internet-facing vulnerability scan will miss most cases because it cannot fingerprint an embedded Perl module version reliably.
  • Simply restarting app servers after patching does not protect users whose TOTP secrets were already generated by vulnerable code; those seeds remain weak until rotated or re-enrolled.
06 · Verification

Crowdsourced verification payload.

Run this on the target host or a build/CI worker that has access to the same Perl runtime as the application. Invoke it as python3 check_cve_2026_46473.py or python3 check_cve_2026_46473.py /usr/bin/perl; it needs only normal user rights and reads the installed Authen::TOTP version via Perl.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# Check for CVE-2026-46473 in installed Perl Authen::TOTP
# Usage:
#   python3 check_cve_2026_46473.py
#   python3 check_cve_2026_46473.py /path/to/perl
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

import re
import sys
import subprocess
from shutil import which

FIXED = (0, 1, 1)


def parse_version(v):
    m = re.match(r'^\s*v?(\d+)\.(\d+)\.(\d+)\s*$', v)
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def main():
    perl = sys.argv[1] if len(sys.argv) > 1 else (which('perl') or 'perl')

    cmd = [
        perl,
        '-MAuthen::TOTP',
        '-e',
        'print defined($Authen::TOTP::VERSION) ? $Authen::TOTP::VERSION : "UNKNOWN"'
    ]

    try:
        proc = subprocess.run(cmd, capture_output=True, text=True, timeout=15)
    except FileNotFoundError:
        print('UNKNOWN: perl not found')
        sys.exit(2)
    except Exception as e:
        print(f'UNKNOWN: failed to execute perl: {e}')
        sys.exit(2)

    if proc.returncode != 0:
        stderr = (proc.stderr or '').strip()
        if 'Can\'t locate Authen/TOTP.pm' in stderr:
            print('UNKNOWN: Authen::TOTP not installed in this Perl runtime')
        else:
            print(f'UNKNOWN: perl returned {proc.returncode}: {stderr}')
        sys.exit(2)

    version = (proc.stdout or '').strip()
    parsed = parse_version(version)
    if not parsed:
        print(f'UNKNOWN: could not parse Authen::TOTP version: {version!r}')
        sys.exit(2)

    if parsed < FIXED:
        print(f'VULNERABLE: Authen::TOTP {version} < 0.1.1')
        sys.exit(1)
    else:
        print(f'PATCHED: Authen::TOTP {version} >= 0.1.1')
        sys.exit(0)


if __name__ == '__main__':
    main()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, treat this as a targeted MFA integrity issue, not an emergency host-compromise event: identify every app that ships Authen::TOTP, determine whether it actually generated user secrets with vulnerable versions, and flag any internet-facing enrollment/reset workflows first. Because this reassessment lands at MEDIUM, there is noisgate mitigation SLA: no mitigation SLA — go straight to the 365-day remediation window; the noisgate remediation SLA is to patch to 0.1.1+ within 365 days, and where the module protected real user accounts, fold secret rotation or user re-enrollment into that same remediation plan for the impacted populations.

Sources

  1. oss-security disclosure
  2. MetaCPAN module documentation
  3. MetaCPAN changelog
  4. Upstream patch commit
  5. MetaCPAN 0.1.1 release
  6. Upstream repository
  7. RFC 6238 TOTP reference
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.