The product uses a function that accepts a format string as an argument, but the format string originates from an external source.

Primary

Implementation
The programmer rarely intends for a format string to be externally-controlled at all. This weakness is frequently introduced in code that constructs log messages, where a constant format string is omitted.

Implementation
In cases such as localization and internationalization, the language-specific message repositories could be an avenue for exploitation, but the format string issue would be resultant, since attacker control of those repositories would also allow modification of message length, format, and content.

High

Confidentiality
Read Memory
Format string problems allow for information disclosure which can severely simplify exploitation of the program.

Integrity
Confidentiality
Availability
Modify Memory
Execute Unauthorized Code or Commands
Format string problems can result in the execution of arbitrary code, buffer overflows, denial of service, or incorrect data representation.

Automated Static Analysis
This weakness can often be detected using automated static analysis tools. Many modern tools use data flow analysis or constraint-based techniques to minimize the number of false positives.

Black Box
Since format strings often occur in rarely-occurring erroneous conditions (e.g. for error message logging), they can be difficult to detect using black box methods. It is highly likely that many latent issues exist in executables that do not have associated source code (or equivalent source.
Limited

Automated Static Analysis - Binary or Bytecode

According to SOAR [REF-1479], the following detection techniques may be useful:

Highly cost effective:

Bytecode Weakness Analysis - including disassembler + source code weakness analysis
Binary Weakness Analysis - including disassembler + source code weakness analysis

Cost effective for partial coverage:

Binary / Bytecode simple extractor - strings, ELF readers, etc.

High

Manual Static Analysis - Binary or Bytecode

According to SOAR [REF-1479], the following detection techniques may be useful:

Cost effective for partial coverage:

Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies

SOAR Partial

Dynamic Analysis with Automated Results Interpretation

According to SOAR [REF-1479], the following detection techniques may be useful:

Cost effective for partial coverage:

Web Application Scanner
Web Services Scanner
Database Scanners

SOAR Partial

Dynamic Analysis with Manual Results Interpretation

According to SOAR [REF-1479], the following detection techniques may be useful:

Cost effective for partial coverage:

Fuzz Tester
Framework-based Fuzzer

SOAR Partial

Manual Static Analysis - Source Code

According to SOAR [REF-1479], the following detection techniques may be useful:

Highly cost effective:

Manual Source Code Review (not inspections)

Cost effective for partial coverage:

Focused Manual Spotcheck - Focused manual analysis of source

High

Automated Static Analysis - Source Code

According to SOAR [REF-1479], the following detection techniques may be useful:

Highly cost effective:

Source code Weakness Analyzer
Context-configured Source Code Weakness Analyzer

Cost effective for partial coverage:

Warning Flags

High

Architecture or Design Review

According to SOAR [REF-1479], the following detection techniques may be useful:

Highly cost effective:

Formal Methods / Correct-By-Construction

Cost effective for partial coverage:

Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)

High

Requirements
Choose a language that is not subject to this flaw.

Implementation
Ensure that all format string functions are passed a static string which cannot be controlled by the user, and that the proper number of arguments are always sent to that function as well. If at all possible, use functions that do not support the %n operator in format strings. [REF-116] [REF-117]

Build and Compilation
Run compilers and linkers with high warning levels, since they may detect incorrect usage.

The following program prints a string provided as an argument.

#include <stdio.h>
void printWrapper(char *string) {

printf(string);
}
int main(int argc, char **argv) {

char buf[5012];memcpy(buf, argv[1], 5012);printWrapper(argv[1]);return (0);
}

The example is exploitable, because of the call to printf() in the printWrapper() function. Note: The stack buffer was added to make exploitation more simple.

The following code copies a command line argument into a buffer using snprintf().

int main(int argc, char **argv){char buf[128];...snprintf(buf,128,argv[1]);}

This code allows an attacker to view the contents of the stack and write to the stack using a command line argument containing a sequence of formatting directives. The attacker can read from the stack by providing more formatting directives, such as %x, than the function takes as arguments to be formatted. (In this example, the function takes no arguments to be formatted.) By using the %n formatting directive, the attacker can write to the stack, causing snprintf() to write the number of bytes output thus far to the specified argument (rather than reading a value from the argument, which is the intended behavior). A sophisticated version of this attack will use four staggered writes to completely control the value of a pointer on the stack.

Certain implementations make more advanced attacks even easier by providing format directives that control the location in memory to read from or write to. An example of these directives is shown in the following code, written for glibc:

printf("%d %d %1$d %1$d\n", 5, 9);

This code produces the following output: 5 9 5 5 It is also possible to use half-writes (%hn) to accurately control arbitrary DWORDS in memory, which greatly reduces the complexity needed to execute an attack that would otherwise require four staggered writes, such as the one mentioned in a separate example.

CVE-2002-1825
format string in Perl program
https://www.cve.org/CVERecord?id=CVE-2002-1825

CVE-2001-0717
format string in bad call to syslog function
https://www.cve.org/CVERecord?id=CVE-2001-0717

CVE-2002-0573
format string in bad call to syslog function
https://www.cve.org/CVERecord?id=CVE-2002-0573

CVE-2002-1788
format strings in NNTP server responses
https://www.cve.org/CVERecord?id=CVE-2002-1788

CVE-2006-2480
Format string vulnerability exploited by triggering errors or warnings, as demonstrated via format string specifiers in a .bmp filename.
https://www.cve.org/CVERecord?id=CVE-2006-2480

CVE-2007-2027
Chain: untrusted search path enabling resultant format string by loading malicious internationalization messages
https://www.cve.org/CVERecord?id=CVE-2007-2027

Logging
Error Handling
String Processing
Memory Management

Memory

Format string vulnerability

Format String

Format string problem

FIO30-C
Exclude user input from format strings
Exact

FIO47-C
Use valid format strings
CWE More Specific

A1
Unvalidated Input
CWE More Specific

6
Format String

IDS06-J
Exclude user input from format strings

IDS30-PL
Exclude user input from format strings
Exact

SFP24
Tainted input to command

ASCSM-CWE-134

Allowed
This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

This weakness is possible in any programming language that support format strings.

In some circumstances, such as internationalization, the set of format strings is externally controlled by design. If the source of these format strings is trusted (e.g. only contained in library files that are only modifiable by the system administrator), then the external control might not itself pose a vulnerability.
While Format String vulnerabilities typically fall under the Buffer Overflow category, technically they are not overflowed buffers. The Format String vulnerability is fairly new (circa 1999) and stems from the fact that there is no realistic way for a function that takes a variable number of arguments to determine just how many arguments were passed in. The most common functions that take a variable number of arguments, including C-runtime functions, are the printf() family of calls. The Format String problem appears in a number of ways. A *printf() call without a format specifier is dangerous and can be exploited. For example, printf(input); is exploitable, while printf(y, input); is not exploitable in that context. The result of the first call, used incorrectly, allows for an attacker to be able to peek at stack memory since the input string will be used as the format specifier. The attacker can stuff the input string with format specifiers and begin reading stack values, since the remaining parameters will be pulled from the stack. Worst case, this improper use may give away enough control to allow an arbitrary value (or values in the case of an exploit program) to be written into the memory of the running program.
Frequently targeted entities are file names, process names, identifiers.
Format string problems are a classic C/C++ issue that are now rare due to the ease of discovery. One main reason format string vulnerabilities can be exploited is due to the %n operator. The %n operator will write the number of characters, which have been printed by the format string therefore far, to the memory pointed to by its argument. Through skilled creation of a format string, a malicious user may use values on the stack to create a write-what-where condition. Once this is achieved, they can execute arbitrary code. Other operators can be used as well; for example, a %9999s operator could also trigger a buffer overflow, or when used in file-formatting functions like fprintf, it can generate a much larger output than intended.

Format string issues are under-studied for languages other than C. Memory or disk consumption, control flow or variable alteration, and data corruption may result from format string exploitation in applications written in other languages such as Perl, PHP, Python, etc.

PLOVER
2006-07-19
Draft 3
2006-07-19

KDM Analytics
2008-08-01
added/updated white box definitions

CWE Content Team
MITRE
2008-09-08
updated Applicable_Platforms, Common_Consequences, Detection_Factors, Modes_of_Introduction, Relationships, Other_Notes, Research_Gaps, Taxonomy_Mappings, Weakness_Ordinalities

CWE Content Team
MITRE
2008-11-24
updated Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2009-03-10
updated Relationships

CWE Content Team
MITRE
2009-05-27
updated Demonstrative_Examples

KDM Analytics
2009-07-17
Improved the White_Box_Definition

CWE Content Team
MITRE
2009-07-27
updated White_Box_Definitions

CWE Content Team
MITRE
2010-02-16
updated Detection_Factors, References, Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2011-06-01
updated Common_Consequences, Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2011-06-27
updated Modes_of_Introduction, Relationships

CWE Content Team
MITRE
2011-09-13
updated Potential_Mitigations, References, Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2012-05-11
updated Observed_Examples, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2014-07-30
updated Demonstrative_Examples, Detection_Factors, Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2015-12-07
updated Description, Modes_of_Introduction, Name, Relationships

CWE Content Team
MITRE
2017-11-08
updated Applicable_Platforms, Causal_Nature, Functional_Areas, Likelihood_of_Exploit, Other_Notes, References, Relationships, Taxonomy_Mappings, White_Box_Definitions

CWE Content Team
MITRE
2018-03-27
updated References

CWE Content Team
MITRE
2019-01-03
updated References, Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2019-06-20
updated Relationships

CWE Content Team
MITRE
2019-09-19
updated Relationships

CWE Content Team
MITRE
2020-02-24
updated Detection_Factors, Relationships

CWE Content Team
MITRE
2020-08-20
updated Relationships

CWE Content Team
MITRE
2020-12-10
updated Common_Consequences, Relationships

CWE Content Team
MITRE
2021-03-15
updated Potential_Mitigations, Relationships

CWE Content Team
MITRE
2023-01-31
updated Description

CWE Content Team
MITRE
2023-04-27
updated References, Relationships

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

CWE Content Team
MITRE
2025-04-03
4.17
2025-04-03
updated Common_Consequences, Demonstrative_Examples, Description, Diagram, Other_Notes

CWE Content Team
MITRE
2025-09-09
4.18
2025-09-09
updated Detection_Factors, Functional_Areas, References

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Applicable_Platforms

Uncontrolled Format String