less permits shell escape and file writes outside secure mode

Direct answers

Does LESSSECURE reliably disable every shell-escape and file-write path? In mainstream GNU less releases from version 4.0 onward, setting LESSSECURE=1 disables the shell-escape command (!), the pipe command (|), and the file-write commands (s, :e, :^E). However, the exact set of disabled commands can vary between builds because some distributions apply patches or compile with optional features disabled. A few older or heavily customized binaries may still allow :e or :^E even when LESSSECURE is set. Minimal or embedded builds may lack the secure-mode checks entirely, leaving shell escape available despite the variable.

Which commands remain available in secure mode, and do they provide an escape vector? Navigation keys, search (/ and ?), marks (m, '), file inspection (:f, :=), and multi-file navigation (:n, :p) remain functional. These do not provide a direct way to execute arbitrary commands or write files. If a particular build fails to disable :e (or :^E) in secure mode, an attacker could still open arbitrary files for viewing, which might be chained with other vulnerabilities.

Can secure mode be made the default for all less invocations without requiring each caller to set the environment variable? Yes. Export LESSSECURE=1 in a shell startup file (e.g., ~/.bashrc, /etc/profile), create an alias such as alias less='LESSSECURE=1 less', set it system-wide via /etc/environment, or place a wrapper script earlier in $PATH that invokes LESSSECURE=1 less "$@". Enabling it globally may break legitimate workflows that rely on shell escapes or pipes from within less (e.g., piping log lines to grep); such workflows must be adjusted or performed outside less.

Verification steps for your installed binary

1. Run less --version to identify the version and any special build flags.
2. Consult the man page (man less) and locate the SECURITY section to see which commands are listed as disabled in secure mode.
3. Start less with LESSSECURE=1 less <file> and attempt the commands !, |, s, :e, :^E; each should be rejected with an error or have no effect.
4. Verify that navigation, search, marks, and file-inspection commands still work as expected in the same session.
5. To test the default-mode approach, add export LESSSECURE=1 to your shell rc, open a new shell, and run less <file> without explicitly setting the variable; repeat the command checks from step 3.

Assumptions and uncertainty

The research reflects behavior of mainstream GNU less 4.0+ releases. Distribution-specific patches, minimal/embedded builds, or versions older than 4.0 may behave differently. The only way to be certain for a given binary is to run the verification steps above. If you are using a non-standard less build (e.g., busybox less, a vendor-patched version), the secure-mode guarantees may not hold.

One missing diagnostic detail

What is the output of less --version on the target systems? Knowing the exact version and any vendor patch string determines whether the mainstream behavior applies or whether you must treat the binary as untrusted until manually verified.