Patch priority for the final week of August

# Patch priority for the final week of August Friday is usually the day security teams pretend they've won the week so they can go home and forget the vulnerabilities they ignored on Tuesday. But if you're looking at your dashboard this morning, you'll see that CISA isn't interested in your weekend plans. The list of Known Exploited Vulnerabilities (KEV) grew this week, and as usual, there is a wide gap between what the vendor calls "critical" and what actually keeps an attacker awake at night. Most companies treat patching like a grocery list—they try to get everything before the store closes. That's a mistake. You don't buy the fancy olive oil when the house is on fire; you put out the fire first. Here is how you should actually rank your priorities for the next 72 hours. First, if you are running Citrix NetScaler ADC or Gateway, and you haven't addressed CVE-2026-8452, stop reading this and go do it now. The federal patch deadline is today, August 29. This isn't a theoretical risk. This is an internet-facing gateway. When a flaw hits the gateway, attackers don't need to trick your employees into clicking a link; they just walk through the front door. The same urgency applies to those running Microsoft SQL Server instances exposed to the wild via CVE-2019-1068. It's an old bug from 2019, which makes its addition to the KEV this week even more embarrassing for the organizations still running it. If you're using a database version that old in a production environment, you aren't managing legacy systems; you're maintaining a museum of vulnerabilities for criminals. The deadline for this is also today, August 29. These are your "Tier 1" priorities because they represent the shortest distance between an attacker and your crown jewels. Then we have the "Tier 2" list: things that are being actively exploited but might be slightly further behind the perimeter. Gitea (CVE-2026-60004) is currently dropping miner-like payloads, and ownCloud (CVE-2023-49105) was just added to the KEV on August 27 with a deadline of August 30. We've already seen the human cost of ignoring the latter—the Philippine nuclear research body had its internal records walked out the door because of it. The second-order effect here is what people miss. When a government research body or a code repository like Gitea gets hit, it isn't just about the data on that one server. It's about the credentials stored there and the trust relationships they hold with other agencies. A breach at a nuclear research site doesn't stay in the research site; it flows downstream to every contractor and international partner who shared a folder with them. Now, let's talk about what can wait. You'll see several Linux Kernel flaws on this week's list, including CVE-2022-0995 and others added on August 27. You'll also see Red Hat Libuser and the Automatic Bug Reporting Tool (CVE-2015-3246 and CVE-2015-5287). Unless you are running a highly specific, high-risk configuration, these can wait until Monday. Why? Because most of these are privilege escalation flaws. To use them, an attacker generally already has to be on the box. If your front door (NetScaler) is wide open and your basement windows (SQL Server) are broken, spending your Friday afternoon patching a privilege escalation bug in the attic is just performing "security theater" for your boss. It makes the report look cleaner, but it doesn't actually make the company safer. This brings us to the incentive problem. Security teams are often measured by "patch compliance percentages." If they patch 90% of the vulnerabilities on a list, they get a gold star. The problem is that the 10% they skip—the difficult, high-uptime systems like an edge gateway—are exactly where 100% of the risk lives. Executives hate downtime, so they push back on patching the NetScalers and SQL servers because those are "mission critical." They argue that a reboot will cost the company thousands in lost productivity. But look at Carhartt, which just saw 12.9 million user accounts exposed. Or look at the fallout from the Boston Scientific attack, where shipment delays have lasted for weeks. The cost of a planned four-hour maintenance window is a rounding error compared to the cost of a total operational halt. The objection is always the same: "We can't take the system offline during business hours." My response is simple: The attackers aren't waiting for your scheduled maintenance window. They are operating on their own timeline, and they've already decided that your uptime is less important than their payday. So, here is the uncomfortable question for the weekend: If you’re choosing not to patch a known exploited gateway bug because of "operational stability," who is actually making that decision—the person who has to defend the network, or the person who just doesn't want to explain a four-hour outage to their VP? Patch the gateways today. Patch the repositories tomorrow. Leave the Linux kernel for Monday.