This was me building a mini project (time converter) after finishing chapter 5 of C Programming: A Modern Approach by K.N. King. I decided to test the program by feeding it input that looked like a valid time range and format but wasn't. Instead of catching it, the program read it successfully and confidently printed a normal-looking, seemingly valid result, even though the input should have been rejected.

[ Full code and PoC on GitHub] (https://github.com/iamduruvictor/scanf-buffer-leftover-bug)

What I noticed

By default, I built in two checks: one for correct time format, and one for correct time range.

if (result != 2) {
    printf("Invalid Time format.\n");
    return 1;
   }

if (hour > 23 || hour < 0 || mintues > 59 || mintues < 0) {
    printf("Invalid Time range.\n");
    return 1;
   }

Whilst testing the program, the snippets successfully caught bad inputs and displayed the right error messages.

Incorrect time format:

Incorrect time range:

Then I tried something different. I gave it a valid-looking two-digit hour and minute value, but added extra digits after them. To my surprise, scanf accepted the input and the program printed a normal-looking result, as if nothing was wrong, even though what I typed was clearly invalid.

This violates the code “Minutes > 59” because of the way I wrote it.

My hypothesis

Since scanf read the input without an error, printed the program successfully, and the extra digits I typed never showed up anywhere in the output, I knew something didn't add up. Based on my knowledge from earlier reading—about inputs being held in a (stdin) buffer before a program reads it, I then began to suspect that the leftover digits hadn't disappeared. They were still sitting in the buffer, waiting for the next scanf call to execute.

Testing it: the PoC

To test that hypothesis, I added a second scanf call after the program's normal logic since my assumption suggests that the leftover value would be sitting somewhere in the stdin buffer.

int attack;
  scanf("%d", &attack);
  printf("\nBuffer Leftover: %d", attack);

I declared a variable called attack (the name was mostly for fun, but it stuck), used scanf to read into it, expecting it would either wait for fresh input from me or, if my hypothesis was right, silently pick up whatever was still sitting in the buffer instead. Then paired it with a printf call to output exactly what got read (i.e what was passed into the variable ‘attack’).

What's actually happening

The program only accepts 2 digits per field (%2d), backed by a format check and a range check, hours between 0–23, minutes between 0–59. Feeding a clearly invalid 3-digit hour or an out-of-range minute (like 60) correctly triggered the error messages, as expected. But this trick worked differently: %2d only ever reads the first 2 digits of whatever I typed, it doesn't care if more digits follow. So it happily read the valid-looking first 2 digits, and the extra digit(s) I typed were left completely untouched in the input buffer.

When I ran the program with my added PoC, the second scanf call didn't wait for me to type anything. It executed itself using the leftover digit(s) still sitting in the buffer from my first input. No new keystroke required, and the printf function call right after it proved it, printing the exact leftover value back to me.

Another trial:

Why it matters

This is a real instance of a well-known weakness pattern CWE-20, Improper Input Validation. In my program, the consequence is harmless: wrong-looking output on my own screen, nothing more. That's an important distinction.

A bug is any unintended behavior; it only becomes a vulnerability once it can be leveraged to actually violate a system's security, whether that's letting someone see data they shouldn't, change something they shouldn't, or break availability. But the same underlying pattern; unvalidated input leaving unexpected data behind for a later read to silently consume, is exactly the kind of weakness that becomes dangerous once it touches something security-relevant: a buffer size calculation, an array index, an authentication check.

The difference between "quirky bug" and "real vulnerability" isn't the mechanism, it's what that leftover data ends up touching downstream.

What I'm taking from this

This taught me that testing a program only within the boundaries you expect isn't enough. The real test is trying to break it from outside those boundaries, deliberately, and seeing what it gives.

This class of bug isn't unique to C. Buffer-related input quirks show up in higher-level languages too (Java's Scanner has a well-documented version of this exact problem). But it's more dangerous specifically in C and C++, because these languages don't manage memory or clean up automatically after use. In a higher-level language, leftover input usually just causes a harmless error. In C, if a value goes unread or a variable goes uninitialized as a result, you're dealing with a real memory-safety problem, not just a logic slip.

As someone building toward vulnerability research and exploit development, this confirmed something I'd heard before but hadn't really felt for myself yet: “one of the best places to find real vulnerabilities in a system is by tracing the code all the way back to where it requires a user input.”