Skip to main content
CVE-2015-5287 High Patch Available

CVE-2015-5287: Red Hat ABRT - Symlink Attack Privilege Escalation

CVE Details

CVE ID CVE-2015-5287
CVSS Score 7.8
Severity High
Vendor Red Hat
Product Automatic Bug Reporting Tool (ABRT)
Patch Status Available
Published August 26, 2026
EPSS Score 3.4%
CISA Patch Deadline September 16, 2026

Executive Summary

CVE-2015-5287 is a local privilege escalation vulnerability in ABRT (Automatic Bug Reporting Tool), the crash-collection and problem-reporting daemon shipped by default on Red Hat Enterprise Linux, CentOS, and Fedora. ABRT’s coredump hook (abrt-hook-ccpp) and its interaction with sosreport write files into predictably named directories under /var/spool/abrt and /var/tmp/abrt without properly checking for symbolic links. A local user who can influence the contents of those directories can plant a symlink pointing at an arbitrary system file, then trigger ABRT’s root-privileged file-writing logic to overwrite that file with attacker-controlled data, resulting in full root compromise on a default RHEL 7.0/7.1 install.

The bug is over a decade old (reported September 2015, patched November 2015), and ABRT itself is a legacy component largely superseded by newer crash-handling tooling on modern distributions. CISA added CVE-2015-5287 to the Known Exploited Vulnerabilities (KEV) catalog on 2026-08-26 with a remediation due date of 2026-09-09, which under CISA’s process signals confirmed evidence of exploitation. No public writeup identifying the specific campaign, threat actor, or targets behind that KEV addition was found during research; this article does not speculate about that gap and instead focuses on the mechanics organizations need to understand to assess exposure.

Affected Versions

ProductAffected VersionsFixed In
ABRT (abrt-hook-ccpp / sosreport integration)Versions prior to 2.7.1, as shipped in RHEL 7.0 and 7.1 (also affecting CentOS 7 and contemporary Fedora releases using the same ABRT codebase)2.7.1 and later, via RHSA-2015:2505

ABRT ships enabled by default on RHEL 7.0/7.1, CentOS 7, and Fedora releases of that era, so any unpatched host running the default crash-reporting configuration is potentially exposed. The vulnerability requires that PrivateReports be left at its (default, off) setting, which is the out-of-the-box state on these systems. RHEL 6 and earlier used a different, less-affected ABRT branch. ABRT has since been deprecated in favor of systemd-coredump and other tooling on current RHEL/Fedora releases, and the affected package family is at end of life on the versions in question. Red Hat’s advisory and the current NVD record are the authoritative sources for exact package-version boundaries in your environment.

Vulnerability Details

ABRT runs, in part, as a privileged (root or setuid) helper that collects crash artifacts, including core dumps, related metadata, and diagnostic bundles, into directories such as /var/spool/abrt/<problem-dir> and /var/tmp/abrt/. These directory and file names are generated in a predictable way (tied to PID or a short-lived naming scheme), and critically, the code that later opens and writes into these paths did not verify that the path component was still a regular file or directory rather than a symlink.

The exploitation primitive is a classic TOCTOU (time-of-check-to-time-of-use) symlink race:

  1. An unprivileged local user with permission to write into the ABRT problem-directory tree (or to race the creation of /var/tmp/abrt/abrt-hax-coredump-style paths) removes or preempts the expected file/directory and replaces it with a symbolic link pointing at a target the attacker wants to overwrite, for example /etc/passwd, /etc/sudoers, or (as demonstrated in public proof-of-concept material) /proc/sys/kernel/modprobe.
  2. The attacker triggers a crash (or otherwise causes ABRT’s root-privileged coredump hook or sosreport invocation to process the problem directory).
  3. ABRT, running with elevated privilege and without symlink validation, follows the link and writes crash/report content through it, corrupting or overwriting the target file with attacker-influenced data.
  4. Depending on the target chosen, this yields arbitrary file write as root. Public research demonstrated pointing the write at the kernel’s modprobe binary path, which the kernel invokes with root privileges when it needs to load a module for an unrecognized binary format, a well-known technique for turning an arbitrary-root-write primitive into direct code execution as root.

CVE-2015-5287 was disclosed alongside a closely related sibling, CVE-2015-5273 (insecure, predictable temp-directory naming in abrt-action-install-debuginfo-to-abrt-cache, which escalates from an unprivileged user to the abrt service account), and both trace back to the same underlying design pattern: ABRT-family tooling of that era trusted file and directory paths under attacker-writable locations without re-validating them immediately before privileged use. An earlier, separately tracked ABRT flaw, CVE-2015-3315, involved similar insecure temp-file handling in ABRT’s Python problem-handling libraries. Researcher Philip Pettersson (Samsung) is credited with reporting the 2015-5273/5287 pair, and public write-ups describe chaining the debuginfo-installer bug (unprivileged user to abrt user) with the sosreport/coredump symlink bug (abrt user, or in some configurations directly an unprivileged user, to root) to obtain a complete privilege-escalation path on a stock RHEL 7 install.

Exploitation in the Wild

Public proof-of-concept exploit code for CVE-2015-5287 has been available since shortly after disclosure, including an Exploit-DB entry (targeting RHEL 7.0/7.1) and a Metasploit module (exploit/linux/local/abrt_sosreport_priv_esc) that automates the symlink race and modprobe-path overwrite. This lowers the bar for exploitation considerably: a local user or an attacker who has already gained low-privilege code execution on a vulnerable, unpatched host can escalate to root with minimal custom tooling.

CISA’s addition of CVE-2015-5287 to the KEV catalog on 2026-08-26 is itself an assertion of confirmed in-the-wild exploitation, per CISA’s inclusion criteria. At the time of writing, no public incident report, vendor advisory update, or threat-intelligence writeup identifying the specific actor, campaign, or victim sector behind that determination was located. Given that this is a purely local privilege-escalation bug with mature, publicly available exploit tooling, the realistic exploitation scenario is post-compromise privilege escalation: an attacker who has already obtained a low-privilege shell (via an unrelated remote vulnerability, stolen credentials, or an insider) on an old, unpatched RHEL/CentOS/Fedora host using this as the final step to full root control. Organizations should not assume the absence of public campaign attribution means the risk is theoretical; treat the KEV listing as confirmation that exploitation has occurred.

Patch and Remediation

Red Hat shipped a fix in ABRT 2.7.1, distributed via RHSA-2015:2505 (released November 23, 2015), which corrected the coredump hook and sosreport interaction to reject symbolic links in the crash-report path rather than following them. The upstream fix is visible directly in the ABRT source history: commit 3c1b60cfa62d39e5fff5a53a5bc53dae189e740e, titled “ccpp: save abrt core files only to new files,” which changes the coredump-saving logic to refuse to write through an existing path (symlink or otherwise) and require creation of a genuinely new file.

Remediation steps:

  1. Patch immediately. Update the abrt package family to a version incorporating RHSA-2015:2505 (ABRT 2.7.1+) via your distribution’s package manager (yum update abrt\* / dnf update abrt\*).
  2. Verify EoL status. Given the age of this bug and of the affected RHEL 7.0/7.1 and contemporary Fedora releases, confirm whether the specific OS version in question is still supported. Systems on end-of-life releases will not receive further security updates and should be prioritized for upgrade or decommissioning rather than point-patching alone.
  3. Disable or remove ABRT where it is not needed. ABRT is a diagnostic convenience tool, not a required system service. On hardened or production systems, disabling the ABRT daemon and coredump hooks (systemctl disable abrtd abrt-ccpp, or removing the package entirely) eliminates the attack surface regardless of patch level.
  4. Review /etc/abrt/abrt.conf. Confirm PrivateReports and related directory-permission settings are configured restrictively, and audit permissions on /var/spool/abrt and /var/tmp/abrt.

Detection

Because this is a decade-old local privilege-escalation bug, detection should focus on host-based indicators rather than network signatures:

  • Package version audit. Inventory all RHEL/CentOS/Fedora hosts and flag any running an abrt package predating the RHSA-2015:2505 fix (ABRT < 2.7.1). This is the most reliable way to identify exposure at scale.
  • File integrity / symlink monitoring. Alert on the creation of symbolic links inside /var/spool/abrt/, /var/tmp/abrt/, or similarly named ABRT working directories, particularly symlinks pointing to sensitive files such as /etc/passwd, /etc/shadow, /etc/sudoers, or /proc/sys/kernel/modprobe.
  • Auditd rules. Configure auditd watches on ABRT’s spool and temp directories (-w /var/spool/abrt -p wa, -w /var/tmp/abrt -p wa) to log unexpected write or attribute-change activity from non-abrt/non-root users.
  • Unexpected root-owned writes correlated with crash events. Look for ABRT-related processes (abrt-hook-ccpp, sosreport) writing to files outside their expected spool directories, or coredump-handling events immediately followed by modification of sensitive system files.
  • Process/EDR telemetry. If endpoint detection tooling is deployed, hunt for local processes invoking sosreport or triggering crashes shortly after creating symlinks in ABRT-managed paths, a strong behavioral signature of this exploitation chain, including the Metasploit abrt_sosreport_priv_esc module’s default behavior.

No public IOC list (hashes, IPs, specific exploit artifacts tied to a named campaign) is available for the exploitation activity behind the KEV addition. Prioritize the package-version audit and patching over indicator-based hunting, since patched hosts are not exploitable regardless of attacker tooling.

References