CRM-In-C-Project CVE-2026-19933

Exploitation requires an authenticated session with the CRM application at the level of a standard user capable of accessing the Customer Search Module (CVSS PR:L) - unauthenticated network attackers cannot reach the vulnerable code path. The overflow is triggered by submitting a search query string that exceeds the fixed stack buffer allocated before the gets() call; no special application configuration or non-default feature enablement is required beyond possessing valid credentials. Limiting factors are: (1) the PR:L authentication gate - the attacker must have valid application credentials; (2) the product's small deployment footprint reduces the population of reachable targets; (3) host-level mitigations such as ASLR and stack canaries, if present, increase but do not eliminate exploitation difficulty.

The CVSS 4.0 score of 5.3 (Medium) reflects network-accessible exploitation (AV:N), low complexity (AC:L), no special attack requirements (AT:N), but a low-privilege authentication barrier (PR:L) that prevents unauthenticated abuse. Impact is rated uniformly Low across confidentiality, integrity, and availability, which appears conservative given that a stack-based overflow with control of the return address can realistically achieve full code execution - not merely 'low' integrity impact. No EPSS score was provided in the input data; exploitation probability cannot be quantified from available signals. The vulnerability is absent from CISA KEV, indicating no confirmed widespread active exploitation. However, the CVSS 4.0 vector explicitly includes E:P (exploit code proven/public), which is the single most material risk escalation factor here: the technique is documented and requires minimal adaptation. The underlying primitive - unchecked gets() - is trivially exploitable once authenticated access to the search module is obtained. Real-world blast radius is sharply constrained by the product's apparent status as a small educational or hobbyist GitHub project with no known enterprise production footprint.

An authenticated attacker logs into the CRM application and navigates to the Customer Search Module, then submits a crafted search string far exceeding the stack buffer's allocated size. The gets() call writes the full input onto the stack without bounds checking, overwriting the saved return address with an attacker-controlled value; when the function returns, execution is redirected to attacker-supplied shellcode or a ROP chain, achieving code execution under the process's OS privileges. Because a working proof-of-concept is publicly documented on the project's GitHub issue tracker, the exploitation path requires minimal technical adaptation.