Ransomware didn't hack in. It logged in.

At 3 a.m., a remote-access VPN session opens. It is fully authenticated. It belongs to an account whose owner is asleep, two time zones away, and who did not touch a keyboard that night.

No exploit alert fires. No malware signature trips. The firewall doesn't flag it, because the firewall is the thing that just vouched for the session. By every log your SOC reads, this is a normal login — the most boring line in the file. Days later, it's Qilin ransomware.

This is the part of the breach nobody screenshots: the attacker didn't break in. They logged in.

The flaw that forges a session

On June 8, 2026, Check Point shipped an emergency hotfix for CVE-2026-50751, a critical authentication bypass (CVSS 9.3) in Remote Access VPN and Mobile Access deployments that still use the deprecated IKEv1 key-exchange protocol. The root cause is a logic flaw in certificate validation. The effect is blunt: an unauthenticated, remote attacker can establish a remote-access VPN connection without a valid user password.

Read that again. Not "crash the gateway." Not "run code." Become a trusted, authenticated user of your network — on purpose, through the front door, with the gateway's blessing.

• May 7, 2026 — quietly live The earliest observed exploitation. No disclosure, no patch, no headlines — just authenticated sessions that shouldn't exist.
• Early June 2026 — escalation Exploitation attempts climb. In at least one confirmed case, the access is followed by post-compromise activity tied to a Qilin ransomware affiliate, across a few dozen targeted organizations.
• June 8, 2026 — disclosure + patch Check Point publishes the hotfix; CISA adds CVE-2026-50751 to its Known Exploited Vulnerabilities catalog the same day.
• June 11, 2026 — three days to fix CISA's remediation deadline for federal agencies — one of the shortest it has ever issued. The clock length is the threat assessment.

The hard breaches of this era don't trip an alarm. They authenticate. The attacker's goal isn't to look like an exploit — it's to look like you.

Why "logged in" is so much worse than "hacked in"

Twenty years of security tooling is tuned to catch the act of breaking: the overflow, the dropped payload, the command that shouldn't run. That tooling is genuinely good now. So attackers stopped breaking.

An authentication bypass produces no exploit to detect. It produces a session — a legitimate-looking, fully-credentialed session that your VPN, your identity provider, and your access logs all agree is real. The only artifact is "successful login," and successful logins are the one thing a SOC is trained never to chase. The signal is indistinguishable from the millions of benign logins around it, because on the wire it is one.

This is why identity is the real perimeter, and why the perimeter device vouching for an intruder is the worst-case version of the problem. The trust decision already happened. By the time anyone asks "should we have trusted that session?", Qilin has been inside for days.

The black-box problem

Here's the uncomfortable question CVE-2026-50751 forces: when a session shows up authenticated, can your stack tell you why it was trusted?

For most teams the honest answer is no. The tools can tell you a session happened — timestamp, account, source IP. They cannot show you the reasoning behind the trust, because there was no reasoning recorded, just a boolean: the gateway said yes. When the basis for trust is opaque, you have no way to separate a real login from a forged one. You're not investigating; you're taking the gateway's word for it. And the gateway was the thing that got fooled.

This is the case for what we call zero black box. Every verdict — including the verdict "this session is trustworthy" — has to be auditable. Not "access granted," but the trail behind it: authenticated over a deprecated IKEv1 path, from a device never seen on this account, from a geography the user has never logged in from, with no second factor, minutes after the same account was idle. Each of those is a quiet signal. Recorded and connected, they are a verdict. Discarded, they are how you find out from the ransom note.

How n0limit catches the login that's an intruder

n0limit treats every authentication event as something to investigate, not something to wave through. When that 3 a.m. VPN session opens, it isn't logged and forgotten — it's enriched against the account's history, correlated with device, geography, protocol path, and second-factor state, and resolved to a verdict in under 500 microseconds. A session that authenticated but contradicts everything known about the user doesn't sit in a "successful logins" bucket; it's surfaced as an incident, with the full reasoning trail attached.

That trail is the point. An operator can see exactly why the session was flagged. So can an auditor, and so can a regulator asking how a credentialed intruder reached your data — the difference between "the VPN said it was fine" and a defensible, recorded chain of reasoning. And because the verdict lands at machine speed, the trust can be revoked before the session becomes an encryption event.

Attackers have done the math: breaking in is loud and getting harder, logging in is quiet and getting easier. The defenses built to catch the break won't see the login. The only thing that will is a SOC that refuses to trust any session it can't explain — and can prove, in microseconds, exactly why.