The parserc_parse routine in HTML::Bare verifies multicharacter strings such as "<![CDATA" or element terminators like ">" without first ensuring that the lookahead positions are inside the input buffer. When a truncated string such as "<a/" is processed, the routine may read past the end of the supplied data, causing an out-of-bounds read that can expose arbitrary memory contents or crash the parser. The weakness is identified as CWE‑125. An attacker could supply crafted input that includes truncated tags to trigger the flaw, potentially leaking confidential data or causing a denial of service. The likely attack vector is any context that allows an attacker to inject arbitrary markup into the HTML::Bare parser—such as a web application rendering user supplied HTML, a configuration file reader, or a custom script processing untrusted markup. Since the flaw requires the ability to inject data directly into the parser, exploitation is contingent on the attacker’s ability to supply such input. Because the read operation can reach beyond the buffer boundaries, the vulnerability can reveal internal memory state or destabilize the application. Although the EPSS score is low and no known exploitable payloads exist in the wild, the high CVSS score indicates significant potential impact. The risk remains high until a fix is applied and the application is hardened against malformed input.

CODECHILD released the Perl module HTML::Bare. Versions up to 0.04, inclusive, are affected. The latest CPAN release 0.02 contains a patch, while newer releases on the git repository include the same fix. Any installation of HTML::Bare 0.04 or earlier, regardless of source, remains vulnerable.

The CVSS score of 9.1 indicates a high severity flaw that can potentially expose data or crash a process. The EPSS score of less than 1% suggests that, as of the last assessment, the likelihood of exploitation is low, and the vulnerability is not listed in the CISA KEV catalog. However, because the flaw requires the injection of crafted input, attackers who can supply such data—through a web form, a configuration file, or a script—can trigger the out‑of‑bounds read. The risk remains high until a fix is applied, given the potential for data leakage and application instability. The probable attack vector is inferred from the description and is not directly stated in the CVE data.