Cybersecurity glossary
What is a Format String Vulnerability?
Learn what a format string vulnerability is, how attacker-controlled format specifiers leak memory or write pointers, how to exploit and prevent format string bugs, and safer logging practices.
Definition
A format string vulnerability occurs when untrusted input is used as the format argument to functions like printf, sprintf, or logging APIs that interpret format specifiers—allowing attackers to read stack memory, crash the process, or write to chosen addresses via %n and related conversions.
Why format string bugs matter
Formatting functions are tiny interpreters. Their first argument is not “text to print”—it is a program written with % tokens that decide which arguments to read and how to write outputs.
Format String Vulnerability appears when that tiny program comes from a user. Attackers can dump memory, discover addresses, crash services, or—historically with %n—perform precise writes into process memory.
How a format string attack works
Find a format sink
Locate printf/sprintf/fprintf/syslog or a wrapper that takes a format parameter.
Control the format string
User input is passed directly as the format instead of as a data argument.
Read memory with specifiers
%x, %p, and %s disclose stack values and pointed-to memory.
Optional write via %n
Where supported, %n writes attacker-influenced values to chosen addresses.
Escalate impact
Leaks bypass ASLR; writes may hijack control flow or corrupt state.
Dangerous patterns
printf(user)
The classic mistake—user input is the format, not a %s argument.
sprintf(buf, user)
Combines format attacks with possible buffer overflows into buf.
Logging wrappers
Custom log(msg) that forwards msg as a format to vsnprintf.
Localized format templates
Translation strings with unintended specifiers from untrusted sources.
Safe formatting practices
| Control | Notes |
|---|---|
| Fixed format strings | Use printf("%s", input) or equivalent; keep templates in code |
| Compiler warnings | Enable -Wformat -Werror=format-security and similar flags |
| Disable %n where possible | Some platforms allow compiling without %n support |
| Safe logging APIs | Prefer structured logging that treats messages as data |
| Code search | Hunt for format functions called with non-literal first arguments |
| Fuzz sinks | Send %n %x %s payloads to logging and message endpoints |
- Grep for printf/sprintf/snprintf/syslog/wprintf call sites with non-literal formats.
- Refactor wrappers so user content is never the format parameter.
- Turn on format-security compiler errors in CI.
- Replace sprintf with safer bounded APIs and fixed formats.
- Test logs and error messages with %x %p %n payloads.
- Review localization pipelines so translators cannot inject active specifiers unexpectedly.
- Prefer structured logs (key/value) over free-form printf templates.
- Treat unexpected process crashes on log lines containing % as possible format bugs.
The practical takeaway
A format string vulnerability lets attackers supply the format program to printf-family functions, enabling leaks and sometimes memory writes. Keep format strings as trusted literals; pass user data only as arguments.
If you see printf(request.getParam(...)), rewrite it before it ships.
Related security terms
Buffer Overflow
Related memory corruption class; format bugs can also lead to writes.
Information Disclosure
Format leaks often expose memory contents and addresses.
Code Injection
Different injection class; format strings abuse formatting interpreters.
Memory Corruption
Severe format string bugs can corrupt memory and control flow.
Frequently asked questions
What is a format string vulnerability in simple terms?
Functions like printf treat a format string as instructions (%s, %x, %n). If users control that format string, they can make the program read or write memory it should not.
Why is %n dangerous?
%n writes the number of bytes printed so far to an address taken from the argument list. Attackers can use it to overwrite function pointers or other control data.
Is this still a modern problem?
Less common in new code that uses safer APIs, but it still appears in C/C++ logging, embedded firmware, and wrappers that pass user input as the format parameter.
How do format strings leak data?
Specifiers like %x/%p/%s can walk stack arguments and print memory, revealing addresses useful for bypassing ASLR or dumping secrets.
What is the correct fix?
Never pass untrusted input as the format string. Use a fixed format such as printf("%s", user) or logging APIs that treat messages as data.
Are modern compilers helpful?
Yes—format warnings and fortified builds catch many mismatches, but they do not stop intentionally attacker-controlled format strings.
Do high-level languages have this bug?
Some logging frameworks historically interpreted format-like syntax. Prefer APIs that separate template and arguments and never concatenate user input into the template.
References
Explore authoritative guidance and frameworks related to format string vulnerability.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.