Patching closes the door. It doesn't check who's already inside

When a serious flaw is being exploited, the instinct is to patch and move on. Two advisories from this month are a useful reminder that patching closes the door, but it doesn't tell you who came in while it was open.

Two recent examples

On 14 October Cisco warned that a critical flaw in Cisco Secure Email Gateway, CVE-2026-76519, was being exploited. According to The Hacker News, an attacker who isn't signed in can write files to the appliance by emailing a crafted attachment, and Cisco says that could lead to commands running as root. Fixed releases are out. But Cisco's advice goes well beyond "upgrade". It tells admins to run a check for signs of compromise on every cluster member, to look through firewall logs for odd uploads and downloads, and, if a device has been compromised, to keep the forensic data before upgrading, because upgrading destroys the logs. A compromised gateway should be rebuilt on a fixed release, with the configuration set up again by hand rather than imported, and with credentials and keys renewed.

A week later, on 20 October, eSecurity Planet reported on CVE-2026-110447 in the Collabora Online built-in CODE server, an optional app for Nextcloud. Attacks had been seen since 10 September. Attackers planted PHP web shells in the app's folder and searched for password manager and crypto wallet files. Collabora's fix is version 26.4.303 of the app, and it says simply disabling the app isn't enough. The article is blunt about the rest: patching does not remove access an attacker already has.

Both cases have the same lesson. If a flaw was exploited before you patched, the patch is only step one.

Why patching isn't the end

Most attackers who get in through a flaw don't rely on that flaw for long. The first thing they usually do is leave themselves another way back in. That might be a web shell, a new account, a scheduled task, a stolen password or token, or a change to the configuration. Patch the original flaw and all of that stays in place.

There's also a time problem. In the Collabora case, attacks started in September and the advisory landed in October. If a system was exposed in that window, you have to assume someone may have used it.

A simple routine for exploited flaws

When a vendor or CISA says a flaw is being exploited, I find it helps to work through the same short list every time.

Find out if you're exposed. Check versions and, just as important, whether the affected feature is switched on. In the Cisco case, only gateways with File Reputation enabled on a mail policy and an older content scanner were exposed.
Work out the window. When did exploitation start, and when did you patch? Anything exposed in between needs checking, not just patching.
Save evidence before you change things. Copy the logs and any suspicious files first. Some upgrades wipe exactly what you'd need later.
Patch or remove. Apply the fixed version. If you can't, take the service off the internet or remove the component.
Hunt for what's left behind. Use the vendor's indicators of compromise. Look for unexpected files in web folders, new admin accounts, new scheduled tasks and unusual outbound connections.
Rotate what the system could see. If the service account could read passwords, keys or tokens, change them. Assume anything it could read may have been copied.
Rebuild if in doubt. If you find signs of compromise, a clean rebuild on a fixed version is usually quicker and safer than trying to clean the old system.

Make it easier next time

A few habits make this routine much less painful:

Keep logs off the box. If logs go to a central system, an upgrade or an attacker can't wipe them.
Know what's internet-facing. Keep a list of every appliance and web app exposed to the internet, with its version. When an advisory drops, you can answer "are we affected?" in minutes.
Keep configurations documented. Cisco's advice to rebuild without importing the old configuration is much easier if you have the settings written down.
Give services the least access they need. In the Collabora case, the damage depended on what the web server account could read. Less access means less to rotate.
Remove what you don't use. Optional apps and features add risk. If nobody uses it, take it out.

The short version

For an ordinary patch, patching is the job. For a flaw that was exploited before you patched, it's the start of the job. Check the window, keep the evidence, look for what was left behind, and rotate anything the system could see.

Sources

← All posts