In mid-April 2024, security researchers disclosed a critical vulnerability in less, the nearly ubiquitous command-line pager found on Linux and Unix-like systems. Tracked as CVE-2024-32487, the flaw allows an attacker to execute arbitrary commands on a victim’s machine simply by crafting a filename that contains a newline character. The bug affects less versions up to and including 653 and carries a CVSS v3.1 base score of 8.6 (High). Distribution maintainers scrambled to release patches, and users are urged to update immediately or apply workarounds.

A Malicious Newline: The Vulnerability at a Glance

The root cause lies in filename.c, the part of less responsible for constructing the command line that invokes an input preprocessor. When the LESSOPEN environment variable is set—a common default in many distributions—less feeds the filename to the preprocessor to handle tasks like automatic decompression or archive browsing. Because the code fails to properly escape or quote the filename, an embedded newline character can break out of the intended context and inject arbitrary shell commands.

For exploitation to succeed, three conditions must align. First, the system must run a vulnerable less binary. Second, LESSOPEN must point to a valid preprocessor script; this is often the case out of the box (e.g., /usr/bin/lesspipe on Debian/Ubuntu, lesspipe.sh on Red Hat derivatives). Third, an attacker must deliver a file with a specially crafted name onto the victim’s filesystem—typically through an archive extracted from an untrusted source. When the user then attempts to view the file with less, the injected commands execute with the user’s privileges.

What Makes This Flaw Dangerous

At first glance, the attack may seem convoluted: it requires user interaction and a local file. But the reality is that tricking someone into opening a malicious archive is a well-worn social engineering tactic. Archive formats like ZIP, tar, and 7z can faithfully preserve filenames exactly as created by the attacker, including those with newlines or other control characters. Users frequently inspect extracted files with less (or tools that shell out to less for previews), making the attack surface broader than it appears.

Moreover, the vulnerability is not remote in the traditional sense, but it can be weaponized in targeted campaigns. An email attachment, a shared network drive, or a repository that compels extraction and paging can all serve as delivery mechanisms. Automated scripts that process archives and invoke less—such as log analyzers, file managers, or continuous integration runners—expand the risk, sometimes removing the need for direct human interaction.

Who Should Worry and Why

Everyday Linux users on desktop or laptop who regularly handle archives from less-than-trusted sources should take note. The attack won’t happen just by downloading a file; you must extract and then view one of its contents with less (or a tool that uses less as a pager). Still, if your system’s LESSOPEN is set—and you can check by running echo $LESSOPEN in a terminal—you are potentially vulnerable.

System administrators and IT teams face a steeper challenge. Servers that run less as part of automated log rotation, monitoring scripts, or inside containers may contain the vulnerable binary. Unpatched container images or virtual machine templates could reintroduce the flaw into production environments. Attackers who gain any foothold—even as an unprivileged user—could leverage this bug to escalate or pivot if they can place a malicious filename where less will eventually process it.

Developers and DevOps engineers should audit their CI/CD pipelines. Build systems that extract archives and run less for documentation generation, linting, or preview steps are potential targets. Additionally, base Docker images often ship an older less. A quick fix is to ensure your Dockerfile or image build includes the patched version.

A Brief History: How Defaults Create Attack Surface

less is a venerable tool, first released in 1983 as a more capable successor to more. Over the decades, it gained the LESSOPEN preprocessor feature to handle compressed files transparently. This convenience became a standard on Linux systems, with distros shipping less pre-configured to invoke a shell script that calls gzip, file, or other utilities. The interaction between LESSOPEN and the shell has always been a sensitive nexus: if the pipeline isn’t bulletproof, untrusted filenames can become command injection vectors.

The 2024 bug is not the first time a pager or file-handling utility has tripped over quoting. Similar issues have cropped up in more, most, and file managers over the years. What sets CVE-2024-32487 apart is the combination of high severity, widespread default exposure, and the triviality of the exploit once the preconditions are met. The vulnerability was responsibly disclosed, and patching began promptly, but the window before widespread updates can leave many systems exposed.

Immediate Steps to Protect Your Systems

1. Patch less immediately

Check your installed version with less --version or your package manager:
- Debian/Ubuntu: apt list --installed | grep less
- RHEL/Fedora: rpm -q less

If the version is ≤ 653, upgrade to the latest from your vendor’s repository. For Ubuntu, the fixed package arrived as less 487-0ubuntu1.2 (for 22.04 LTS) and similar. Red Hat backported fixes into less-530-2.el8_7 and later. Apply these using your normal patch management workflow.

2. Mitigate without patching: unset LESSOPEN

If you can’t update immediately, effectively disable the vulnerable feature by unsetting the environment variable:

unset LESSOPEN

Make this persistent by removing or commenting out the line that sets LESSOPEN from /etc/profile.d/less.sh (or global shell profiles) and your own ~/.bashrc. Be aware that this will also disable legitimate decompression and preprocessing, but it eliminates the attack vector entirely.

3. Harden archive handling

  • Never extract archives from untrusted sources on production or personal systems without precautions.
  • Use tools that sanitize filenames during extraction. For example, bsdtar can be told to reject unusual characters; 7z has a -scs flag for control character handling.
  • Extract into isolated directories or containers, and inspect filenames before opening with less.
  • If you must view archive contents, consider non-shell-based previewers or find combined with grep that avoid LESSOPEN.

4. Audit your automation

Review any scripts, cron jobs, or CI steps that invoke less directly or indirectly. Look for:
- Log analysis pipelines that use less to display extracted log files.
- Git configurations that set core.pager to less and may encounter filenames from git archive.
- File managers that call less for text previews.

In such cases, either unset LESSOPEN before execution or switch to a different pager that does not support preprocessing.

5. Detection and hunting

  • Inventory all hosts and container images that include less. Use package queries (dpkg -l less, rpm -qa less) across your fleet.
  • Check for the presence of LESSOPEN in environment dumps: env | grep LESSOPEN on live systems, or inspect /proc/*/environ for running processes.
  • Hunt for filenames containing newline or other control characters on filesystems. The find command can locate such oddities: find / -name $'* *' (this literal newline may need careful quoting).
  • Review shell history, syslog, and process creation logs for unusual less invocations that could indicate exploitation.

The Road Ahead

The upstream fix properly escapes filenames before passing them to the preprocessor, closing the quoting gap. Distributions have backported these changes into supported releases, and the update should make its way into all active repositories shortly. However, lingering risks remain in unmanaged devices, forgotten container registries, and custom appliances that rarely see updates.

Longer term, this incident underscores the hazards of default-on convenience features that bridge user-facing tools and the shell. Maintainers are likely to reexamine whether LESSOPEN should be enabled by default, or at least whether it should unconditionally invoke a shell pipeline. More robust interfaces, such as execve()-style calls that avoid shell interpretation, could be explored. In the meantime, every administrator should treat less like any other critical package—patch quickly, monitor aggressively, and reduce its attack surface where possible.

CVE-2024-32487 is a sobering reminder that even the small, trusted utilities we use every day can harbor dangerous flaws. A single newline in a filename shouldn’t be able to compromise your system. By applying the steps above, you can make sure that it doesn’t.