DEV Community: Gary Austin

Patched Is Not Fixed: The Second Pass After Every Patch

Gary Austin — Wed, 21 Oct 2026 14:07:00 +0000

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.

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.
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.
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.

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.
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.
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.
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.
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: ""

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:

Huntress, Threat Actors Exploit Critical AhsayCBS Flaws to Drop Webshells and XMRig Cryptominer, October 8, 2026 (updated October 12): https://www.huntress.com/blog/ahsaycbs-flaws-exploit
The Hacker News, AhsayCBS Flaws Exploited to Deploy Web Shells Get New Fixes After Incomplete Patches, October 15, 2026: https://thehackernews.com/2026/10/ahsaycbs-flaws-exploited-to-deploy-web.html
Help Net Security, CISA flags exploited flaws in Palo Alto, Cisco and Ahsay products, October 15, 2026: https://www.helpnetsecurity.com/2026/10/15/cve-2026-0322-cve-2026-76519-cve-2026-105133-cve-2026-105134-exploted/
cybersecuritynews.com, CISA Warns of Palo Alto Networks PAN-OS Code Injection Vulnerability Exploited in Attacks, October 16, 2026: https://cybersecuritynews.com/pan-os-vulnerability-exploited-cisa-warns/
The Hacker News, CISA Urges Immediate Ivanti Connect Secure Updates as Honeypots Log 105 Exploit Attempts, October 14, 2026: https://thehackernews.com/2026/10/cisa-urges-immediate-ivanti-connect.html

The Acting CISO: The Weekly Cadence

Gary Austin — Wed, 14 Oct 2026 14:07:01 +0000

The acting CISO: the weekly cadence that turns "you handle our security" into a job

In a survey commissioned by Sophos, a security vendor, MSPs estimate that 46% of their customers rely on them to act as CISO. Only a third say they are completely confident they can document compliance continuously across customers. Our read: the gap looks like a missing cadence more than a missing tool. A cadence is a practical starting point to adapt: the same few questions, answered the same way, on a schedule, with the evidence kept. Here is what the survey does and does not say, what the latest vulnerability news teaches about inventory, and a six-step weekly loop you can adapt.

A client says it in a kickoff call, a renewal meeting, or a ticket at 4:40 on a Friday: "You handle our security, right?"

Say yes, and you may have accepted a job. Our read: nobody may have written the job description, scoped it, budgeted it, or decided what "handled" means when a firewall CVE drops on a Tuesday. Our read: the client may assume someone is watching, deciding, and keeping records.

Our read: that is the acting CISO problem, and it is mostly an operations problem, not a security-product problem.

The job may not be written down

A survey commissioned by Sophos, a security vendor, put a number on the pattern. Read it with that in mind: Sophos sells security products and announced a CISO-service offering in the same release. We do not discuss that product, and The Security Gator is not affiliated with Sophos or any vendor named in this post.

The method, because it matters:

Who was asked: 800 MSPs for the Sophos-commissioned survey, senior to board-level stakeholders, across the US, UK, Germany, France, Singapore, Australia and Brazil.
Who ran it: Vanson Bourne, commissioned by Sophos. Fieldwork was April 2026. The release describes the research as independent and vendor-agnostic.
What it measures: MSP perception and practice. It does not measure customer security outcomes.

The headline, in the Sophos-commissioned survey: on average, MSPs estimate that 46% of their customers rely on them to act as CISO. That is an MSP estimate, not a count of customers, and a vendor-commissioned one. Treat it as a signal about how the market describes the role, not as a measurement of anyone's client base.

Two more figures from the Sophos-commissioned survey, each an MSP-reported number. In the Sophos-commissioned survey, 84% of MSPs expect demand for CISO services to rise over the next 12 months, which is an expectation, not a measurement. In the same Sophos-commissioned survey, 99% provide at least one cybersecurity compliance service.

Our read: if that sounds like your week, the useful question is not "which tool do we buy". It is "what do we do every week, and can we show it".

What the survey says about the gap, and what it cannot

The part worth a sysadmin's attention is the delivery side, again as the Sophos-commissioned survey reports it:

Finding (MSP-reported)	Value
Offer full compliance program management	58%
Offer the full range of compliance services evaluated in the survey	6%
"Completely confident" they can continuously monitor, manage and document compliance across customers	33%
Use a single tool or platform for compliance and CISO-type activities	36%
Use multiple tools	53%
Use a fully or semi-automated process for consolidated posture reports	86%
Still require some manual effort for those reports	55%
Can generate those reports quickly through a fully automated process	31%

The release characterizes multi-tool setups as delivery that "remains complex, disjointed, and potentially harder to scale." That is Sophos's framing, and it comes from a vendor with a product to sell. Sophos's Scott Barlow adds: "The challenge now is delivering that leadership consistently and efficiently across a growing customer base."

Our reading, labeled as ours: the phrase to take from this is "only a third say they are completely confident". Not "MSPs are failing". Confidence in continuous documentation is a high bar, and 33% saying "completely" tells you where the hard part is, not that anyone is doing badly.

What the survey cannot tell us:

Whether any given MSP's acting-CISO work is contracted, scoped or insured. Open question.
Whether the customers believe what the MSPs estimate.
Whether more automation produces better outcomes. The survey also includes a hypothetical estimate about time saved by a unified platform. It is a guess about a product category in a vendor-commissioned survey, so we are not repeating it as a benefit.

Our read: the pattern in the Sophos-commissioned table is the point: lots of services offered, thin confidence in continuous documentation, and 55% still need some manual effort on posture reports. A repeatable cadence is a practical starting point for exactly that.

The Pulse is an inventory lesson

Three items from the news, read 2026-10-11 via The Hacker News and cybersecuritynews.com. Our read: each is a different way of asking "do you know what you are running". A scope line before the list: CISA KEV due dates bind Federal Civilian Executive Branch agencies only. They are a useful priority signal for everyone else, not an obligation. We print no severity scores here; KEV does not publish one, and any score belongs to the article that cites it.

1. Five older flaws, added to KEV. CISA added five flaws to the Known Exploited Vulnerabilities catalog on 2026-10-08 (federal due date 2026-10-11, federal civilian agencies only): ProFTPD CVE-2015-3306 (improper access control, file read/write), ONLYOFFICE Docs CVE-2021-3199 (path traversal, possible remote code execution), Strapi CVE-2023-22894 (cleartext storage of sensitive information), Apache Struts CVE-2016-3081 (command injection when Dynamic Method Invocation is enabled) and ISC BIND CVE-2015-5477 (reachable assertion leading to denial of service via TKEY queries). The Hacker News ties the activity to "a China-linked threat actor known as Flax Typhoon"; the joint advisory it links, from agencies in AU, CA, JP, NZ, ES, UK and US, concerns a China-based company, Integrity Technology Group. The article does not say that advisory names Flax Typhoon. A CISA official, Chris Butera, is quoted referring to Chinese government-affiliated actors generally. CVE years: ProFTPD 2015, ONLYOFFICE 2021, Strapi 2023, Struts 2016, BIND 2015. Our read: nothing here is new software. It is software somebody forgot.

2. Palo Alto Networks PAN-OS GlobalProtect / Prisma Access, CVE-2026-0257. An authentication bypass. Per cybersecuritynews.com (2026-10-11), ransomware groups named as Qilin and Settra are reported to be exploiting it to create unauthorized VPN sessions and reach internal networks, per ReliaQuest. Palo Alto disclosed it on 2026-05-13 and rates it High; Panorama and Cloud NGFW are not affected. The detail that matters for this post: exposure depends on configuration, specifically authentication override cookies being enabled plus a particular certificate configuration. Mitigation per the article: upgrade per the vendor's fixed-version table, disable authentication override cookies you do not need, and use a newly generated certificate dedicated to them. Users re-authenticate after the patch. The article does not state KEV status. CISA's Known Exploited Vulnerabilities catalog does: the flaw was added on 2026-05-29 with a federal due date of 2026-06-01 (federal civilian agencies only), and the catalog marks known ransomware campaign use. We checked the catalog on 2026-10-13.

3. N-able N-central, CVE-2026-18577, an August callback. An authentication bypass from incomplete patching of CVE-2026-18556. CISA added it to KEV on 2026-08-03 (federal due date 2026-08-06, federal civilian agencies only). N-able acknowledged that "a limited number of customers" were compromised and has not disclosed the scale; the fix is in version 2026.3 HF1. It is older than the other two items, and it is here because it is the MSP's own management tool.

Our read, and it is an opinion: all three are things an acting CISO is expected to know about without being told. A forgotten legacy service. A VPN whose exposure depends on a setting, not just a version number. The tool that manages client environments. We are not claiming anyone's client was compromised through these beyond what the sources report, and we do not know which of these products you run.

Our read: that last point is the lesson. If your inventory holds only product names, "are we exposed?" is a research project. If it holds version and configuration notes per client, it is a lookup.

The six-step weekly cadence

This is our framing, not from any source: a practical starting point to adapt. One loop, same day each week, same shape every time.

Inventory. What systems, accounts and internet-facing services exist per client, and who owns each one. If it has no owner, that is the first finding.
Exposure check. What is internet-facing, which version, and which configuration options matter. The GlobalProtect item is the reminder: the version was only half the answer.
Known-exploited check. Compare the inventory to the CISA KEV catalog on a fixed day each week. Remember the due dates are federal-civilian only; use them to rank, not to excuse.
Risk register. The top items, each with an owner, a decision (fix, accept or transfer) and a date.
Evidence. Keep what you checked and when: screenshots, exports, ticket links. This is what turns "we looked" into something you can show.
One-page report. Same shape every time: what changed, what you decided, what is open, what you need from the client.

A minimum viable record per client service, in whatever you already use (a spreadsheet, a PSA custom field, a YAML file in a repo):

client: example-co
service: vpn-gateway
exposed_to_internet: true
product: ""
version: ""
config_notes: ""
owner: ""
last_checked: YYYY-MM-DD
kev_checked: YYYY-MM-DD      # compared to the catalog on this date
decision: fix | accept | transfer
decision_date: YYYY-MM-DD
evidence: ""

Our read: none of this is exotic. Its value is that it is the same every week, so the week-over-week diff becomes the report.

Role clarity, and what we do not know

The cadence is the operational half. The other half is a sentence in writing: what you are accountable for, and what you are not. Which systems are in scope, who decides on the client side, what "acting CISO" means in your service description and what it does not. We cannot tell you what that sentence should say for your contract, and we do not give legal advice on liability, insurance, or whether a title like "vCISO" has regulatory meaning. For any specific agreement, that is a question for counsel.

What we do not know, stated plainly:

Whether the 46% reflects your clients. It is a vendor-commissioned survey of MSPs' own estimates, averaged across 800 firms in seven countries.
Whether acting-CISO work is usually contracted, scoped or insured. The sources do not say.
Who among you runs the products in the Pulse. If you do not know either, see the inventory section.
Current status. Pulse details were read on 2026-10-11 from news coverage. Check the KEV catalog and the vendor advisories directly before acting on any of it.

Take the loop with you

The cadence above is the argument. If you want the discipline of a written, repeatable response in one place, our standing free field guide, The Leaked-Secret Response Kit (Gatorbyte #016), is built in the same spirit: a first-hour runbook, a secret hunt, a secrets register with owner, revocation path and expiry columns, and an evidence register. 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/gb016-leaked-secret-response-kit

The kit is a practical starting point to review and adapt for your organization; not legal, compliance, or audit advice, and not a substitute for a forensic investigation or your incident-response plan. The Security Gator is not affiliated with Sophos, Vanson Bourne, Palo Alto Networks, N-able, or any vendor named in this post.

Sources:

Sophos, MSPs Have Quietly Become Acting CISO for Nearly Half of Their Customers, Sophos Research Finds, press release via GlobeNewswire, September 15, 2026: https://www.globenewswire.com/news-release/2026/09/15/3362118/0/en/msps-have-quietly-become-acting-ciso-for-nearly-half-of-their-customers-sophos-research-finds.html
The Hacker News, report on five older flaws added to KEV (article dated October 9, 2026): https://thehackernews.com/2026/10/flax-typhoon-exploits-five-flaws-as.html
cybersecuritynews.com, report on the Palo Alto GlobalProtect flaw and VPN access (October 11, 2026): https://cybersecuritynews.com/palo-alto-globalprotect-flaw-vpn-access
The Hacker News, report on CISA adding the N-able N-central flaw to KEV (August 2026): https://thehackernews.com/2026/08/cisa-adds-exploited-n-able-n-central.html

It Compiles. Nobody Asked If It Was Safe: The One-Afternoon Review for an AI-Built App

Gary Austin — Wed, 30 Sep 2026 14:07:00 +0000

It compiles. Nobody asked if it was safe: the one-afternoon review for an AI-built app

In Veracode's 2026 testing, AI-generated code compiled almost every time and passed security checks about half the time — with no security prompting, on raw models. Two public cases — a scan of Lovable's showcase in 2025 and Wiz's Moltbook disclosure in 2026 — show one shape a failure can take: a key that is meant to be public, and a server-side rule that was missing or wrong. Here is the mechanism, what the record actually establishes, what it does not, and the afternoon that checks for it.

Somebody on your side of the table shipped an app this quarter that no security person ever read. A client intake portal. A technician's internal tool. A dashboard built in an afternoon with an AI coding assistant and a login page that made it feel finished.

It works. I believe you. That is not the question any more.

Working is the easy part now

Veracode's 2026 GenAI Code Security Report (press release, July 28, 2026) tracks code generated by more than 100 models. By Veracode's numbers:

the code compiles at a near-universal ~100% syntax pass rate;
it passes Veracode's security tests 56% of the time on average — "virtually unchanged" from their previous report;
the best model on their summer leaderboard still failed nearly one security task in three.

Two conditions ride with those numbers and they matter: the tests used no security-specific prompting, and they ran against raw models — not agents, not tools with guardrails, not code a human reviewed. Veracode says so explicitly.

So the honest reading is not "AI code is insecure." It is narrower and more useful: code that nobody asked about security, and nobody reviewed, passes security checks about half the time. Our read: that describes a lot of the apps quietly going live inside small businesses right now.

The key is supposed to be public

Many of these apps put their data in a hosted database — Supabase is a common one — and the browser talks to it directly. To do that, the page carries a key.

Here is the part people get backwards: that key is supposed to be public. A publishable (or "anon") key is designed to sit in the browser. Anyone can read it. That is fine, because the key is not the lock.

The lock is a rule on the database itself — in Supabase, a Row Level Security policy — that says this user can read these rows, and only these. When the rule exists and is right, the public key is harmless. When the rule is missing or wrong, the public key opens the whole table, for anyone, without logging in. And nothing on the screen looks any different.

That is the entire mechanism behind both cases below.

170 of 1,645: the showcase scan

In March 2025, Matt Palmer — who works in developer relations at Replit, which builds a competing AI app builder; read the finding with that in mind, and read his method yourself — found a Lovable-built site that would hand over its whole users table when a request was edited to ask for everything. So he and a colleague checked the rest.

Lovable keeps a showcase page of launched projects. Their script visited the homepages of 1,645 projects listed there, captured each request to the database, and re-issued it asking for everything. Per Palmer's published statement:

170 projects (about 10.3%) returned data with inadequate Row Level Security;
across 303 endpoints;
exposing things like emails, phone numbers, subscription and payment details, and developer API keys.

He is careful about the method, and so are we: the script only analysed homepages. It never logged in and never crawled deeper. Our read: that count is a floor, not a ceiling.

It was published as CVE-2025-48757 on May 29, 2025. Palmer also writes (as of May 2025) that Lovable's later "security scan" checked that an RLS policy existed, not whether it was correct. That is his assessment — but hold onto the underlying point, because it comes back below.

One setting: Wiz and Moltbook

In January 2026, Moltbook — a social network for AI agents that had just gone viral, and whose founder said publicly he had vibe-coded it — got a visit from Wiz researchers who, in their words, were "simply browsing like normal users."

Within minutes they found a Supabase key in the site's client-side JavaScript. Wiz is precise here: it was a publishable key, and exposing one "does not automatically indicate a security failure." The failure was behind it — no Row Level Security. Per Wiz's write-up (Gal Nagli, February 2, 2026), that key gave unauthenticated read and write access to the production database:

1.5 million API authentication tokens;
35,000 email addresses;
private messages between agents, some containing plaintext third-party API keys;
and the ability to edit live posts.

Moltbook secured it within hours of Wiz's report, over several rounds of fixes, and Wiz deleted the data it had accessed. This was a research disclosure, not an attack report. (Wiz notes that researcher Jameson O'Reilly independently found the same misconfiguration.) Wiz's own summary is the line worth keeping: the issue "ultimately traced back to a single Supabase configuration setting."

The button is hidden. The route is not.

Neither case is new in kind. OWASP's Top 10:2025 keeps Broken Access Control at #1; in OWASP's contributed test data, every application tested had some form of it. And OWASP states the principle plainly: access control is only effective when implemented in trusted server-side code.

One of OWASP's own example scenarios is an app that keeps its access checks in the front end — JavaScript that stops you navigating to the admin page — while the admin URL itself still answers a direct request. The attacker never clicks the button. They call the route.

Our read: this is the pattern an assistant ships most easily, because it builds exactly what was asked for: a page, a hidden button, a redirect for non-admins. It all looks right in a demo. Nothing in the demo asked the server to refuse.

What we do not know

It is worth being honest about the edges of the record.

We do not know how many AI-built apps your clients are running today. If you do not know either, that is finding number one.
We do not know how many of those 170 are still open. Palmer's scan is from March 2025.
We do not know how representative either case is. One was a showcase of one builder's apps; the other was one viral app. Neither is a census.

What does hold across both: a rule that exists is not a rule that works, and the only way to know which one you have is to try it — from the outside, as somebody who should not get in.

The afternoon

One app. The one a real person can sign into today. Put whoever built it in the room.

THE PRE-LAUNCH AFTERNOON — ONE APP
1  PICK     one app a real person can sign into.
2  SECRETS  search the BUILT front end (view source,
            network tab, build output) — not the repo —
            for keys. Publishable key: fine.
            Service / admin key: remove it,
            redeploy, rotate, treat as exposed.
3  ROWS     for every table the browser can reach,
            confirm the row rule EXISTS, then prove it
            WORKS with two test accounts: B's record
            as A, and with no session; read AND
            write. You should get nothing back.
4  ROUTES   call the admin API directly as an
            ordinary user. Expect a refusal (401/
            403/404) or empty result, never data.
5  HOW      every PASS gets a How-verified line, a date
            and a named human.

Step 5 is the one that turns an afternoon into evidence. "The assistant said it did" is not a how. "Called /api/users/2 as user 1, got 403, 2026-09-29, J. Smith" is.

Two ground rules. Run this only on apps you own or are authorized to test. And if a check returns data that should not have been readable, treat it as a potential exposure — follow your incident-response plan and bring in counsel and your insurer; notification duties are a legal question, not a checklist one.

The free kit: The Vibe-Coded App Pre-Launch Kit (Gatorbyte #015) is this afternoon on paper — 26 controls in six groups, the five things the login page probably forgot, a legal and trust pass, a review-only prompt for the assistant that built the app, and a pre-launch register with a How-verified column. Runs offline as a portable Windows app; no account, nothing phones home. Free to use inside your organization and with your clients, including in paid engagements.
→ https://thesecuritygator.gumroad.com/l/gb015-vibe-coded-app-prelaunch-kit

The kit supports secure-development, pre-release review and audit-preparation workflows — a practical starting point to review and adapt for your organization; not legal, compliance, or audit advice, and not a substitute for a penetration test or an application security assessment. The Security Gator is not affiliated with Veracode, Wiz, OWASP, Replit, Lovable or Moltbook.

Sources:

Veracode, 2026 GenAI Code Security Report — press release, July 28, 2026: https://www.businesswire.com/news/home/20260728207685/en/
Matt Palmer, Statement on CVE-2025-48757, May 29, 2025: https://mattpalmer.io/posts/2025/05/statement-on-CVE-2025-48757/
Wiz Research (Gal Nagli), Hacking Moltbook, February 2, 2026: https://www.wiz.io/blog/exposed-moltbook-database-reveals-millions-of-api-keys
OWASP Top 10:2025, A01 Broken Access Control: https://owasp.org/Top10/2025/A01_2025-Broken_Access_Control/

Twenty Got Three Days, Eight Got Fourteen: CISA's KEV Due Date Is the Free Sort Key Nobody Reads

Gary Austin — Wed, 23 Sep 2026 14:07:01 +0000

Twenty got three days. Eight got fourteen. Your patch queue's sort key was already free — and it's a date.

CISA's Known Exploited Vulnerabilities catalog publishes no CVSS score. Not for any entry, not ever. What it publishes is a dueDate — one per flaw — and in the first half of September 2026 that single field sorted twenty-eight CVEs into two piles with nothing in between. All ten security and remote-management products landed in the short pile. Here is how to read the field, why a Cisco-rated 10.0 and an Acronis-rated 7.8 drew the same deadline, and the one-afternoon inventory that turns it into a queue.

I pulled the catalog on September 18, 2026. It is a public JSON file — no account, no vendor, no scanner:

https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json

catalogVersion 2026.09.18 · dateReleased 2026-09-18T13:49:41.7236Z · 1,715 entries in the catalog · 28 of them added since September 1.

Open one entry: CVE ID, vendor, product, vulnerability name, dateAdded, dueDate, knownRansomwareCampaignUse, CWEs, a required action, notes.

Now notice the absence. There is no CVSS field. CISA publishes no severity score in KEV — not a base score, not a vector, nothing. Every CVSS number you have seen sitting next to a KEV entry came from a vendor or from NVD, and somebody else put it there.

What CISA publishes instead is a date.

Twenty got three days. Eight got fourteen. There is no middle.

Subtract dateAdded from dueDate across September's twenty-eight entries and the month falls into exactly two buckets.

Three days — 20 CVEs. Linux Kernel ×2 (CVE-2025-39964, CVE-2026-53266) · Google Pixel (CVE-2026-58704) · Cisco Identity Services Engine (CVE-2026-76460) · Acronis Backup (CVE-2026-87886) · Cisco Secure Email Gateway (CVE-2026-76461) · ConnectWise ScreenConnect (CVE-2026-84869) · GitLab CE/EE (CVE-2026-85706) · MikroTik RouterOS ×2 (CVE-2026-86060, CVE-2026-67277) · Citrix NetScaler (CVE-2026-19490) · Fortinet Multiple Products (CVE-2025-25249) · Cisco Secure Firewall Management Center (CVE-2026-20079) · Adobe Commerce and Magento (CVE-2026-75650) · N-able N-central (CVE-2026-86218) · Kestra OSS (CVE-2026-49869) · JFrog Artifactory (CVE-2026-82329) · Sangoma Switchvox (CVE-2026-9586) · SonicWall SMA1000 ×2 (CVE-2026-83548, CVE-2026-83549)

Fourteen days — 8 CVEs. JFrog Artifactory ×2 (CVE-2026-42016, CVE-2026-42018) · Google Chromium V8 ×2 (CVE-2026-87491, CVE-2026-85046) · Microsoft Windows ×2 (CVE-2026-81963, CVE-2026-85880) · BerriAI LiteLLM (CVE-2026-59822) · Kludex Starlette (CVE-2026-48710)

20 + 8 = 28. No sevens, no twenty-ones, no thirties. Two values and a hard edge between them, which is what a decision looks like once it lands in a data structure. Somebody read each entry and put it in a pile.

One more fact about all twenty-eight, because it is the field people reach for when they want to feel urgency: every September entry carries knownRansomwareCampaignUse: "Unknown". The scary column is blank on the whole month. The date still says three days on twenty of them.

The honest part, before you take this anywhere

BOD 26-04 deadlines are compulsory for Federal Civilian Executive Branch agencies only. They do not bind your company, your MSP, or your clients. Not a little, not implicitly, not "as a best practice." That distinction gets flattened constantly, usually by someone with something to sell — and the flattened version is worthless anyway: "patch within three days or you're non-compliant" describes no obligation a private company actually has. Binding for federal civilian agencies; free for everyone else to copy. Copy the signal, not a claim of compliance.

The field comes from BOD 26-04, Prioritizing Security Updates Based on Risk, issued June 10, 2026, which sets remediation urgency from exposure, KEV status, exploit automation and technical impact. You do not have to adopt the directive to use its output: the dueDate is that four-variable model already run, already published, already free, shipping in the same file as the CVE ID.

The ten — and what they have in common

Ten of September's twenty-eight are security or remote-management products, defined tightly enough to be auditable: products whose purpose is to secure, authenticate, protect, back up, or remotely manage other systems.

#	Product	CVE	Added	Due
1	Cisco Identity Services Engine	CVE-2026-76460	09-16	09-19
2	Acronis Backup	CVE-2026-87886	09-16	09-19
3	Cisco Secure Email Gateway	CVE-2026-76461	09-14	09-17
4	ConnectWise ScreenConnect	CVE-2026-84869	09-11	09-14
5	Citrix NetScaler	CVE-2026-19490	09-09	09-12
6	Fortinet (Multiple Products)	CVE-2025-25249	09-09	09-12
7	Cisco Secure Firewall Management Center	CVE-2026-20079	09-09	09-12
8	N-able N-central	CVE-2026-86218	09-08	09-11
9	SonicWall SMA1000 Appliances	CVE-2026-83548	09-02	09-05
10	SonicWall SMA1000 Appliances	CVE-2026-83549	09-02	09-05

Every one: three days. Not one of them got fourteen.

State the boundary out loud, because a category you cannot audit is a statistic you cannot trust. MikroTik RouterOS appears twice in the three-day pile and is excluded here as general networking rather than security tooling; count it in and the number is twelve. The claim is ten, under that definition, checkable against the feed in about a minute.

Then read the list again and notice what it is. That is not a software inventory. It is an org chart of a security program — the box that decides who gets on the network, the box that filters the mail, the box that manages the firewall, the box that holds the backups, and the two boxes that reach every machine you own.

Contrast one: Cisco's 10.0 and Acronis's 7.8 drew the same three days

Cisco Identity Services Engine, CVE-2026-76460. Added September 16, due September 19, CWE-648 Incorrect Use of Privileged APIs. Cisco's own advisory scores it 10.0 — Cisco's number; CISA publishes no CVSS score in KEV. It was a zero-day, and Cisco PSIRT states it is aware of active exploitation. A remote, unauthenticated attacker bypasses authentication with crafted requests to an API endpoint that does not apply sufficient authentication controls, and successful exploitation can execute commands with root privileges — which includes hiding or deleting the indicators that anyone was ever there. It affects Cisco ISE and ISE-PIC regardless of device configuration. Fixed in 3.5 Patch 4, 3.4 Patch 7, 3.3 Patch 12, 3.2 Patch 11 and 3.1 Patch 12.

That is the appliance that decides who is allowed onto the network. Root on it means the system of record for who got in becomes a system the intruder controls.

Acronis Backup, CVE-2026-87886. Added the same day, due the same day. CWE-276 Incorrect Default Permissions. Acronis rates it 7.8 — Acronis's number, again not CISA's. Acronis describes it as a local privilege escalation from insecure file permissions, requiring an attacker to already hold authenticated, low-privileged local access to the Linux server. It affects the Acronis Backup plugin for cPanel & WHM (Linux) before build 1.9.3.1021, the extension for Plesk (Linux) before 1.8.11.638, and the plugin for DirectAdmin (Linux) before 1.2.3.238. Acronis confirmed exploitation observed in the wild against the cPanel & WHM plugin.

So: Cisco's 10.0 — remote, unauthenticated, root. And Acronis's 7.8 — local, foothold required first. A 2.2-point spread, two entirely different threat models, and the same deadline to the day.

The scores are not wrong. They answer a different question. Severity asks what could happen; the deadline asks whether somebody is doing it. One of those is a continuum two databases can argue about. The other is a yes or a no, and it changes when you wake up tomorrow. Only one is a sort key.

Contrast two: the browser waited, the backup plugin did not

Google Chromium V8 out-of-bounds write, CVE-2026-87491, added September 9 — fourteen days. The rendering engine on effectively every desktop you own.

Acronis Backup local privilege escalation, CVE-2026-87886, added September 16 — three days. A plugin on a control panel, needing an attacker already authenticated on the box.

Rank those two by instinct and most people invert them. Instinct ranks blast radius. The field ranks evidence.

The MSP item: two management platforms, three days apart

N-able N-central, CVE-2026-86218 — added September 8, due September 11, CWE-96 Static Code Injection. We took that one apart last week; here it is the second data point.

ConnectWise ScreenConnect, CVE-2026-84869 — added September 11, due September 14, CWE-269 Improper Privilege Management plus CWE-862 Missing Authorization. It affects the ScreenConnect client prior to 26.6.5: missing authorization controls allow file transfer and execution through an active remote session without host confirmation. Huntress reported it exploited in the wild since August 20, 2026 — roughly three weeks before it reached the catalog. The behaviour Huntress reported was worm-like: a modified ScreenConnect instance deployed four VBScript files for persistence and propagation to other ScreenConnect clients. The fix is 26.6.5 or later; ConnectWise's interim mitigation is to disable TransferFiles permissions.

I have deliberately not quoted a CVSS figure for either. The week's argument is that the date outranks the score, and the paragraph is stronger without a number in it.

Two remote-management platforms, three days apart, both in the three-day pile. If you run one, that console reaches every endpoint in your book of business — row one on the asset list, not a footnote under "tools." If you buy from someone who runs one: which management platforms reach your estate, are they internet-facing, and when were they last patched? Ask in writing. Keep the answer with a date on it.

The mail gateway, and what a zero-day looks like in the record

Cisco Secure Email Gateway, CVE-2026-76461 — added September 14, due September 17, CWE-89 SQL Injection. Cisco's advisory published on September 14, the same day CISA added it to KEV. That is what "exploited before disclosure" looks like read off a timeline instead of a press release: the vendor's first public word and the catalog entry land together, because the exploitation came first and the paperwork caught up.

Unauthenticated, no user interaction. A crafted email passing through the gateway carries SQL statements, and exploitation can reach root command execution on the underlying OS. Affects AsyncOS 16.5, 16.0, and 15.5 and earlier, on-premises physical and virtual appliances. Fixed in AsyncOS 15.5.5-0141, 16.0.4-3021 and 16.5.0-780. No workaround — meaning the mitigation column on your tracker reads "upgrade" and nothing else, which is worth knowing before the maintenance-window conversation rather than during it.

How to read the due date yourself

Three fields do all the work.

product      → what you search on. NOT the score.
dateAdded    → the day CISA published the entry.
dueDate      → the deadline it carries.

dueDate − dateAdded = CISA's urgency verdict, as an integer.

All three are free and account-free: the JSON feed above; a CSV at the same path with a .csv extension, if you would rather open it in a spreadsheet; and the browsable catalog at cisa.gov/known-exploited-vulnerabilities-catalog. Pull the file, filter entries on product against the names on your own list, and for every hit subtract. A 3 means CISA set a three-day remediation window; a 14 means fourteen. Both are in the catalog because exploitation was observed — the integer is urgency, not evidence.

Search by product, never by score. Most teams get this backwards, and it is the difference between a five-minute answer and an afternoon reconciling severity numbers two databases disagree about. You are not asking "how bad is this CVE." You are asking "is anything I own in this file, and what integer did it get." Product name in, integer out — and read the version off the host, not off the management dashboard, because dashboards report what they were last told and appliances get rebooted, restored and half-upgraded.

The list you have to build first, because you probably don't have it

You cannot filter a feed against a list you never wrote down, and the list this month demands is the one almost nobody has — not the servers, not the laptops, but the tools doing the protecting, including the vendor consoles you neither host nor patch.

Those tools sit in a structural blind spot, and it is the same one every time: excluded from the vulnerability scan because they are the security stack, patched on the vendor's cadence rather than yours, owned by "whoever set it up," and frequently the only boxes in the building with no named human on them. That is precisely the population that went ten-for-ten into the three-day pile this month.

So the afternoon runs in three passes:

Enumerate the security and management stack. One row per product: vendor, product, version read off the host, where it is reachable from, and a named human — not a team, not a mailbox, not someone who left.
Filter the KEV feed on product for every name on that list.
For every hit, record dateAdded, dueDate and the integer between them — then inherit the integer as your own priority order. Federal civilian agencies are bound by that date; you are voluntarily copying homework somebody published for free. Where no fix exists yet, write the actual mitigation in the row: restrict source addresses, take the interface off the internet, disable the feature. "Waiting on the vendor" is a status, not a control.

The artifact is the point

The rule carries over from every review in this series: every claim gets a number and a date.

"We're on top of patching" is a mood. Something shaped like "23 security and management products inventoried Sep 18; 4 matched KEV by product; 3 patched, 1 mitigated by source restriction pending vendor fix; versions read off-host; owner named on every row; next pass Dec 18" is an artifact — and it is the shape of answer that cyber-insurance applications and client security questionnaires keep asking for.

The re-ranking itself costs nothing. It is a change of sort order, not a change of budget, which makes it the cheapest item on any security roadmap this quarter.

The severity number is a judgement two authorities can disagree about. The due date is CISA's verdict on whether the thing is currently being used against people: published in a free file, updated as new exploitation is confirmed, expressed as an integer you can subtract in your head.

The sort key was already free. And it's a date.

The kit is free. The Security Stack Kit (Gatorbyte #014) is this afternoon on paper: the inventory of the tools doing the protecting, the version-read-off-host column, the KEV cross-check by product, the dateAdded / dueDate / days-between fields, and the named-owner column that makes a row survive triage. It supports vulnerability-management and audit-preparation workflows — a practical starting point to review and adapt for your organization; not legal, compliance, or audit advice. Kits are free to use inside your organization and with your clients, including in paid engagements — thesecuritygator.gumroad.com/l/gb014-security-stack-kit

CISA Binding Operational Directive deadlines are compulsory only for the Federal Civilian Executive Branch agencies BOD 26-04 names. Nothing here creates an obligation on a private organization, and nothing here substitutes for managed security, penetration testing, or incident-response services.

Sources: CISA KEV catalog · KEV JSON feed, catalogVersion 2026.09.18, read 2026-09-18 · CISA KEV addition alerts, 2026-09-02, 09-09, 09-14 and 09-16 · Cisco security advisories for CVE-2026-76460 and CVE-2026-76461 · ConnectWise advisory for CVE-2026-84869 · Acronis advisory for CVE-2026-87886 · CISA BOD 26-04 — "Prioritizing Security Updates Based on Risk"

A note on the scores, because it is the article's premise: the KEV catalog contains no CVSS field. The 10.0 is Cisco's, from Cisco's own advisory; the 7.8 is Acronis's. Trade coverage carries CVSS figures for the Cisco Secure Email Gateway and ConnectWise ScreenConnect flaws too — omitted here on purpose, because a piece arguing that the date outranks the score should not lean on the score. No figure here is CISA's. CISA publishes none.

Nobody Broke In. They Signed In: The One-Afternoon Login-Surface Review

Gary Austin — Thu, 10 Sep 2026 14:07:00 +0000

Nobody Broke In. They Signed In: The One-Afternoon Login-Surface Review

The instructive intrusions of the season share a shape: the authentication failed, not the firewall. Here's the afternoon review that counts every door your organization exposes — and turns the count into a signed record.

The pattern with no forced entry in it

Read this month's actively-exploited list with one question in mind — what actually failed? — and a theme emerges. A screen-sharing service that authenticated a network attacker without valid credentials. A collaboration platform whose security feature could be walked past after a public proof-of-concept dropped. A management console, weeks earlier, whose login could be skipped entirely via an alternate path. And in the same season, a seven-figure dump of contact records — name, email, address, phone — whose main criminal application is making the next call to a help desk sound exactly like the user it claims to be.

No malware had to beat your EDR in any of those stories. The doors did what they were configured to do. The configuration was the finding.

Which leads to an uncomfortable reframe: your perimeter is not a firewall diagram. It's the set of every internet-reachable place that accepts a credential for your organization — or for each client, if you're the MSP. And in most shops, that set has never been written down.

You can't lock a door you haven't counted

The review starts with an inventory, because every later question is per-door. Twelve categories jog the memory:

Identity provider / SSO — the front desk itself
Email & webmail — including the legacy paths (OWA, ActiveSync, basic auth)
VPN portals & remote-access gateways
Firewall / network-gear admin interfaces
RMM & remote-support tooling — last week's master key cabinet
Hypervisor & infrastructure management — vCenter, iLO/iDRAC, cloud consoles
File / intranet / collaboration platforms
SaaS admin consoles — PSA, billing, backup, the password manager
Remote desktop & screen sharing — RDP, VNC, OS-native sharing
Break-glass & emergency accounts
Service accounts & API keys — doors with no human attached
The help desk's reset procedure — a door that answers to a voice

One row per door: what it is, who uses it, what it accepts, who owns it, when it was last checked. If producing that table takes more than an afternoon, that fact is itself the first finding.

"We have MFA" is a per-door claim

Here's where last week's management-plane review and this week's shake hands. The five console questions asked is MFA enforced on the console itself — because a console with local accounts is indifferent to how good your identity provider's MFA is. This week generalizes it. For every row in the inventory, mark exactly one:

ON THE DOOR — the service itself enforces a second factor, local accounts included.
UPSTREAM — MFA lives at the IdP; anything the door authenticates locally walks past it.
NOWHERE — a password alone opens it.

Then two follow-ups per door: can any account skip it? (service accounts, legacy protocols, app passwords) and does this door hold accounts the IdP has never heard of? The org-level sentence "we have MFA" aggregates away exactly the information an attacker cares about. The matrix exists to de-aggregate it.

The side doors

Most gaps the matrix finds fall into a short, familiar list — the paths that skip the second factor:

Legacy mail protocols still answering basic auth
App passwords and long-lived tokens that outlive their owner's MFA
Vendor and default accounts that shipped with a product and still resolve
Break-glass accounts with no compensating alert on use
Admin interfaces exposed to the whole internet where an allowlist would do
API keys embedded in scripts older than the last rotation
The MFA exception that was "temporary" two migrations ago

Close what you can in the afternoon. For what you can't, write down the reason and an owner — an accepted risk with a name and a date is a decision; the same gap undocumented is just exposure.

The human door

The password reset flow is an internet-reachable authentication endpoint. It runs on a human, under social pressure, and its verification data — the things a caller is asked to prove — is precisely what large contact-data dumps put in criminals' hands. So the script is short and strict: never authenticate on knowledge alone; call back on the number already on file, never the one the caller offers; verify through a second channel the account owner controls; allow no urgency exceptions, because manufactured urgency is the technique; and log every reset — who asked, how verified, who approved, when.

Five lines, printable. It converts the softest login you own into one of the most defensible — and the log converts it into evidence.

The record is the deliverable

Same rule as restore week and console week: every claim gets a number and a date. The afternoon ends with one page: doors enumerated, MFA state per door, paths closed, exceptions accepted (with owners), script deployed, next check booked. "Twenty-two doors, MFA enforced on nineteen, three legacy paths closed, Aug 27, J.R., re-check November" is an artifact — the kind cyber-insurance applications and client questionnaires increasingly expect. "We're pretty locked down" is a mood.

The whole thing, packaged free

The Login Surface Kit (Gatorbyte #010) bundles the review: the 12-category inventory worksheet, the MFA coverage matrix, the legacy-path kill list, the help-desk verification script, and the evidence log — free: thesecuritygator.gumroad.com/l/gb010-login-surface-kit.

One afternoon. Twelve categories. One signed page either way it lands. Because a door you haven't counted is a door you can't lock.

This is a review format, not managed security services — and not legal, compliance, or audit advice. Authentication capabilities vary by product and license; verify against your vendor's current documentation. If a review turns up evidence of compromise, follow your incident-response plan.

Same Attack, Two Companies. One Never Responded: The One-Afternoon Alert Coverage Review

Gary Austin — Wed, 09 Sep 2026 14:07:00 +0000

Same attack, two companies. One never responded.

CISA ran the same red team playbook against two organizations at the same time and published both outcomes. One SOC quarantined the machines. The other received the alerts and never responded — and the reason it didn't is the cheapest problem in this whole story to fix.

In August, CISA published something unusual: the results of two red team assessments run at the same time, against two different critical-infrastructure organizations, using similar tradecraft. Advisory AA26-237A, titled "A Tale of Two SOCs."

It is unusual because it is the experiment nobody gets to run on themselves. Same attackers, same playbook, same week, two environments — and the results printed side by side.

Both organizations were compromised at domain level. In both, the red team reached sensitive business systems and cloud resources. So the interesting variable is not whether the attack worked. It worked twice.

The interesting variable is what happened in the minutes after.

The one that worked

Organization B, a water and wastewater entity, was phished. Three users clicked, and the red team landed on three workstations.

The SOC caught the payload on each one. Every execution generated a medium-severity alert; staff quarantined the workstation, analyzed it, and reimaged it before putting it back online. Three times. Command-and-control never held.

Then something worth noticing happened. Because the defenders removed that initial foothold, the red team could not proceed — so the engagement was restructured. Organization B's own trusted agents — IT staff who knew about the assessment — executed a red-team-provided payload on a designated internal host tied to a standard, non-administrative account, replicating the access the team would have had if they hadn't been thrown out.

Assume-breach is a standard phase of these assessments, so this isn't a trophy on its own. What it does tell you is the direction the pressure ran. The team didn't move to assume-breach on schedule; they moved to it because containment worked.

Later, when the red team reached a bastion host in the OT DMZ, that host blocked outbound connections and the payload execution triggered an alert. Staff quarantined it. When the team logged into the Azure portal with a compromised account, an automated alert fired and staff blocked the account.

None of that is exotic. It is ordinary tooling, plus somebody reading the output.

The one that didn't

Organization A, in government services, did not respond.

Not to the phishing. Not to the privilege escalation — a default Machine Account Quota and a misconfigured AD CS certificate template. Not to credentials sitting in cleartext, or static cloud access keys set never to expire. At one point the red team used an over-permissioned application to review SOC staff email, specifically to see whether staff were aware of the compromise. The SOC never responded.

Here is the part that should change how you think about your own program.

The alerts fired.

The advisory is explicit: the SOC received medium- and low-severity EDR alerts related to red team activity "but did not respond to them." Thousands of false positive alerts corresponding to normal business operations — many at higher severity — obscured the real ones.

That is not a detection failure. The tools detected it. It is a response failure, and it has a completely different fix, at a completely different price.

The detail worth an afternoon

One alert in that environment was real, and a human looked at it.

Red team members observed defenders' chat about an alert on an SCCM server. The defenders tried to determine who owned that system, what it did, and how it was normally used. They could not. The SOC eventually flagged it a false positive.

Read that again slowly. The detection worked. The alert was true. It died in triage because the asset inventory could not name a person.

Which means your CMDB is doing detection work, whether or not anyone staffed it that way. An alert arrives carrying a hostname. Whether it survives the next four minutes depends entirely on whether someone can attach meaning to that hostname at two in the morning.

CISA also found Organization A running multiple SOCs and multiple EDR products whose staff neither communicated with each other nor had visibility into each other's detection tools — and SOC staff and system owners did not communicate either. More consoles is not more coverage. Each additional console is another place a signal can arrive and stop.

The advisory's closing line is blunt, and worth quoting exactly:

"Detection tools are only as effective as the people, processes, and procedures supporting them."

It is not one unlucky organization

You could read all of that as a story about one badly-run SOC. The numbers say otherwise.

The Blue Report 2026, published in August by Picus Labs, measured more than 338 million attack simulations run in real production environments. Two of its scores matter here:

Logging: 58%
Alerting: 14% — flat year over year

Fewer than one simulated attack in seven produced an alert at all.

Worth naming the obvious: Picus sells breach-and-attack-simulation tooling, and a report finding that untested detection underperforms is a report that sells more testing. Read it as vendor research. It is still worth citing, because the methodology is stated, the sample is enormous, and the finding is independently corroborated by a government advisory with nothing to sell — one describing a SOC that received real alerts and did not act on them.

Put the two numbers side by side, because the gap is the entire argument. More than half the telemetry is arriving. The event gets written down. What almost never happens is a rule that reads it and routes it to a human.

That is not a collection problem, and it will not be fixed by more retention or a bigger ingest bill. It is a detection-engineering problem. One of those costs money. The other starts with an afternoon.

The afternoon

Five events. Not fifty.

Fifty detections is a project, a budget line, and a thing you never start. Five is an afternoon. Pick five you would be embarrassed to miss, and leave the rest for next quarter:

A new global or domain administrator
A log source going dark
An impossible-travel or anomalous-location login
A mass export or bulk download
A new mailbox forwarding or inbox rule

Pick by consequence, not by ease of detection. The temptation is to choose the five you already know alert — which measures your confidence, not your coverage.

Then, for each one, three questions:

Is it logged? Usually yes. Name the source and the retention window, not just "yes."
Does it raise an alert? Now you're guessing. A rule in a vendor template is not a rule that is enabled and scoped to your tenant.
Who receives it, at 2am? This is the one that decides everything.

Question three is where most programs quietly die. "Does it alert" is answerable on paper. "Who receives it at 2am" is answerable only by looking, and the answer is startlingly often a distribution list with one person on it who left, or a channel nobody has opened since the integration was built.

Then stop guessing

Everything above is still paperwork. This part isn't.

Generate the event. Get approval, work inside a change window, and tell the people who would otherwise page out that it's you. Create a throwaway administrator. Trigger a deliberate bulk download. Add a test forwarding rule.

Then watch three places: the console that should show it, the channel that should carry it, and the human who should receive it. Record the wall-clock deltas — trigger to alert, alert to acknowledgement. Those numbers are the deliverable.

And record the silences. An event that produced nothing is the most valuable row on the page, because it converts "would we catch that?" from an assumption into a finding — one you made on your own schedule instead of during an incident.

Then remove what you created, and log the removal.

The artifact is the point

The rule carries over from every review in this series: every claim gets a number and a date.

"We'd catch that" is a mood. Something shaped like "five events tested Sep 10; three alerted within four minutes; one alerted to a dead channel; one produced nothing — two tickets filed, retest Sep 24" is an artifact. It is also the exact thing that answers an assessor asking whether your monitoring is real or aspirational, and the kind of evidence assessors and insurers increasingly ask about.

Fix the routing before you fix the rule, incidentally. An alert nobody receives and an alert that doesn't exist cost precisely the same during an incident, and the routing is usually the cheaper repair.

Both organizations in that advisory had tools. Both had logs. One of them knew what it would see.

Your logging is probably fine. Your alerting is the open question.

The worksheets are free. The Alert Coverage Kit (Gatorbyte #012) is a self-contained offline HTML file — the five-event picker, the three-question test, the generate-and-watch protocol, a coverage log with time columns, the asset-ownership check, and an evidence register — plus CSV and Excel export of every worksheet. No account required — thesecuritygator.gumroad.com/l/gb012-alert-coverage-kit

This is a review format and a practical starting point to adapt for your organization. It supports detection-coverage documentation and audit-preparation workflows; it is not legal, compliance, or audit advice, and not a substitute for managed security or incident-response services. Generating test events changes state in a live environment — get approval and work inside a change window.

Sources: CISA AA26-237A — "A Tale of Two SOCs" · CISA KEV alert, Sep 2 · Blue Report 2026, Picus Labs

They Left in March. Their Account Didn't: The One-Afternoon Offboarding Review

Gary Austin — Wed, 02 Sep 2026 14:07:01 +0000

They Left in March. Their Account Didn't: The One-Afternoon Offboarding Review

Last week CISA added vulnerabilities from 2015 to the actively-exploited catalog. The mechanism that keeps an eleven-year-old bug exploitable is the same one that keeps a departed employee's API token alive — and here's the afternoon review that finds it.

Decay, with a date stamp on it

On August 26, 2026, the Known Exploited Vulnerabilities catalog picked up four entries worth reading twice: CVE-2015-3246 and CVE-2015-5287, both Red Hat, both from 2015; CVE-2019-1068, a SQL Server remote code execution; and CVE-2021-23758, a deserialization flaw in Ajax.NET Professional. Entries land in that catalog on evidence of active exploitation. Somebody is still exploiting a bug that turned eleven years old.

The catalog doesn't say why. But the simplest explanation for an eleven-year-old bug still being exploited is that it is still running somewhere, on a host nobody owns, that nobody has deliberately logged into since the person who built it left.

Five days later the same catalog added two PaperCut NG/MF flaws, one of which is described in its own entry as Missing Authentication for Critical Function — on a print management server, the archetypal thing an MSP installs once in year one and never revisits. And in between, on August 27, an ownCloud improper-authentication bug from 2023 was added with a three-day federal remediation deadline.

Read together, those look less like three patching stories than one ownership story. The risk factor is not unpatched; unpatched is a symptom. The risk factor is unowned — and access decays exactly the same way, only more quietly, because an orphaned account never throws an alert.

HR closes a person. Security has to close identities.

Offboarding gets filed as an HR event, and that framing is why it quietly fails. HR closes a person. Access lives as identities, and the mapping is one-to-many.

The directory account is the one identity that reliably has a human's name attached and a process pointed at it. It gets disabled on day one, and it is what everyone points to when you ask whether offboarding works. Underneath it sits everything that was created ad hoc, is owned by nobody in particular, and has no lifecycle tied to employment at all.

So the process reports success while most of the surface is untouched.

The six-month rule

Before the hunt, one decision determines whether this review measures anything: who you audit.

Reviewing last week's leaver tells you almost nothing. The ticket is still open, the manager remembers, someone is still copied on the thread. Of course it looks clean — you are measuring your attention, not your process.

Pull five people who left six months ago or longer, or five contractors whose engagement ended that long back. That tells you what your process produces once attention has moved on, which is the only condition it will actually operate under for the rest of its life.

It is the same logic as testing a restore instead of trusting a green backup job. The green light describes an intention. The restored file describes reality.

Ten places access hides

One row per identity, not per person. A single departure usually produces several:

Directory / SSO account — the easy one, and the one that flatters the process
Local accounts on appliances — firewall, hypervisor, NAS, print server, switch; tied to no directory
Shared credentials in the team vault — four people know it, so rotating it means telling four people, so it never gets rotated
Service accounts — nobody offboards one, because nobody thinks of it as a person; yet it carries their naming convention and their permissions
API tokens and app passwords — they outlive the human because the token appears in no list anyone reads
MFA enrolments on personal devices — the account is disabled, the phone is still a registered authenticator
Vendor and support portals — they are still the registered contact, so resets and license changes still route to them
Client tenants and delegated access — MSP-specific, and the highest blast radius on the list
Repos, CI, and deploy keys — org membership and personal access tokens both outlive employment
Mailbox rules and forwarding — survives the mailbox being converted to shared, and quietly keeps delivering

If your hunt produces one row per person, you have found the checklist, not the access.

Verify in the system, not on the checklist

This is the step most reviews skip, and skipping it makes the other steps decorative.

A completed offboarding checklist is a claim. The system's actual user list is evidence.

On a first pass those two usually disagree — and when they do, the checklist is what's wrong. It recorded an intention formed at the moment of ticking, and nothing re-validated it afterwards. A user list pulled today is a statement about now.

The failure modes are mundane, which is exactly why they persist:

The account was disabled but never removed from its security groups, so a re-enable for a mailbox restore silently returns full access.
The human was revoked and the token they generated wasn't, because the token isn't attached to them anywhere a person looks.
The shared vault entry was never rotated, because rotating it is a conversation with four people.
Two admins each assumed the other one did it.

None of these require carelessness. They require a process that stops at ticked.

The artifact is the point

The review is just how you produce the record. The record is what survives.

Log what you revoked, from where, on what date, verified how, and checked by whom — and fill it as you go, because retro-filling is how dates stop being true. Then write the per-departure summary: systems checked, identities found, how many were still active, when they were closed, and what process gap let it happen.

That last field matters more than it looks. What you found is a gap in the runbook, not in one person's file. Patching the record leaves the next departure exactly where this one was.

The rule carries over from every review in this series: every claim gets a number and a date. "We offboard people properly" is a mood. Something shaped like "five departures reviewed, 31 identities found across 9 systems, 6 still active, all revoked, Sep 4, verified by J.R." is an artifact — and it is the one an assessor asks for when they want to know whether your access-control process is real or aspirational.

When you find something

Preserve before you act — screenshots, exports, timestamps — and if there is any sign the access was used after the person left, stop and follow your incident-response plan. A worksheet is not one. Engage counsel and your insurer per your policy's terms before external communications.

And a clean review is still a deliverable. Identities counted, nothing still open, dated and signed, filed. An identity nobody owns goes on the risk register with one owner and one fix-by date, not in a drawer.

The worksheets are free. The Offboarding Evidence Kit is a self-contained offline HTML file — identity hunt across all ten categories, verification pass, revocation log, per-departure review record, evidence register — plus CSV and Excel copies of the three registers. No account required — thesecuritygator.gumroad.com/l/gb011-offboarding-evidence-kit

This is a review format and a practical starting point to adapt for your organization. It supports access-review and audit-preparation workflows; it is not legal, compliance, or audit advice, and not a substitute for managed security or incident-response services. Account and token lifecycle behaviour varies by product and license — verify against your vendor's current documentation.

Sources: CISA KEV catalog · KEV alert, Aug 26 · KEV alert, Aug 27 · KEV alert, Aug 31

They Didn't Break In. They Logged In: The Two-Hour Management-Plane Review

Gary Austin — Wed, 19 Aug 2026 14:07:00 +0000

They Didn't Break In. They Logged In: The Two-Hour Management-Plane Review

One console in your stack can reach every machine you manage. This month an attacker demonstrated exactly what that means — without deploying a single piece of malware. Here's the two-hour review that turns that lesson into a signed record.

The intrusion with no malware in it

The most instructive incident reporting of the month describes an attack with no phishing email, no dropper, no encrypted payload. An authentication bypass in a widely deployed remote monitoring and management (RMM) platform gave the attacker administrative access to the management console — and from that point they never needed an exploit again. They used the product's own remote-control feature, the same one technicians use every day, to reach managed endpoints and leave persistence behind. In at least one confirmed case, the session ran under a default support account that ships with the product.

Read that chain again from your tooling's point of view. The endpoint agent saw a legitimate remote-support session. The firewall saw a signed, widely used tunneling utility connecting to a well-known service. The audit log saw a support account supporting. Every control was working correctly. They were answering questions nobody had asked.

Why the management plane is a different asset class

Compromise an endpoint and an attacker owns an endpoint. Compromise the management plane and they own every endpoint it manages — and if you're an MSP, that's not one company, that's your entire book, through one console that lives on the internet because it has to.

A workstation is a room. Your RMM is the master key cabinet. That asymmetry is why the console deserves harder questions than any other server you run — questions that outrank every feature comparison on the next renewal call:

Does the console share an identity system with your domain? Shared identity means one takeover becomes two.
Is MFA enforced on the console itself — not just on the technician's email account?
Can any technician open remote control on any endpoint at any hour, or is that scoped and scheduled?
Does the management server have unrestricted outbound access? A server that can tunnel anywhere can beacon anywhere.
Is there one session record an administrator of that same server cannot quietly edit? If the intruder is admin on the console, the console's log belongs to them too.

Patched is not fixed

Here's the detail worth tattooing on the inside of the ticket queue: the flaw being actively exploited exists because the patch for an earlier vulnerability was incomplete. The first fix shipped; the underlying path stayed open; a second CVE was issued for the same way in — and the second one is what attackers are using. A population of teams did everything right, applied the update, closed the ticket, and remained exposed.

So verify patches the way you'd verify a restore:

Check the version on the host itself. The console reporting on itself is a claim; the host is the fact.
Check every instance, not the one you remember.
Where the vendor documents the closed path, re-test the path rather than trusting the version string.
Re-read the advisory a week later. Incomplete fixes are usually discovered after the first patching wave, not before.

Then write it down: version confirmed, instances checked, date, who, what test. "We're patched" is a mood. That log is an artifact — the same artifact cyber-insurance applications and client security questionnaires keep asking for.

The four tells (context, not tooling)

What actually separates an attacker from a technician when the tool, the account, and the feature are all legitimate? Context. Four kinds of it:

1. HOUR    — a support session at 3 AM on a Sunday
2. SOURCE  — a consumer-VPN exit node, not your office or corporate VPN
3. IDENTITY— a default account name nobody on your team actually uses
4. SHAPE   — connect → enumerate → disconnect
             (reconnaissance looks nothing like support)

None of these are alerts in most shops today. All four are answerable this week, from logs you already collect.

Hunt backwards, then write it down

Because this class of flaw tends to be exploited before it's catalogued, forward-looking controls are half the job. The other half is a 90-day retro-hunt: pull remote-session history and read it against the four tells; look for tunneling utilities registered as services on machines with no business running them; look for executables in user document folders wearing system file names; search for persistence no ticket explains. You're not looking for a hit — you're building the ability to say you looked, and what you found. A clean hunt, dated and signed, is still a deliverable.

The whole thing, packaged free

The Management Plane Kit (Gatorbyte #009) bundles the review: the five-question hardening checklist, the patch verification log template, the four tells as a starting detection list, and the 90-day retro-hunt worksheet — free: thesecuritygator.gumroad.com/l/gb009-management-plane-kit.

Two hours. Five questions. One signed page either way it lands. Because a control you can't evidence is a control you're only assuming you have.

This is an exercise and review format, not managed security services — and not legal, compliance, or audit advice. Vendor advisories change; verify version guidance against the current advisory before acting. If you find evidence of compromise, follow your incident-response plan.

Your Backups Are a Hypothesis: The 45-Minute Restore Test

Gary Austin — Sun, 16 Aug 2026 09:15:00 +0000

The green checkmark problem

Every MSP dashboard has one: the backup column, green for months. Green feels like safety. But a green job proves exactly one thing — the job ran. It does not prove the data comes back, how long that takes, whether the increment you'll need survived the retention policy, or whether anyone alive can find the decryption key at 2 AM.

Two weeks ago this series argued that an incident response plan that's never been exercised is a hypothesis. Backups are the same species of hypothesis, with quieter failure modes:

Rotated credentials. The backup service account changed; jobs kept "succeeding" against a subset of targets.
Corrupt increments. The chain is only as good as its weakest link, and nothing verifies links like a restore.
Retention surprises. The copy you need is from 9 days ago; retention keeps 7.
Key-inside-the-vault. The decryption key or console password is documented… inside a system that's now encrypted.
Scope drift. The new file share, the new VM, the migrated mailbox — added to production, never added to the job.

Every one of these is invisible on a green dashboard, and every one of them is found in one of two moments: a scheduled drill on a Tuesday afternoon, or the worst hour of your year.

The drill

THE 45-MINUTE RESTORE TEST  (roles: an operator + a scribe. That's the team.)

0:00  Pick the target BEFORE you feel ready: one production system that
      would hurt Monday morning — file server, finance share, the PSA/RMM
      database. Not the easy one. The one that matters.

0:05  Restore last night's copy to an ISOLATED target: a spare VM, an empty
      VLAN, a cloud sandbox. NEVER over production. No internet egress
      required — isolation is the point.

0:35  Verify like a USER, not an admin: open three files, run one report,
      log in with a real non-admin account. "It boots" is not "it works."

0:40  Write four numbers: minutes to restore · GB restored · items verified
      · today's date. The scribe signs the page.

That signed page is the deliverable. Everything else — the war stories, the "huh, interesting" moments, the ticket you'll open about the service account — is bonus.

The one rule

Borrowed from the tabletop drill and repointed: every claim gets a number and a date.

"Restores work fine" is a mood. "47 minutes, 212 GB, three files opened and readable, August 11, signed by the scribe" is evidence — the kind cyber-insurance applications and enterprise security questionnaires are explicitly asking for when they say tested recovery and documented RTO. You're not doing extra work to satisfy the questionnaire; the drill's natural output is the answer.

The math you can finally do

Recovery time estimates usually divide a known number by a guess:

Real downtime ≈ (data that must come back) ÷ (restore throughput)

Every team knows the first number. Almost nobody has measured the second — and the difference between an assumed and a measured throughput is the difference between promising "a few hours" and delivering a long weekend. After one timed drill, your RTO conversations use a measurement. Guessing is over.

The trap: your backups are the first target

Ransomware crews have told reporters for years that backup infrastructure is their first stop — delete or encrypt the recovery path, then detonate. Recent KEV traffic makes the architectural point for them: Veeam's advisory for CVE-2026-44963 describes a critical RCE on domain-joined backup servers, reachable by any authenticated domain user. One stolen domain account, and the vault is another room on the sinking ship.

So alongside the restore drill, three architecture questions worth an hour:

Credential separation. Does the backup console share credentials (or auth domain) with production? It shouldn't.
An undeletable copy. Does at least one copy live where a domain admin cannot delete it — immutable object storage or genuinely offline?
Console-loss drill. If the console died tonight, who could still reach a copy, and by what path?

The commonly used rule of thumb is 3-2-1-1-0: three copies, two media, one offsite, one offline or immutable, zero errors on verification. The last digit is the one everyone skips — and it's the only one that involves actually restoring. Treat it as a starting point to adapt, not a certification to claim.

When the test fails

A restore test that fails is a successful test — it located a real gap for the price of 45 minutes. Run the tabletop rule on it: the gap gets an owner and a date, and the failed log page stays in the file next to the eventual passing one. The paper trail from red to green is itself evidence of a functioning program. The only failed test is the one never run.

Make it a rhythm

One drill is a data point; a rhythm is a program. Rotate targets quarterly — file server this quarter, the PSA database next, a full VM the one after. Fifteen minutes of scheduling covers a year: four calendar invites, each with an operator, a scribe, and a target named in advance. Booked beats intended.

This is a review format and a practical starting point to adapt for your organization. It supports backup- and recovery-evidence documentation and audit-preparation workflows; it is not legal, compliance, or audit advice, and not a substitute for managed security or incident-response services. Restore behaviour varies by backup product and license — verify against your vendor's current documentation and rehearse inside a change window.

Local-first GRC: why I'm building a compliance workbench that doesn't phone home

Gary Austin — Tue, 28 Jul 2026 09:27:58 +0000

I'm Gary — The Security Gator. I build a GRC command deck for vCISOs, MSPs, and consultants who are tired of renting access to their own compliance data.

The premise is simple: most compliance platforms are SaaS. Your control assessments, your risk scores, your client evidence — all of it lives on someone else's servers, behind a subscription that never ends. Stop paying, lose access.

The bet: own it, don't rent it

AxiomLens is a NIST CSF 2.0 workbench that runs entirely on your machine — SQLite under the hood, a local GUI on top, one-time license. After activation it's strictly offline.

	CaaS / SaaS	AxiomLens
Your data lives	On their servers	In a SQLite file you own
Access model	Log in to their cloud, every session	Activate once, then fully offline
Cost shape	Subscription, forever	One-time license
When you stop paying	Locked out	Nothing happens — it's yours

$ axiomlens status --json
{
  "controls_total": 106,
  "in_scope": 100,
  "coverage": "computed locally"
}

Coverage math, scored risk, board-ready reports, client hand-off docs — computed on your machine, owned outright. It supports compliance documentation and audit preparation; it's not a substitute for legal, compliance, or audit advice — and I'm careful to never claim otherwise. That honesty is part of the pitch.

What I'll write about here

The build, in public: SQLite schema decisions for framework crosswalks, packaging Python into a single exe with Nuitka, deterministic report generation instead of LLM roulette, and the general weirdness of shipping desktop software in a SaaS world.

The free stuff — field guides, a governance tool, starter kits — lives on the Gatorbyte Free Shelf.

Everything else: thesecuritygator.com · Bayou Bytes newsletter