CWE-152 covers products that fail to neutralize special elements read as macro symbols by a downstream component. A macro symbol is a marker that triggers expansion: the parser replaces it with other content. If the marker comes from untrusted input, the attacker chooses what gets expanded.
This affects template engines, preprocessors, report generators and any service that supports a macro or placeholder language and accepts text from outside.
How it happens
Two observed cases show the pattern. CVE-2002-0770 describes a server that trusts the client to expand macros, so macro characters could be expanded to trigger resulting information exposure. CVE-2008-2018 lets an attacker obtain sensitive information from a database by using a comment containing a macro, which inserts the data during expansion.
In both, expansion happens at a point where the input should have been plain text. The macro processor cannot tell who wrote the symbol.
What an attacker gains
MITRE lists integrity impact as unexpected state. The examples above show the more concrete result, which is information exposure through expansion of stored or server side values.
How to find it
No detection methods are listed, so check directly.
- Find every place your product expands macros, placeholders or templates, and note whose text feeds them.
- Submit macro markers in comments, names and free text fields, then look for expanded output.
- Check whether expansion runs on the client side of a trust boundary or the server side.
How to fix it
- Expand macros only in content you wrote. Treat user supplied text as literal.
- Neutralize macro symbols in input that must pass through a macro processor, using the escape rule of that processor.
- Validate input with an accept known good strategy and reject what does not conform.
- Never let a client decide what the server expands.
Quick check
Why is a macro in a comment dangerous?
If the processor expands macros inside comments, the comment becomes a way to insert data. CVE-2008-2018 is an example.
