CWE-134 Base Draft High likelihood

Use of Externally-Controlled Format String

This vulnerability occurs when a program uses a format string from an untrusted, external source (like user input, a network packet, or a file) in a formatting function (e.g., printf, sprintf). An…

Definition

What is CWE-134?

This vulnerability occurs when a program uses a format string from an untrusted, external source (like user input, a network packet, or a file) in a formatting function (e.g., printf, sprintf). An attacker can craft a malicious format string to read or write memory, potentially crashing the application or executing arbitrary code.

Format string vulnerabilities happen because functions like printf interpret special sequences (like %s, %n, %x) in their format argument. When an attacker controls this string, they can use these sequences as instructions to read from the stack, write to arbitrary memory addresses, or leak sensitive information. This is not a buffer overflow; it's a direct misuse of a powerful feature that expects a trusted, developer-controlled format. To prevent this, never pass user-controlled data directly as the format string argument. Always use a static, immutable format string and pass external input as separate arguments to the function (e.g., printf("%s", user_input) instead of printf(user_input)). Input validation is not sufficient here; the architecture of the call itself must be corrected to ensure the attacker never gains control over the formatting instructions.

Vulnerability Diagram CWE-134

Real-world impact

Real-world CVEs caused by CWE-134

CVE-2002-1825

format string in Perl program
CVE-2001-0717

format string in bad call to syslog function
CVE-2002-0573

format string in bad call to syslog function
CVE-2002-1788

format strings in NNTP server responses
CVE-2006-2480

Format string vulnerability exploited by triggering errors or warnings, as demonstrated via format string specifiers in a .bmp filename.
CVE-2007-2027

Chain: untrusted search path enabling resultant format string by loading malicious internationalization messages

How attackers exploit it

Step-by-step attacker path

1
The following program prints a string provided as an argument.
2
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.
3
The following code copies a command line argument into a buffer using snprintf().
4
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.
5
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:

Vulnerable code example

Vulnerable C

The following program prints a string provided as an argument.

Vulnerable C

#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);
  }

Secure code example

Secure pseudo

// Validate, sanitize, or use a safe API before reaching the sink.
function handleRequest(input) {
  const safe = validateAndEscape(input);
  return executeWithGuards(safe);
}

What changed: the unsafe sink is replaced (or the input is validated/escaped) so the same payload no longer triggers the weakness.

Prevention checklist

How to prevent CWE-134

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.

Detection signals

How to detect CWE-134

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 Limited

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.

Automated Static Analysis - Binary or Bytecode High

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.

Manual Static Analysis - Binary or Bytecode SOAR Partial

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

Dynamic Analysis with Automated Results Interpretation SOAR Partial

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

Dynamic Analysis with Manual Results Interpretation SOAR Partial

According to SOAR [REF-1479], the following detection techniques may be useful: ``` Cost effective for partial coverage: ``` Fuzz Tester Framework-based Fuzzer

Plexicus auto-fix

Plexicus auto-detects CWE-134 and opens a fix PR in under 60 seconds.

Codex Remedium scans every commit, identifies this exact weakness, and ships a reviewer-ready pull request with the patch. No tickets. No hand-offs.

Get a demo Try Plexicus free

Frequently asked questions

What is CWE-134?

How serious is CWE-134?

MITRE rates the likelihood of exploit as High — this weakness is actively exploited in the wild and should be prioritized for remediation.

What languages or platforms are affected by CWE-134?

MITRE lists the following affected platforms: C, C++, Perl.

How can I prevent CWE-134?

Choose a language that is not subject to this flaw. 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]

How does Plexicus detect and fix CWE-134?

Plexicus's SAST engine matches the data-flow signature for CWE-134 on every commit. When a match is found, our Codex Remedium agent opens a fix PR with the corrected code, tests, and a one-line summary for the reviewer.

Where can I learn more about CWE-134?

MITRE publishes the canonical definition at https://cwe.mitre.org/data/definitions/134.html. You can also reference OWASP and NIST documentation for adjacent guidance.

Related weaknesses

Weaknesses related to CWE-134

CWE-668 Parent

Don't Let Security
Weigh You Down.

Stop choosing between AI velocity and security debt. Plexicus is the only platform that runs Vibe Coding Security and ASPM in parallel — one workflow, every codebase.

Get started free Book a demo

Use of Externally-Controlled Format String

What is CWE-134?

Real-world CVEs caused by CWE-134

Step-by-step attacker path

Vulnerable C

Secure pseudo

How to prevent CWE-134

How to detect CWE-134

Plexicus auto-detects CWE-134 and opens a fix PR in under 60 seconds.

Frequently asked questions

Weaknesses related to CWE-134

Exposure of Resource to Wrong Sphere

Improper Isolation of Shared Resources on System-on-a-Chip (SoC)

Assumed-Immutable Data is Stored in Writable Memory

Binding to an Unrestricted IP Address

Improper Isolation of Shared Resources in Network On Chip (NoC)

Exposure of Sensitive Information to an Unauthorized Actor

Passing Mutable Objects to an Untrusted Method

Returning a Mutable Object to an Untrusted Caller

Insecure Temporary File

Further reading

Don't Let Security
Weigh You Down.

Use of Externally-Controlled Format String

What is CWE-134?

Real-world CVEs caused by CWE-134

Step-by-step attacker path

Vulnerable C

Secure pseudo

How to prevent CWE-134

How to detect CWE-134

Plexicus auto-detects CWE-134 and opens a fix PR in under 60 seconds.

Frequently asked questions

Weaknesses related to CWE-134

Exposure of Resource to Wrong Sphere

Improper Isolation of Shared Resources on System-on-a-Chip (SoC)

Assumed-Immutable Data is Stored in Writable Memory

Binding to an Unrestricted IP Address

Improper Isolation of Shared Resources in Network On Chip (NoC)

Exposure of Sensitive Information to an Unauthorized Actor

Passing Mutable Objects to an Untrusted Method

Returning a Mutable Object to an Untrusted Caller

Insecure Temporary File

Further reading

Don't Let SecurityWeigh You Down.

Don't Let Security
Weigh You Down.