CWE-149 covers products that do not neutralize quote characters before passing data to another component. A single or double quote is a delimiter in SQL, shell commands, CSV, mail headers and many other formats. When attacker data carries a quote that the downstream parser treats as syntax, the data stops being data.
The record describes it plainly: an injected, absent, duplicate or malformed use of quotes may cause the process to take unexpected actions. Anyone who builds strings that another parser will read is exposed, which means almost every web backend.
How it happens
The common pattern is string building. Code concatenates user input into a query, command or document, and the receiving parser sees the quote as the end of a value.
# Vulnerable: the quote in name ends the string literal
cur.execute("SELECT * FROM users WHERE name = '" + name + "'")
If name contains a quote, the query structure changes. The same idea applies when a quote is missing. Two observed examples show that quotes do not have to be well formed to cause trouble. CVE-2004-0956 is a database denial of service from a MATCH AGAINST query with an opening double quote and no closing one. CVE-2003-1016 is a mail filter bypass using fields that should not be quoted, duplicate quotes, and missing leading or trailing quotes.
So there are three failure shapes: an extra quote that closes a value early, a missing quote that leaves a value open, and a duplicated quote that a security check and the real parser read differently.
What an attacker gains
The record lists integrity impact in the form of unexpected state. In practice that ranges from a crash, as in the database example, to getting past a security check, as in the mail example. When the quote reaches a query or command interpreter, the damage can be larger, but that falls under the injection weaknesses that sit above this one.
How to find it
MITRE lists no detection methods for this variant, so use simple checks.
- Search the code for queries, commands and documents built with string concatenation or formatting.
- Test every input field with a lone single quote, a lone double quote, a doubled quote and an unterminated quote. Watch for errors, crashes and changed output.
- Review any filter that tries to strip or escape quotes by hand. Hand rolled escaping is where duplicate and missing quote cases slip through.
How to fix it
- Do not build structured text by concatenation. Use parameterized queries and argument arrays so the data never shares a channel with the syntax.
# Fixed: the driver sends the value separately from the SQL text
cur.execute("SELECT * FROM users WHERE name = %s", (name,))
- Assume all input is hostile and validate with an accept known good strategy. Define what a valid value looks like, reject the rest, and consider length, type, syntax and consistency across related fields.
- Where a quote is legitimately allowed, encode it for the specific destination at the point of output, not earlier.
- Anticipate that quotes will be injected, removed or manipulated, and write parsers that fail closed on malformed input instead of guessing.
Try it yourself
Run a static scan over a small sample and see which lines get flagged for string built queries.
Click through it at your own pace, or open it full screen.
Quick check
Is escaping quotes with a backslash enough?
Not on its own. Escaping rules differ per destination, and hand written escaping tends to miss duplicate and unterminated cases. Parameterization removes the problem by keeping data out of the syntax channel.
Can a missing quote be a security issue?
Yes. CVE-2004-0956 shows an unterminated double quote crashing a database query. Malformed input needs a defined, safe failure path.
If the quote handling bug sits in a library you ship, the free in-browser dependency scan checks up to 100 dependencies without a login, and the file stays on your machine.
