CWE-1286Base

Improper Validation of Syntactic Correctness of Input

Incomplete in the CWE catalog · 100 CVEs mapped

100
CVEs mapped
7.2
Median CVSS
What it is

The product receives input that is expected to be well-formed - i.e., to comply with a certain syntax - but it does not validate or incorrectly validates that the input complies with the syntax.

Recent examples
—none
CVE-2026-110675

CVE-2026-110675 - UNKNOWN Severity Vulnerability

Cpanel::JSON::XS versions from 4.33 before 4.80 for Perl accept malformed UTF-8 in bare hash keys under allow_barekey in decode_hv. With utf8 and allow_barekey, which relaxed enables, a quoted key is validated as UTF-8 but a bare key's bytes are stored as a UTF-8 flagged string without any check. Malformed UTF-8, control bytes and backslashes reach the decoded hash, while malformed UTF-8 and control bytes in a quoted key or a value are rejected. Later operations on the key, including lc, uc or encoding the hash again, die with a malformed UTF-8 error.

no explanation yet
0%
epss
9.8cvss
CVE-2026-110759

CVE-2026-110759 - CRITICAL Severity Vulnerability

Text::CSV_XS versions before 1.65 for Perl return a 0xFF byte that is not in the input for an empty last field followed by a lone CR in parse. When the input to parse ends in a separator and a lone CR, the parser treats the end of the input as the next character and stores the end-of-file marker in the field as the byte 0xFF. With binary set, parse("a,\r") returns the fields "a" and "\xFF". On UTF-8 flagged input the last field is a UTF-8 flagged string holding that lone byte, which is malformed UTF-8. The same input with a non-empty last field is rejected as an error. A CRLF file read line by line and chomped ends this way when its last column is empty, so the application receives a byte that is not in its input.

CRITICALno explanation yet
0%
epss
—none
CVE-2026-105660

CVE-2026-105660 - UNKNOWN Severity Vulnerability

Improper Validation of Syntactic Correctness of Input vulnerability in mtrudel bandit allows an unauthenticated remote attacker to set conn.host and conn.port to values outside the RFC 3986 host grammar via the authority of an HTTP/1 absolute-form or authority-form request target. Bandit validates the Host header and answers 400 when it is malformed, but when the request target carries its own authority that authority takes precedence, as RFC 9112 requires, and Bandit.Pipeline.determine_host_and_port!/4 in lib/bandit/pipeline.ex passes it to the application unchecked. A request line such as GET http://[email protected]/x HTTP/1.1 with a valid Host header yields a conn.host of [email protected], and the same path admits NUL, DEL and non-ASCII bytes, invalid IP literals and ports outside 1..65535. The HTTP/1.0 clause needs no Host header at all, and CONNECT places the unparsed port string in conn.port. Applications that build absolute URLs from conn.host, such as through Plug.Conn.request_url/1 or Phoenix URL helpers, emit links whose authority the attacker chose. Message framing is unaffected, and no CR or LF can reach conn.host. This issue affects bandit: from 0.6.0 before 1.13.0.

no explanation yet
0%
epss
The record
Technical detail
CWE ID
CWE-1286
Abstraction
Base
Structure
Simple
Status
Incomplete