Check Point gateway attacks led to ESXi wiper and 3 more

What people are saying

The brief asks the court to rule that police searches of automated license plate reader (ALPR) databases require a warrant. The post drew a long discussion on Hacker News and circulated on Bluesky and X.

What holds up

The core claim is confirmed by the EFF's own account of its filing. The brief argues that ALPR tracking is a "search" under the Fourth Amendment.

The EFF says officers ran an open-ended search of two ALPR databases, Flock and ELSAG, to find a suspect car in a Cleveland-area robbery investigation. The district court opinion denied the motion to suppress. It still called the motion "a close and difficult constitutional question."

That opinion said no circuit court had yet ruled on whether ALPR database queries are Fourth Amendment searches. It also said no federal district court had held that ALPR use violates the Fourth Amendment. The EFF says that changed last month, when a federal district court called ALPRs "a form of indiscriminate mass surveillance."

Elsewhere, a Minnesota federal court noted that the Eighth Circuit has not squarely considered the issue. That court declined to decide it. The EFF made a similar argument in a 2025 brief to the Virginia Court of Appeals. The EFF says it hopes the Sixth Circuit will reverse the lower court.

Inside the threads

Most Hacker News commenters backed the EFF. A sizable camp said a warrant rule does not go far enough and argued the data should not be collected at all. One commenter wrote that "Making things illegal does not stop abuse."

A commenter pointed to a New Hampshire statute that, by their description, requires deletion of non-hit plate images within three minutes. Others said retention limits were the more practical lever.

A counter-camp argued that a warrant rule would block useful searches, such as tracing a car's movements in the 48 hours before a crime. One commenter raised a question that matters to private operators: whether retailers running their own cameras share data informally with officers who ask. One commenter's description of what location data a large tech company records was an unverified assertion, not reporting.

Our take

An amicus brief changes nothing on its own, and we would not treat this as settled law. The signal is in the trend: judges keep calling ALPR questions novel and difficult, and at least one court has now found a possible Fourth Amendment problem. In our reading, the underrated issue is the private side. Businesses that run plate readers in parking lots, campuses or logistics yards often feed or share data with networks that police can query. A warrant rule would govern police searches, but your organization would still own the retention decision and the sharing decision. The EFF cites a survey finding that 99.5% of scans involved people with no association to crime. We think that statistic shows how much third-party data your systems may be holding for no business purpose.

What to do

• Inventory every ALPR or camera system you operate, including vendor-hosted ones, and record what each captures and where the data flows.
• Set and enforce a short retention period for non-hit plate data, tied to a documented business need.
• Route all law-enforcement requests through legal review, and bar informal sharing by site or loss-prevention staff.
• Review vendor contracts and settings for default data-sharing into wider networks, and turn off what you have not approved.

What people are saying

In a Mastodon thread, the researcher who shared the sample wrote that security scanners see YouTube as the domain on these links and mostly let them through. Replies quickly turned to why YouTube runs a redirector that can be abused. In our reading, the LearnWorlds angle is what made the post travel, and it is the part with the least behind it.

What holds up

The lure itself is well described in the thread. The original poster agreed it was a fake window and guessed at a real-time phishing proxy. Another commenter said the domains behind the fake portal had been reported to Google as phishing.

The target is familiar. Google's Threat Analysis Group has disrupted financially motivated phishing aimed at YouTubers since late 2019. Those attackers hijack channels, then sell them or use them to broadcast cryptocurrency scams. Google reported that hijacked channels sold for $3 to $4,000 depending on subscriber count.

LearnWorlds' data security page says each school is isolated, so a school that is compromised or goes rogue leaves the others unaffected. It also says the company monitors accounts and school activity for abuse.

Our verdict is unconfirmed. The phishing technique is real, but a breach of LearnWorlds' mail infrastructure is still the original poster's suspicion.

Inside the threads

One camp asked why YouTube keeps a redirector at all. A reply explained that reviewers link products in video descriptions and earn small commissions on clicks. Practitioners added the most useful detail: the BitB finding, and the reports filed against the phishing domains. A commenter called it a "pretty sophisticated scam" that defeats the cues users are trained to check. Another said they would use the example to improve their anti-phishing tools.

Our take

We think the vendor name is the least useful part of this story for most security leaders. Given that LearnWorlds isolates each school, an abused customer account on a shared platform strikes us as at least as plausible as a vendor breach, and the two call for different responses. The underrated lesson is the stack: a legitimate sender, a trusted redirect domain and a fake login window together beat filters and training at once. Google has also tied the rise of cookie theft to wider adoption of multi-factor authentication (MFA), which pushes attackers toward session hijacking. In our view, any team running brand or creator accounts on YouTube is a likely target and deserves specific attention.

What to do

• Ask your email security team whether filters follow redirects through trusted domains to the final destination, not just the first link.
• Train staff who manage social or video accounts to treat sign-in pop-ups inside a web page as suspect, and move those accounts to phishing-resistant MFA such as passkeys or hardware keys.
• If you use LearnWorlds, report suspicious mail to the address it lists for security issues, support@learnworlds.com, and review your school's sending activity.

What people are saying

A BleepingComputer report says vulnerable Check Point Security Gateway instances were targeted in PHP2Shell attacks that deployed data-wiping malware on VMware ESXi hosts. The story drew discussion in a Reddit r/cybersecurity thread, where commenters argued that exposed management interfaces were to blame. A post on X from a security news account said hackers were exploiting PHP2Shell in unpatched Check Point gateways to gain root access and wipe files.

What holds up

Check Point's own research write-up confirms the chain: PHP2Shell through Mobile Access portals for initial access, followed by CVE-2026-123039. It says the attackers pivoted from the gateway to a VMware ESXi host over SSH and deployed the destroy_v6 wiper.

PHP2Shell is two PHP interpreter flaws, and the Cybersecurity and Infrastructure Security Agency (CISA) added both to its Known Exploited Vulnerabilities (KEV) catalog on October 26. The National Vulnerability Database entry for the Gaia OS privilege escalation flaw shows CISA added it to KEV on November 13.

Scale is smaller than the chatter suggests. Check Point's advisory says only a couple of dozen unpatched systems in a single region were compromised. It says fixes were available a week before the attack, on October 23.

The first wave, on October 30, targeted Israeli organizations and turned destructive at some of them. The second wave, on November 2, showed no evidence of destructive activity. Check Point notes that ESET associated the related malware framework with the China-nexus cluster UNC5221, but says the evidence does not allow a high-confidence assessment.

The entry point Check Point describes is the Mobile Access Portal, not a management interface. Our verdict: confirmed, on the vendor's own account.

Inside the threads

One Reddit camp treated this as a patching failure, with a commenter saying boundary devices should be patched first. Another camp focused on management-plane exposure. A reply in that camp pointed to existing out-of-band management products as the answer to remote-site emergency access.

A practitioner added that an inventory is most useful when it records the running version, the internet exposure and a named owner for each appliance. A commenter warned that edge devices popular with large enterprises are "being reverse engineered constantly."

On X, one post said a root zero-day let attackers reach ESXi. Check Point says the move to ESXi came through lateral movement over SSH using a service account. One security vendor's write-up called the political messaging deliberate false-flag messaging. Check Point lists a false flag as only one of several plausible scenarios.

Our take

In our reading, the victim count is small and the lesson is large: a fix existed for a week, and unpatched edge appliances still fell. We think the management-interface argument is a distraction here. Mobile Access portals are meant to face users on the internet, so the control that failed was patch speed, not exposure policy.

The underrated part is the path from firewall to hypervisor. A security gateway that can open SSH sessions to ESXi hosts is a segmentation gap most teams have never tested.

The attribution debate is noise for defenders. What matters is that a compromised gateway can also degrade the logs you would use to spot it.

What to do

• Install the November Jumbo Hotfix on all Management Servers and Security Gateways, prioritizing internet-facing Mobile Access deployments, then verify the running version.
• Hunt on gateways exposed since late October for Check Point's listed indicators: PHP session files containing upload_progress_pwn, processes named like CPconfigdaemon, and unexplained gaps in firewall logs. A clean result does not rule out compromise.
• Block SSH from gateways to internal ESXi hosts and alert on any attempt, since BleepingComputer calls such activity a clear sign of breach.
• Inventory PHP beyond web servers. CISA warns it is often embedded in other software.