CWE-1286: Improper Validation of Syntactic Correctness of Input

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.

Often, complex inputs are expected to follow a particular syntax, which is either assumed by the input itself, or declared within metadata such as headers. The syntax could be for data exchange formats, markup languages, or even programming languages. When untrusted input is not properly validated for the expected syntax, attackers could cause parsing failures, trigger unexpected errors, or expose latent vulnerabilities that might not be directly exploitable if the input had conformed to the syntax.

Consequences

• Other: Varies by Context

How to prevent it

• Implementation: Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

Recent advisories

• EEF-CVE-2026-105660 — Unvalidated HTTP/1 request-target authority lets a client choose conn.host and conn.port in Bandit
• GHSA-f52w-8j3h-j724 — Traefik: Rootless HTTP/1 request-target routes as "/" but is forwarded verbatim, bypassing path-scoped routing, middleware guards and access logging
• GHSA-6h8r-xr42-gp59 — xmldom: Parser silently accepts a not-well-formed end tag whose name is followed by a line break and trailing content
• GHSA-g2pf-xv49-m2h5 — Rack::Request accepts invalid Host characters, enabling host allowlist bypass
• GHSA-pq2q-rcw4-3hr6 — NATS: Pre-auth remote server crash via WebSocket frame length overflow in wsRead
• GHSA-vprv-35vv-q339 — NATS has pre-auth server panic via leafnode handling
• GO-2026-4601 — Incorrect parsing of IPv6 host literals in net/url
• GHSA-cjfx-qhwm-hf99 — FacturaScripts has SQL Injection in API ORDER BY Clause
• GHSA-pj86-258h-qrvf — Weblate's over‑permissive webhook endpoint enables mass repository updates and component enumeration
• GHSA-mm7p-fcc7-pg87 — Nodemailer: Email to an unintended domain can occur due to Interpretation Conflict
• GHSA-3wqc-mwfx-672p — Traefik affected by Go oauth2/jws Improper Validation of Syntactic Correctness of Input vulnerability
• GHSA-6v2p-p543-phr9 — golang.org/x/oauth2 Improper Validation of Syntactic Correctness of Input vulnerability
• GHSA-rv95-896h-c2vc — Express.js Open Redirect in malformed URLs
• GHSA-8gq9-2x98-w8hf — protobuf-cpp and protobuf-python have potential Denial of Service issue

All advisories for CWE-1286