CVE-2026-13048 in Data::MuForm::Localizer
Summary
by MITRE • 08/13/2026
Data::MuForm::Localizer versions through 0.05 for Perl execute Perl from a message catalog header, reached at an arbitrary path because load_lexicon interpolates the language attribute into the catalog filename.
load_lexicon builds the catalog path by appending `Messages/$lang.po` to the directory holding Localizer.pm, where $lang is the language attribute, with no check that it names a bare locale tag. A value holding `../` segments walks out of the message directory, so any readable path with a `.po` suffix is loaded. While parsing the catalog, extract_header_msgstr takes the `Plural-Forms:` header, prefixes `$` to the bare words nplurals, plural and n, and passes the rest verbatim into a string that is evaluated: the nplurals form evaluates the header expression immediately, and the plural_code form compiles it into a subroutine whose body runs when a plural message is localized. A header of `nplurals=2; plural=(system('...'),0);` therefore runs that command as the catalog loads. The evaluation inherits strict, so an expression that assigns to an undeclared variable fails to compile, while one built from calls alone does not.
An application that sets the language attribute from request data, an Accept-Language header or a locale parameter, and an attacker who can place a file with a `.po` suffix and chosen contents at a readable path, together give code execution as the application user. The message expansion path is not affected: expand_named substitutes only the placeholder names the caller supplies, and _mangle_value returns the value unchanged.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/13/2026
This vulnerability exists in Data::MuForm::Localizer versions through 0.05 where the load_lexicon function improperly handles language attribute input leading to arbitrary code execution. The flaw occurs because the function directly interpolates user-controlled language values into file path construction without proper sanitization or validation. When an application uses request data, Accept-Language headers, or locale parameters to set the language attribute, attackers can manipulate these inputs to traverse directories and load malicious .po files from arbitrary locations.
The technical implementation combines path traversal with code injection through message catalog parsing. The load_lexicon function constructs paths using Messages/$lang.po format where $lang represents the unvalidated language parameter. When this parameter contains ../ sequences, it allows attackers to escape the intended message directory and access any readable file ending in .po. The vulnerability becomes exploitable during catalog parsing when extract_header_msgstr processes the Plural-Forms header by prefixing $ to variable names nplurals, plural, and n before evaluating the remainder as Perl code.
The evaluation mechanism creates a dangerous execution environment where headers containing system commands can be executed immediately upon catalog loading. Specifically, a malicious header like nplurals=2; plural=(system('...'),0); will execute arbitrary shell commands as the application user during the catalog loading phase. This occurs because the code evaluation inherits Perl's strict pragma which prevents assignment to undeclared variables but allows function calls and expressions to execute normally. The nplurals form immediately evaluates the header expression while the plural_code form compiles a subroutine that executes when plural messages are processed.
The operational impact extends beyond simple command execution to full system compromise when applications use this library with user-controllable locale settings. Attackers can leverage this vulnerability through web applications that accept language parameters from user input, potentially leading to remote code execution, data exfiltration, or privilege escalation depending on the application's execution context and permissions. This type of vulnerability aligns with CWE-22 Path Traversal and CWE-94 Code Injection categories while following ATT&CK techniques for command execution through software libraries.
Mitigation strategies include validating and sanitizing all language parameters before passing them to load_lexicon, implementing strict path validation that prevents directory traversal sequences, and avoiding direct interpolation of user input into file paths. Applications should also consider using whitelisting approaches for valid locale values or implementing proper input validation that rejects potentially dangerous sequences like ../. Additionally, the library itself should be updated to properly escape or validate language identifiers before constructing file paths, ensuring that only legitimate message catalog files can be loaded regardless of user-provided inputs.
The vulnerability demonstrates the critical importance of input validation in internationalization libraries where user-controlled parameters directly influence file system operations and code execution contexts. This flaw represents a classic case of insufficient sanitization combined with dangerous evaluation patterns that can lead to full system compromise when exploited in applications handling untrusted user input through locale settings.