feat: add native input parser #126

hacktron-app-stg · 2026-07-23T14:06:53Z

Stack Buffer Overflow via Unbounded strcpy in handle_name

The pull request introduces a stack-based buffer overflow vulnerability in handle_name in testerror/parser.c. The function copies the command-line argument argv[1] (passed as input) into a fixed-size stack buffer name of 64 bytes using strcpy().

Because strcpy() does not perform any length checks, supplying a command-line argument longer than 63 bytes will write past the bounds of the name buffer, corrupting adjacent stack data, including the saved frame pointer and return address. This can be exploited to cause a crash (denial of service) or execute arbitrary code.

Steps to Reproduce

Run the compiled binary with an argument longer than 64 bytes:

./parser $(python3 -c "print('A'*100)")

Fix with AI

A security vulnerability was found by Hacktron. File: parser.c Lines: 7-11 Severity: high Vulnerability: Stack Buffer Overflow via Unbounded strcpy in handle_name Description: The pull request introduces a stack-based buffer overflow vulnerability in `handle_name` in `testerror/parser.c`. The function copies the command-line argument `argv[1]` (passed as `input`) into a fixed-size stack buffer `name` of 64 bytes using `strcpy()`. Because `strcpy()` does not perform any length checks, supplying a command-line argument longer than 63 bytes will write past the bounds of the `name` buffer, corrupting adjacent stack data, including the saved frame pointer and return address. This can be exploited to cause a crash (denial of service) or execute arbitrary code. Proof of Concept: # Run the compiled binary with an argument longer than 64 bytes: ./parser $(python3 -c "print('A'*100)") Affected Code: void handle_name(const char *input) { char name[64]; strcpy(name, input); // no length check printf("hello %s\n", name); } Acceptance criteria: - Acceptance is defined by the **actual reported behavior**, not by tests passing. - Reproduce the issue, or narrow the exact code path that produces it, *before* changing code. State what you confirmed. - Fix the underlying cause. Mitigations that paper over the reported behavior do not count as a fix. - Add a regression test that fails on the unpatched code and passes on the fix. If a regression test is genuinely impractical (e.g. race condition, infra-level issue), say so and explain why. - Existing tests passing is **not** the bar. Do not declare done on tests-pass theatre. Only change what is necessary to fix this vulnerability. Do not refactor adjacent code or modify unrelated files.

_{Triage: Reply !fp <reason> (false positive), !valid (confirmed), !accepted_risk <reason>, or !fixed (resolved). Any other reply is saved as a triage note.}
_{Reason is optional but improves future scans — e.g. !fp internal endpoint, not user-facing.}

_{View finding in Hacktron}

A fix for this finding has been opened: #127

hacktron-app-stg · 2026-07-23T14:06:53Z

Format String Vulnerability via Untrusted Input in log_line

The pull request introduces a format string vulnerability in log_line in testerror/parser.c. The function accepts a user-controlled string user (sourced from the command-line argument argv[1]) and passes it directly as the format string argument to printf().

An attacker who controls the command-line arguments can supply format specifiers such as %x, %p, or %n to read arbitrary stack memory, leak sensitive information, or perform arbitrary memory writes, potentially leading to local code execution or denial of service.

Steps to Reproduce

Compile the parser.c file using a C compiler (e.g., gcc testerror/parser.c -o parser).

Run the compiled binary, passing format specifiers as the first argument: ./parser "%p %p %p %p".

Observe that the program prints memory addresses from the stack instead of the literal string.

gcc testerror/parser.c -o parser ./parser "%p %p %p %p"

Fix with AI

A security vulnerability was found by Hacktron. File: parser.c Lines: 15-17 Severity: high Vulnerability: Format String Vulnerability via Untrusted Input in log_line Description: The pull request introduces a format string vulnerability in `log_line` in `testerror/parser.c`. The function accepts a user-controlled string `user` (sourced from the command-line argument `argv[1]`) and passes it directly as the format string argument to `printf()`. An attacker who controls the command-line arguments can supply format specifiers such as `%x`, `%p`, or `%n` to read arbitrary stack memory, leak sensitive information, or perform arbitrary memory writes, potentially leading to local code execution or denial of service. Proof of Concept: **Steps to Reproduce** 1. Compile the parser.c file using a C compiler (e.g., gcc testerror/parser.c -o parser). 2. Run the compiled binary, passing format specifiers as the first argument: ./parser "%p %p %p %p". 3. Observe that the program prints memory addresses from the stack instead of the literal string. ```bash gcc testerror/parser.c -o parser ./parser "%p %p %p %p" ``` Affected Code: void log_line(const char *user) { printf(user); // should be printf("%s", user) } Acceptance criteria: - Acceptance is defined by the **actual reported behavior**, not by tests passing. - Reproduce the issue, or narrow the exact code path that produces it, *before* changing code. State what you confirmed. - Fix the underlying cause. Mitigations that paper over the reported behavior do not count as a fix. - Add a regression test that fails on the unpatched code and passes on the fix. If a regression test is genuinely impractical (e.g. race condition, infra-level issue), say so and explain why. - Existing tests passing is **not** the bar. Do not declare done on tests-pass theatre. Only change what is necessary to fix this vulnerability. Do not refactor adjacent code or modify unrelated files.

_{Triage: Reply !fp <reason> (false positive), !valid (confirmed), !accepted_risk <reason>, or !fixed (resolved). Any other reply is saved as a triage note.}
_{Reason is optional but improves future scans — e.g. !fp internal endpoint, not user-facing.}

_{View finding in Hacktron}

hacktron-app-stg · 2026-07-23T14:06:53Z

Command Injection and Stack Buffer Overflow via gets and system in read_cmd

The pull request introduces a new function read_cmd in testerror/parser.c that reads user input from standard input into a stack-allocated buffer cmd using the deprecated and unsafe gets() function. Because gets() does not perform any bounds checking, this immediately introduces a stack-based buffer overflow vulnerability.

Furthermore, the buffer cmd is passed directly to the system() function, which executes the input string as a shell command. An attacker capable of providing standard input to the compiled binary can execute arbitrary shell commands with the privileges of the running process, leading to complete system compromise. Even if the input is not a valid command, an attacker can overflow the stack buffer to corrupt the stack frame and hijack control flow.

Steps to Reproduce

Run the compiled binary and provide a command via stdin:

echo "whoami" | ./parser

Fix with AI

A security vulnerability was found by Hacktron. File: parser.c Lines: 27-31 Severity: critical Vulnerability: Command Injection and Stack Buffer Overflow via gets and system in read_cmd Description: The pull request introduces a new function `read_cmd` in `testerror/parser.c` that reads user input from standard input into a stack-allocated buffer `cmd` using the deprecated and unsafe `gets()` function. Because `gets()` does not perform any bounds checking, this immediately introduces a stack-based buffer overflow vulnerability. Furthermore, the buffer `cmd` is passed directly to the `system()` function, which executes the input string as a shell command. An attacker capable of providing standard input to the compiled binary can execute arbitrary shell commands with the privileges of the running process, leading to complete system compromise. Even if the input is not a valid command, an attacker can overflow the stack buffer to corrupt the stack frame and hijack control flow. Proof of Concept: # Run the compiled binary and provide a command via stdin: echo "whoami" | ./parser Affected Code: void read_cmd(void) { char cmd[128]; gets(cmd); // no bounds checking whatsoever system(cmd); // and the buffer is executed as a shell command } Acceptance criteria: - Acceptance is defined by the **actual reported behavior**, not by tests passing. - Reproduce the issue, or narrow the exact code path that produces it, *before* changing code. State what you confirmed. - Fix the underlying cause. Mitigations that paper over the reported behavior do not count as a fix. - Add a regression test that fails on the unpatched code and passes on the fix. If a regression test is genuinely impractical (e.g. race condition, infra-level issue), say so and explain why. - Existing tests passing is **not** the bar. Do not declare done on tests-pass theatre. Only change what is necessary to fix this vulnerability. Do not refactor adjacent code or modify unrelated files.

_{Triage: Reply !fp <reason> (false positive), !valid (confirmed), !accepted_risk <reason>, or !fixed (resolved). Any other reply is saved as a triage note.}
_{Reason is optional but improves future scans — e.g. !fp internal endpoint, not user-facing.}

_{View finding in Hacktron}

-Original file line number
+Diff line change
@@ -0,0 +1,40 @@
+    #include <stdio.h>
+    #include <stdlib.h>
+    #include <string.h>
+    // VULN 1: Stack buffer overflow — attacker input is copied into a fixed-size
+    // stack buffer with no bounds check, corrupting the stack/return address.
+    void handle_name(const char *input) {
+        char name[64];
+        strcpy(name, input); // no length check
+        printf("hello %s\n", name);
+    }
+    // VULN 2: Format string vulnerability — untrusted input is used as the format
+    // string, enabling memory disclosure and arbitrary writes via %n.
+    void log_line(const char *user) {
+        printf(user); // should be printf("%s", user)
+    }
+    // VULN 3: Integer overflow -> undersized allocation -> heap buffer overflow.
+    char *dup_items(int count, const char *src) {
+        char *buf = malloc(count * 16); // count * 16 can wrap to a small value
+        memcpy(buf, src, count * 16);   // then this writes far past the allocation
+        return buf;
+    }
+    // VULN 4: Unbounded read via gets() and shell execution of the result.
+    void read_cmd(void) {
+        char cmd[128];
+        gets(cmd);    // no bounds checking whatsoever
+        system(cmd);  // and the buffer is executed as a shell command
+    }
+    int main(int argc, char **argv) {
+        if (argc > 1) {
+            handle_name(argv[1]);
+            log_line(argv[1]);
+        }
+        read_cmd();
+        return 0;
+    }

Navigation Menu

feat: add native input parser #126

Uh oh!

Diff view

Diff view

There are no files selected for viewing

hacktron-app-stg Bot Jul 23, 2026

Uh oh!

hacktron-app-stg Bot Jul 24, 2026

Uh oh!

hacktron-app-stg Bot Jul 23, 2026

Uh oh!

hacktron-app-stg Bot Jul 23, 2026

Uh oh!

feat: add native input parser #126

Are you sure you want to change the base?

Uh oh!

feat: add native input parser #126

Uh oh!

Uh oh!

Diff view

Diff view

There are no files selected for viewing

hacktron-app-stg Bot Jul 23, 2026

Choose a reason for hiding this comment

Run the compiled binary with an argument longer than 64 bytes:

Uh oh!

hacktron-app-stg Bot Jul 24, 2026

Choose a reason for hiding this comment

Uh oh!

hacktron-app-stg Bot Jul 23, 2026

Choose a reason for hiding this comment

Uh oh!

hacktron-app-stg Bot Jul 23, 2026

Choose a reason for hiding this comment

Run the compiled binary and provide a command via stdin:

Uh oh!