croc CVE-2026-119298

Concrete prerequisites, all drawn from the advisory: (1) the victim must run croc receive and accept a transfer from the attacker (UI:R); (2) a regular file whose basename begins with 'croc-stdin-' must already exist in the receiver's working directory under an exact name the sender can predict (receiver-generated text artifacts use unpredictable os.CreateTemp suffixes, so the practical target is a name the attacker already knows, e.g. a file kept from an earlier transfer by the same peer); (3) the attacker sends a file whose basename reuses that exact 'croc-stdin-' name, with Size==0 or a Symlink to hit the delete-and-replace branch, or a non-empty regular file to hit the O_RDWR truncate/overwrite branch. Limiting factors that reduce realistic risk: exploitation cannot reach outside the croc-stdin- namespace (dotfiles such as .bashrc cannot be named this way and are unreachable), symlink targets remain confined to the receive directory, there is no read/confidentiality primitive, and only croc receivers prior to 11.5.2 are affected. The only complete fix stated is updating to 11.5.2, which gates the prefix exemption on c.Options.SendingText.

Signals converge on a genuine but low-urgency integrity/availability issue, not a high-CVSS paper tiger nor an emergency. The provided NVD vector (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:L = 4.2) and the vendor GHSA both agree the sender is remote and unauthenticated (PR:N) but that exploitation requires the victim to accept a transfer (UI:R); they disagree on complexity, with NVD choosing AC:H (reflecting the need for a pre-existing, predictably-named colliding file) and the GHSA arguing AC:L (base 5.4) plus an alternative I:H reading at 7.1 - this AC/impact discrepancy is unresolved and should be verified against your environment. No EPSS score is provided and there is no CISA KEV entry in the supplied data, so there is no evidence of active or widespread exploitation; the vuln.today priority is 'this_month' (schedule, not act_now/emergency). A public PoC reference exists in the form of a self-contained reproduction test in the GHSA advisory, but it is not marked as confirmed working exploit code. Net: patch on a normal monthly cadence. Practical risk is bounded by three factors stated in the advisory - the victim must accept the attacker's transfer, a regular file must already exist with an exact sender-predictable name in the croc-stdin- namespace, and there is no read/exfiltration primitive (C:N) - which together make this targeted rather than mass-exploitable.

A user runs croc and accepts a transfer from a peer they do not fully trust (croc's sender-is-untrusted model). The attacker sends a file whose basename begins with croc-stdin- and exactly matches a pre-existing file in the receiver's working directory; the receiver skips the overwrite confirmation and silently truncates/overwrites that file via recipientInitializeFile, or deletes and replaces it with an empty file or an in-directory symlink via createEmptyFileAndFinish. A reproduction test demonstrating this is included in the GHSA advisory (public PoC reference, not verified here as packaged working exploit code).