Four CVSS 10.0 vulnerabilities in SAP, an entire RMM platform taken offline, state-attributed IoT sabotage with kinetic consequences, and an OpenSSH bypass that botnets are already using. Monday’s news cycle delivers on every front.

In the News

SAP Patches ICM2SHELL and PROXYGATE - Four CVSS 10.0 Unauthenticated RCE Flaws

SAP released emergency patches for four maximum-severity vulnerabilities affecting NetWeaver Application Server and Web Dispatcher. Tracked collectively as ICM2SHELL and PROXYGATE, all four carry a perfect CVSS 10.0 score and require no authentication to exploit. The attack surface is any SAP system reachable over HTTP - which, in most enterprise environments, includes ERP instances, supply-chain integration layers, and customer-facing portals.

The unauthenticated nature of these flaws eliminates the most common defensive assumption: that an attacker needs valid credentials before they can cause damage. A single HTTP request to an unpatched NetWeaver or Web Dispatcher instance is sufficient for remote code execution. Organizations running SAP in flat network architectures - where ERP systems share segments with general corporate traffic - face the highest risk.

Patching is the primary remediation, but network segmentation is the compensating control that matters while patching proceeds. SAP estates should be isolated behind application-layer firewalls with strict ingress rules, and intrusion prevention systems should be updated with signatures for these CVEs as vendors release them. Any internet-facing SAP system that has not been patched should be considered at immediate risk.

What defenders should do: Apply SAP’s emergency patches immediately. Verify that NetWeaver and Web Dispatcher instances are not directly reachable from untrusted networks. Deploy IPS signatures as they become available from your NGFW vendor. Audit network segmentation around SAP infrastructure - if ERP is on a flat network, this is the forcing function to fix that.

Source: BleepingComputer

N-able N-central Pulled Offline After 30+ Zero-Days Published with PoC Exploits

A security researcher published proof-of-concept exploits for over 30 zero-day vulnerabilities in N-able’s N-central remote monitoring and management platform - a disclosure campaign dubbed Able2Shell. N-able responded by taking its N-central cloud service offline and advising on-premises customers to shut down their instances until patches are available.

The implications extend well beyond N-able’s customer base. RMM platforms are high-value targets because they hold administrative access to every endpoint they manage. A single vulnerability in the RMM layer becomes a vulnerability in every managed device across every customer environment. This is the same supply-chain trust model that made the Kaseya VSA attack in 2021 so devastating - MITRE ATT&CK technique T1072 (Software Deployment Tools) applied at scale.

For organizations that depend on N-central, the immediate operational question is visibility. With the management platform offline, endpoint telemetry, patching, and remote remediation capabilities are degraded or gone. EDR running independently on each endpoint becomes the last line of defense.

What defenders should do: If running N-central on-premises, follow N-able’s guidance and shut down until patches ship. Verify that your EDR agent operates independently of the RMM platform. Review application allowlisting policies on managed endpoints. Audit which credentials and access tokens the RMM platform holds - those are now potential IOCs if any instance was compromised before the takedown.

Source: SecurityWeek

France Attributes Iranian IRGC Unit Shahid Kaveh to Refrigeration Controller Attacks

France officially attributed October’s cyberattacks on commercial refrigeration controllers to Shahid Kaveh, an Iranian Islamic Revolutionary Guard Corps (IRGC) cyber unit. The attacks manipulated IoT-connected cooling systems at approximately 700 retail sites across France, causing refrigeration units to overheat and starting 15 fires - one of the clearest examples of cyber-to-kinetic impact against commercial infrastructure in Western Europe.

The attack vector exploited the absence of IT/OT segmentation in retail environments. Refrigeration controllers connected to store networks without access controls or dedicated monitoring provided the initial access point. Once on the device, the attackers modified temperature setpoints to force overheating - a technique that requires no malware in the traditional sense, only unauthorized access to a management interface. MITRE ATT&CK maps this to T0855 (Unauthorized Command Message) and T0831 (Manipulation of Control).

This attribution reinforces what OT security practitioners have warned about for years: IoT devices in commercial environments - refrigeration, HVAC, lighting controls, building management systems - are rarely inventoried, rarely segmented, and rarely monitored. The attacker does not need sophistication when the target has no defenses.

What defenders should do: Inventory IoT and OT devices in retail and commercial environments. Segment operational technology from corporate IT networks at the switch and firewall level. Deploy OT-aware anomaly detection that can identify unauthorized changes to device configurations. Treat any IoT device with a network management interface as an attack surface.

Source: The Record

OpenSSH SSHole Bypass Under Active Exploitation by Botnets

CVE-2026-123158 - dubbed SSHole - is an authentication bypass in OpenSSH that is being actively exploited by botnets and cryptocurrency miners. The flaw is startlingly simple: any password of 257 or more characters successfully authenticates against accounts configured for key-only authentication, completely bypassing public-key enforcement.

The vulnerability undermines a foundational assumption in Linux and Unix hardening: that disabling password authentication and requiring SSH keys is sufficient to prevent unauthorized access. Every internet-facing SSH service running an unpatched OpenSSH version is now a target for automated exploitation. Botnets are already scanning for and exploiting this at scale.

What defenders should do: Patch OpenSSH immediately on all internet-facing systems. As a compensating control, restrict SSH access to known management IP ranges at the firewall level - do not rely solely on SSH configuration to prevent unauthorized connections. Monitor for anomalous SSH authentication events, particularly successful authentications to key-only accounts. Audit which systems expose port 22 to the internet and reduce that surface to the minimum required.

Source: BleepingComputer

Defender Action Items

  • SAP (ICM2SHELL/PROXYGATE): Apply emergency patches to NetWeaver Application Server and Web Dispatcher. Verify network segmentation isolates SAP estates from untrusted traffic. Update IPS signatures.
  • N-central (Able2Shell): Shut down on-premises instances per N-able guidance. Confirm EDR operates independently. Audit RMM-held credentials.
  • OpenSSH (SSHole CVE-2026-123158): Patch all OpenSSH instances. Restrict port 22 to management subnets at the firewall. Monitor for successful key-only account password authentications.
  • Chrome (CVE-2026-125350): Force-update Chrome to latest stable across managed endpoints. This is the eighth Chrome zero-day in 2026 - browser patching cadence must be automated.
  • IBM Aspera Faspex (CVE-2026-123218): CISA KEV-listed, CVSS 9.8. Patch or isolate Faspex instances. Federal agencies face a 3-day remediation deadline.
  • IoT/OT segmentation: Use the France/IRGC attribution as a catalyst to audit IoT device inventory and network segmentation in retail, logistics, and commercial environments.

Detection Queries

The SSHole vulnerability (CVE-2026-123158) produces a distinctive authentication pattern: successful password-based logins to accounts that should only accept key authentication. The following Splunk SPL query identifies these anomalous events in OpenSSH auth logs.

index=linux sourcetype=syslog ("sshd" AND "Accepted password")
| rex field=_raw "Accepted password for (?<user>\S+) from (?<src_ip>\S+)"
| lookup ssh_key_only_accounts user OUTPUT key_only
| where key_only="true"
| stats count by user, src_ip, host
| where count > 0
| sort -count

This query requires a lookup table (ssh_key_only_accounts) mapping usernames configured for key-only authentication. Any hit is a high-fidelity indicator of exploitation - there is no legitimate reason for a password-based login to succeed on a key-only account. False positive rate is effectively zero if the lookup table is accurate.

For environments without a lookup table, a broader detection searches for password-accepted events on any account where PasswordAuthentication no is set in sshd_config:

index=linux sourcetype=syslog ("sshd" AND "Accepted password")
| stats count by host, user
| where count > 0

Any result warrants immediate investigation - if password authentication is disabled in configuration, these events should not exist.

References

Subscribe to it-learn Brief

Get it-learn Brief in your inbox (Mon–Fri) - Daily cybersecurity news, SE angles, and detection queries.