CWE-1078, Inappropriate Source Code Style or Formatting, describes source code that does not follow the desired style for indentation, white space, comments and similar details. MITRE files it as a Class level entry, and it applies to every language.
This is not a vulnerability in the usual sense. MITRE says so directly: the entry is primarily a quality issue with no direct security implications, and the CWE ID is marked as prohibited for mapping to real world vulnerabilities. It is in the catalog because messy code makes security review harder. If you review code for a living, that is reason enough to care.
How it happens
Style drift is rarely a single decision. It builds up.
- Several developers work in the same file with different editor settings.
- Code is copied in from another project with its own conventions.
- A deadline pushes someone to skip the formatter.
- There is no agreed style at all, so every choice is personal.
The result is a codebase where indentation, spacing and comments vary from file to file, sometimes within one function.
MITRE's own demonstrative example is about a related habit: using a hard coded constant instead of a symbolic name. Here is the pattern in C.
/* Vulnerable pattern: the size 1024 appears in two places */
char buffer[1024];
fgets(buffer, 1024, stdin);
If someone later changes the array size and misses the number in the fgets call, the code can read more data than the buffer holds. MITRE notes that this could lead to a buffer overflow. The fix is one named value.
/* Fix: one symbolic name, one place to change */
enum { MAX_BUFFER_SIZE = 1024 };
char buffer[MAX_BUFFER_SIZE];
fgets(buffer, MAX_BUFFER_SIZE, stdin);
What an attacker gains
Nothing directly. The listed consequence is Other, with increased analytical complexity. In MITRE's words, variations in indentation, white space and comments can make it more difficult for human analysts to understand the actual behavior the code implements.
That matters because reviewers are the main defense against subtle logic errors. Code that is hard to read gets skimmed, and skimmed code gets approved. An attacker benefits only indirectly, from bugs that a clearer file would have exposed.
How to find it
MITRE lists automated static analysis as a detection method. Static analysis tools, and the linter built into most editors, can report or highlight style problems. In practice:
- Run a formatter and a linter in CI and fail the build on violations.
- Enable format on save in the shared editor config.
- Look for repeated literals, especially sizes and limits, that should be named constants.
How to fix it
The record does not list formal mitigations, so these are plain engineering steps.
- Pick one style guide and write it down.
- Adopt an automatic formatter for each language and commit its config.
- Enforce it in a pre commit hook and in CI, so style is never a review comment.
- Replace magic numbers with named constants.
- Keep comments accurate. A comment that contradicts the code is worse than none.
A formatter ends the style debate because the tool decides.
Try it yourself
See how static analysis flags code patterns and ranks them.
Click through it at your own pace, or open it full screen.
Quick check
Is CWE-1078 a vulnerability an attacker can exploit directly?
No. MITRE describes it as a quality issue with no direct security implications. Its effect is indirect: harder to read code is harder to review.
What does the MITRE example say can go wrong with a hard coded buffer size?
If the size must be changed and a developer misses one of the occurrences, the code could end up with a buffer overflow. A symbolic name means one change updates every use.
Sources
- MITRE CWE-1078
- To check your own dependencies, try the free in browser scan at gold.safeguard.sh/scan. No login, the file stays on your machine, up to 100 dependencies.
