1. The largest Patch Tuesday on record, two exploited zero-days, and a DNS bug with a bad ancestor

Help Net Security · September 9, 2026

Two of this month’s flaws are already being exploited. CVE-2026-81963 is an elevation-of-privilege flaw in the Windows Update Stack that lets an authenticated low-privilege attacker gain SYSTEM; CVE-2026-85880 is an elevation-of-privilege flaw in Windows Advanced Local Procedure Call that also ends at SYSTEM. Both are rated CVSS 7.8 in Tenable’s companion analysis — the Help Net Security article itself lists no CVSS scores at all. CVE-2026-81963 was reported by the Microsoft Threat Intelligence Centre and CVE-2026-85880 by Proofpoint, and neither has published exploitation details or attribution. For a SOC that means there is nothing to hunt on: no indicators, no tradecraft description, no named operator. Patching is the entire control. Note also what these two are — both are privilege escalation, not initial access — which puts them in the second stage of an intrusion, chained behind something else you have not found yet.

The count is where this story needs care. Help Net Security says only “another record-breaking number of patches” and gives no total; the number to use is Tenable’s, which is 964 CVEs — 104 Critical, 860 Important, 44.7% elevation of privilege, 26.8% remote code execution — and Tenable calls it the largest Patch Tuesday ever shipped. Other outlets have published 974, 973 and 1,169 for the same release, so attribute the figure or leave it out. The single item to move to the front of the queue is CVE-2026-69730, a remote code execution flaw in Windows DNS Server that Tenable scores at CVSS 9.8 and that Help Net Security describes as “the spiritual successor to SigRed,” the wormable 2020 Windows DNS bug CVE-2020-1350. Nine DNS Server RCEs were patched this month and this is the most severe of them; in most Windows estates the DNS role sits on domain controllers, which makes the blast radius of a DNS RCE identical to the blast radius of the directory. Other named entries worth pulling into a change record: CVE-2026-69414, an elevation-of-privilege flaw in Microsoft Defender nicknamed “ShieldBreak”; CVE-2026-69676, a Kerberos authentication bypass; CVE-2026-80093, elevation of privilege in the Windows Cloud Files Mini Filter Driver; and CVE-2026-55007, an Exchange Server RCE reachable through a Visio attachment. Dustin Childs, Head of Threat Awareness at the Zero Day Initiative, summarises the top of the list: “In each of these cases, a remote, unauthenticated attacker could get arbitrary code execution on affected systems with no user interaction.”

The piece closes on a timing problem that should change how you schedule. An anonymous researcher operating as Nightmare Eclipse has made a pattern of publishing zero-day proof-of-concept code targeting Microsoft software within hours of the Patch Tuesday release, and Help Net Security describes this as the new normal rather than an anomaly. If that holds, the useful measurement is no longer how long it takes you to deploy a patch but whether your deployment window is shorter than the interval between Microsoft shipping the fix and working exploit code appearing in public. For most organisations running a monthly change board, it is not.

Sources: Help Net Security (September 2026 Patch Tuesday, zero-days and the SigRed successor)

2. Check Point: a government forecast, not a confirmed intrusion — and an upgrade project underneath it

BleepingComputer · September 12, 2026

The Dutch National Cyber Security Centre has issued an advisory on two Check Point flaws, CVE-2026-85102 and CVE-2026-85103, for which no CVSS scores have been published. Read the status precisely before you escalate: this is an assessment, not an observation. “The NCSC assesses the likelihood of exploitation and the potential impact as high and expects exploitation attempts to occur soon,” the advisory says. There is no confirmed in-the-wild exploitation, neither CVE is in CISA’s Known Exploited Vulnerabilities catalogue, and the advisory carries no indicators of compromise and no detection guidance. That combination matters operationally, because it means there is no hunt to run and no rule to deploy. Patching or upgrading is the only stated action, and the correct internal framing is “assessed as likely,” not “under attack” — a distinction worth preserving when this goes to an emergency change board.

The affected set is R81.20, R82 and R82.10 on the gateway side, plus Quantum Spark R81.10.x and R82.00.x. R82.20 is not affected. Remediation is Check Point LivePatch Take 24 for R81.20, R82 and R82.10, or the Jumbo Hotfix Accumulators — R82.10 Take 44 or later, R82 Take 126 or later, R81.20 Take 166 or later. Quantum Spark needs R82.00.10 Build 2325 or later, or R81.10.17 Build 4968 or later. Check those build numbers against what is actually running rather than against what your standard image says, because the gateway estate is exactly the kind of population where a device gets left behind at a version that was current when it was commissioned. The harder part of this advisory is the end-of-support list: R80 through R80.40, R81 and R81.10 are affected and will not receive fixes. For anything in that range the remedy is an upgrade, which is a project with a lead time, testing and a maintenance window — not something that closes inside a patch cycle. If you have gateways on those versions, the useful action this week is not a patch ticket but a decision about when they come off, and an interim compensating control on management and VPN interface exposure while they do not.

Sources: BleepingComputer (Dutch NCSC advisory on Check Point VPN flaws)

3. WatchGuard: the story is the nine thousand still exposed, not a new vulnerability

BleepingComputer · September 10, 2026

CVE-2025-14733 is a remote code execution flaw in WatchGuard Firebox firewalls; no CVSS score is given in the reporting. What changed this week is narrower than the headline suggests. The CVE was added to CISA’s Known Exploited Vulnerabilities catalogue in December 2025, with a one-week federal remediation deadline under BOD 22-01, and that deadline expired nine months ago. The September 2026 news is CISA updating the existing entry to flag known ransomware use — not a fresh listing, and not a fresh vulnerability. CISA confirms the flaw is now known to be used by ransomware operators but has released no further detail, and no specific group is named, so there is no attribution to work from and no group-specific tradecraft to build detections around.

The operational story is the exposure curve. At the December 2025 listing, over 115,000 unpatched Fireboxes were exposed on the internet. Nine months on, nearly 9,000 instances remain unsecured. That is a substantial reduction and still a large residual population, and the residual is the interesting part: these are devices that survived a KEV listing, a federal deadline and nine months of public attention. The vulnerable firmware spans Fireware OS 11.x and later — including 11.12.4_Update1 — 12.x and later including 12.11.5, and the 2025.1 line through 2025.1.3, which is a wide enough range that “we refreshed our firewalls recently” is not an answer. Two concrete actions follow. First, inventory Fireware versions directly rather than trusting a support contract or an asset register; the version bands above are the check. Second, retrieve the indicators of compromise WatchGuard has published — the article does not reproduce them — and hunt with them, because a device that has been exposed for nine months against a flaw now confirmed in ransomware use is a device you should assume was reachable rather than assume was missed. There is a third, quieter action for the vulnerability management team: confirm that your KEV ingestion re-alerts on updated entries. If you import the catalogue as a one-time list of CVE identifiers, an update to an existing entry produces no signal at all, and this week’s news passes you by entirely.

Sources: BleepingComputer (CISA flags WatchGuard RCE in ransomware use)

4. Okta patches three flaws in the components you operate, not the ones Okta operates

GBHackers · September 11, 2026

Three CVEs: CVE-2026-85982 at CVSS 9.0 and rated Critical, CVE-2026-78626 at 8.1, and CVE-2026-78623 at 7.7. The affected software is the Auth0 AD/LDAP Connector, vulnerable before version 8.0.0 and fixed in 8.0.0 and later, and Okta Access Gateway, vulnerable before 2026.9.1 and fixed in 2026.9.1 and later. The single most important line in the advisory is a deployment fact rather than a technical one: these are customer-managed components. Okta updating its own cloud service does not remediate them. If your identity team’s mental model is that Okta patches Okta, these three will sit unpatched indefinitely, and the connector in particular tends to be installed once during a directory integration and then forgotten. Remediation for the connector is upgrading the auth0/ad-ldap-connector package; for the gateway it is moving to 2026.9.1 or later.

The flaw classes are worth understanding because one of them is not closed by the patch alone. One issue is cross-site scripting in the Auth0 AD/LDAP Connector. The Access Gateway issue is the more interesting one: SAML assertion attribute values reach custom SQL datastore queries as untrusted input. That is injection through an identity assertion — a data path most teams do not think of as user-controlled, because the assertion is signed and therefore feels trusted. Signed does not mean sanitised. Accordingly, Okta’s guidance goes beyond the version bump: audit your custom SQL datastore queries, identify which SAML attributes are being used as query inputs, and restrict what values those assertions are allowed to carry. Do that work even after patching, because the pattern will recur in any custom query you write next. No active exploitation has been reported for any of the three, and none is in CISA’s KEV catalogue — which, given that these are self-hosted components with historically slow patch uptake, is a window rather than a reassurance. One editorial note for readers who like a quotable line: the source article contains none. No named speaker is quoted anywhere in it, at Okta or elsewhere.

Sources: GBHackers (Okta patches Auth0 AD/LDAP Connector and Access Gateway)

5. Teams and Copilot are changing domains — and it is domains, not IP ranges

CSO Online · September 11, 2026

Microsoft is migrating Microsoft Teams to teams.cloud.microsoft and Microsoft 365 Copilot to copilot.cloud.microsoft, consolidating both onto the cloud.microsoft domain. All redirects are due to complete in early October 2026, with limited exceptions for Teams extending to 31 December 2026. If firewalls, proxies, secure web gateways and other URL-aware controls are not updated before the cutover, the failure mode is not degraded performance — users will be unable to connect. Because the change is scheduled rather than announced at short notice, the entire risk here is administrative: someone has to read the message centre posts and turn them into rule changes. The authoritative references are Microsoft Message Center posts MC1465764 and MC1462915, plus the Microsoft 365 Copilot network requirements documentation; put those three in the change ticket rather than a news link.

Say this part explicitly to whoever does the work, because the “changing address” framing in the headline invites exactly the wrong search: this is a change to domains and URLs, not to IP address blocks. Nobody needs to hunt for new IP ranges, and an admin who goes looking for them will conclude nothing has changed and close the ticket. What needs reviewing is everything that matches on a hostname or URL — firewall and proxy allowlists, secure web gateway policy, SSL inspection exception lists, CASB rules, proxy PAC files — plus the documentation and runbooks that reference the old names, which is the part that quietly rots. Treat the December exception window as a hazard rather than as slack: an estate that limps through October on a partially updated allowlist will look fine, and then break in the new year when the last redirects land. CSO’s Maxwell Cooter puts the instruction plainly in his reporting — no external speaker is quoted in the piece — that “organizations using these products are advised to update their systems and documentation to ensure continued access.” The documentation half of that sentence is the half most teams will skip.

Sources: CSO Online (Teams and Copilot move to cloud.microsoft)

6. Non-human identities top the entry-point ranking — and three vendors want you to act on it

Infosecurity Magazine · CSO Online · TechCrunch · Help Net Security · September 7–11, 2026

The headline number comes from the SpyCloud Identity Threat Report, and the first thing to fix is its epistemic status: this is vendor research based on a survey of 750 cybersecurity leaders and practitioners at organisations with 500 or more employees across North America, the UK, Spain, Germany, the Netherlands, Austria and Switzerland. It is self-reported data, not incident-response telemetry, so “number one entry point” is a survey finding rather than a measured breach statistic. With that caveat attached, the finding is that non-human identities accounted for 31% of intrusions against 17% for social engineering. The pair of numbers worth taking to your own team is different, though, and harder to dismiss: 95% of organisations believe they have adequate visibility of their non-human identities, and only 36% actually monitor them. Sixty-eight per cent suffered identity-based events in the period and 42% experienced NHI-related misuse. There is also a usable operational signal buried in the visibility data — 37% of organisations that can see stolen session cookies experienced identity events, against 50% of those without that visibility — which is a reasonable argument for treating infostealer session-cookie feeds as a detection input rather than an intelligence curiosity. On governance, 56% have formal AI governance processes and 41% rely on informal ones. On supply chain, 23% cite malware-infected third-party devices and 22% exposed API keys involving vendors or partners, and 32% plan to prioritise supply chain risk management over the next 12 to 18 months. Trevor Hilligoss, SpyCloud’s Chief Intelligence Officer, gives the line that explains the persistence problem: “Every one of these identities is a standing invitation that renews itself until someone notices.”

Two other pieces this week make substantially the same argument from the authorization side, and they should be read as one item rather than two independent confirmations. CSO Online’s report on an “authorization blind spot” in AI workflows is built on “Workflow Identity Hijacking” research from Noma Labs — the research arm of Noma Security, an AI-security vendor selling into exactly this category — and the article does not frame it as vendor research. More importantly for anyone deciding what to do about it, the research contains no statistics, no sample sizes and no measured prevalence; the findings are illustrative demonstrations of a confused-deputy pattern in which an agent executes with privileges that are not tied to the requester. The problem is plausible and the scale is simply unknown. Infosecurity Magazine’s piece on organisations skipping permissions reviews before deploying AI tools reaches the same conclusion from a Syskit survey — the State of Microsoft 365 Governance Report 2026, 327 IT and security decision-makers in the US and UK at organisations with 500-plus employees — and Syskit sells Microsoft 365 governance tooling, so the finding is self-serving in the ordinary way. Its strongest statistic is also its most testable: 83% claim to know who accesses sensitive data, but only 4% could produce a complete access report within an hour, and 9% allow agents to inherit the full permissions of whoever deployed them. That 4% is the useful thing in both articles, because unlike everything else here you can reproduce it in your own environment this afternoon.

Rounding out the theme, TechCrunch reports that Cymphony has raised a Series A co-led by Sequoia Capital on the thesis that AI agents create new categories of enterprise security risk — reported funding amounts differ between outlets, so no figure is given here. And Help Net Security carries a Q&A with Chris Webber, VP Product Marketing at Teleport, on why zero trust for AI agents requires a different model from zero trust for users; it is explicitly labelled sponsored content and is a paid vendor Q&A, which is worth knowing before citing it in an architecture document. It is a reasonable framing of the problem — short-lived credentials, per-action authorisation, an identity for the agent that is distinct from the identity of whoever invoked it — provided it is read as a vendor’s framing. Taken together, the honest summary of this cluster is that four of the five pieces are produced by companies selling the remedy, they agree with each other, and the only number any of them offers that you can independently verify is Syskit’s access-report test.

Sources: Infosecurity Magazine (NHIs as the number one entry point — SpyCloud survey) · CSO Online (AI workflow authorization blind spot — Noma Labs research) · Infosecurity Magazine (organisations skipping permissions reviews — Syskit survey) · TechCrunch (Sequoia co-leads Cymphony Series A) · Help Net Security (zero trust for AI agents — sponsored Teleport Q&A)

7. Your phishing programme is reporting the wrong number, and it gets worse before it gets better

SecurityWeek · September 11, 2026

The Phishing Behaviour Report 2026 comes from Pistachio, a security awareness training vendor founded in 2019 with offices in Oslo, London and Valencia — so a company whose product is the thing the report recommends. The dataset is unusually large for this category and worth engaging with on its merits: 2.47 million simulated phishing attempts against more than 123,000 employees at over 1,200 organisations, between 1 June 2025 and 31 May 2026. Two findings puncture assumptions that are baked into a lot of programme design. Click rates by sector ranged from 26% in Design to 41% in Construction, and 30% of technical development and IT employees clicked — which is not meaningfully better than the average and directly undercuts the widespread assumption that technical staff can be given lighter-touch training. Nearly 20% of construction and real estate employees leaked credentials. On a first simulation, 1.57% of employees leaked credentials, which the report renders concretely as roughly eight people in a 500-employee company handing over a password on day one.

The finding that should change how you run the programme concerns the shape of the curve. Click and credential-leak rates initially rose during the first six months of a programme before declining. That is the opposite of what a quarterly steering committee expects to see, and it means a short pilot will be judged at precisely the point where the numbers look worst — a programme killed at month six is a programme killed on a misreading. By the end of a twelve-month programme, employees reported suspicious emails nearly twice as often as they clicked them, and the report’s argument follows from that: reporting rate, not click rate, is the meaningful metric. For a SOC this is not just a reporting-line question. Click rate measures a failure you cannot act on; reporting rate measures an input you can, because a reported email is a sample, a sender, a URL and a timestamp arriving in the queue while the campaign is still live. If your awareness programme reports click rate to the board, you have chosen a metric that moves the wrong way first and that generates nothing the security operations team can use. Joe Jones, Pistachio’s CEO and co-founder, frames it as a question about what happens after the click: “What matters more is what happens next: does the employee hand over credentials, recognize the attack and stop, or report it so the wider business can act?” The operational version of that question is whether your report-phishing button routes somewhere a human is actually watching.

Sources: SecurityWeek (Pistachio Phishing Behaviour Report 2026)

8. 26,153 findings, 202 patched: the Mythos firehose meets a human funnel

Dark Reading · Cybersecurity Dive · August 18 – September 9, 2026

Claude Mythos, deployed through Anthropic’s Project Glasswing — launched in April 2026 with Apple, Google and Microsoft as partners — has generated 26,153 total vulnerability findings. Only 2,736 of them, 10.4%, have reached the public disclosure ledger; roughly 23,417, or 89.6%, have not. The number that matters most is further down the pipeline still: of everything generated, 202 vulnerabilities — 0.8% — are currently patched. Two hundred and forty-five findings were withdrawn, and 191 sit in pre-disclosure, never reported to maintainers at all. There is also a calibration problem sitting on top of the volume problem: Claude assessed 91.5% of disclosed findings as critical or high severity, while maintainers rated only 61.3% that way. If your prioritisation pipeline sorts on a severity field, that is a systematic upward bias in exactly the column you sort on. Contrast Security’s own testing supplies the reliability half of the picture — three different AI scanners agreed on only 5% of findings across the same codebase — and its founder Jeff Williams supplies both the diagnosis and the image: “The world is still doing security at human speed,” which he elsewhere renders as pointing a firehose at a funnel.

The economics explain why the funnel does not widen. Scanning a two-million-line codebase through an API costs about $315. Triaging what comes back costs about $128,000. Discovery has become a rounding error and verification has not, and no amount of additional scanning capacity changes the ratio — it only lengthens the queue. That figure is also the evidence base for the week’s companion piece, Cybersecurity Dive’s reporting on the AI-powered vulnerability clearinghouse the US Treasury is standing up under the name “Gold Eagle,” which faces deep scepticism and significant challenges: the objections centre on funding and staffing, and the $315-to-$128,000 split is precisely the argument that a clearinghouse built around intake volume is solving the half of the problem that is already solved. Read the two together and the shape is clear — more finding capacity, public or private, does not produce more fixed vulnerabilities. One caveat for anyone tempted to turn this into a work queue: the Dark Reading piece identifies no specific affected open source projects and offers no explicit practitioner recommendations. It is context for a capacity argument, not a list of things to go and patch. The honest takeaway for a SOC lead is a budgeting one: measure what a single machine-generated finding costs your team to close out, and use that number to decide how much discovery you can afford to consume — rather than buying discovery first and discovering the triage bill afterwards.

Sources: Dark Reading (Mythos vulnerability firehose and the human bottleneck) · Cybersecurity Dive (AI-powered vulnerability clearinghouse faces scepticism)