ZeroDayAlert

CVE-2015-5287: Red Hat Automatic Bug Reporting Tool Privilege Escalation Vulnerability

Red Hat Automatic Bug Reporting Tool (ABRT) contains a privilege escalation vulnerability that could allow local users with certain permissions to gain privileges via a symlink attack on a file with a predictable name. The impacted product(s) could be end-of-life (EoL) and/or end-of-service (EoS). Users are advised to discontinue use and/or transition to a supported version.

Red Hat Automatic Bug Reporting Tool Added to KEV 2026-08-26 Federal due 2026-09-09 Known ransomware use

Required action — quoted from CISA

Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA’s “Forensics Triage Requirements” (see URL in Notes). Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable. Stakeholders are responsible for evaluating each asset's internet exposure and ensuring adherence to BOD 26-04 patching guidelines.

Where this comes from. The identifier, product, dates and required action above are copied verbatim from the CISA Known Exploited Vulnerabilities catalog. The action plan below is written by an AI agent from that record and published automatically. AssurePort has not independently tested this vulnerability and makes no claim about whether any specific system is affected.

Who is affected

Red Hat's Automatic Bug Reporting Tool (ABRT) is vulnerable to privilege escalation by local users with certain permissions through a symlink attack. The record notes that affected product versions may be end-of-life or end-of-service, and does not specify which Red Hat distributions or ABRT versions are in scope. You should treat this as potentially affecting older Red Hat Enterprise Linux deployments where ABRT was enabled by default.

How to check whether this touches you

  • Inventory Red Hat systems in your estate and identify those running ABRT; check /usr/sbin/abrtd or query rpm -q abrt on each host.
  • Confirm whether ABRT is enabled and running: check systemctl status abrtd and whether the service is set to start on boot.
  • Establish which local user accounts exist on affected systems and whether they have permissions to trigger ABRT crash reporting (typically unprivileged users can do so).
  • Query Red Hat's security advisories and your patch management system for the ABRT package version on each system; version alone is a signal, not proof, since backported fixes may exist in your distribution's build.
  • If ABRT is handling crash reports from applications you run, determine whether those applications are still actively supported.

What to do

  1. Consult Red Hat's security guidance for this CVE and confirm whether a patch is available for your specific ABRT version and distribution release; if the product is end-of-life, Red Hat may not have released one.
  2. If a patch exists and the product remains supported, schedule patching within your organisation's BOD 26-04 timelines (federal agencies: by 2026-09-09; others: per your risk assessment).
  3. If no patch is available or the product is unsupported, disable ABRT immediately: systemctl disable abrtd && systemctl stop abrtd, and document the decision and date.
  4. Review whether ABRT is necessary for your operational or compliance requirements; if not, consider removing the package entirely.
  5. Audit /var/spool/abrt and /tmp for predictable symlink targets that could be exploited by local users; document any suspicious activity and preserve logs.
  6. If you cannot patch or disable ABRT within your change windows, restrict local shell access to trusted administrators and monitor for symlink-based attacks in system logs.

If you find you were exposed

Exploitation of symlink races typically requires repeated attempts or specific timing, so review system logs from the past six months for failed ABRT operations or privilege escalation attempts (sudo logs, auth.log, SELinux audit logs if enabled). Check whether unprivileged users successfully escalated to root or another user during the exposure period. Log retention and the age of ABRT's spool directory will determine how far back you can hunt; if logs have rotated, focus on current running processes and file ownership anomalies.

Get these the morning they land.

One email, only when a vulnerability is newly confirmed as exploited — the CISA record plus our action plan. No more than one a day, and nothing on quiet days.

Knowing it exists is not the same as knowing you are exposed.

This page can tell you that CVE-2015-5287 is being exploited. It cannot tell you whether Automatic Bug Reporting Tool is running somewhere of yours that is reachable. That question is what a scan answers.

Check your own surface →