September's posts covered fifteen cases: twelve flaws in products organizations can run themselves, one espionage campaign that named no flaw, one breach carried out with valid passwords, and one appliance fingerprinted before anything was exploited. In four of them nobody had confirmed a successful compromise when we wrote, and those posts say so: they were exposure windows, not reconstructions of an attack.
Each post was written alone, about one product. Read together, they show something no single one could. The advice at the end of each was not ours. It came from the vendors, national agencies and research firms involved, and in ten of the fifteen it came down to the same advice.
Ten cases, one piece of advice
| Case | Who advised it | What they said |
|---|---|---|
| JFrog Artifactory | IONIX, an exposure management firm | Restrict network access to trusted networks until the upgrade is complete |
| SonicWall SMA1000 | Beazley Security Labs | Restrict the Work Place interface to trusted networks; allowlist the management console |
| Kestra | Microsoft | Do not expose management interfaces directly to the internet |
| Exchange relay flaw | NCSC-NL | Servers that cannot take the update should be accessible only internally |
| Cisco Secure FMC | Cisco's hardening guide | Permit HTTPS and SSH access only from specific IP addresses |
| PAN-OS | Palo Alto Networks, NHS England | Restrict management access to trusted internal addresses |
| WSO2 | Field Effect | Limit access to management interfaces and administrative services |
| NetScaler | Guidance reported by BleepingComputer | Take exposed appliances offline, and restrict access to trusted networks |
| SharePoint | Canadian Centre for Cyber Security | Limit the internet exposure of SharePoint servers |
| Cisco SD-WAN Manager | Cisco | Allow only known, trusted hosts to send traffic to the system |
In six of those ten the vendor listed no workaround, and for NetScaler there was not yet an advisory at all. Where a workaround would normally sit, the advice was about reachability. An eleventh case went further: when the flaw behind the FortiGate fingerprinting was new, Fortinet's advice to anyone who could not patch was to turn SSL-VPN off entirely, which is the same instruction with the precision removed.
Palo Alto made the point in arithmetic. It scored one PAN-OS flaw twice: 7.2 on a PA-Series firewall whose management interface answers anyone, 5.2 where it answers only trusted addresses.
One bug, one patch level, two numbers, and the only variable between them is who the interface answers.
None of this advice needs new equipment. Source-based rules on a firewall or a cloud security group are older than most of the products involved.
Patched, and still answering
Six cases involved a flaw whose fix was already out.
- Exchange. Fixed on 11 August. On 31 August, Shadowserver still counted 21,899 unpatched servers reachable from the internet.
- SharePoint. Fixed on 11 August under a spoofing label at CVSS 6.5. Exploited as code execution by late September.
- Cisco Secure FMC. Hotfixes for CVE-2026-20079 existed for five months before Cisco became aware of exploitation in August.
- WSO2. Patched by May. On 13 September, watchTowr reported forged administrator tokens arriving at its honeypots.
- F5 BIG-IP APM CVE-2025-53521. Fixed in October 2025, when it was classified as denial of service. On 7 September, 795 exposed endpoints were still vulnerable, and Sophos described an implant that survives upgrade images.
- FortiGate SSL-VPN at a Thai broadband provider. The flaw the toolkit was aimed at was disclosed in February 2024. The appliance was running firmware older than that.
None of this is negligence. Updating a mail server, a collaboration server or the appliance every remote worker signs in through is scheduled work, and scheduled work slips. Labels make it slip further: a moderate spoofing issue and a denial-of-service fix do not win an out-of-band maintenance window. The patch is the remedy in every one of these posts. It is also the one control that runs on a calendar.
Nothing to apply yet
In five cases, exploitation came before there was anything to install, or before anyone had named the flaw.
- NetScaler. watchTowr found two flaws being exploited during forensic work. Until Citrix's bulletin on 27 September there was no CVE, no build list and no patch.
- F5 BIG-IP APM CVE-2026-94127. F5's advisory on 22 September said the flaw had already been exploited.
- Cisco SD-WAN Manager. CVSS 9.8, exploited in September, no workaround. CISA gave federal agencies three days.
- SonicWall SMA1000. Both flaws exploited at disclosure, the entry point the second pre-authentication flaw of that shape in seven weeks.
- Eight Latin American governments. ESET says the operators exploited publicly reachable Exchange servers, and names no vulnerability.
Patching, detection and signature rules all need an input: a fixed build, an indicator, a known request. In these five, for some window, none existed. Who the service answered did not depend on the flaw having a name.
JFrog and Kestra sit between the two groups. A fix existed, and exploitation followed four days later at JFrog and, Microsoft assesses, within the same month at Kestra.
The access layer answered first
Eight of the fifteen were the equipment organizations use to control access: the SMA1000, both F5 APM flaws, NetScaler Gateway, the FortiGate SSL-VPN, a PAN-OS firewall, the Secure FMC that writes firewall policy, and the SD-WAN Manager that writes it for every connected site. Every one has a login, and in every one the flaw was reached before that login, or around it.
The month also separated a hard case from an easy one. A remote access gateway has to answer everybody who works at the company, which is what makes restricting it hard. A management console has to answer a handful of administrators. FMC, the PAN-OS management plane and SD-WAN Manager are the easy case, and Palo Alto has now priced getting it right at two points of severity.
One case with no exploit at all
France's tax administration lost data on roughly 353,000 individuals and 252,000 businesses to valid staff passwords, presented at portals that asked for nothing else. ANSSI's report lists the signals nobody correlated. Three of them, connections from VPNs, addresses in India and addresses already known to be malicious, described where a connection came from. All three existed before the login they belonged to.
Why the advice is not already how these run
The posts reached the same explanation, and it is worth giving once. A list of trusted networks is wrong from the day it is written, and wrong asymmetrically: an address left in too long is silent, while a missing one is a person who cannot work, filing a ticket within minutes. So the range widens until it is no longer a control, or it is never written. The advice in the table is correct. It has never been maintainable by hand.
The month's one essay, on AI attackers, argued that the window is closing from the other side. The scan, find and exploit loop used to cost a skilled person's time, and that cost bought defenders the weeks a change window needs. Four days at JFrog is what a short window looks like, whoever is on the other end.
Where Veribound fits
Veribound is a Pre-session Edge Access Control (PEAC) platform and an intelligence layer. It is additive: every patch, login, firewall and console in these fifteen posts stays where it was, and the customer's own equipment keeps enforcing its own policy.
An agent on each staff and administrator device keeps confirming it is still the one the organization trusted. What reaches the customer's existing controls is a trusted origin: the network that device is connecting from, in practice its public address. Those arrive as address-group updates against policy the organization already has, which is the restriction ten of September's fifteen cases were told to put in place.
It repairs none of these flaws. It has nothing to offer the parts of these products built to answer strangers, such as inbound mail, a public load balancer or a firewall's data interface, and nothing against an attacker already working from a device and network the organization trusts. What it changes is the one thing every advisory in the table asked for, and almost nobody could keep true.
Sources: the sixteen September posts linked above, each of which cites its own.