Top 5 Cybersecurity News Stories July 24, 2026

The five stories in this week’s Cybersecurity News Stories July 24, 2026 share a structural feature that distinguishes them from the opportunistic exploitation patterns that dominate most news cycles: in each case, the component that was compromised, configured, or exposed was not the primary IT system the organisation considers its attack surface. It was the layer behind it — the control logic that governs what the industrial process is permitted to do, the management console that configures what the firewall is allowed to block, the cryptographic keys the server uses to validate every authentication it issues, the query engine that evaluates the code the enterprise’s own workflow automation runs, and the third-party IT support platform used to manage client data on behalf of a firm whose clients include some of the largest organisations in the world. In each case, the attack did not reach its target by breaking through the outer layer of the defended perimeter. It reached its target by operating inside a component the organisation had placed into a category other than “security risk” — the safety interlock, the network management plane, the token-signing infrastructure, the AI platform foundation, the outsourced service provider’s helpdesk archive. The pattern this week is not about organisations failing to defend the attack surface they knew about. It is about the attack surface expanding into the management layer — the infrastructure that manages infrastructure.

1) Iranian State Actors Modify PLC Safety Logic in Water, Energy, and Government Facilities — CISA Updates AA26-097A to Include Siemens and Schneider Electric

On July 22, 2026, CISA, the FBI, the NSA, the EPA, the Department of Energy, and US Cyber Command updated joint advisory AA26-097A to expand its scope to include two additional industrial control system vendors: Schneider Electric and Siemens, whose EcoStruxure Control Expert and TIA Portal engineering software are now explicitly named alongside Rockwell Automation’s Studio 5000 as platforms through which Iranian state-affiliated actors have obtained access to and modified programmable logic controller configurations in water treatment, wastewater management, energy generation, and government facilities across the United States. The technique documented in the updated advisory is operationally precise in a way that separates it from most ICS threat reporting: the actors use the same legitimate engineering software that plant personnel use for routine PLC programming and maintenance to connect directly to internet-exposed controllers, download the PLC project files, modify the Add-On Instructions and equivalent logic blocks that encode the process’s safety constraints — shutdown triggers, alarm thresholds, interlock conditions — and upload the modified project back to the controller. The plant’s human-machine interface continues to display normal readings. The safety interlock that was meant to trigger a controlled shutdown under overpressure or overtemperature conditions no longer does so — or now triggers at a threshold set by the attacker rather than the process engineer.

The strategic quality of this technique is that it operates entirely within the legitimate software environment and leaves no artefact that conventional IT security monitoring is designed to detect. There is no malware binary, no anomalous network protocol, no credential that deviates from what a plant engineer would generate. The access path is the internet exposure of the PLC’s programming interface — a condition that exists in some facilities because engineering software requires remote access for maintenance, and in others because a device was connected to a network that was connected to the internet without a deliberate boundary control being implemented at the OT layer. CISA’s advisory specifies the access vectors: default or weak credentials on the engineering software access path, unsecured remote desktop or VNC connections used to reach the engineering workstation, and direct internet exposure of the PLC’s programming port on TCP/44818 (Rockwell Automation EtherNet/IP), TCP/102 (Siemens S7 protocol), and Modbus TCP (Schneider Electric). The extension to Siemens and Schneider Electric is operationally significant beyond the US context: Siemens S7 controllers and Schneider EcoStruxure installations are the dominant OT platform in DACH-region manufacturing, utilities, water management, and process industries. What the advisory’s original scope described as a threat to US water treatment facilities is, in its extended scope, a threat model directly relevant to the PLC estate that forms the operational backbone of European critical infrastructure.

The remediation posture for OT environments facing this class of threat differs structurally from the patch-and-monitor cycle that governs enterprise IT vulnerability management, because this technique exploits a programming interface that is functioning as designed. Patches address code vulnerabilities; they do not address legitimate engineering software reaching a legitimately internet-exposed PLC. The mitigations CISA specifies address the access path: remove internet exposure of PLC programming ports, require multi-factor authentication for engineering software access, implement change management controls for PLC project uploads so that unexpected modifications generate alerts before they affect process behaviour, and deploy OT-specific network monitoring that can detect when a project file is downloaded or uploaded outside of scheduled maintenance windows. For any DACH-region organisation with Siemens, Schneider Electric, or Rockwell Automation PLCs accessible through internet-connected engineering workstations — including utilities, water and wastewater operators, chemical manufacturers, and energy producers — the updated advisory’s content is the most directly operationally actionable threat intelligence published this week.

Read more on: CISA Advisory AA26-097A · SecurityWeek

2) Check Point SmartConsole CVE-2026-16232: Unauthenticated Token Forgery Gives Full Admin Access to Firewall Management — CISA Deadline July 25

On July 22, 2026, Check Point released a hotfix for CVE-2026-16232 (CVSS 9.1), an improper authentication vulnerability in Check Point SmartConsole — the management application used to configure, monitor, and maintain Check Point firewall security policies, VPN gateway configurations, intrusion prevention rules, and access control across all managed gateways in a Check Point deployment. The vulnerability allows an unauthenticated attacker who can reach the Check Point Management Server’s administration port to obtain an application login token without possessing valid credentials, then use that token to authenticate to SmartConsole with full administrative privileges. An attacker with SmartConsole administrative access can read and modify all firewall security policies, add or remove access rules, alter VPN gateway configurations, install policy updates to every managed gateway simultaneously, and export the full configuration of the managed security infrastructure — including the encryption keys and certificate authorities used for VPN authentication. CISA added CVE-2026-16232 to its Known Exploited Vulnerabilities catalog on July 22, 2026, with a federal remediation deadline of July 25. Rapid7 and BleepingComputer both confirm active exploitation in the wild prior to the patch release. Affected versions include R81.10, R81.20, R82, and R82.10.

The architectural implication of CVE-2026-16232 is not primarily about the specific exploitation path — an unauthenticated token-forgery against a management port. It is about what SmartConsole controls. In a Check Point deployment, the management server is the administrative plane for security policy across every managed gateway: the perimeter firewalls, the branch-office gateways, the remote-access VPN endpoints. An organisation managing its entire perimeter security posture from a single Check Point Management Server has, in effect, concentrated the ability to define what is blocked and what is permitted into a single point of administrative control. Compromise of SmartConsole means an attacker can read the existing security policy and understand precisely what traffic patterns are being blocked, modify those policies to permit their own traffic flows, and install the modified policy to every managed gateway — silently, from the internet, without any credential that the organisation’s identity and access management infrastructure would record. The pattern is structurally consistent with what CISA documented in advisory AA26-097A, published the same day: the management layer — the software used to configure what the security control does — is itself the attack surface.

This is not the first Check Point CVE to carry active exploitation in 2026. CVE-2026-50751, a VPN authentication bypass in Check Point’s remote access VPN component, was documented in June with confirmed exploitation in the wild. Two actively exploited vulnerabilities in the security management and remote access components of the same vendor’s stack within two months represents a pattern of sustained attacker investment in the Check Point management plane as a target class. For any organisation with a Check Point Management Server accessible from an internet-facing host — including managed security service providers managing multiple customer environments through a shared SmartConsole deployment — the July 25 CISA deadline is operative regardless of whether those environments are federal. The compensating control Check Point published alongside the hotfix — restricting SmartConsole connections to explicitly specified trusted client IP addresses — provides the mitigation for environments in which the hotfix cannot be applied within the deadline window.

Read more on: BleepingComputer · The Hacker News · Rapid7

3) SharePoint CVE-2026-50522: Machine-Key Theft Means Patching Alone Is Not Enough — Forged Tokens Survive the Fix

CVE-2026-50522 (CVSS 9.8), a deserialization-of-untrusted-data vulnerability in Microsoft SharePoint Server, was patched in the July 14, 2026 Patch Tuesday cycle alongside 621 other CVEs. It remained quiet until a public proof-of-concept exploit surfaced on July 20. Within hours of that release, watchTowr’s global honeypot network recorded active exploitation attempts in the wild. CISA added CVE-2026-50522 to the Known Exploited Vulnerabilities catalog on July 22 with a federal remediation deadline of July 25. The affected versions are SharePoint Enterprise Server 2016, SharePoint Server 2019, and SharePoint Server Subscription Edition. The mechanism: an unauthenticated attacker sends a single crafted HTTP request to the SharePoint server’s web front end, triggering a deserialization gadget that causes the server to expose its ASP.NET machine keys — specifically the ValidationKey and DecryptionKey used to sign and encrypt authentication tokens, ViewState values, and session cookies. Once an attacker holds these keys, they can forge authentication tokens that the SharePoint server treats as legitimate without any further interaction, impersonating any user account including the SYSTEM account, and accessing any document, site, or content store that account can reach.

The finding that is operationally distinct about CVE-2026-50522 is not the machine-key theft mechanism itself, which has been documented as an attack technique since at least 2020. It is the relationship between the stolen keys and the patch. Microsoft’s Patch Tuesday update for CVE-2026-50522 closes the deserialization vulnerability — it removes the unauthenticated path through which an attacker can force the server to return its machine keys. It does not change the machine keys themselves. If an attacker extracted the keys before the patch was applied — in the six days between the public PoC release on July 20 and the CISA KEV deadline on July 25, or at any point while the server was internet-exposed and unpatched — those keys remain cryptographically valid on a fully patched server. Tokens forged from stolen machine keys are indistinguishable from legitimate tokens, not because of any remaining code vulnerability, but because the server’s signing and validation logic is performing exactly as designed using the correct keys. The required remediation is therefore patch plus machine-key rotation — the explicit rotation of the ASP.NET ValidationKey and DecryptionKey across all SharePoint web application configurations, documented in Microsoft’s guidance and not performed automatically by the patch. For any internet-exposed SharePoint server that has applied the patch but has not yet rotated its machine keys, the question is not whether the vulnerability has been closed. The question is whether the keys were stolen before the closing.

This is the third SharePoint Server RCE with confirmed active exploitation in the space of three weeks, following CVE-2026-56164 — exploited as a zero-day before the July 14 Patch Tuesday shipped, with machine-key theft documented as part of the observed attack chain — and CVE-2026-58644, CVSS 9.8, CISA KEV July 16, deadline July 19. The sustained pattern of high-severity SharePoint exploitation indicates that the on-premises SharePoint attack surface is receiving concentrated attacker investment, and that the DACH-region manufacturing, financial services, and public-sector organisations that continue to operate on-premises SharePoint Server farms — some running 2016 installations that have been customised for eight years — are the primary exposed population. For those environments, the appropriate response to a third critical RCE in three weeks is not to treat each incident as a discrete patching event. It is to review whether the on-premises SharePoint deployment architecture — network exposure, authentication configuration, machine-key management practices — reflects the threat model that the current pattern of active exploitation has established.

Read more on: The Hacker News · BleepingComputer · Help Net Security

4) ServiceNow CVE-2026-6875: Pre-Authentication Sandbox Escape in the Platform Running 85% of Fortune 500 Workflows — Vendor Said “No Exploitation” While Attackers Were Already In

CVE-2026-6875, scored at CVSS 9.5 under the SSVC v4.0 framework, is a pre-authentication sandbox escape in ServiceNow’s GlideRecord query engine — the JavaScript evaluation layer that processes database queries across ServiceNow’s Now Platform, the enterprise IT service management and workflow automation system used by 85% of Fortune 500 companies and processing more than one hundred billion workflow operations per year. The vulnerable endpoint, /assessment_thanks.do, accepts attacker-supplied JavaScript as a query parameter and evaluates it in a context that is intended to be sandboxed, restricted to read-only database operations without access to system-level functions. The sandbox restriction fails under conditions demonstrated by the public proof-of-concept published by Assetnote: the GlideRecord query evaluation context can be escaped via a gadget chain that reaches server-side script includes, which execute with the privileges of the Now Platform’s application server, giving an unauthenticated attacker remote code execution on the ServiceNow instance. ServiceNow patched cloud-hosted instances on July 13, 2026; self-hosted customer deployments received remediation packages the same day. Active exploitation was confirmed by Defused on July 18 — five days after patching, three days before ServiceNow’s own advisory acknowledged any exploitation risk.

The detail that defines the strategic content of this story is not the CVSS score or the exploitation mechanism. It is the sequence of events between July 13 and July 20, and specifically the divergence between what ServiceNow’s own advisory communicated and what external security researchers confirmed was happening. ServiceNow’s advisory, last updated July 20, described the exploitation risk as theoretical and stated the company was “not currently aware of any exploitation” of CVE-2026-6875. Defused, the threat intelligence firm that confirmed active exploitation on July 18, published technical evidence of in-the-wild attacks two days before ServiceNow’s advisory acknowledged that exploitation was a live risk. A second finding compounded the gap: researchers subsequently identified a second bypass gadget for the sandbox restrictions that circumvents the defensive tuning organisations had applied based on the published proof-of-concept — meaning the mitigation intelligence available from the PoC had already been partially superseded by a different attack path before the vendor advisory caught up with the first. For any organisation that made remediation prioritisation decisions for CVE-2026-6875 based on the vendor’s characterisation of exploitation risk — specifically, any organisation that weighted “vendor not currently aware of exploitation” as evidence of low urgency — the gap between advisory and reality is precisely the risk window that materialised.

ServiceNow’s position in the enterprise technology stack makes the vendor-disclosure gap operationally significant beyond this specific CVE. ServiceNow is not a perimeter device or an endpoint agent: it is the system that manages IT service requests, change approvals, incident tickets, vendor relationships, and in many deployments the approval workflows for security exceptions and access requests. A pre-authentication compromise of the Now Platform does not give an attacker access to one system. It gives them access to the workflow infrastructure that governs access to every system — the change management process that controls what gets deployed, the incident management platform that tracks what security tools have flagged, the service request system that manages user access privileges. For DACH-region organisations that depend on ServiceNow for ITSM and GRC workflow management, the exploitation window that opened five days after patching — the period during which cloud-hosted instances were patched but self-hosted deployments may not have applied the remediation package — is the window that needs to be assessed against the organisation’s own deployment timeline, patching completion records, and incident telemetry from that period.

Read more on: BleepingComputer · Help Net Security

5) Ernst & Young Third-Party Data Breach: 15 Days Inside a Support-Ticket Archive, Undetected — SSNs, Tax Returns, and Financial Account Data Exposed

Ernst & Young disclosed in mid-July 2026 that it had notified affected individuals of a data breach resulting from unauthorised access to a third-party IT service management platform used by EY’s own IT support staff to manage client-facing requests in the tax and financial planning practice. The access window ran from March 28 to April 12, 2026 — fifteen days of confirmed unauthorised access. EY detected the breach on April 23, eleven days after the access window closed. The data exposed includes the categories of personal and financial information that clients submit through professional services engagements: Social Security numbers, tax identification numbers, tax return filings, financial account codes, credit and debit card information, and government-issued identification documents. Breach notifications were filed with the attorneys general of California, Texas, Massachusetts, and Vermont, with the number of confirmed affected individuals at the time of filing representing a floor figure for the actual affected population. The four-state filing pattern — California, Texas, Massachusetts, and Vermont are each among the states with the broadest data breach notification requirements — is consistent with a broader affected population than the individual state notifications individually reflect.

The structural detail that defines the exposure in this incident is the nature of the platform that was compromised. The third-party ITSM system used by EY’s IT staff for client support is not, in the architecture of a professional services firm, typically modelled as a sensitive data repository. It is modelled as a helpdesk ticketing system: a tool for tracking support requests, routing IT assistance, and managing client communications. The sensitivity of a helpdesk platform is a function of what clients send through it — and clients of a tax and financial planning practice send, in response to support requests and document collection workflows, exactly the categories of data that now appear in the breach notification: identity documents, financial records, completed tax forms, account numbers. That data accumulates as ticket attachments and conversation history, persists in the system under the data retention policies of the third-party platform rather than EY’s own sensitive data governance programme, and is accessible through the third-party platform’s access control model, which is what the unauthorised access exploited for fifteen days. The support-ticket archive is the shadow data repository that no one is thinking about when designing the sensitive data governance programme — until it is the repository that is breached.

This is EY’s third vendor-side data exposure incident in under three years: the 2023 MOVEit exploitation campaign, in which EY client data was exfiltrated alongside data from hundreds of other firms using the same file transfer platform, a 2025 incident involving unauthorised access to an Azure-hosted environment used for client services delivery, and this 2026 breach of a third-party ITSM platform. The pattern across all three incidents is structurally identical: the point of exposure is not EY’s own primary infrastructure. It is a third-party or cloud platform used by EY in the course of service delivery, in which EY client data has accumulated as an operational artefact of normal service activity. For any organisation that works with large professional services firms — tax advisors, audit partners, legal counsel, financial consultants — and that has submitted sensitive documents, financial records, or personal data through any client portal, support channel, or document collection workflow, the EY timeline is a demonstration of the exposure model. The data is in the third party’s environment, governed by the third party’s controls and their vendors’ controls, and the organisation has no direct visibility into whether those controls were effective until the breach notification arrives weeks after the access window has closed.

Read more on: BleepingComputer · SecurityWeek

If this week’s Cybersecurity News Stories July 24, 2026 tells us anything, it’s this:

The five stories in this week’s Cybersecurity News Stories July 24, 2026 are each a version of the same finding expressed at a different layer of the technology stack. Iranian state actors did not attack the perimeter of a water treatment facility — they attacked the safety logic that defines what the industrial process is permitted to do inside the perimeter, using software that has legitimate access to modify it. Check Point’s exploited vulnerability did not target the firewall’s packet inspection engine — it targeted the management console used to configure what the engine is told to block, accessed without credentials, from the internet. SharePoint’s machine-key theft does not survive patching because it exploits a code flaw that remains after the patch — it survives patching because the stolen keys are cryptographically valid regardless of the code that was changed, and patching does not rotate them. ServiceNow’s exploitation was confirmed in the wild before the vendor acknowledged it was happening, and a second bypass gadget was already in circulation before organisations had finished tuning their defences to the first one. And EY’s client data was held in a third-party helpdesk system that no one had modelled as a sensitive data repository — which it became the moment clients submitted tax returns through a support ticket.

The operational implication is not only “patch by July 25,” though that is urgent for CVE-2026-16232 and CVE-2026-50522, and machine-key rotation for every internet-exposed SharePoint server is a mandatory second step that the patch does not perform. The deeper implication is about the inventory assumption. Every organisation running a security programme has a model of its attack surface. That model almost certainly includes the perimeter, the endpoints, the identity layer, the applications, and the cloud workloads. What this week’s five stories collectively demonstrate is that the actual attack surface has reached the layer behind that model — the OT safety logic that sits inside the perimeter’s inner boundary, the management consoles that define the perimeter’s own behaviour, the cryptographic infrastructure that the identity layer trusts, the workflow foundations that the applications run on, and the third-party service environments where client data accumulates as an unintended artefact of service delivery. None of these are novel attack surfaces in the abstract. All of them were targeted this week. The security programme that defends what it knows about, while the actual attack surface continues to include what it has not yet modelled, is not failing at execution. It is operating on a map that is no longer accurate.

For more information, please contact us now!