CWE-194 Variant Incomplete High likelihood

Unexpected Sign Extension

This vulnerability occurs when a signed number from a smaller data type is moved or cast to a larger type, causing its sign bit to be incorrectly extended. If the original value is negative, this…

Definition

What is CWE-194?

This vulnerability occurs when a signed number from a smaller data type is moved or cast to a larger type, causing its sign bit to be incorrectly extended. If the original value is negative, this sign extension can fill the new, higher-order bits with '1's, leading to unexpectedly large positive values and causing logic errors, buffer overflows, or security bypasses.
Sign extension is a standard behavior in programming languages like C and C++ when promoting a signed integer (e.g., a signed 8-bit `char`) to a larger signed type (e.g., a 32-bit `int`). The problem arises when developers don't account for this automatic behavior, especially when treating the resulting value as an unsigned number or using it for operations like memory allocation, array indexing, or length validation. A classic example is reading a byte value of `0xFF` (-1 as a signed char) into an unsigned integer, which becomes `0xFFFFFFFF` (a very large positive number), potentially leading to out-of-bounds access. To prevent this, developers must be explicit about data types during conversions. Always consider if the source data should be treated as signed or unsigned before widening it. Use explicit casts to the intended target type, and when working with raw byte data or protocol parsing, prefer unsigned types for counts and indices. Performing range checks on the source value before the conversion or using bit masks (e.g., `new_value = old_value & 0xFF`) can effectively strip unwanted sign-extended bits and ensure the resulting value matches the intended logic.
Real-world impact

Real-world CVEs caused by CWE-194

  • Chain: unexpected sign extension (CWE-194) leads to integer overflow (CWE-190), causing an out-of-bounds read (CWE-125)

  • Sign extension error produces -1 value that is treated as a command separator, enabling OS command injection.

  • Product uses "char" type for input character. When char is implemented as a signed type, ASCII value 0xFF (255), a sign extension produces a -1 value that is treated as a program-specific separator value, effectively disabling a length check and leading to a buffer overflow. This is also a multiple interpretation error.

  • chain: signed short width value in image processor is sign extended during conversion to unsigned int, which leads to integer overflow and heap-based buffer overflow.

  • chain: signedness error allows bypass of a length check; later sign extension makes exploitation easier.

  • Sign extension when manipulating Pascal-style strings leads to integer overflow and improper memory copy.

How attackers exploit it

Step-by-step attacker path

  1. 1

    Identify a code path that handles untrusted input without validation.

  2. 2

    Craft a payload that exercises the unsafe behavior — injection, traversal, overflow, or logic abuse.

  3. 3

    Deliver the payload through a normal request and observe the application's reaction.

  4. 4

    Iterate until the response leaks data, executes attacker code, or escalates privileges.

Vulnerable code example

Vulnerable C

The following code reads a maximum size and performs a sanity check on that size. It then performs a strncpy, assuming it will not exceed the boundaries of the array. While the use of "short s" is forced in this particular example, short int's are frequently used within real-world code, such as code that processes structured data.

Vulnerable C
int GetUntrustedInt () {
  	return(0x0000FFFF);
  }
  void main (int argc, char **argv) {
  		char path[256];
  		char *input;
  		int i;
  		short s;
  		unsigned int sz;
  		i = GetUntrustedInt();
  		s = i;
  		/* s is -1 so it passes the safety check - CWE-697 */
  		if (s > 256) {
  			DiePainfully("go away!\n");
  		}
  		/* s is sign-extended and saved in sz */
  		sz = s;
  		/* output: i=65535, s=-1, sz=4294967295 - your mileage may vary */
  		printf("i=%d, s=%d, sz=%u\n", i, s, sz);
  		input = GetUserInput("Enter pathname:");
  		/* strncpy interprets s as unsigned int, so it's treated as MAX_INT
  		(CWE-195), enabling buffer overflow (CWE-119) */
  		strncpy(path, input, s);
  		path[255] = '\0'; /* don't want CWE-170 */
  		printf("Path is: %s\n", path);
  }
Secure code example

Secure pseudo

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-194

  • Implementation Avoid using signed variables if you don't need to represent negative values. When negative values are needed, perform validation after you save those values to larger data types, or before passing them to functions that are expecting unsigned values.
Detection signals

How to detect CWE-194

SAST High

Run static analysis (SAST) on the codebase looking for the unsafe pattern in the data flow.

DAST Moderate

Run dynamic application security testing against the live endpoint.

Runtime Moderate

Watch runtime logs for unusual exception traces, malformed input, or authorization bypass attempts.

Code review Moderate

Code review: flag any new code that handles input from this surface without using the validated framework helpers.

Plexicus auto-fix

Plexicus auto-detects CWE-194 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.

Frequently asked questions

Frequently asked questions

What is CWE-194?

This vulnerability occurs when a signed number from a smaller data type is moved or cast to a larger type, causing its sign bit to be incorrectly extended. If the original value is negative, this sign extension can fill the new, higher-order bits with '1's, leading to unexpectedly large positive values and causing logic errors, buffer overflows, or security bypasses.

How serious is CWE-194?

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-194?

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

How can I prevent CWE-194?

Avoid using signed variables if you don't need to represent negative values. When negative values are needed, perform validation after you save those values to larger data types, or before passing them to functions that are expecting unsigned values.

How does Plexicus detect and fix CWE-194?

Plexicus's SAST engine matches the data-flow signature for CWE-194 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-194?

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

Ready when you are

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.