CVE-2026-119298 in croc
Summary
by MITRE • 10/30/2026
croc is a tool that allows any two computers to simply and securely transfer files and folders. Prior to 11.5.2, the receive-side file-readiness loop in src/croc/croc.go treats any sender-controlled basename beginning with croc-stdin- as a trusted text-transfer artifact even when SendingText is false. This skips askReceiveOverwrite and rename handling for a predictable exact-name collision in the receiver's working directory, allowing a remote sender whose transfer the user accepts to overwrite or truncate a matching regular file through recipientInitializeFile, or to remove and replace a matching destination with an empty file or an in-directory symlink through createEmptyFileAndFinish, without confirmation. The impact is limited to pre-existing names in the croc-stdin- namespace that the sender can predict; other filenames retain the prompt, dotfiles outside that namespace are not reachable, and symlink targets remain confined to the receive directory. This issue is fixed in version 11.5.2.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified in the croc file transfer utility represents a significant logic flaw within its secure data reception mechanism, specifically affecting versions prior to 11.5.2. Croc is designed as a peer-to-peer tool for securely transferring files and folders between computers, relying on user confirmation steps to prevent accidental or malicious overwrites of existing local assets. The core issue resides in the receive-side file-readiness loop located within the source code module src/croc/croc.go. This component is responsible for managing how incoming data streams are mapped to local filesystem paths during a transfer session initiated by a remote sender.
The technical flaw stems from an overly permissive trust model applied to filenames that begin with the specific prefix croc-stdin-. When a file received has a basename starting with this string, the application treats it as a trusted text-transfer artifact regardless of whether the SendingText flag is set to false. This logic bypasses critical safety checks designed for standard binary or general file transfers. Specifically, the vulnerability allows the system to skip the askReceiveOverwrite prompt and associated rename handling procedures that would normally alert the user if a destination file already exists in their working directory. By skipping these confirmation steps, the application fails to verify whether an overwrite is intentional, thereby creating a path for unauthorized modification of local files.
The operational impact of this vulnerability allows a remote sender, whose transfer has been accepted by the recipient, to exploit predictable filename collisions. If the receiver's working directory contains pre-existing filenames that match the croc-stdin- namespace and can be predicted by the attacker, the sender can overwrite or truncate these regular files through the recipientInitializeFile function. Furthermore, via the createEmptyFileAndFinish routine, an attacker can remove existing destination files and replace them with either empty files or symlinks located within the receive directory. This capability effectively allows for data destruction or potential symlink-based attacks if subsequent operations interact with those paths without proper validation of their current state.
Despite the severity of bypassing user confirmation prompts, the scope of this vulnerability is somewhat constrained by its reliance on predictability and namespace specificity. The attack surface is limited to pre-existing names within the croc-stdin- namespace that an attacker can accurately guess or enumerate. Filenames outside this specific prefix do not trigger the flawed logic path, meaning standard file transfers still retain their protective prompts. Additionally, dotfiles located outside of this namespace remain unreachable through this vector, and any symlinks created are confined to the receive directory rather than escaping to arbitrary locations on the filesystem. This containment limits the potential for widespread system compromise but remains critical for data integrity within the affected scope.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation, as the application fails to adequately validate or sanitize the handling of filenames based on their prefix and context. It also relates to CWE-354 Improper Validation of Integrity Check Value if one considers the bypass of integrity checks like overwrite confirmation as a failure in validating the expected state of the local environment before modification. In terms of adversary tactics, this behavior facilitates Initial Access or Persistence depending on how the overwritten files are utilized by an attacker post-exploitation, fitting into ATT&CK techniques related to file manipulation and potential defense evasion through trusted path exploitation.
To mitigate this risk, organizations and individual users must upgrade croc to version 11.5.2 or later, where the logic governing the receive-side file-readiness loop has been corrected to enforce proper validation regardless of filename prefixes. Until an update is applied, administrators should exercise extreme caution when accepting transfers from untrusted sources and avoid maintaining files with predictable names in the working directory that match common tool-specific prefixes. Monitoring for unexpected modifications to local files following transfer sessions can also serve as a detection mechanism for exploitation attempts targeting this specific logic flaw.