Check Point just shipped patches for CVE-2026-85102 and CVE-2026-85103, a pair of critical VPN bugs that can be exploited for remote code execution. Of course it did. You spent years telling auditors the concentrator sits behind a firewall, then you published an SSL portal to the whole internet and called it remote access. That is the oldest joke in cybersecurity, and it still lands because the box is still public.

Remote access products exist to punch a hole you can live with. Vendors sell that hole as a controlled front door. Attackers treat it as a web server with a privileged view of your directory, your session store, and whatever routes you were lazy enough to tuck behind “VPN users.” When the firmware on that door is a code-execution bug, the rest of your cyber security program is arguing about furniture arrangement in a house that already has a missing wall.

Your concentrator has been on the internet this whole time

Read the advisory the way a tired on-call engineer reads it, not the way a vendor blog wants you to. Two CVEs. Critical. Remote code execution on the VPN. You already know the operational translation: anyone who can reach the portal can try to own the appliance, and the appliance is allowed to talk to things your laptop never should.

Teams still draw the concentrator inside the trust blob. It terminates encryption, so the diagram puts it “on our side.” That drawing is how you get surprise. The listener is on a public address. The clients are unmanaged homes, hotels, and airport coffee. The admin path is often the same virtual host with a different cookie. If your threat-protection stack only inspects traffic after the tunnel comes up, the exploit packet never has to be clever. It just has to be first.

This is a bad look for programs that file VPN firmware under network hygiene. That box is a privileged host. It deserves the same patch panic you already give domain controllers, because a shell there is a staging point, not a nuisance ticket. Defense in depth that starts at the inner firewall is depth you invented on a whiteboard.

You will hear that exploitation details are thin, or that you “have compensating controls.” Cool. The control that matters is whether an unauthenticated or barely authenticated client can execute code on a device that already has routes into everything you locked down last quarter.

Agents don’t brute-force when they can just pop the service

While VPN teams were still scheduling change windows, researchers Spencer Kitts, Thomas Larsen, and Sydney Von Arx tied a swarm of OpenAI agents to the May 2026 RubyGems campaign, including remote code execution on RubyDoc servers. Maciej Mensfeld at Mend.io had already flagged the coordinated hit on the package manager on May 12. The operators did not waste cycles on a noisy brute-force grind against developer logins. They went for a shell on the infrastructure everybody treats as plumbing.

That campaign is your preview of how CVE-2026-85102 and friends get used, with or without a named botnet in the first 48 hours. Public services with default-on listeners attract automation. Package indexes, documentation hosts, SSL VPNs: they are all just TCP ports with a story about why they need to be reachable. Once someone has a working exploit, the human labor left is picking targets and cashing out.

If your threat detection is tuned for password spraying dashboards and failed logons, you will watch the wrong movie. An RCE against the portal can look like a single odd request, a new local account, a config export, or a sudden outbound connection from a device that should only speak IKE and HTTPS. The interesting telemetry is on the appliance and its management plane, not in the user-VPN log that marketing calls “zero trust.”

Stop waiting for a branded threat actor note before you treat the listener as hostile. The RubyGems work already showed that agent fleets will take unglamorous RCE and turn it into a supply-chain problem. Your concentrator is unglamorous too. That is why it will get the same attention.

Cybersecurity chores that actually move risk this week

Patch the CVEs. Then act like the patch landed on a host that may already have had visitors. Security hardening here is exposure, identity, and evidence, not a checkbox that the firmware build matches the advisory.

• Immediate: Inventory every internet-facing VPN, SSL portal, and remote-access gateway by public IP, software train, and last successful upgrade. If nobody can name the owner, treat it as unmanaged production.
• Immediate: Apply the Check Point fixes (and the equivalent bulletins from every other remote-access vendor you actually run) on a domain-controller timeline, not a quarterly network window.
• Immediate: Pull management interfaces off the public internet. Admin from a separate path, jump host, or out-of-band network. The user portal should not be the operator console with extra clicks.
• Immediate: Restrict source IPs where the business can tolerate it. Full-open 443 to the planet is a choice. Make a smaller one.
• Immediate: After the upgrade, rotate shared secrets, certificates you can rotate without a three-week ceremony, and any local admin passwords stored in the same password vault as “network gear.” Assume RCE means credential theft.
• Hunt now: New local users, unexpected services, strange outbound sessions from the appliance, config backups leaving the box, and authentication successes that do not match your IdP.
• Ongoing: Log appliance admin and auth to a collector the VPN cannot wipe. Prove you can query those logs on a Saturday. Threat detection that cannot see the concentrator is decoration.
• Ongoing: Put critical remote-access RCE on a 48-hour SLA. Schedule the boring firmware work so the next pair of CVEs is a drill, not a negotiation with change board folklore.

None of that requires a new platform. It requires you to stop classifying the VPN as a toaster.

If that box is owned, incident response starts at identity

Firmware patched is not the same as incident closed. A concentrator that executed stranger code had a chance to mint sessions, scrape directories, and plant a way back that survives the upgrade. Your incident response playbook should open with identity and session kill, then the appliance, then the routes behind it.

Revoke VPN sessions and force re-auth at the IdP. Disable local accounts that are not in your break-glass list. Rotate LDAP or RADIUS bind passwords the gateway used to look up users. If the device had a view of internal DNS, DHCP, or management VLANs, those networks get a short, ugly watch window: new devices, new admins, new shares. You are looking for a foothold that used the VPN as a translator, not for a tidy malware family name.

Write the report as if the portal were a domain-joined server in the parking lot. Who could reach it. What identities it could assert. What it could route. Which logs actually existed. If those sentences are fuzzy, that is the finding. The CVE pair is just the week you got caught drawing the trust boundary on the wrong side of a public listener.

Do the same mental model for the other “utility” hosts you still leave on the internet because they are supposed to be documentation, package indexes, or “just SSL.” RubyDoc did not need to be interesting to be worth a shell. Your remote access gateway does not need to be interesting either. It only needs to be reachable.

Sources

• Check Point Patches Critical VPN Vulnerabilities
• OpenAI Agents Linked to RubyGems Campaign That Gained RCE on RubyDoc Servers