Federal Watchdog Issues Urgent Warning Over SolarWinds and Ivanti Security Holes

What CISA actually flagged, and what it did not

Start with a correction you will not find on most news sites. As of today, none of the three flaws below sits on CISA’s KEV catalog. They are all real, all fixed by the vendor, and all worth patching. But a critical rating isn’t the same as attackers using it, and treating every high score as an emergency is how good teams end up patching the wrong things.

Here is what is true. Ivanti’s gateways were hit hard in early 2024, through a different pair of flaws that attackers chained together and used in real attacks. Those two are on KEV. That history is why any Ivanti gateway flaw earns a fast look, even when the newest one has not been used in an attack yet.

The three flaws, accurately

All three are genuine and already patched. What separates them is how urgent each one is. Here they are side by side. Here is each flaw in plain terms, with one thing to watch for on the box itself.

SolarWinds Access Rights Manager, CVE-2024-28991. A critical flaw, scored 9.0, that lets an attacker with valid access run code on the server. SolarWinds fixed it in ARM 2024.3.1, and there is no confirmed use in the wild. Watch for code running under the ARM service account or odd child processes on that host.

Ivanti Connect Secure and Policy Secure, CVE-2024-22024. A high flaw, scored 8.3, in the login component. It lets an attacker reach restricted files without logging in. A public proof of concept exists, so do not sit on it. Ivanti fixed it in the February 2024 builds. Watch for unexpected requests to the SAML login paths on the gateway.

HPE Aruba, CVE-2023-22747. A critical flaw, scored 9.8, that lets an attacker with no login run code as a privileged user by sending crafted packets to a management port. Aruba patched it in 2023. Watch for unexpected traffic to the PAPI port, UDP 8211, from outside your network.

KEV vs. a high severity score

A severity score and a KEV listing answer two different questions. The score tells you how bad a flaw could be if someone used it. The KEV listing tells you whether anyone is using it. You need both, but they do different jobs. The score sets the ceiling. KEV sets the schedule. Tens of thousands of flaws are scored every year. Only a thin slice ever shows up in a real attack. An even thinner slice is both used by attackers and sitting exposed in your own environment. That last slice is the work. Everything above it is planning, not panic. For a fuller method, see our guide to a risk-based, fix-first list and the difference between exposure and vulnerability management.

How to prioritize what to patch first

You do not need a bigger team to handle this well. You need an order of operations. Here is one that holds up.In practice, the loop above comes down to four moves:

• Find what you have. You cannot fix what you cannot see. Scan for any SolarWinds ARM, Ivanti gateway, or Aruba device that is reachable from the internet.
• Sort by exploitability, not just by score. Put anything on the KEV list first. Then flaws with a public proof of concept. Then the rest.
• Confirm it is reachable. A critical flaw on a box no attacker can touch is not an emergency. Check what is actually reachable before you pull people off other work.
• Patch, then prove it. Apply the fix, retest, and keep the record. A patch you never checked is a hope, not a fix.

What to do if you run SolarWinds ARM, Ivanti, or Aruba

If any of these products are in your stack, three moves cover most of the risk.

• Patch to the fixed versions above. That closes all three flaws at the source.
• Take management interfaces off the public internet. None of these should answer to the open web. This alone removes most of the attack surface.
• Tighten access and limit blast radius. Add strong login controls and limit what any single account can reach, so one foothold doesn’t turn into full access. Our guide to zero trust principles walks through how.

How Secure.com helps

The hard part is not reading a CISA advisory. It is knowing which flaws are actually reachable in your environment, then closing them and proving it. Secure.com runs governed AI teammates above the stack you already own, so the work moves off your team while your team keeps the final say.

• A Red Teammate validates what is genuinely exploitable in your environment, so you patch by proof, not by score.
• A Cloud Security Teammate finds the SolarWinds, Ivanti, and Aruba boxes exposed to the internet and drives the fix.
• A SOC Teammate watches for the behavior these flaws produce, so exploitation doesn’t go undetected.
• Every consequential action pauses for your approval and is logged, so you can show a board or auditor exactly what happened.
• It runs above your existing stack, with no rip-and-replace, and can give your team back hundreds of hours a month.

Frequently asked questions