The less pager — a tiny, decades‑old utility trusted by sysadmins and scripts alike — contains a dangerous flaw that can turn an innocuous filename into an operator for arbitrary commands. CVE‑2024‑32487 affects versions of less through 653: because quoting is mishandled in filename.c, a filename containing a newline can inject shell syntax into the input preprocessor command line when the LESSOPEN mechanism is active. In practical terms, an attacker who can deliver attacker‑controlled filenames (for example, files extracted from an untrusted archive) can cause less to execute commands in the context of the user who opens the file list. The bug was publicly disclosed in April 2024 and has been assigned a high severity rating (CVSS v3.1 base score 8.6) by several maintainers and trackers.
less is the ubiquitous, line‑oriented pager shipped with almost every Unix‑like operating system. Administrators and users rely on it for paging output from logs, manual pages, searches, and scripts. Because less is small and typically runs with the privileges of the invoking user, flaws in how it handles file names — not only file contents — can become powerful primitives for local command execution.
The problem at the center of CVE‑2024‑32487 is not a buffer overflow or a heap corruption; it is a quoting bug in filename.c. less constructs a command line for the input preprocessor controlled by the environment variable LESSOPEN. If the code fails to escape or quote the pathname properly, special characters inside a filename (notably a newline) can be interpreted by the shell and appended commands executed. This is especially hazardous because LESSOPEN is commonly set by default in many distributions and interactive shells.
If the command line used to call the LESSOPEN preprocessor concatenates the filename into a shell invocation without proper quoting and escaping, an attacker can trick the caller into interpreting a filename as a sequence that includes shell metacharacters — including newlines that break the intended quoting and start new commands. That’s the precise failure mode reported here.
This is not a purely theoretical issue: archive formats and extraction utilities often preserve filenames supplied by an archive author. That makes untrusted archives a convenient vehicle for supplying attacker‑controlled filenames to a target system. Because users frequently open files extracted from archives with less (or system utilities that call less for previews), the attack surface is both local and broad in practical scenarios.
For defenders, the right priorities are immediate patching, sanitizing archive handling, and removing or controlling LESSOPEN in sensitive environments. For attackers, the complexity is moderate — the exploit is local and needs social or operational access — but the payoff is substantial because a successful exploit runs as the victim user and can be chained into privilege escalation or lateral movement.
If you manage Unix‑like servers, containers, or developer workstations, treat this as a high‑urgency patch-and-hunt item: inventory, patch, and harden your archive workflows now.
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background
less is the ubiquitous, line‑oriented pager shipped with almost every Unix‑like operating system. Administrators and users rely on it for paging output from logs, manual pages, searches, and scripts. Because less is small and typically runs with the privileges of the invoking user, flaws in how it handles file names — not only file contents — can become powerful primitives for local command execution.The problem at the center of CVE‑2024‑32487 is not a buffer overflow or a heap corruption; it is a quoting bug in filename.c. less constructs a command line for the input preprocessor controlled by the environment variable LESSOPEN. If the code fails to escape or quote the pathname properly, special characters inside a filename (notably a newline) can be interpreted by the shell and appended commands executed. This is especially hazardous because LESSOPEN is commonly set by default in many distributions and interactive shells.
What exactly is vulnerable — the technical mechanics
The LESSOPEN preprocessor model
less supports an input preprocessor mechanism via the LESSOPEN environment variable. When LESSOPEN is set, less runs the program or pipeline it points to and feeds it the filename to produce content for display. This mechanism is intended to allow automatic decompression, viewing of archives, or custom preprocessing for special file types.If the command line used to call the LESSOPEN preprocessor concatenates the filename into a shell invocation without proper quoting and escaping, an attacker can trick the caller into interpreting a filename as a sequence that includes shell metacharacters — including newlines that break the intended quoting and start new commands. That’s the precise failure mode reported here.
The newline injection vector
Newline characters are unusual inside filenames but not impossible on many Unix‑like filesystems. The vulnerability requires a filename that contains a newline (for example, the file created as "safe.txt\nrm -rf / #.txt" — note: filenames containing literal newlines are awkward to show here). When less passes that filename to the LESSOPEN preprocessor using code in filename.c that does not properly escape or quote the string, the preprocessor’s shell interpreter can parse the embedded newline as a command terminator and execute the text that follows.This is not a purely theoretical issue: archive formats and extraction utilities often preserve filenames supplied by an archive author. That makes untrusted archives a convenient vehicle for supplying attacker‑controlled filenames to a target system. Because users frequently open files extracted from archives with less (or system utilities that call less for previews), the attack surface is both local and broad in practical scenarios.
Preconditions for exploitation
Exploitation generally requires three things:- A less binary built from the vulnerable versions (through 653).
- The LESSOPEN environment variable set to a preprocessor program or pipeline — this is commonly present by default in many installs.
- An attacker path to getting files with crafted filenames into the victim’s filesystem (for example, via a malicious archive, a shared file server, or a symlinked directory).
Affected scope: who needs to care
- Upstream: less versions through 653 are explicitly listed as vulnerable by CVE records and distributors.
- Distributions: multiple mainstream Linux distributions issued advisories or patches after disclosure — Debian, Ubuntu, Red Hat/OEL, Amazon Linux, Oracle Linux and others released updates or recommended mitigations. Patch metadata and advisories show coordinated distribution fixes across April–July 2024 and later.
- Containers and images: any Docker/OCI image or VM image that contains older less installs is effectively vulnerable. Build pipelines and base images must be checked and rebuilt.
- Tooling that shells out to less for previews: automated previewers or scripts (for example, certain git pager configurations, mail/browser attachments, or file managers that call less via LESSOPEN) expand the realistic attack surface by automatically invoking less on files not fully trusted. Treat any automation that processes archive content as high risk if less is present and the system relies on the default LESSOPEN behavior. While a few integrations auto‑invoke less, many rely on user actions — so the human factor remains the common exploitation vector.
Patching and vendor response
The disclosure on 13 April 2024 prompted a wave of vendor advisories and distribution packages that address the issue. Ubuntu, Red Hat, Oracle and others published fixes or backported patched versions of less, and maintainers referenced upstream commits that corrected quoting in filename.c. Ubuntu’s security tracker lists an upstream patch and distribution package revisions; Red Hat and Oracle published errata with fixed package versions. Administrators should treat distribution updates as the canonical remediation path and apply vendor packages rather than attempting ad hoc source edits.Immediate mitigations (practical steps you can take right now)
If you cannot apply a vendor patch immediately, there are practical mitigations that significantly reduce exploitation risk. Implement these in order of rapidity and safety.- Unset LESSOPEN in session and system profiles
- Temporarily prevent LESSOPEN‑based preprocessing by unsetting the variable:
- In interactive shells: run
unset LESSOPEN - To make persistent for user accounts, remove or guard the export from shell profile files (for example, remove or comment the export from /etc/profile.d scripts or user ~/.bashrc).
- Replace less with a patched package
- Upgrade the less package from your OS vendor’s repository as soon as updates are available. Do not rely on third‑party compiled binaries without validation. Use your normal patching channels (apt, yum/dnf, zypper) and follow vendor advisories for emergency updates.
- Harden archive handling workflows
- Refuse or quarantine archives from untrusted sources before extraction.
- Use extraction flags or tools that sanitize or reject filenames containing unusual bytes such as NUL or newline.
- Prefer extraction under isolated containers or short‑lived VMs where possible.
- Audit and wrap pager usage for automation
- Identify scripts that call less automatically (for logging, previews, or git paging) and ensure they either unset LESSOPEN or call less with sanitized inputs.
- Where possible, use explicit, safer commands for previewing archive contents rather than piping user‑controlled data through shell‑built command lines.
- Emergency policy: deploy an organization‑level wrapper
- For fast, centralized mitigation, replace /usr/bin/less with a thin wrapper that unsets LESSOPEN before invoking the real binary, or apply an LSM/AppArmor policy to restrict execution of less with untrusted environment variables. This can be riskier—test on representative hosts before mass deployment.
Detection, hunting and post‑incident measures
Detection and threat hunting should focus on the conditions that enable exploitation and on indicators of suspicious command execution.- Inventory check: find systems running vulnerable less versions.
- On Debian/Ubuntu: check package versions via apt/dpkg (for example, dpkg -s less or apt policy less) and compare against vendor advisory revisions. On RPM systems, use rpm -q less and compare the release. Distribution trackers list the corrected package numbers that you should verify against.
- Check LESSOPEN presence:
- Look for system‑wide or user‑level exports for LESSOPEN in /etc/profile.d, /etc/environment, and shell startup files.
- Scan running processes for environment variables containing LESSOPEN — many forensic tools or osquery can enumerate process environments.
- Hunt for extraction workflows and suspicious filenames:
- Search archive extraction logs, file system modification timestamps, and tmp directories for files with odd names (including newline characters). Many log formats will escape newlines, so hunt for sequences that indicate attempted newline injection.
- If EDR capabilities exist, create rules that flag uses of less launched with environment variables or suspicious argv[] patterns.
- Monitor for unexpected post‑exploitation activity:
- Because the payer is local and privilege‑equivalent to the user, look for lateral movement, unauthorized process creation, and suspicious shell commands appearing in bash_history, syslog, cron entries, or unexpected file writes.
- If compromise is suspected:
- Treat as high‑severity local execution — perform full incident response: isolate the host, collect memory and process images, preserve artifacts (shell history, environment dumps, /proc/*/environ for processes), and continue investigation per policy.
Risk analysis: strengths and weaknesses of the response
What went well
- Coordinated, rapid vendor response: mainstream distributions pushed patches within weeks of disclosure and backported fixes to supported releases. That rapid triage reduced the window for widespread exploitation. Ubuntu, Red Hat, Oracle and other vendors published specific package updates and advisories.
- Clear technical description: the core failure mode is narrow and well‑described (mis‑quoting in filename.c, newline injection with LESSOPEN). Narrow descriptions enable focused patches and mitigations (for example, quoting fixes in filename.c rather than large rewrites).
Where gaps remain and the risks that persist
- Default environment exposure: the fact that LESSOPEN is often set by default on many systems increases risk. Defaults matter in security: a harmless environment variable can dramatically widen attack surface if not designed defensively. Distributions and package maintainers should scrutinize such defaults to avoid creating exploitable chains.
- Human and automation factors: the vulnerability relies on user action or on automated previewers. Social engineering remains a reliable exploitation vector: attackers can deliver malicious archives via email, hosting, or shared file services. Any automation that processes user archives automatically is a potential pivot point.
- Forensics complexity: filenames with newline characters can make logging and detection noisy. Many tools log filenames by escaping characters, or logs may be incomprehensible when names contain control characters. That makes post‑exploit triage more challenging.
- No guarantee of patching completeness: while many distributions shipped fixes, ad hoc environments (embedded devices, private images, container registries, or minimal rescue media) may contain the older less binary. Administrators must find and update every image and device, not just the primary fleet. Sufficient scanning and inventorying remain practical challenges.
Operational checklist — what IT teams should do now
- Identify all hosts and images that contain less.
- Query package inventories, container images, and base VMs. Treat any image or host with less ≤653 as in scope.
- Patch or replace less on all systems.
- Apply vendor patches via your standard patch management pipeline. Prioritize interactive and user‑facing systems where users commonly open archives or logs.
- For legacy or air‑gapped systems where immediate patching is impossible:
- Unset LESSOPEN systemwide and/or replace /usr/bin/less with a wrapper that sanitizes environment variables.
- Consider AppArmor/SELinux rules to prevent less from running with untrusted environment data in privileged contexts.
- Harden archive ingestion points:
- Force archive extraction into quarantined directories with filename sanitation.
- Train staff not to trust archive contents from unknown sources.
- Update detection and response playbooks:
- Add checks for LESSOPEN, inspect shell exports, and add EDR/IDS rules to flag suspicious uses of less or suspicious filenames.
- Rebuild images and container registries:
- Ensure CI/CD pipelines use patched base images and do not unintentionally reintroduce vulnerable less builds.
- Communicate to users:
- Notify users that viewing files from untrusted archives could be dangerous and provide guidance on safe steps to view archived content (for example, extract only in isolated test environments).
Responsible disclosure and public exploitation
At the time of public advisory aggregation and vendor fixes, there was limited public proof‑of‑concept exploitation reported in the wild. Several vulnerability trackers and community databases indicated no widespread exploitation evidence, but the high severity and the ease of the exploitation chain under typical defaults warranted urgent remediation. Because the attack vector relies on user interaction and local access, the vulnerability has not been catalogued as a remote wormable threat; however, it can be weaponized in targeted campaigns, supply‑chain attacks, and malicious‑archive phishing.Developer and upstream considerations
Fixing quoting bugs correctly requires discipline: never construct shell command lines by concatenating untrusted data; use execve(2)‑style calls or carefully escape/quote every argument. The upstream less maintainers addressed the problem via a commit that sanitizes or properly quotes filenames before passing them to the preprocessor. Distribution maintainers then packaged those upstream fixes into distro releases. Going forward, maintainers should:- Reexamine default settings that enable features like LESSOPEN without strict security checks.
- Add unit tests that exercise filenames containing control characters such as newlines and NULs.
- Prefer safer IPC/exec patterns that avoid invoking a shell with unsanitized arguments.
Final verdict: severity and real‑world impact
CVE‑2024‑32487 is a clear example of how contextual bugs — quoting failures in a trusted utility — can produce high‑impact local command execution vulnerabilities. The technical failure is straightforward, the prerequisites are realistic (LESSOPEN defaults and archive extraction), and distributions widely considered the problem severe enough to push patches quickly.For defenders, the right priorities are immediate patching, sanitizing archive handling, and removing or controlling LESSOPEN in sensitive environments. For attackers, the complexity is moderate — the exploit is local and needs social or operational access — but the payoff is substantial because a successful exploit runs as the victim user and can be chained into privilege escalation or lateral movement.
If you manage Unix‑like servers, containers, or developer workstations, treat this as a high‑urgency patch-and-hunt item: inventory, patch, and harden your archive workflows now.
Quick reference (one‑page action list)
- Check: identify less versions ≤653 across your fleet.
- Patch: apply vendor updates immediately.
- Mitigate: unset LESSOPEN where patching is delayed.
- Harden: sanitize archive extraction and previewers.
- Hunt: search for unusual filenames and suspicious less invocations.
Source: MSRC Security Update Guide - Microsoft Security Response Center
