DEV Community

Gary Austin
Gary Austin

Posted on Originally published at thesecuritygator.hashnode.dev

Patched Is Not Fixed: The Second Pass After Every Patch

#security #msp #sysadmin #cybersecurity

Patched is not fixed: the second pass that turns "we patched it" into something you can show

A backup management console used mostly by MSPs was patched in August and exploited in October; per The Hacker News and Help Net Security, the vendor then confirmed the August patches did not fully fix the two flaws. The same week, a firewall management-interface flaw with no workaround and a VPN flaw exploited before the alert both landed in CISA's catalog. Our read: none of this argues against patching. It argues for a second pass after the patch. Here is what happened, what "fixed" should mean, and a five-check loop you can adapt.

"We patched it" is a sentence about a ticket. "It is fixed" is a sentence about a machine. Most weeks the two agree. In mid-October 2026 they did not, and the gap had a product name.

Our read: the useful question after any patch is not "did the ticket close". It is "what would I have to see to say it is fixed, and have I looked".

The patch that did not fully fix it

AhsayCBS is the management console for Ahsay's backup software. Per Huntress, which published its findings on 2026-10-08, it is "primarily used by managed service providers (MSPs) and system integrators." The Security Gator is not affiliated with Ahsay, Huntress, or any vendor or researcher named in this post.

Two flaws, per Huntress:

  • CVE-2026-105133 - improper authentication in the checkSysPwd function. Huntress rates it medium.
  • CVE-2026-105134 - command injection in the Replication Receiver (/rps/api/json/UpdateReceivers.do). Huntress rates it critical.

Chained, the first bypasses the login and the second runs code as NT AUTHORITY\SYSTEM: unauthenticated remote code execution on the host. We print no severity scores; KEV does not publish one, and the words above are Huntress's.

The timeline, per Huntress:

  • 2026-10-04 - Huntress identifies both flaws.
  • 2026-10-07, 23:20 UTC - first observed exploitation: suspicious child processes spawned by cbssvcX64.exe.
  • 2026-10-08 - five organizations targeted, as of that date. Huntress does not say who they were.
  • Payloads: JSP webshells, then an XMRig cryptominer renamed edge.exe to pose as Microsoft Edge, run as a service named MicrosoftEdgeUpdateSvc through a modified NSSM binary. A PowerShell script stopped the miner whenever Task Manager was open. In one incident the vulnerable WinRing0x64.sys driver was loaded.

The part that gives this week its title, per The Hacker News (2026-10-15) and Help Net Security (2026-10-15): AhsayCBS v9.15.2.59 and v10.3.4.0, released in August 2026, were initially thought to fix the flaws. Ahsay later confirmed those patches did not fully fix them. Help Net Security puts the admission in an October 12 alert. The fixed builds are the v10.3.4.45 hotfix for v10 and v9.15.2.70 for v7, v8 and v9, available through Ahsay's partner portal, with a reboot after applying. Huntress "independently verified that the AhsayCBS 10.3.4.45 hotfix mitigates the initial entry point"; earlier v10 versions were still susceptible.

CISA added both CVEs to the Known Exploited Vulnerabilities catalog on 2026-10-14 with a federal due date of 2026-10-17. KEV due dates bind Federal Civilian Executive Branch agencies only. Our read: for everyone else they are a priority signal.

Huntress's guidance: restrict access to the AhsayCBS management interface to trusted IPs or require VPN, and if indicators are found, "carry out a full host re-image from a trusted backup" because attackers may have hidden secondary backdoors. Huntress has published four Sigma rules in its threat-intel repository.

Our read: an MSP that installed the August build did the right thing with the information available. The lesson is not "they should have known". It is that the vendor's definition of fixed changed on October 12, and nothing in a closed ticket would have told them.

Three ways a door stays open

Our read, labelled as ours: this week showed three distinct ways "patched" and "fixed" diverge, on three different products.

1. The patch was incomplete. Ahsay, above. The vendor finds out later and names a new version. If nobody re-reads the advisory, the old version stays "fixed" in your records.

2. The patch was fine, but reach was the problem. Palo Alto Networks PAN-OS CVE-2026-0322 is a code injection flaw in the management interface. The vendor calls it an authenticated remote code execution vulnerability: an attacker with valid credentials and network access to the management interface can run code as root on the firewall. Affected: PA-Series and VM-Series firewalls and Panorama (Help Net Security); cybersecuritynews.com adds M-Series appliances. Cloud NGFW and Prisma Access are not affected. Palo Alto reports "very limited exploitation" against the management interface and lists three IP addresses tied to attempts. The flaw was discovered internally by Suraj Siddharudh of Palo Alto Networks. Fixes are in the PAN-OS 10.2, 11.1, 11.2, 12.1 and 12.2 branches (12.2.4 or later; 11.2.16 was expected 2026-10-15); unsupported releases must move to a supported fixed version. There is no workaround. The vendor's first mitigation is about reach: restrict management-interface access to trusted internal IP addresses. Palo Alto's advisory and the KEV addition are both dated 2026-10-14, federal due 2026-10-17 (federal civilian agencies only). Our read: "authenticated" is not a comfort word; credentials leak, and reach is the control you own.

3. The attacker was inside before the alert. Ivanti Connect Secure CVE-2026-104935 is an authentication bypass allowing remote, unauthenticated command execution; The Hacker News (2026-10-14) reports that CISA describes it as a zero-day. Affected: ICS 25.1.1.1 and prior, 25.1.2.2 and prior, and 22.8R2.4 and prior (22.8 reaches end of life on 2027-01-31). Per The Hacker News: Volexity attributes exploitation to a previously undocumented, criminally motivated actor it calls UTA0576, first observed 2026-10-03 and chained with a privilege-escalation flaw for root; Defused Cyber's decoys caught pre-disclosure exploitation starting 2026-10-01; Previdian logged 105 attempts from 50 unique IPs against honeypots as of 2026-10-14. CISA's alert is dated 2026-10-13, federal due 2026-10-16 (federal civilian agencies only). The recovery list, as The Hacker News reports it: back up the configuration, factory reset, upgrade (or rebuild virtual and cloud instances), restore the configuration, then reset all account passwords, revoke and reissue certificates, and reset API keys and license-server credentials. Our read: that list is long because the window opened twelve days before the alert, and patch day is not day one.

Also added on 2026-10-14: Cisco Secure Email Gateway CVE-2026-76519, a relative path traversal in the Advanced Malware Protection feature. Per Help Net Security, a crafted attachment can write files and run commands as root when File Reputation is enabled and Content Scanner Tools is older than 25.3.0.5525; Cisco PSIRT became aware of active exploitation in October 2026. Content Scanner Tools 25.3.0.5525 or later fixes it without an upgrade or restart; AsyncOS releases older than 16.5 should move to 16.5.0-780. No workaround. Cisco notes that attackers with root may hide evidence, so check external network and firewall logs for unexpected uploads. Federal due 2026-10-17, federal civilian agencies only.

What "fixed" should mean

Our read: three statements, each one checkable, each one with evidence behind it.

  1. The version running on the machine is the version the vendor names as fixed today. Not the version that was fixed when you installed it. Today's.
  2. The interface can be reached only from where you decided. Management consoles, admin portals and replication endpoints are not internet-facing unless someone chose that and wrote it down.
  3. Nobody got in before the door closed, or you have looked. Logs for the IPs in the advisory. Unexpected admin accounts. Unexpected services and child processes. Unexpected outbound connections.

If you cannot make all three statements, the ticket is closed and the work is not.

The fix-verification loop

This is our framing, not from any source: a practical starting point to adapt. It is the second pass after a patch ticket closes, and it extends step 3 of last week's acting-CISO cadence (the known-exploited check). Same order, every time.

  1. Re-read the advisory today. Is the version you installed still the version the vendor names? The Ahsay lesson: the August build was the fix until October 12.
  2. Confirm the running version on the machine. Not the ticket, not the change record. A version string from the box, with a screenshot or export kept.
  3. Who can reach the interface? Trusted IPs or VPN for every management plane. The PAN-OS lesson: valid credentials plus reach was enough, and the vendor's own first mitigation is to restrict reach.
  4. Look for compromise before and after. If you find indicators, follow the vendor's recovery list. For Ivanti that means factory reset and rotate everything; for AhsayCBS, Huntress says re-image from a trusted backup. Not a cleanup. A rebuild.
  5. Evidence and the register. Date, version confirmed, who can reach it, what you looked for, what you found. Decision (fix, accept or transfer), owner, date.

A minimum record per system, in whatever you already use:

client: example-co
system: backup-console
product: ""
advisory_reread: 2026-10-20          # date you re-read the vendor advisory
fixed_version_named_today: ""
running_version_confirmed: ""
reachable_from: "trusted-ips | vpn | internet (decided by: )"
compromise_check: 2026-10-20         # logs, accounts, services, outbound
indicators_found: none | 
decision: fix | accept | transfer
owner: ""
evidence: ""
Enter fullscreen mode Exit fullscreen mode

Our read: the fifth check is the one that makes the other four something you can show. A client who asks "are we exposed to the Ahsay issue" should get a date and a version string, not a shrug.

What we do not know

  • How many AhsayCBS servers were exposed. No source we read gives a number.
  • Whether any of the five organizations Huntress saw were MSPs. Huntress does not say.
  • Who among you runs these products. If you do not know either, start with the inventory from last week.
  • Current status. We read these items on 2026-10-16 from Huntress, The Hacker News, Help Net Security and cybersecuritynews.com; cisa.gov did not render to our fetcher, so KEV dates come from those outlets, which agree. Check the catalog and the vendor advisories directly before acting on any of it.
  • Counterfactuals. We are not saying any of this would have stopped a specific incident. We are saying a second pass is cheaper than finding out in October that August did not take.

Take the loop with you

This week's free kit, The Fix-Verification Kit (Gatorbyte #017), is the five-check loop above as something you can hand over: a per-system Fix-Verification Log, a Fix-Verification Register (version installed, version the vendor names today, confirmed on the box, who can reach it, compromise checks, decision, owner, evidence), a reach checklist, a compromise-check hunt list and an evidence register, with CSV and Excel export. It runs offline as a Windows app: a portable .exe with a one-file .html alongside, no account, no server, no network requests. Free to use inside your organization and with your clients, including in paid engagements.
→ https://thesecuritygator.gumroad.com/l/gb017-fix-verification-kit

When the check fails and the vendor's recovery list says rotate - the Ivanti list is reset passwords, revoke and reissue certificates, reset API keys - that is a secrets-rotation job, and The Leaked-Secret Response Kit (Gatorbyte #016) is built for that bookkeeping: a first-hour runbook, a secret hunt, a secrets register and an evidence register.
→ https://thesecuritygator.gumroad.com/l/gb016-leaked-secret-response-kit

Both kits are a practical starting point to review and adapt for your organization; not legal, compliance, or audit advice, and not a substitute for the vendor's advisory, your incident-response plan, or a forensic investigation. The Security Gator is not affiliated with Ahsay, Huntress, Palo Alto Networks, Ivanti, Cisco, Volexity, Defused Cyber, Previdian or any vendor or researcher named in this post.

Sources:

Top comments (0)