Your site-to-site tunnel doesn't ask for MFA because there's nobody to ask

On September 22 CISA added two Check Point vulnerabilities to its catalog of exploited flaws, with a deadline of the 25th. Three days. Most of the coverage we saw stopped at "patch your remote access VPN". But the official entry says, literally, "using Site to Site VPN or Remote Access VPN". And the tunnel between your own offices is a different animal: there is no user there to ask for a second factor. There is nobody to ask.

What the catalog says, word for word

We downloaded the CISA KEV catalog JSON (version 2026.09.25, 1,726 entries) instead of trusting the headlines, because the nuance is in the text. Both new entries are dated September 22, both due on the 25th, and both flagged as requiring forensic triage:

Both carry a CVSS of 9.8. We won't dwell on the second one, because we covered the management plane thoroughly back in July with the SmartConsole zero-day, and the thesis was the same: the console is a better prize than the firewall. What we had never written about is the line above.

The detail that decides whether it applies to you: certificate or pre-shared key

The important caveat, because it almost never shows up: the scope centres on tunnels that use — or merely allow — certificate-based authentication. And that "allow" is the uncomfortable part. A gateway that in practice brings its tunnels up on a pre-shared key may still accept a certificate during negotiation, so "we're on PSK" isn't an answer until somebody has gone and looked at the configuration. Checking and assuming are not the same thing, and on a pre-authentication flaw under active exploitation the difference isn't academic.

There's also one detail of the observed attacks that fits everything that follows: the wave that started on September 12 went mainly after Spark customers — the small range, the one that sits in branches and ten-person offices. The attackers came out through VPN services and proxies to hide their origin and sent malformed X.509 certificates during negotiation. Which means the box taking the most hits isn't the big one in the datacenter.

A site-to-site tunnel has no user

Here is what we think has been told badly. When someone says "VPN flaw", the reflex is to picture the door people walk through: the laptop at home, the user, the password, the second factor. We've built a decade of controls on top of that door. Conditional access, MFA, device compliance, geolocation, sessions that expire.

The site-to-site tunnel has none of that, and not out of negligence: by definition. It authenticates machines, not people. There's no second factor because there is no factor. There's no conditional access because there is no identity to attach a condition to. It doesn't expire: it was configured once, the day the Girona office opened, and it has been there ever since. It doesn't show up in the monthly access report, because it isn't an access — it's topology.

Now put that together with where the flaw sits. Certificate validation happens during negotiation — before authentication ever completes, and long before your directory learns that someone knocked. To be precise: the certificate is the machine's authentication, and the flaw sits exactly there, in the step that decides whether that machine is who it claims to be. Your entire identity apparatus — MFA, conditional access, policies — lives behind the piece that broke. It isn't that the controls failed: they never got to run.

What sits on the other side of the tunnel

The second part is worse than the first, and it's pure network design. A site-to-site tunnel almost always ends in flat routing: the branch network sees head office, and often the other way round. It gets built that way because it's convenient. The ERP has to be reachable, the branch printer has to print the delivery note, the technician has to reach the NAS over there from over here.

So the day someone takes that gateway, they inherit the road between all your sites — and with code execution on the very device that polices it. It's the same shape of problem we described three days ago with the SD-WAN orchestrator: some components aren't measured by what they do, but by how many places they reach. And the same thing we saw when the branch firewall was a checkbox someone ticked and nobody looked at again.

The two advisories, read side by side

There's one detail that only surfaces if you lay both scopes side by side, and we think it's the most useful part of all this. According to the published scope summaries, the R82.20 branch is NOT affected by the gateway flaw (85102)… and yet it does appear in the scope of the management server flaw (93616). The version that saves you from one is exactly the one that leaves you exposed to the other.

That's why "are we patched?" is the wrong question. The right one is "patched against which?". And there's a documented trap waiting right there: the automatic patching channel covers one of the two flaws and not the other. The live patches that closed the gateway one do not remediate the management server one, and the vendor has said there will be no live patch for it given the nature of the fix: you have to install the accumulator, and in R82.20's case a separate specific hotfix. Translated for Monday's meeting: you can see "protected" in the console, be right, and still sit inside the scope of the other flaw. We deliberately don't reproduce the exact version numbers here — publishing a wrong version in a security post is worse than publishing none — take them from sk1000117 and sk1000171, and from nowhere else.

This isn't about one vendor

It would be easy and dishonest to turn this into a dig at a brand. Read in full, the catalog says something else. So far this year the same vendor has four entries in the catalog, and three of them attack the same point: the place where it is decided who you are. (The fourth is the management server one above.) In June, an authentication flaw in the IKEv1 key exchange that allowed — quoting the catalog itself — "an unauthenticated remote attacker to bypass user authentication and establish a remote access VPN connection without a valid user password", which CISA flags as used in ransomware campaigns. In July, the console's administrator token. In September, the certificate negotiation.

Call it a pattern of the category. The VPN concentrator is a favourite target because it is the one piece of your infrastructure that is required to be exposed. You can hide a server. You can segment a database. The firewall terminating your tunnels has to answer whoever talks to it on the Internet, because that is its job. We build our own inter-site tunnels with WireGuard and BGP, so this particular CVE doesn't touch our network. That doesn't make us better: it makes us have a different vendor to worry about and a different advisory to read on Mondays.

Opinion: the patch that arrived on its own

What we would check this week

You already know how to patch. This is the other part — the part that still holds once the patch is in and the next advisory hasn't landed yet:

On the published indicators: three certificate subjects have been described in the observed attempts (vpn, vpn-user, vpnuser). They're useful for looking backwards, not for declaring anything clean. The advisory itself warns more may be in use, so not finding them proves nothing.

Zero Trust, said without the fog

Zero Trust has been worn thin by people selling boxes with it. Applied to this specific case it fits in one sentence you can test on your own network this afternoon, with nothing to buy and no two-year programme. Coming in through the tunnel must grant nothing by itself. Scope should be decided by identity and destination, not by origin. "It comes from the Girona office" should stop being an authorization argument — because while it is one, whoever takes the Girona gateway inherits that argument whole.

This week's flaw already has its deadline behind it. The decision about how far a tunnel reaches was made years ago and stands until somebody changes it. The first is set by somebody else's calendar; the second is yours, and it is the one that decides whether the next advisory costs you an afternoon or a weekend.

Sources. Dates, literal descriptions, scope and the forensic triage requirement: CISA Known Exploited Vulnerabilities catalog, version 2026.09.25, read directly from its JSON — cisa.gov (entries CVE-2026-85102 and CVE-2026-93616, added 2026-09-22; CVE-2026-50751, added 2026-06-08). CVSS 9.8, references sk1000117 / sk1000171, the scope centred on tunnels that use or allow certificate-based authentication, and per-branch scope: summaries from Qualys ThreatPROTECT. The September 12 wave against Spark customers using malformed X.509 certificates during negotiation, the automatic live patch rollout, the fact that this channel does NOT cover CVE-2026-93616, and the observed certificate subjects: the vendor's own advisory and BleepingComputer. Per-branch scope for the second one (including R82.20 and the accumulators that close it), cross-checked against the Beazley Security advisory, which lists R82.20 as the fixed version for the gateway flaw. Take numbers are deliberately not reproduced here: get them from the vendor advisory.