Threat Pulse – August 2026

Each month, DigitalXRAID’s Security Operations Centre (SOC) analysts share the top threats affecting businesses globally. Take action to protect your organisation against these prolific threats.

If you’ve been affected by any of these threats, we’re here to help. You can call our Cyber Emergency line any time of the day or night for help with active cyberattacks.

DigitalXRAID’s SOC analysts constantly monitor for zero-day threats and update our signature databases using the most comprehensive Threat Intelligence and Open Threat Exchange databases available worldwide.

Cyber Incidents in August

Manchester Airports Group – Breach of Ancillary Customer Systems Affecting 8.7 Million People

What happened:

On 27 August 2026 Manchester Airports Group confirmed that an unauthorised third party had accessed customer data belonging to approximately 8.7 million people. MAG is a public-private partnership, majority owned by ten Greater Manchester local authorities with Australian fund IFM Investors holding a minority stake, and operates Manchester Airport, London Stansted and East Midlands Airport. The systems involved supported car parking, airport lounge and Fast Track bookings, together with in-terminal Wi-Fi registrations. MAG said it believed the attacker first reached customer data a few days before the intrusion was discovered. Reporting by the BBC states that a ransom was demanded and that MAG refused to pay it.

Who was behind it:

No group has publicly claimed the intrusion and MAG has not attributed it. The absence of a leak-site listing at the time of writing is consistent either with a negotiation that has not yet failed publicly or with an actor that has chosen not to publicise the theft.

How the attack worked:

MAG has not disclosed how access was obtained, nor what the attacker did while inside beyond accessing customer data. What is public is the target selection, and it is the most instructive part of the incident. Nothing airside, flight-critical or aviation-security related was affected. The compromise sat entirely in the commercial periphery: parking reservations, lounge and Fast Track bookings, and the free Wi-Fi sign-up that asks a passenger for little more than a name and an email address in exchange for network access. These systems are usually procured by commercial teams rather than IT, are frequently supplier-operated, and accumulate records at a rate far beyond anything the operational estate produces. They also tend to sit outside the segmentation and monitoring applied to operational technology, because nobody classifies a car park booking engine as critical.

Scale of the damage:

Around 8.7 million customer records were accessed. The exposed fields include email addresses, telephone numbers, vehicle registration numbers and postcodes. MAG stated that the vast majority of those affected had only an email address exposed, which is consistent with the bulk of the population coming from Wi-Fi registrations. Neither MAG nor the affected system held bank or payment card details. The three airports handled more than 65 million passengers in the previous year, although only a subset would have used the affected services. MAG temporarily suspended its online Manage My Booking service as a precaution.

Real world impact:

The absence of cancelled flights does not make this a minor incident. The combination of data taken is unusually well suited to convincing fraud: an attacker knows the individual has a relationship with a named airport, and holds a phone number, a postcode and, in many cases, a vehicle registration. That is enough to construct a credible unpaid parking charge notice, a booking amendment request or a refund lure, and to quote details back to the victim as proof of legitimacy. Vehicle registration is a particularly durable identifier, and its pairing with a postcode has value well beyond travel-themed phishing. The timing, immediately before one of the busiest travel periods of the UK year, increases the probability that a fraudulent message will arrive when the recipient is genuinely expecting airport correspondence.

The incident also continues a pattern the aviation sector should now treat as settled. Airports keep being reached not through flight-critical systems but through the ancillary software that sells parking, checks in lounge guests and hands out Wi-Fi. The September 2025 attack on Collins Aerospace’s MUSE check-in platform, which disrupted Heathrow, Brussels and Berlin Brandenburg, made the same point from the supplier side.

Response and recovery:

MAG restricted access to the affected systems to contain the breach, engaged external cyber security specialists and notified the relevant authorities, including the Information Commissioner’s Office. Flights, airport operations and parking services continued normally, and MAG stated that passenger safety and aviation security were unaffected. Upcoming reservations remained valid; customers needing to change a booking within 72 hours were directed to a telephone line while Manage My Booking was offline. MAG has not published a technical account of the intrusion.

Remediation guidance:

• Inventory the commercial and marketing systems that hold customer data at population scale, including Wi-Fi captive portals, booking engines, loyalty schemes and lounge and parking platforms, and confirm which are supplier-operated. In most organisations the largest personal-data holdings sit outside the systems the security function actively monitors.
• Apply a retention limit to captive-portal and ancillary booking records and enforce it technically. A free Wi-Fi sign-up has no business reason to remain queryable years later, and the size of this breach is a function of retention as much as of the intrusion itself.
• Segment ancillary customer platforms from corporate and operational networks so that a compromise of a booking or Wi-Fi system cannot be used to reach either. Verify the segmentation by testing it rather than by reading the network diagram.
• Pre-write the customer communications for this scenario now, including the specific fraud patterns the exposed fields enable. Organisations that publish concrete warnings about parking-charge and booking-amendment lures materially reduce the second-stage loss.
• Brief fraud, contact-centre and finance teams that inbound callers may hold accurate booking, vehicle and address details, and remove those data points from the set used to verify a caller’s identity.
• Assess whether the volume of data collected at the point of Wi-Fi registration is justified. Reducing collection is the only control that removes the risk rather than managing it.

 

CEVA Logistics – Contract Logistics Compromise Rippling Across European Retail and Banking

What happened:

Attackers were inside CEVA Logistics between 29 July and 1 August 2026. CEVA is the contract logistics arm of the CMA CGM Group, the world’s third-largest shipping company; it operates more than 1,000 warehouses, handled 15 million shipments last year and reported 18.3 billion US dollars in revenue in 2025. On 1 August CEVA notified affected corporate customers that a cyber intrusion was affecting part of its European contract logistics operations and that goods held in the disrupted warehouses were not shipping. Over the following four weeks a widening list of CEVA’s clients disclosed that their own customers’ data had been exposed, including Valve, Dutch retailers Bol and De Bijenkorf, ING, eyewear company Ace & Tate and Amsterdam football club Ajax.

Who was behind it:

No threat actor has been named and no group had claimed the intrusion at the time of writing. CEVA has not publicly disclosed the attack itself and did not respond to media enquiries; everything in the public record comes from its clients or from trade reporting.

How the attack worked:

CEVA has not disclosed the initial access vector or the actions taken inside its environment. The structural mechanism of the data exposure is clear from the client disclosures. CEVA requires shipping and delivery information from its clients in order to fulfil orders, and retains that information for up to 90 days after an order completes. A compromise of the contract logistics environment therefore exposed the personal data of its clients’ customers rather than CEVA’s own, and each client had to determine independently which of its customers fell inside the retention window.

Scale of the damage:

CEVA stated that the operational impact was limited to eight European warehouses, that no other CEVA systems globally were affected and that all other operations continued without incident. Trade reporting confirmed that its air, ocean, ground and rail transportation management operations were undisrupted. On the data side, exposed fields across the affected clients include names, postal addresses, email addresses, telephone numbers, order details and shipment tracking information. Valve confirmed that payment card details, account passwords and Steam Guard two-factor codes were not exposed because CEVA never held them; De Bijenkorf confirmed that no financial data was involved. Bol warned customers to expect delays and some order cancellations. The total number of individuals affected has not been published by CEVA or by any client.

Real world impact:

This is a fourth-party exposure event, and it behaved like one. Consumers received breach notifications from Valve, Bol or Ajax about an incident at a company they had never transacted with and had probably never heard of. The notification burden, the regulatory exposure and the reputational damage all landed on the clients, while the organisation that was actually breached said almost nothing publicly. Clients were left describing an incident they had not investigated, on the basis of information a supplier chose to share, which is a position no data controller should be comfortable occupying.

The second-order effect is operational rather than informational. Retailers whose inventory sat in the affected warehouses simply could not ship, and CEVA’s clients absorbed the delay, the cancellations and the customer service load. For any organisation that has outsourced fulfilment, warehousing or last-mile delivery, this is the more likely failure mode: not the theft of data, but the sudden inability to move goods, with recovery timelines set by a third party.

Response and recovery:

CEVA said its cyber security teams activated security protocols as soon as the incident was identified and launched an investigation that remained ongoing. It notified affected corporate customers on 1 August. Valve learned on 7 August that Steam customer data was likely compromised, began notifying affected customers on 10 August, notified data protection authorities in the affected countries, and stated that it was pressing CEVA for further detail on what was taken and how the breach occurred. De Bijenkorf, Bol, Ace & Tate and Ajax issued their own notifications. Warehouse operations were restored progressively.

Remediation guidance:

• Map fourth-party data flows, not just direct suppliers. Identify every party that holds your customers’ personal data because a supplier passed it on, and record what each holds and for how long. Most organisations discover this list only during an incident.
• Put a defined notification clock into logistics, fulfilment and outsourcing contracts, with a right to the supplier’s forensic findings and a right to communicate independently with affected individuals. A supplier’s decision not to disclose publicly should not be able to delay your own regulatory obligations.
• Minimise what fulfilment partners receive and reduce their retention period. A 90-day retention of full delivery data across a client base of this size is a design decision, and it set the size of this breach.
• Build and rehearse a manual fulfilment contingency for the loss of a warehousing or logistics provider, including how customers are informed and how order cancellations and refunds are handled at volume.
• Prepare customer messaging for fourth-party incidents in advance. Recipients will not understand why a company they have never dealt with holds their address, and unexplained notifications drive both complaint volume and susceptibility to follow-on phishing.
• Warn affected customers that fraudulent messages will reference genuine order details, including their own address, and tell them what your organisation will and will not ask for in delivery communications.

 

McKesson – Vishing to Okta Single Sign-On to Salesforce and Snowflake

What happened:

McKesson, one of the largest healthcare and pharmaceutical distributors in the United States, detected a cyber security incident on 25 August 2026 and disclosed it on 28 August in a Form 8-K filing with the Securities and Exchange Commission, describing unauthorised access to third-party applications and the exfiltration of data. Hours after the disclosure the ShinyHunters extortion group listed McKesson on its leak site and claimed to hold 284 million patient data records.

Who was behind it:

ShinyHunters, a prolific data-theft and extortion group that has run a consistent 2026 campaign against large enterprises. McKesson has not named the group. ShinyHunters provided data samples to CyberInsider, which reported that they appeared consistent with the categories described in the claim; none of the group’s claims have been independently verified.

How the attack worked:

According to ShinyHunters, the intrusion began with voice phishing that compromised the Okta single sign-on accounts of multiple employees. Those accounts were then used to reach McKesson’s Salesforce and Snowflake environments. The group claims it fully compromised the Salesforce tenant, including support cases, and separately extracted a much larger volume of patient-related records from Snowflake, exfiltrating roughly one terabyte over four days between 21 and 25 August. It says it contacted McKesson after completing the exfiltration and demanded 55,236,150 US dollars with a 72-hour deadline, and that McKesson did not respond. McKesson has confirmed unauthorised access to third-party applications and data exfiltration but has not disclosed which applications were involved or how access was obtained.

Scale of the damage:

The 284 million figure is a raw count of database rows, not unique individuals, and ShinyHunters has been explicit about that distinction; a single patient generates many rows across appointments, prescriptions and claims. The group says the records relate to tens of millions of patients but that it has not finished analysing the data. McKesson’s early findings indicate the incident involves data relating to a subset of customers of its Oncology and Multispecialty and its Medical-Surgical business units. The categories claimed include names, addresses, dates of birth, Social Security numbers, patient identifiers, Medicaid details, medical record numbers, medication and allergy information, physician information, doctor-patient messages, internal Salesforce records and employee data. No census has been published by McKesson or by the Department of Health and Human Services.

Real world impact:

Nothing was encrypted and no operations stopped, which is precisely why this class of incident is underweighted. The harm sits in the data. Social Security numbers and Medicaid identifiers alongside diagnosis and medication information is a materially different exposure from a contact-details leak: it supports medical identity theft, insurance fraud and direct extortion of individual patients, and it does not decay. Expect fraudulent prior-authorisation and prescription-refill approaches that quote a real medication and a real prescriber.

The control that failed was identity, not a software vulnerability. Multi-factor authentication was in use in the sense that codes were requested, and the codes were phished. Once inside the identity provider, the attacker reached two cloud data platforms that most customers never see and that frequently hold larger, less well-governed datasets than the applications of record. This is the same pattern seen across the sector during August, including Baylor Genetics with approximately 2.8 million individuals affected, CareCloud with more than 3.75 million, and Unlimited Technology Systems with roughly 3.8 million.

Response and recovery:

McKesson activated its incident response protocols, engaged external cyber security experts and stated that its initial actions to prevent further unauthorised access appear to have been successful, with no further unauthorised activity detected. The investigation remains in its early stages and the company has not determined whether the incident is material. Separately, and usefully for defenders, ReliaQuest confirmed that ShinyHunters had targeted its own employees using impersonation and a fake single sign-on page, and that the attempt was contained before any application access or customer data theft occurred, which demonstrates that this playbook is detectable and stoppable.

Remediation guidance:

• Move to phishing-resistant authentication for all staff who can reach cloud data platforms or administrative consoles. FIDO2 security keys or platform passkeys remove the credential and code that this attack chain depends on; app-based codes and push approvals do not.
• Impose a verification standard on the IT service desk that cannot be satisfied over the phone, and publish it to staff so that a caller demanding an urgent security migration is recognised as an anomaly rather than an instruction.
• Apply network policies and trusted-location restrictions to Snowflake, Salesforce and equivalent platforms so that valid credentials alone are insufficient from an unfamiliar network, and require re-authentication for bulk export operations.
• Alert on data-volume egress from cloud data platforms rather than only on authentication anomalies. A terabyte leaving over four days is a detectable pattern in query history and warehouse metering even when every session is authenticated.
• Review what production data has accumulated in analytics environments and remove or tokenise identifiers that the analytical use case does not require. Snowflake held more than the applications of record in this case, which is common and rarely intentional.
• Scope third-party application access with the assumption that it will be reached through a compromised employee identity, and separate integration and service accounts from interactive user accounts so that a phished session does not inherit integration privilege.

 

UNC6671 and the Redact, Pink, Helix and Falcon Brands – Voice Phishing Campaign Against Financial Services

What happened:

On 6 August 2026 Google Threat Intelligence Group and Mandiant published research on UNC6671, a financially motivated extortion operation that compromises enterprises through voice phishing while posing as IT helpdesk staff. Google assessed that despite the announced retirement of the BlackFile extortion brand in May 2026, the group had not disbanded but had diversified across four extortion fronts with shared infrastructure: Redact, Pink, Helix and Falcon. By July its targeting had shifted towards financial services, private equity, law firms and professional services. Reuters, drawing on Google data and internet intelligence, reported credential-harvesting sites built to target employees at Apollo Global Management, Blackstone, Bridgewater Associates, Bain Capital, KKR, TPG, CME Group, Clearlake Capital and Moody’s. On 6 August the Financial Times reported that Point72, Citadel and Millennium Management had been targeted by a wave of voice phishing. On 21 August Apollo confirmed a breach.

Who was behind it:

UNC6671, assessed by Google as financially motivated and affiliated with the loose criminal community known as The Com. Google’s principal threat analyst Austin Larsen characterised the campaign plainly, telling Reuters that it was about money and that sophisticated was not the right word for it. The named target list came from Reuters rather than from Google’s own publication.

How the attack worked:

The method is a telephone call to an employee’s personal mobile, in which the caller impersonates a colleague or IT helpdesk staff member facilitating a mandatory and urgent security migration. The employee is directed to a lookalike sign-in portal that captures the password and the multi-factor authentication code in real time, giving the attacker an authenticated session. Access is then used to locate and exfiltrate data, after which the victim is extorted with the threat of publication on one of the group’s leak sites. Apollo’s head of human capital, Matthew Breitfelder, confirmed that the breach resulted from social engineering rather than the exploitation of a software vulnerability.

Scale of the damage:

Dozens of financial institutions were targeted over a period of weeks. In Apollo’s case the attackers accessed its cloud environment between 6 and 10 July 2026, and on 12 August Apollo determined that names, dates of birth, contact information, home addresses and Social Security numbers had been compromised. Google reported that some of the attacks netted ransoms of up to 750,000 US dollars and that some companies paid, without naming them. Point72 said it did not believe any client information was stolen and Citadel did not appear to have been breached. The full victim count is unknown, because extortion that succeeds quietly produces no disclosure.

Real world impact:

The sector with the largest security budgets in the economy was breached by telephone calls. That is the finding worth carrying into a board discussion, because it decouples defensive spend from defensive outcome in a way that technical controls cannot easily fix. Private equity and asset management are attractive targets for reasons that go beyond personal data: these firms hold confidential merger and acquisition material, debt financing terms and portfolio company operating detail, and a single compromise reaches across many underlying businesses at once. The four-brand structure also matters for anyone tracking exposure. A group can retire a brand, keep its infrastructure and personnel, and reappear under several names simultaneously, which defeats any monitoring approach keyed to leak-site names rather than to tradecraft.

Response and recovery:

Apollo notified law enforcement, engaged external cyber security and forensic experts, contained the unauthorised access, enhanced its security protocols and implemented secondary identity verification across its cloud environments. Google published indicators and infrastructure analysis with its research. The pattern is consistent enough that it can be defended against specifically, as ReliaQuest demonstrated in the same month when it detected and contained an equivalent attempt against its own staff.

Remediation guidance:

• Deploy phishing-resistant multi-factor authentication. Every element of this campaign depends on the attacker being able to relay a credential and a one-time code; hardware-bound authenticators break the chain outright.
• Establish and publicise a rule that IT will never telephone staff to request credentials or authentication codes, and give employees a single verified channel for confirming that a caller is genuine. Personal mobile numbers should be treated as an untrusted contact path.
• Monitor for newly registered domains and certificates that resemble your single sign-on and helpdesk portals, and pre-emptively block them. These campaigns rely on lookalike infrastructure that is visible before it is used.
• Alert on impossible-travel, new-device and unusual-client authentication events against the identity provider, and treat a successful authentication from unfamiliar infrastructure as an incident rather than an anomaly to be reviewed later.
• Rehearse the executive decision about extortion payment in advance, with legal, communications and insurance participation. Google’s finding that some firms paid indicates that this decision is being taken under pressure without preparation.
• Extend the same controls and awareness to portfolio companies, funds administration providers and outsourced back-office functions, which hold the same data with materially less security capability.

 

United States Water and Wastewater Sector – Mass Targeting of Internet-Facing Programmable Logic Controllers

What happened:

On 30 July 2026 the Federal Bureau of Investigation and the Environmental Protection Agency issued a public service announcement warning that malicious cyber actors were attacking operational technology at water and wastewater utilities, specifically Rockwell Automation and Allen-Bradley programmable logic controllers in the MicroLogix 1100 and 1400 series. Since 27 July, utilities in at least seven states had reported incidents to the FBI and some of that activity had degraded water operations. CISA issued its own advisories through August, and acting director Nick Andersen said the agency was observing a significant increase in threat actors targeting PLCs at water utilities. By late August reported activity had spread to around twelve states, and on 26 August CISA disclosed that more than 100 internet-exposed systems in the sector had been targeted during July. Separately, in mid-August CISA and international partners warned that threat actors were conducting reconnaissance and capability development against United States Siemens S7 series PLC installations using AI-generated exploitation scripts disguised as legitimate monitoring tools.

Who was behind it:

Neither CISA nor the FBI has attributed the activity. The technical pattern matches advisories issued earlier in 2026 warning of Iranian-affiliated PLC targeting across water, energy and government facilities, and private-sector threat analysts have said Iran is almost certainly responsible. Officials speaking on background have pointed in the same direction without confirming it. Chinese pre-positioning activity of the Volt Typhoon type, Russian operations and criminal actors all remain capable of identical tradecraft, and the defensive response does not depend on which of them is correct.

How the attack worked:

No vulnerability was exploited. The actors reached programmable logic controllers that were connected directly to the public internet, in many cases still carrying default or weak credentials, and then changed the devices’ IP addresses and passwords. The effect is a loss of monitoring and control: the operator is locked out of equipment that continues to run. Many of the devices involved are old, internet-exposed and no longer supported by their manufacturers. The Siemens S7 advisory describes a different phase of the same problem, in which AI-generated scripts packaged to look like legitimate monitoring tools are used for reconnaissance and capability development against exposed controllers across water, energy, wastewater, chemical and commercial facilities.

Scale of the damage:

More than 30 community water systems in Minnesota were targeted in late July. At least seven states reported incidents initially, rising to around twelve, with more than 100 internet-exposed systems targeted. CISA said the activity resulted in boil-water notices and sustained manual operations, and that entities of all sizes were being targeted. In Clayton County, Georgia, customers experienced low or no water pressure. In Utah, an incident reportedly caused pumps to run dry while control panels continued to indicate that water was being pumped. No contamination has been reported, and the FBI stated that drinking water was not contaminated, although untreated groundwater entered some pipelines.

Real world impact:

The Utah case is the one to brief upward. The failure there was not availability but integrity: the operator’s instrumentation was lying to them, which is a categorically worse position than a visible outage because it defeats the human judgement that normally compensates for a system failure. The wider point is that this campaign required no technical sophistication and is therefore repeatable at scale by anyone. Exposure and default credentials are the whole attack. The AI-generated scripting against Siemens S7 devices lowers the remaining effort further and widens the target set well beyond water.

The regulatory response moved quickly. Regulations under the Cyber Incident Reporting for Critical Infrastructure Act are expected to be finalised in September 2026, and on 26 August the White House issued an executive order declaring a national emergency over risks associated with foreign-produced equipment in the United States bulk-power system, explicitly covering industrial control systems, programmable logic controllers, remote terminal units, intelligent electronic devices, distributed control systems and the associated software, firmware and remote-access capabilities, with powers for the Department of Energy to require high-risk equipment to be identified, isolated, monitored, secured, disconnected, replaced or removed.

Response and recovery:

The FBI, EPA and CISA recommended immediate action: remove programmable logic controllers and other operational technology from direct internet exposure, change default passwords, and route remote access through a virtual private network or gateway. CISA continued to find exposed water system controllers online weeks after the first warning, which is the most telling detail in the whole sequence. Affected utilities reverted to manual operation and, in several cases, issued precautionary boil-water notices. Senator Tom Cotton wrote to the Treasury Secretary urging investment in and modernisation of American operational technology.

Remediation guidance:

• Scan your own external estate for exposed operational technology rather than relying on network documentation. Use an internet-wide exposure service to look for your address ranges from the outside, and treat any PLC, HMI or historian that answers as an incident.
• Remove direct internet exposure from controllers and place remote access behind a gateway with strong authentication. This single change accounts for almost all of the risk in this campaign.
• Replace default and shared credentials on every controller and document the result. Where a device cannot support adequate authentication, compensate with network isolation rather than accepting the exposure.
• Build detection for configuration change rather than only for intrusion. Alarm on unexpected changes to controller IP addresses, credentials, programme downloads and mode changes, since these were the observable actions in every reported incident.
• Validate telemetry independently at critical points. The Utah case shows that a compromised control system can report normal operation while the physical process fails; independent instrumentation or manual verification is the only protection against that.
• Rehearse extended manual operation, including the staffing implications of running a site by hand for days rather than hours, and confirm that the manual procedures still match the current plant.
• Treat AI-generated tooling as a capability change, not a novelty. Assume that reconnaissance against your exposed OT is now continuous and automated, and prioritise reducing exposure over improving detection of it.

 

United Kingdom Power Generator – Four-Day Shutdown Attributed in Reporting to Iran-Linked Actors

What happened:

On 22 August 2026 the Telegraph reported that hackers linked to Iran had penetrated a small British electricity generator in July 2026 and caused it to shut down for four days. The story was subsequently carried by the BBC, the Guardian and the Financial Times, largely on the basis of the Telegraph’s account. A UK government spokesperson confirmed that the incident affected a small-scale energy generator and that at no point was there a risk to the wider energy system. Energy Minister Michael Shanks said there was no threat to the wider grid and that nobody lost power. On 24 August the government briefed energy industry leaders on measures to strengthen their defences. Separately, on 10 August Poland’s CERT disclosed an intrusion at a small combined heat and power plant in which attackers moved from a compromised wind-farm network into the plant through a misconfigured private access point name, reached the operational technology network and switched Siemens PLCs into STOP mode, shutting down the steam turbine and the water treatment system.

Who was behind it:

For the UK incident, press reporting and British intelligence assessments cited by the Telegraph point to hackers linked to the Iranian regime, likely associated with the Islamic Revolutionary Guard Corps. The UK government has not publicly attributed the attack, and there has been virtually no comment from the National Cyber Security Centre. The Polish incident was attributed to Electrum, a Russian-linked group. The two are separate events; their proximity in the same month is the point.

How the attack worked:

No technical detail has been published for the UK incident, including the initial access vector, the systems reached or why recovery took four days. The identity and location of the generator have not been disclosed. The Polish case, by contrast, is fully described and is instructive as a model: lateral movement from one energy asset’s network into another through a misconfigured private mobile access point name, then access to the operational technology network, then a legitimate PLC command issued for a destructive purpose. Nothing in that chain required an exploit.

Scale of the damage:

A single small generator was offline for four days. According to a government source the generator was small enough to sit below the legal threshold at which cyber activity must be notified to government. The United Kingdom has an estimated 200 or more dedicated gas peaking facilities, which typically sit idle for more than 90 per cent of the year and may run for only a few hours a week; the loss of any one of them is immaterial to supply. In Poland the steam turbine and water treatment system were stopped, staff restored the systems quickly, and the outage was short-lived with no effect on residents.

Real world impact:

This is believed to be the first disruptive Iranian cyberattack of its kind in the UK. The significance is not the megawatts lost but the demonstration. Attacks of this kind are highly repeatable, as Dragos field chief technology officer Phil Tonkin observed, and a four-day recovery at a small, simple site raises an uncomfortable question about what recovery would look like at a large one. Commentators also drew attention to the notification threshold: an incident of clear national interest was effectively invisible to regulators because the asset was too small to be in scope, which is precisely the gap that distributed generation creates.

The policy backdrop moved in the same direction during the month. The Department for Energy Security and Net Zero and Ofgem published their government response on whole energy cyber resilience requirements on 5 August, setting out an intention to develop baseline cyber resilience requirements for all Ofgem licensees and to review the applicability of the NIS Regulations to the sector, with a wider Energy Resilience Strategy due later in 2026. Read alongside the Cyber Security and Resilience Bill, the direction is unambiguous: scope is widening to include smaller operators and their suppliers, and reporting timelines are tightening.

Response and recovery:

The affected UK plant was restored after four days. The government briefed energy company executives on 24 August and is preparing a broader resilience strategy. No indicators of compromise, no technical report and no formal attribution have been published, which limits what other operators can do with the information. In Poland, plant staff restored the stopped systems quickly and CERT published an account of the intrusion path.

Remediation guidance:

• Assume you are in scope of the next iteration of energy cyber regulation regardless of current thresholds, and close the gap between what you would have to report and what you could actually detect within 24 hours.
• Audit connectivity between separately operated energy assets, including private mobile networks, access point names, shared engineering access and supplier remote-access paths. The Polish intrusion crossed from a wind farm to a heat and power plant through a configuration error of exactly this kind.
• Alarm on PLC mode changes and programme downloads. The destructive action in Poland was a legitimate STOP command, which no vulnerability-focused control would have prevented and which a behavioural alarm would have caught immediately.
• Test recovery time for the operational technology estate specifically, with the plant offline, and record how much of the four days would be diagnosis, how much would be rebuild and how much would be waiting for a supplier engineer.
• Confirm that small and remote sites are inside your monitoring and asset inventory. Facilities that run for a few hours a week attract the least attention and, in this campaign, proved the most reachable.
• Establish a direct route for reporting and receiving threat information even where an asset falls below a statutory notification threshold, so that a below-threshold incident still produces sector-wide learning.

 

Beacon CRM – An Exposed Cloud Access Key Exposes the Supporter Data of More Than 1,500 UK Charities

What happened:

Beacon, a UK customer relationship management platform used by charities and non-profit organisations to manage donors, supporters, volunteers and fundraising activity, disclosed in early August 2026 that attackers had downloaded its customer database backups. On 12 August the company’s chief technology officer, David Simpson, published an incident update confirming that the likely root cause was a compromised Amazon Web Services access key exposed in publicly accessible JavaScript build artefacts hosted on Beacon’s own website, and that the attacker had made a complete copy of the customer database, including attachment files, and exfiltrated it.

Who was behind it:

No threat actor has been identified and no group has claimed the intrusion. As at the latest updates there was no indication that the stolen data had been published online or otherwise misused, and Beacon detected no attempt by the attacker to establish persistence in its environment.

How the attack worked:

An access key was inadvertently baked into client-side build output, which meant that anyone inspecting the site’s web assets in a browser could harvest it. The attacker authenticated directly to Amazon Web Services with a valid credential, which bypassed perimeter controls entirely and rendered encryption at rest irrelevant, because data encrypted at rest is decrypted on legitimate retrieval. Beacon’s forensic investigation, conducted with external specialists, reconstructed the event from AWS Cost and Usage reports covering May to July 2026: the earliest malicious activity was recorded on 27 July 2026 at 01:20:16 UTC, the attacker operated for approximately one hour and 27 minutes, and a sharp spike in data transfer on 27 and 28 July matched the total volume of stored platform records and attachments, leading investigators to conclude that the entire database had been exported.

Scale of the damage:

Approximately 1,500 charity and non-profit customers were affected, which is Beacon’s entire customer base. The exposed data includes names, email addresses, telephone numbers, postal addresses, donation and membership records and attachment files. Payment card details, bank account information and patient data were not involved. Affected organisations identified in reporting include The Survivor’s Trust, the British Dental Association, GuildCare, Saints Foundation, Full Fact, The Shrewsbury and Telford Hospital Charity and Yorkshire’s Brain Tumour Charity. English National Ballet was among cultural organisations reported in the same period as affected by a cyber attack on customer relations software.

Real world impact:

One supplier’s development error created roughly 1,500 simultaneous data controller obligations. Every affected charity had to assess, notify and communicate on the basis of a forensic investigation it had no part in, and Beacon advised all of them to report the breach to the Information Commissioner’s Office. On 13 August The Survivor’s Trust said the ICO had reviewed its case and concluded that the charity bore no responsibility for the breach, which is a helpful precedent but not a general indemnity.

The sensitivity here is not in the field list. For a charity providing specialist rape and sexual abuse support, the fact of an individual’s presence on a supporter or service list is itself the sensitive information, and no amount of absent payment data changes that. Small charities also have the least capacity to absorb a supporter-facing incident, and the sector has become a concentrated target precisely because a handful of specialist platforms serve thousands of organisations. It is also worth noting how the breach was found: through cloud billing and usage data rather than security telemetry.

Response and recovery:

Beacon rotated the compromised credential, removed the exposed secrets, reset all credentials for services and accounts integrated with its AWS environment to prevent repeat access, deployed additional security tooling, notified the Information Commissioner’s Office and published an incident report with a timeline. It advised its charity customers to report the breach to the ICO. Affected charities issued their own notifications and urged supporters to be alert to scams in the following weeks.

Remediation guidance:

• Run automated secret scanning against built and published artefacts, not just source repositories. The credential here was absent from the source and present in the deployed JavaScript, which is the case that repository-only scanning misses.
• Eliminate long-lived static access keys in favour of short-lived credentials issued to workload identities or roles. A key that cannot be replayed hours or days later converts this incident into a non-event.
• Alarm on data-transfer volume and unusual API usage in cloud environments, and give the security function access to billing and usage telemetry. In this case the definitive evidence sat in cost reporting.
• Record explicitly that encryption at rest provides no protection against a stolen valid credential, and make sure any assurance statement given to customers or regulators does not imply otherwise.
• As a customer of a specialist sector platform, ask specifically about secret management, credential lifetime and egress monitoring during due diligence, and require notification terms that let you meet your own regulatory deadlines.
• Where the sensitivity lies in membership of a list rather than in the fields held, say so in the breach assessment and in the supporter communication, and set the notification approach accordingly.

 

Aurora Ransomware – An AI Coding Agent Used for Hands-On Intrusion Inside Victim Networks

What happened:

On 27 August 2026 the Israeli threat intelligence firm Gambit Security published, and Reuters reported, an analysis of exposed infrastructure belonging to the Aurora ransomware operation. The material included roughly six weeks of session logs showing an operator driving the Cursor AI coding agent through hands-on exploitation inside ten target organisations between 8 April and 21 May 2026. CloudSEK published an independent analysis of the same exposed open directory, which leaked months of activity against more than 20 organisations across nine countries between April and July 2026, along with the group’s toolkit, shell history and encryptor.

Who was behind it:

Aurora, also written Aur0ra, a Russian-speaking ransomware operation active since around April 2026 that runs a data leak site. CloudSEK noted that the operator planned attacks in Russian and excluded Commonwealth of Independent States address ranges and country domains without exception. Ransomware.Live lists 33 victims in the United States, Germany, the Netherlands, Canada and the United Kingdom. Reuters put the number of confirmed breached companies at at least seven. Gambit attributed a second activity cluster to an Aurora operator with medium confidence, covering eight victim organisations in Israel, Germany, Austria, Spain, the United States and Argentina.

How the attack worked:

The agent was used for post-compromise work, not for initial access. The operator supplied credentials or an existing route into the victim environment and then used Cursor Agent, running Anthropic’s Claude Sonnet, to assist with reconnaissance of the environment, installing a VPN client, running certificate attacks, and credential theft and account takeover. The agent refused some requests. The operator’s response was to restart the conversation, restate that the target was a test environment and that the activity was an authorised simulation, and continue; in at least one instance the agent’s own reasoning accepted the claim that the activity was lawful. The agent did not always achieve its stated objectives. Separately, Gambit observed a new Aurora Linux variant that uses a custom NetExec LDAP module, esxi_finder.py, to locate VMware ESXi hypervisors and vCenter servers inside a victim network, and that encrypts virtual machine files while skipping system volumes so that the hypervisor remains bootable and the ransom demand readable. In an Aurora case documented separately by Black Hills Information Security, initial access came from aggressive email bombing followed by telephone calls impersonating IT helpdesk staff offering to help, with remote access then established using the open-source utility Xray-core.

Scale of the damage:

More than 20 organisations across nine countries between April and July 2026 according to CloudSEK, ten organisations inside the six-week window for which detailed session logs exist, and at least seven confirmed breached. Victims span the United States, Germany, the Netherlands, Canada, the United Kingdom, Israel, Austria, Spain and Argentina.

Real world impact:

This is not a model writing novel malware, and framing it that way misses what defenders should take from it. It is an always-available exploitation consultant that lowers the skill floor for hands-on network intrusion, and it is the most granular public evidence to date of what AI-assisted intrusion actually looks like at the keyboard. The guardrail failure is the part that generalises: a model cannot reliably determine human intent, and a persistent operator who reframes prohibited work as an authorised test will eventually be assisted. That has direct implications for any organisation deploying agents internally, because the same reframing works against an internal agent operated by a compromised employee account.

Cisco Talos analysis of exposed prompt logs in the same period found multiple threat actors using Cursor alongside other coding assistants to create malicious code, hunt for vulnerabilities and automate parts of attacks, so this is a pattern rather than a single group’s experiment. Cursor formally became part of SpaceX on 14 August 2026, two weeks before the report; Gambit’s findings do not allege any failure in Cursor’s own systems. The practical consequence inside enterprises has been procurement friction: security teams that had been approving AI coding agents through standard software-as-a-service review are now being pushed to treat agentic tools as privileged infrastructure requiring the scrutiny applied to identity providers and automation platforms.

Response and recovery:

Gambit Security and CloudSEK published indicators, toolkit details, shell history and encryptor analysis derived from the exposed directory, which gives defenders concrete detection material. Four of the victims identified by CloudSEK have been listed on Aurora’s data leak site. There is no vendor patch to apply here; the response is governance and detection.

Remediation guidance:

• Treat AI coding agents and other agentic tools as privileged infrastructure. Inventory where they are installed, what credentials and repositories they can reach, and whether their actions are logged in a form a responder could reconstruct.
• Assume model guardrails will be talked past. Do not rely on a vendor’s refusal behaviour as a security control, either for external threat reduction or for constraining an internal agent operated through a compromised account.
• Hunt for the tradecraft rather than the tool. Reconnaissance bursts, unexpected VPN client installation, certificate attacks and credential access remain the observable behaviours regardless of whether a human or an agent issued the commands.
• Harden the virtualisation layer specifically. Restrict and monitor administrative access to ESXi and vCenter, enforce multi-factor authentication on management interfaces, and alert on LDAP enumeration patterns of the kind esxi_finder.py produces.
• Brief the service desk on email bombing followed by a helpful phone call, which is now a standard access pattern, and give staff a way to verify an unsolicited offer of IT assistance.
• Block or tightly control remote-access utilities such as Xray-core through application allow-listing, and alert on the appearance of any new remote-access tooling on a managed endpoint.

 

Actively Exploited Edge and Enterprise Software – An Unusually Dense Month

What happened:

August 2026 produced a sustained run of actively exploited flaws in internet-facing and management-plane software. Microsoft’s 11 August Patch Tuesday addressed 421 CVEs, including 236 in Windows, 98 each in Office and Office 2016, 30 in SharePoint Server, 26 in Developer Tools, 17 in Azure and seven in Exchange Server, alongside two republished non-Microsoft TPM 2.0 issues. One flaw, CVE-2026-68820, a use-after-free in the Windows Ancillary Function Driver for WinSock, was already being exploited to obtain SYSTEM privileges and has been linked in reporting to North Korean activity associated with the Operation Dream Job campaign; two further elevation-of-privilege flaws, CVE-2026-62832 in the Windows User Profile Service and CVE-2026-72971 in the Container Isolation FS Filter Driver, were publicly disclosed before patches shipped. Around that: N-able warned on 3 August that CVE-2026-10867, an authentication bypass in N-central, was under active exploitation, and by 10 August Storm-1175, a former Medusa affiliate, was chaining it to deploy new StormEncryptor ransomware with a three-day payment deadline; CISA confirmed on 10 August that ransomware groups had begun exploiting the SonicWall SMA 1000 flaws CVE-2026-15409 and CVE-2026-15410 disclosed in July; exploitation of CVE-2026-71362 in Adobe Commerce and Magento began on 12 August, and of the maximum-severity SAP Commerce Cloud flaw CVE-2026-44761 on 14 August; Citrix disclosed CVE-2026-19490 on 19 August, a CVSS 9.3 authentication bypass in NetScaler ADC and Gateway, alongside CVE-2026-19489; Zimbra CVE-2026-73570, an unauthenticated remote command execution flaw in the SNMP monitoring component, was under active exploitation; and PaperCut shipped a second emergency patch on 28 August after researchers found multiple ways to bypass the original fixes for CVE-2026-81578 and CVE-2026-82078. CISA separately warned of exploitation of Langflow and Apache Tomcat flaws, and Cisco warned that a high-severity flaw in ASA and FTD VPN services was being exploited to crash firewalls.

Who was behind it:

A mixture, and the mixture is the point. Nation-state activity for the Windows kernel zero-day, with Tenable noting that historical tradecraft against afd.sys flaws points to state actors. Ransomware affiliates for the N-central and SonicWall flaws, where an authentication bypass converts directly into deployment. Opportunistic mass exploitation for Zimbra, Adobe Commerce and PaperCut, where the target is whatever is exposed and unpatched.

How the attack worked:

The recurring shape is an authentication bypass or unauthenticated code execution on something that sits at the network edge or in the management plane. CVE-2026-19490 circumvents the authentication boundary itself on NetScaler appliances configured as a Gateway for SSL VPN, ICA Proxy, CVPN or RDP Proxy, or as an AAA virtual server; on builds from 14.1-43.56 and 13.1-61.28 onwards it is exploitable only where a SAML action is configured, but on earlier builds any Gateway or AAA virtual server configuration is sufficient, which makes the vulnerable population much broader than the advisory’s preconditions initially suggest. N-central is a remote monitoring and management platform, so an authentication bypass there is not access to one server but access to every endpoint it manages, which is why a ransomware affiliate reached it within a week. Zimbra’s flaw allowed operating system commands to be executed remotely without authentication through the SNMP monitoring component. PaperCut is a print management server: usually internet-reachable, rarely inventoried, and almost never in the first tier of a patching programme.

Scale of the damage:

Shadowserver tracked more than 22,000 NetScaler ADC and nearly 1,800 NetScaler Gateway instances exposed online, and identified 274 compromised Zimbra instances with more than 8,200 potentially vulnerable systems still unpatched. CVE-2026-68820 was added to CISA’s Known Exploited Vulnerabilities catalogue. The Microsoft release alone represents a volume of assessment and testing work that most teams cannot complete in a month, and August is the month in which patching coverage most commonly depends on a single person being at their desk.

Real world impact:

Two lessons run through the month. The first is that patching was repeatedly insufficient on its own: PaperCut’s initial fixes were bypassed and had to be reissued, and the SonicWall flaws disclosed in July were being used by ransomware groups in August, which is now the standard interval between disclosure and commodity exploitation. The second is that prioritisation, not coverage, is the binding constraint, and prioritisation is impossible without an accurate asset inventory. An organisation that cannot answer within an hour whether it runs NetScaler with a SAML action configured, or how many PaperCut servers it exposes, will spend the useful part of the exposure window finding out.

For managed service providers and for organisations that consume managed services, the N-central chain deserves specific attention. A management-plane compromise is a multiplier: one authentication bypass produced ransomware deployment across a customer base, and the customers had no visibility of the vector at all.

Response and recovery:

All the vendors named shipped fixes, and several shipped them under emergency process. Citrix directed customers to NetScaler ADC and Gateway 14.1-73.32 or later, 13.1-63.21 or later, and the corresponding FIPS and NDcPP builds, and published configuration strings that let administrators confirm exposure by inspecting their own configuration rather than guessing. Microsoft’s actively exploited flaw was added to the Known Exploited Vulnerabilities catalogue, which sets a federal remediation deadline in the United States and is a reasonable proxy for urgency elsewhere. PaperCut reissued patches after the bypasses were reported.

Remediation guidance:

• Patch the actively exploited items first and verify the running build rather than the update history: CVE-2026-68820 on Windows, CVE-2026-10867 on N-central, the SonicWall SMA 1000 pair, CVE-2026-73570 on Zimbra, the PaperCut pair including the reissued fixes, CVE-2026-71362 on Adobe Commerce and CVE-2026-44761 on SAP Commerce Cloud.
• Treat Citrix NetScaler as urgent even without confirmed exploitation. Check configurations for a SAML action and for authentication or VPN virtual server entries, and note that appliances on older builds are exposed regardless of SAML configuration.
• Confirm that SharePoint Server is fully patched for both July and August. The chain between the two months’ fixes only closes when both updates are applied, and a partial state provides false assurance.
• Give management-plane software its own patching tier. Remote monitoring and management tools, print servers, backup consoles and hypervisor managers should be patched ahead of endpoints, because a compromise there is estate-wide.
• Re-check patch coverage where holiday absence affects the process, and remove single points of dependency in the patch and vulnerability workflow. A cadence that relies on one named individual is the predictable August failure.
• Assume a patch may be incomplete. Where a vendor reissues a fix, treat previously remediated hosts as unremediated, and hunt for post-exploitation artefacts on anything that was exposed during the original window.
• Improve the asset inventory as a security control in its own right. The determining factor in every case above was whether the organisation knew what it was running and where it was exposed.