May 2026 Deadline? Why CISA's New KEV Entries Matter Now
Just saw the update from CISA adding four new flaws to the KEV catalog. While the federal deadline for remediation is set for May 2026, the citation of 'active exploitation' means we can't treat this as a future problem.
The standout is CVE-2024-57726 (CVSS 9.9), which impacts SimpleHelp remote support software. It's a missing authorization vulnerability, which essentially means attackers can bypass authentication checks entirely. If you have this exposed to the internet, assume it's owned.
Also flagged are vulnerabilities in Samsung MagicINFO 9 Server and D-Link DIR-823X series routers. The D-Link gear is particularly concerning since a lot of these older consumer routers end up in SMB environments or IoT labs and rarely get patched.
If you need to quickly audit your Linux endpoints for SimpleHelp installations, here is a quick grep one-liner to find the running processes:
ps aux | grep -i "simplehelp" | grep -v grep
And if you are hunting for the MagicINFO instances on your network, checking for the default web interface ports is a good start:
nmap -p 80,443,8000-8100 --open
Has anyone started seeing IOCs related to the SimpleHelp auth bypass in the wild yet? I'm curious if this is being leveraged by initial access brokers or just opportunistic scanning.
The D-Link DIR-823X issue is a nightmare for MSPs. I've seen these units in client closets for years, 'just working,' usually with the default credentials still set because no one wants to touch the routing config and break connectivity. Since many are EOL, I'm telling clients to just replace them. You can't patch hardware that the vendor no longer supports.
We use SimpleHelp internally, but we keep it behind a VPN and never expose the management interface to the public web. That saved us this time. However, this is a good reminder to review our allow-lists. For those detecting this, you might want to look for spikes in traffic on TCP port 8080 if you aren't using the default config.
A CVSS 9.9 for missing authorization is brutal. It usually implies the attacker can invoke privileged functionality just by sending a crafted request without any session token. If you are running MagicINFO 9, I'd suggest blocking inbound traffic to the server at the perimeter until a patch is validated. The risk of ransomware dropping via these digital signage servers is non-trivial.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access