ScienceLogic SL1 CVE-2024-9537: Rackspace Zero-Day

What to do

1. Check the SL1 version on every appliance (System > Tools > Updates) and confirm it is 12.1.3, 12.2.3, 12.3 or later, or that the remediation for older lines is installed.
2. Move off 10.x and 11.x lines onto a current supported SL1 release.
3. Restrict SL1 web interfaces to an admin network or VPN.
4. If SL1 was exposed and unpatched in late 2024, rotate the device and agent credentials stored in it.
5. Ask ScienceLogic support for any detection guidance it shares privately with customers.

How to check if you are affected or compromised

• Confirm when the SL1 remediation was applied; exposure before that date is your risk window.
• Review SL1 appliance web and system logs from that window for unexpected processes, new files or outbound connections.
• Watch monitored devices for logins using credentials SL1 holds, from sources other than the SL1 collectors.

What happened#

On September 24, 2024, Rackspace found an attacker exploiting a zero-day remote code execution flaw in its ScienceLogic EM7 monitoring platform, now called SL1. Rackspace used it to monitor internal services and to generate internal performance reporting. According to The Register, three internal monitoring web servers were accessed. ScienceLogic said the flaw sat in "a non-ScienceLogic third-party utility" shipped with SL1. It built a patch with Rackspace and said it knew of only one exploited customer.

Rackspace told customers the exposed data was limited monitoring information. It included customer account names and numbers, usernames, internal device IDs and names, device IP addresses, and AES256-encrypted internal device agent credentials. Rackspace took the dashboard offline and rotated the agent credentials. It also told customers they needed to take no action. CISA, acting as CNA, published CVE-2024-9537 on October 18. It scored the flaw CVSS 4.0 9.3 and CVSS 3.1 9.8, and added it to the KEV catalog on October 21, 2024.

Who is affected#

Only organizations running SL1 themselves. The CVE record says the issue is fixed in SL1 12.1.3+, 12.2.3+ and 12.3+. ScienceLogic also made remediations for the 10.1.x, 10.2.x, 11.1.x, 11.2.x and 11.3.x lines. ScienceLogic's knowledge-base articles on the fix sit behind its customer portal, and the exact builds for older lines are not in the public record. Rackspace customers who only consumed Rackspace's monitoring service did not run SL1 themselves and have nothing to patch.

Do you really need to act?#

If you run SL1, confirm you are patched. Otherwise, little has changed since 2024. What stands out is how much is still unknown. As of Oct 23, 2026, the following have not been disclosed:

• The name of the third-party utility. ScienceLogic withheld it "to diminish potential risk to our customers"; Arctic Wolf adds that other products may use the same utility.
• The root cause, attack vector details and indicators of compromise. The NVD entry calls it an "unspecified vulnerability."
• The attacker. Arctic Wolf found no link to a known group and no public proof of concept.
• How many Rackspace customers were affected. Rackspace did not answer that question.

Because the component is unnamed, you cannot check whether other software you run shares it. The Stack noted that neither ScienceLogic nor CISA had named it. The real risk sits with the monitoring platform itself: it holds credentials for, and network paths to, many monitored devices.

What to do now#

1. Check the SL1 version on every appliance under System > Tools > Updates, the location Arctic Wolf cites. Confirm 12.1.3, 12.2.3, 12.3 or later, or the vendor remediation on older lines.
2. Move any 10.x or 11.x deployment to a current supported SL1 release.
3. Restrict SL1 web interfaces to an admin network or VPN.
4. If SL1 was internet-reachable and unpatched in late 2024, rotate the device and agent credentials it stores, as Rackspace did.
5. Ask ScienceLogic support for any private detection guidance.

How to tell if you were hit#

No public indicators exist. Work from the risk window instead: find when the remediation was applied, then review SL1 web and system logs from before that date. Look for unexpected processes, new files or unusual outbound connections. On monitored devices, look for logins with SL1-held credentials from hosts other than your SL1 collectors. Rackspace customers can check that the device IPs exposed in 2024 show no unusual inbound scanning or login attempts. As BleepingComputer noted, leaked IPs make targeting easier.

Timeline#

• Sep 24, 2024 — Rackspace detects exploitation and takes its ScienceLogic dashboard offline.
• Sep 30, 2024 — The incident is reported publicly; ScienceLogic confirms a third-party utility zero-day and a patch.
• Oct 18, 2024 — CISA publishes CVE-2024-9537 with fixed versions.
• Oct 21, 2024 — CISA adds the CVE to KEV, with a due date of November 11.

Vulnerability records

• CVE-2024-9537 · KEV 2024-10-21 · ScienceLogic SL1 (formerly EM7) is affected by an unspecified vulnerability involving an unspecified third-party component packaged with SL1.

Sources

Original sources first: vendor and project advisories, CVE and government records, the discoverers’ write-ups. Every claim above links to one of these. See how the Security Desk works.

Original and primary sources

1. CVE record — CVE-2024-9537 cve.org
2. NVD — CVE-2024-9537 nvd.nist.gov
3. CISA — Known Exploited Vulnerabilities: CVE-2024-9537 cisa.gov
4. Arctic Wolf — Rackspace breach linked to zero-day in ScienceLogic SL1's third-party utility arcticwolf.com
5. The Stack — ScienceLogic critical bug remains unidentified thestack.technology

Coverage and analysis

1. The Register — Rackspace monitoring data stolen in ScienceLogic zero-day attack theregister.com
2. BleepingComputer — Rackspace monitoring data stolen in ScienceLogic zero-day attack bleepingcomputer.com