The CVE-2026-105841 code is contained but not reachable. It is fixed by https://github.com/UweOhse/lrzsz/commit/9eef71ce20fda2b345ef8431359aec96121215bd
Evidence from the packaging: - debian/rules:39 configures with --program-transform-name=s/l//, so bin_PROGRAMS=lrz lsz (src/Makefile.am:1) install as rz and sz, plus the install-exec-local links rb, rx, sb, sx (src/Makefile.am:18-29). No lrztar/rztar/lrzip name is shipped anywhere (tree-wide search: none). - Topipe is set only in chkinvok() when the basename — after stripping leading -/dir and an optional v/l — has a non-null char at index 2: if (s[2] && protocol!=ZM_XMODEM) Topipe = 1; (src/lrz.c:1578). Trigger requires a >=3 char suffixed name like rztar/lrztar. - All installed names are exactly 2 chars (rz, sz, rb, rx, sb), s[2] is \0), so Topipe is never set and the vulnerable popen(Pathname,"w") at src/lrz.c:1299 is unreachable via the packaged binaries. Two caveats: 1. The vulnerable code is still compiled in, so exposure is purely a matter of invocation name. A local user or an enclosing program that creates a suffixed symlink/copy (ln -s /usr/bin/rz lrztar) would re-enable it. This matches the CVE/NEWS wording that the bug "was only accessible if the installer gave appended some string to the lrz (or rz) commands name." Debian does not do this. 2. This is separate from the -C/--allow-remote-commands ZCOMMAND rexec path (upstream 3dbc195), which is opt-in and additionally forced off in Restricted mode (default).
