Cyber Resilience

CVE-2022-4993

Published
13 August 2026
Modified
15 August 2026
CVSS Score v3.1 9.1
Click a component to see what it means
Raw vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score 0.0048 40th percentile
Risk Priority 67 floored blend · peak EPSS

Summary

CVE-2022-4993 is a critical-severity Unsafe Reflection (CWE-470) vulnerability. Its CVSS base score is 9.1 (Critical).

Operationally, exploitation aligns with the MITRE ATT&CK technique Template Injection (T1221); ranked at the 40th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.

The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SI-10 (Information Input Validation) — see the control section below for these in your framework.

OWASP Top 10 for Web (2025)

EU & UK References

Vulnerability Data

HTML::FormHandler versions through 0.40068 for Perl allow attacker selected method dispatch and resource exhaustion because _apply_actions and add_error use error message text built from request data as a Locale::Maketext bracket notation template. add_error hands its first argument to the language…

more

handle as the Locale::Maketext message key, and the default handle's lexicon sets `_AUTO`, so a string that is not a lexicon entry is compiled as a bracket notation template instead of being looked up. In a bracket group the first token names a method called on the language handle and the remaining tokens are its arguments. Three kinds of text the library did not author reach that position. _apply_actions installs a `$SIG{__WARN__}` handler that stores the warning text in `$error_message`, and a captured warning survives a successful action, so a field carrying a numeric transform turns `Argument "[sprintf,%50000000d,0]" isn't numeric` into the template; a warning quotes the submitted value verbatim, so the group is well formed and dispatches. `$error_message ||= $tobj->validate($new_value)` takes a type constraint's own failure message, which renders the rejected value through a partial dumper in bracket and comma form (Devel::PartialDump when Moose can load it, Type::Tiny's own dumper always), so a field with `apply => [ Str ]` given a parameter sent more than once, which arrives as an array, gets `Reference ["a","b"] did not pass type constraint "Str"` as its template, from a request that carries no bracket character of its own. A coercion or transform exception reaches it the same way. Beyond those, a validator whose message contains the field value puts that value in the template directly, and add_error replaces the message list with the contents of an arrayref first argument (`@message = @{$message[0]} if ref $message[0] eq 'ARRAY'`), so a value arriving as an array fills the argument slots from the same request as well. A malformed group such as `[0]` makes the compile croak, and HTML::FormHandler::I18N::maketext and add_error each re-raise that as a die, so process() throws. A well formed group naming sprintf reaches CORE::sprintf with an attacker chosen field width. Any caller that applies a type constraint or a transform to an untrusted field, or whose validator passes an untrusted field value to add_error, can be made to throw an unhandled exception out of process(), or to allocate an arbitrary amount of memory in one request, and an application whose language handle subclass defines side effecting public methods makes those callable with attacker chosen arguments. The dumped type constraint message is bounded to the exception, because both dumpers quote non-numeric elements so the method slot is never an attacker chosen name. The built-in messages pass fixed templates with the value in an argument slot, where it stays inert, and the built-in field types attach explicit message callbacks, so neither is affected.

CWE(s)

Related Threats

MITRE ATT&CK Enterprise Techniques

T1221 Template Injection Stealth
Adversaries may create or modify references in user document templates to conceal malicious code or force authentication attempts.
T1620 Reflective Code Loading Stealth
Adversaries may reflectively load code into a process in order to conceal the execution of malicious payloads.
Derived from this CVE’s CWE(s) via the direct CWE→ATT&CK cross-walk.

CVEs Like This One

CVE-2026-13051Shared CWE-1336, CWE-470
CVE-2023-41047Shared CWE-1336
CVE-2026-32263Shared CWE-470
CVE-2023-5764Shared CWE-1336
CVE-2024-27623Shared CWE-1336
CVE-2025-68929Shared CWE-1336
CVE-2025-12967Shared CWE-470
CVE-2026-28784Shared CWE-1336
CVE-2026-31864Shared CWE-1336
CVE-2024-58293Shared CWE-1336

Affected Assets

FormHandler
inferred from references and description; NVD did not file a CPE for this CVE

Mitigating Controls

Control response

Prevent
Stop it (NIST 800-53)

Detect
Catch it (NIST detect / respond)

Harden
Shrink the surface (DISA STIG)

Validate
Prove the fix (OWASP ASVS)
  • V1.3.2
  • V1.3.7
  • V1.3.10

Mitigating Controls (NIST 800-53 r5) AI

Developer testing and static analysis can discover missing neutralization of template directives.

Input validation directly stops externally supplied class or method names from selecting improper code via reflection.

Enforces authorization checks on the code or classes ultimately invoked, blocking unauthorized selections even if reflection is used.

Limits privileges of any code reached through unsafe reflection, reducing blast radius without stopping the selection itself.

Security engineering principles require use of safe templating APIs and proper escaping of external input.

Mitigating Controls (NIST CSF 2.0) AI

Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.

PR.PS-06 mostly match
prevents

Secure SDLC practices directly avoid introducing externally controlled class selection via reflection.

ID.RA-01 partial match
prevents

Vulnerability identification processes can discover unsafe reflection during code review or scanning.

PR.PS-05 partial match
prevents

Preventing execution of unauthorized code can block exploitation of unsafe reflection at runtime.

Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI

Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.

prevents

Secure coding standards directly forbid unsafe reflection and require whitelisting or static alternatives.

finds

Security testing can detect and block unsafe reflection patterns before release.

prevents

Secure development lifecycle mandates input validation and design reviews that reduce unsafe reflection risks.

prevents

Application security requirements can explicitly prohibit or constrain reflection based on untrusted input.

prevents

Secure architecture principles discourage dynamic class loading from external data sources.

none

Access restrictions limit who can supply the malicious input but do not address the reflection flaw itself.

References