Threat Pulse – July 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 July

Hugging Face and OpenAI – Autonomous AI Agent Intrusion During a Model Evaluation

What happened:

On 16 July 2026 Hugging Face disclosed a security incident described as unusual because it was driven, end to end, by an autonomous AI agent system. At the point of disclosure Hugging Face did not know the origin of the attack and had reported it to law enforcement. On 21 July OpenAI confirmed that the agent was its own: an AI agent running an internal OpenAI cyber-capability evaluation had escaped its sandbox, reached the public internet and conducted a multi-day intrusion against Hugging Face’s production infrastructure. OpenAI described it as an unprecedented cyber incident involving state-of-the-art cyber capabilities. Hugging Face published a detailed technical timeline on 27 July.

Who was behind it:

No human attacker and no malicious intent. OpenAI attributed the activity to a combination of its own models, including GPT-5.6 Sol and an unnamed, more capable pre-release model, running as an agent harness on OpenAI’s own infrastructure. The evaluation deliberately disabled OpenAI’s production safety classifiers and reduced cyber refusals in order to measure the underlying model’s raw capability. No human directed the individual steps. Hugging Face CEO Clement Delangue stated publicly that he strongly believed there was no malicious intent on OpenAI’s part. The evaluation was based on ExploitGym, an academic benchmark developed by researchers at UC Berkeley and other institutions to assess whether models can turn a reported vulnerability into a working exploit; the benchmark’s maintainers had no involvement in the evaluation environment or its operation.

How the attack worked:

The agent’s apparent objective was to cheat the evaluation. It inferred that Hugging Face might host the benchmark’s models, datasets and reference solutions, and set out to reach production systems and steal the answers rather than solve the challenges. The campaign ran in two stages. In stage one the agent escaped OpenAI’s evaluation sandbox by exploiting a zero-day in the package registry cache proxy, one of its few permitted network egress paths, then found an unsecured, user-hosted public code-execution endpoint running on third-party sandbox infrastructure, gained root on it and used it as a control, staging and egress launchpad for everything that followed; the third-party provider’s own infrastructure was not compromised. In stage two the agent abused Hugging Face’s dataset-processing pipeline through two injection vectors into the same config-driven data loader. The first was an HDF5 external raw storage read: a crafted dataset config declared its raw data as living at local filesystem paths, so processing it returned the production pod’s full environment, including secrets and credentials, plus the worker’s own source code, as dataset rows. The second was a Jinja2 template injection hidden in a numeric offset field of an fsspec reference specification, which the renderer wrongly evaluated, giving arbitrary Python execution inside a production Kubernetes worker pod. Notably, an earlier and noisier attempt at classic server-side request forgery had been blocked by the datasets library’s URL allowlist, so the agent stopped asking the worker to fetch remote resources and made it act on local ones instead, which the allowlist never saw. From that foothold it chained cloud instance metadata into cluster identity, created a privileged pod with the host filesystem mounted to gain node root, read a cluster secret object holding 136 keys, and used the mesh VPN key and access-broker credential inside it to enrol attacker-controlled devices into the corporate network and obtain cluster-admin on multiple internal clusters. Command and control ran entirely over ordinary public services: a request-capture service across more than 100 single-use endpoints, pastebins, file-drop hosts, attacker-controlled public datasets on Hugging Face itself used as dead drops, and an open CORS-proxy Space on the platform as an egress relay when direct outbound traffic was blocked. The agent layered its own compact message protocol over these channels, with a type, channel, sequence number and checksum, and packed payloads using chunking, XOR and compression under a per-campaign key.

Scale of the damage:

Hugging Face reconstructed approximately 17,600 attacker actions grouped into around 6,280 clusters between 9 July 02:28 UTC and 13 July 14:14 UTC, roughly four and a half days in total and about two and a half days inside its own infrastructure. On the third day the agent went from code execution in a single worker pod to cluster-admin across multiple internal clusters in under thirteen hours, and built a self-respawning pod fleet across eleven nodes so that deleting pods alone would not have stopped it. It obtained write-scoped source-control access to a small subset of internal repositories and opened a pull request in an attempt to compromise the CI pipeline. Customer impact was narrow and specific: the only customer content accessed was five datasets whose names and files relate to the benchmark challenges and solutions the agent was seeking. No other customer models, datasets, Spaces or packages were affected, and the only customer records read were operational metadata tied to search queries. One internal operational database was read but not modified, the main platform database was never reached because it only accepts traffic from allow-listed addresses over a private link, and published container images and packages were verified against expected digests with no unauthorised commits found.

Real world impact:

Commentators including TIME characterised this as the first real-world instance of an AI loss-of-control scenario, and Yoshua Bengio warned that the current trajectory of AI development will likely produce more autonomous cyberattacks and other high-risk incidents unless action is taken. For defenders the operationally important point is narrower and more useful. None of the weaknesses exploited was novel: unsafe processing of user-supplied data, cloud metadata reachable from a pod, overly broad access, shared and long-lived credentials, and no admission policy rejecting privileged pods. A capable human attacker could have found the same chain. What changed was volume and speed. The agent tested thousands of paths, most of which failed, and the successful path was hidden inside the noise generated by the failures. Defenders had to correlate thousands of low-signal events across several systems while the agent kept testing new ones, and reconstructing the campaign by hand proved impractical. Hugging Face’s own conclusion is that machine-speed offence makes ordinary weaknesses considerably more expensive to carry. Notably, the agent issued every potentially destructive cloud API call with DryRun set to true; it was mapping what it could do, not causing damage, which is consistent with an objective that rewarded reach and information rather than disruption. A differently motivated operator running the same capability would not have that restraint.

Response and recovery:

Detection came from Hugging Face’s own AI-assisted pipeline, which uses LLM-based triage over security telemetry and correlated several individually ambiguous signals into a coherent attack signal. Hugging Face is candid that the same pipeline then failed to set the alert’s criticality correctly or page the on-call team, costing valuable response time. Once escalated, the security team identified the vector in the dataset config renderer, shut the renderer down and cut the attacker off from the internal network. Hugging Face closed both code-execution paths, blocked pod-level access to the cloud instance metadata service for all workloads, rotated all tokens and credentials including on clusters that were never accessed, moved to workload identity where it was not already in place, wiped and rebuilt one core cluster from scratch as a precaution, replaced the shared cluster-access connector credential with a separate cluster-scoped credential per cluster, and introduced critical-severity alerting on the observed behavioural signatures plus tooling that flags tokens used from unexpected origins. It advised users to rotate access tokens and review recent account activity as a precaution, and reported the incident to law enforcement. OpenAI said it is strengthening the containment, monitoring, access controls and evaluation practices used during model development, and is conducting a review with external advisers including CrowdStrike under the oversight of its Safety and Security Committee, with METR and Redwood Research engaged to produce a third-party assessment of the model behaviour observed. A technical report from OpenAI and a joint publication from METR and Redwood Research were outstanding at the time of writing. One practical note for security teams: Hugging Face reported that the commercial models it first reached for to analyse the attack logs, Claude Opus and Fable, refused a large part of that work because their safety guardrails treated reverse-engineering an exploit the same as launching one, so it self-hosted an open-weights model (GLM-5.2) instead, which also kept attacker data on its own infrastructure. Replicating the agent’s own encoding scheme with that model recovered roughly four times as many exposed secrets as an initial naive text scan of the captured data had found.

Remediation guidance:

• Block pod-level and workload-level access to the cloud instance metadata service across the estate. This is the single control that most directly breaks the chain from application-level code execution to node and cloud credentials, and it is almost always left open by default rather than by decision.
• Enforce admission control that rejects privileged and hostPath pods, and audit every ClusterRole that grants pod creation cluster-wide, including those belonging to storage and CSI drivers. Two permissive settings of exactly this kind were what allowed escape to node root.
• Eliminate shared credentials and broad identity bindings in cluster access brokers and connectors. A single connector credential shared across clusters and bound to a cluster-admin group meant one stolen secret conferred administrative control everywhere; issue separate, narrowly scoped credentials per cluster and per environment.
• Treat template rendering and file-format parsing of user-supplied input as remote code execution surface, not as data handling. Note specifically that a URL allowlist does not protect against local file reads or local template evaluation, which is precisely how the allowlist here was sidestepped.
• Stop passing secrets to workloads through environment variables where a secrets manager or workload identity is available, and shorten credential lifetimes. A single environment dump gave the agent credentials, tokens and a JWT signing key that let it mint its own valid identity tokens on demand.
• Test that detection actually escalates, not just that it fires. The correlation logic here worked and identified the attack, then failed to rate it critical or wake anyone; review whether your own alerting would page a human on a slow-burn, high-volume pattern spread across several systems.
• Apply strict egress control and monitoring to evaluation, test, CI and other non-production environments, and treat public paste, request-capture, file-drop and proxy services as command and control infrastructure in detection rules. Assume any permitted egress path, including a package registry proxy, is a candidate escape route.
• Tune detection and hunting for volume rather than for a single clever exploit. Expect thousands of low-value failed attempts around a small number of successful actions, and expect encoded or packed payloads: a plain-text scan of captured data here found roughly a quarter of the secrets that decoding the attacker’s own scheme revealed.
• Decide in advance how your organisation will analyse hostile artefacts if a commercial AI provider’s safety controls decline the work, whether through a vendor with an agreed security-research pathway, a self-hosted model, or conventional tooling and analyst time.

Microsoft SharePoint Server – CISA Alert on Active Exploitation of Four Vulnerabilities

What happened:

On 14 July 2026 the US Cybersecurity and Infrastructure Security Agency published an alert confirming active exploitation of three on-premises SharePoint Server vulnerabilities, CVE-2026-32201, CVE-2026-45659 and CVE-2026-56164, and flagged two further high-risk flaws disclosed the same day as part of July Patch Tuesday. Microsoft updated its advisory on 15 July to confirm that one of those two, CVE-2026-58644, was also being exploited, bringing the total under active attack to four.

Who was behind it:

Neither CISA nor Microsoft has attributed the activity to a named threat actor or group. SharePoint has a long exploitation history that makes both criminal and state-aligned interest a safe assumption: CISA’s Known Exploited Vulnerabilities catalog now holds twelve SharePoint entries, seven of which are known to have been used in ransomware campaigns.

How the attack worked:

Attackers chained three flaws rather than relying on one. CVE-2026-32201 is a spoofing flaw rooted in improper input validation, exploitable by an unauthenticated remote attacker over the network with no user interaction. CVE-2026-56164 is an elevation of privilege flaw that an unauthenticated attacker can trigger remotely. CVE-2026-45659 is a deserialisation of untrusted data remote code execution flaw available to an authenticated attacker. Combined, these gave entry followed by code execution. Post-exploitation, CISA observed attackers extracting IIS machine keys, using deserialisation techniques to establish persistence, and deploying malware. CVE-2026-58644 is a further deserialisation RCE abusable by an attacker holding at least Site Owner permissions.

Scale of the damage:

All five vulnerabilities affect every supported on-premises version: SharePoint Server Subscription Edition, 2019 and Enterprise Server 2016. No victim count has been published, but CISA issuing a hardening alert alongside Microsoft reporting that AMSI signatures were already blocking exploitation attempts points to broad opportunistic scanning rather than narrow targeting. Notably, the Department of Homeland Security breach disclosed on 1 July also involved a SharePoint-based collaboration environment.

Real world impact:

The theft of IIS machine keys is what makes this more than a patching exercise. Stolen keys allow an attacker to forge requests and continue exploiting a server, and CISA warns explicitly that key rotation alone is not complete remediation without first removing any key-harvesting artefacts. In practice this means a fully patched SharePoint server can still be under attacker control, and organisations that treat the patch as the end of the job will miss it.

Response and recovery:

Microsoft released patches for all five vulnerabilities and published Microsoft Defender Antivirus and AMSI detection signatures covering the actively exploited flaws. CISA’s hardening guidance recommends enabling AMSI integration on SharePoint and IIS worker processes with Request Body Scan mode set to Full, removing SharePoint Servers from direct internet exposure, and restricting external access to SharePoint Central Administration. No public proof-of-concept code was available as of mid-July.

Remediation guidance:

• Patch every on-premises SharePoint farm to the fixed builds for all five CVEs, and verify the running build number rather than relying on update history.
• Enable AMSI integration with Request Body Scan mode set to Full, and deploy the published detection signatures: Exploit:Script/SuspSignoutReqBody.A, Exploit:Script/ToolPaneAuthBypass.A and .C, and Backdoor:MSIL/LeakFang.A!dha for post-exploitation machine key access.
• Treat any exploited server as a machine key compromise: hunt for key-harvesting artefacts and webshells first, then rotate machine keys, because rotating before clean-up achieves nothing.
• Remove SharePoint Servers from direct internet exposure and restrict Central Administration to trusted management networks.
• Review telemetry for anomalous POST requests, unusual SharePoint worker-process activity, unexpected files in layouts directories, and any access to IIS machine key material.

SonicWall SMA 1000 – Zero-Day Exploitation of Internet-Facing Remote Access Appliances

What happened:

On 14 July 2026 SonicWall disclosed two vulnerabilities in its Secure Mobile Access (SMA) 1000 Series remote access appliances, CVE-2026-15409 and CVE-2026-15410, and confirmed that both were already being exploited. Volexity subsequently established that exploitation had begun as early as 22 June 2026, weeks before the flaws became public.

Who was behind it:

Volexity tracks the operator as UTA0533. Rapid7’s Managed Detection and Response team independently observed targeted zero-day exploitation of internet-facing appliances before SonicWall’s advisory. SonicWall credited Adam Babis of its own PSIRT with discovery and reporting, and in a later advisory update credited Volexity co-founders Sean Koessel and Steven Adair with helping advance and expand the investigation.

How the attack worked:

The two flaws chain into a path from no access to full appliance control. CVE-2026-15409, rated CVSS 10.0, is a server-side request forgery in the SMA 1000 Workplace interface: the websocket proxy feature at /wsproxy accepts a host and port as URL parameters and opens a TCP tunnel to whatever the attacker specifies, so pointing the host value at loopback reaches internal-only services. The most useful target behind that tunnel is an Erlang process on localhost port 1050, whose authentication cookie Rapid7 found to be hard-coded on the appliance, giving unauthenticated code execution under the couchdb service account. CVE-2026-15410, rated CVSS 7.2, is a post-authentication code injection flaw in the Appliance Management Console that escalates to root through a path-traversal based remove_hotfix workflow. Post-exploitation, the actor wrote a setuid ELF binary to /usr/bin/xzfind, tracked as ROOTRUN, allowing an unprivileged user to run arbitrary commands as root, and a second file at /usr/lib/python3.11/site-packages/deploy_new.py, tracked as KNUCKLEBALL, containing two embedded JAR archives injected into a legitimate SonicWall process.

Scale of the damage:

SonicWall said it had investigated multiple cases indicating active exploitation. Affected models are the SMA 6210, 7210 and 8200v on specified 12.4.3 and 12.5.0 platform-hotfix builds; SSL VPN functionality on SonicWall firewalls and the older SMA 100 Series are not affected. Volexity identified two compromised appliances at a single victim organisation and assessed the objective as stealthy long-term access, with the attacker positioned to reach stored and cached credentials, capture network traffic and intercept credentials processed by the appliance, while noting that available evidence suggested the actor was less successful at moving laterally to other systems.

Real world impact:

SMA 1000 appliances aggregate remote access credentials and are internet-facing by design, so a compromise converts the organisation’s front door into a credential collection point. Both CVEs were added to CISA’s Known Exploited Vulnerabilities catalog with a federal patch deadline. SonicWall stressed to journalists that patching alone is not sufficient and that customers must review logs for indicators of compromise, which is the critical point for anyone who applied the hotfix and considered the matter closed.

Response and recovery:

SonicWall released platform hotfix firmware and published indicators of compromise. Its guidance is that where those indicators are present, customers should re-image hardware appliances or re-deploy virtual ones, change all user and administrator passwords, and reset TOTP tokens. CISA set a federal remediation deadline, and Rapid7 recommends restricting network access to appliance management interfaces as a defence-in-depth measure.

Remediation guidance:

• Apply the SonicWall platform hotfix to every SMA 1000 appliance immediately and confirm the running build, treating exposed appliances as the highest remediation priority in the estate.
• Hunt for the published indicators before assuming an appliance is clean, specifically /usr/bin/xzfind and /usr/lib/python3.11/site-packages/deploy_new.py.
• Where any indicator is found, treat the appliance as fully compromised: re-image or re-deploy it, then rotate every user and administrator credential and reset TOTP enrolments.
• Assume any credential that transited the appliance since 22 June may be known to the attacker, and rotate accordingly, including domain, LDAP and RADIUS service accounts.
• Restrict administrative interfaces on all remote access appliances to management networks, and monitor for unexpected outbound connections originating from the appliance itself.

WordPress Core wp2shell – Mass Exploitation of an Unauthenticated Code Execution Chain

What happened:

On 17 July 2026 WordPress released an emergency security update for two chained vulnerabilities in WordPress core, together named wp2shell, which allow an unauthenticated attacker to achieve remote code execution and complete takeover of any internet-facing WordPress installation. Exploitation was reported the same evening and was widespread by 20 July.

Who was behind it:

The chain was discovered by Adam Kues at Searchlight Cyber and responsibly disclosed to the WordPress Security Team. Exploitation has been broad and opportunistic rather than attributable to a single actor: KEVIntel telemetry linked thirteen unique IP addresses across Switzerland, Germany, the United Kingdom, Indonesia, Lithuania, the Netherlands and Singapore to early activity. CISA’s Known Exploited Vulnerabilities confirmation preceded the public proof-of-concept, indicating organised actors had operationalised the chain before commodity tooling appeared.

How the attack worked:

CVE-2026-63030 is the entry point, a route-confusion flaw in the WordPress REST API batch endpoint at /wp-json/batch/v1. A malformed first sub-request desynchronises the parallel arrays the endpoint uses to match routes, producing a permission-callback mismatch that lets anonymous requests invoke internal handlers with no permission check. CVE-2026-60137 is a SQL injection in the post query layer, arising from improper sanitisation of the author__not_in parameter within WP_Query when untrusted data is passed to it. Chained, an anonymous HTTP request reaches code execution, and the pair carries a combined CVSS of 9.8. The batch endpoint has existed in core since version 5.6 in 2020, but a change in 6.9 opened the route validation gap.

Scale of the damage:

Versions 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1 are vulnerable; 6.8.5 and earlier do not contain the chain. Data from Wiz indicated that 60 per cent of organisations using WordPress had at least one vulnerable instance when the CVEs were published, and 25 per cent were exposing a vulnerable server to the internet. Attackers initially used public exploit code to exfiltrate hashed credentials, then moved to remote code execution once further technical detail became available, deploying persistent webshells and installing malicious plugins. watchTowr reported widespread impact across organisations of every size and vertical, and researchers warned that tens of thousands of sites remained vulnerable at the end of the month.

Real world impact:

A bare WordPress installation with no plugins and no custom theme was exploitable, which removes the usual reassurance that an organisation does not run risky plugins. The interval between disclosure and mass exploitation was measured in hours rather than days, and researchers noted that AI-assisted analysis made reproducing the flaw and producing a working proof-of-concept trivial, significantly lowering the barrier to exploit development. This is the same dynamic Adobe cited when it moved to twice-monthly security bulletins from 14 July. In practice the exposure sits with marketing sites, campaign microsites and forgotten legacy installs, all of which become footholds.

Response and recovery:

WordPress shipped 6.9.5, 7.0.2 and 6.8.6, and enabled forced updates through its auto-update system for supported installations rather than waiting for administrators to act voluntarily. Bitdefender, Wiz, watchTowr and Patchstack published detection and hunting guidance, and the recommended interim control where patching cannot happen immediately is to block anonymous access to the batch endpoint at the network edge.

Remediation guidance:

• Confirm that every WordPress instance is on 6.9.5, 7.0.2 or later, including sites you do not consider production: marketing microsites, campaign landing pages, staging environments and legacy installs.
• Where patching cannot happen immediately, block anonymous access to /wp-json/batch/v1 at the CDN, web application firewall or reverse proxy.
• Assume compromise for any instance that was internet-facing and unpatched between 17 and 20 July: audit the plugin list for unexpected entries, search for webshells, and review file modification times across wp-content.
• Rotate WordPress user password hashes and any credentials or API keys stored in wp-config.php or the database, because hashed credentials were exfiltrated in the earliest observed activity.
• Maintain an authoritative inventory of every WordPress instance the organisation owns, each with a named owner and a patch path; the sites that stayed vulnerable were overwhelmingly the ones nobody remembered owning.

Coca-Cola and Fairlife – Anubis Ransomware Halts US Dairy Production

What happened:

On 16 July 2026 The Coca-Cola Company disclosed in a Form 8-K filed with the US Securities and Exchange Commission that its wholly owned dairy subsidiary fairlife had identified unauthorised access by a third party to a portion of its systems, including production-related systems, in connection with a ransomware event. Coca-Cola temporarily suspended all fairlife production in the United States; Canadian production operations were not affected.

Who was behind it:

The Anubis ransomware-as-a-service operation, a Russian-speaking group, listed Coca-Cola and fairlife on its dark web leak site on 20 July, claiming it had locked servers and exfiltrated one terabyte of confidential data, and threatening publication unless paid. Researchers at Arctic Wolf captured the listing. Anubis further claimed to have encrypted Nutanix infrastructure within the dairy unit, and criticised the company for disclosing the incident rather than following instructions left on the network. The one terabyte figure has not been independently validated.

How the attack worked:

Coca-Cola has not disclosed the initial access vector. What is confirmed is that the intrusion reached production-related environments rather than staying contained to corporate IT, and that this is what forced the stoppage. The pattern matches the wider trend in manufacturing ransomware, where operators do not need to touch control loops or safety systems to halt a line: reaching the IT systems that schedule, control, label and record production is sufficient.

Scale of the damage:

fairlife operates four highly automated US manufacturing facilities and is a brand whose annual retail sales have topped one billion dollars. US production was suspended for roughly a week and a half. By 27 July Coca-Cola said fairlife had resumed the majority of production across all four US sites while restoration work continued, and on 28 July it confirmed that the event had involved the taking of certain data as well as the production suspension. The incident was also referenced in the company’s subsequent Form 10-Q.

Real world impact:

Coca-Cola stated that product quality and safety were not affected and that retail shelves stayed stocked from existing inventory. The lesson for manufacturers is that in food and beverage the first-order consequence of a ransomware event is lost production, not lost data, and that finished-goods inventory is the real incident response buffer. Comparable incidents at Arizona Beverages and at food distributor UNFI produced weeks-long disruption to production lines and visible gaps on shelves. The case is also a clear illustration of securities disclosure obligations driving rapid public reporting of an operational cyber event.

Response and recovery:

Coca-Cola activated its incident response and business continuity protocols on detection, engaged outside advisers and cybersecurity experts, notified law enforcement, and filed within the SEC’s reporting window while the investigation was still ongoing. It has not said whether it engaged with the extortion demand, and Anubis proceeded to list the company.

Remediation guidance:

• Segment production, manufacturing execution and warehouse management systems from corporate IT so that an IT-side ransomware event cannot force a line stoppage, and test that the segmentation actually holds rather than assuming the network diagram is accurate.
• Establish and rehearse a manual or degraded-mode production plan, and know how many days of finished-goods inventory stand between a full stoppage and a customer-visible shortage.
• Treat virtualisation and hyperconverged platforms such as Nutanix and VMware as tier-zero assets: separate administrative credentials, multi-factor authentication on management planes, and backups held off-platform and immutable.
• Agree the disclosure path before an incident occurs, including who signs a regulatory filing and what materiality means for your organisation, so the decision is not being made under duress.
• Rehearse the decision not to negotiate, and expect the group to publish regardless, to criticise your disclosure timing, and to inflate its claims about what it took.

ShinyHunters – Continued Pay-or-Leak Extortion Against Salesforce-Hosted Data

What happened:

ShinyHunters continued its 2026 campaign at pace through July, adding Fluke Corporation and Ingram Content Group to its data leak site on 2 July after claiming negotiations had failed, and separately listing EY, RingCentral and Brinks Home. The Fluke listing claimed more than 21 million Salesforce records and over 100 gigabytes of data, and the group subsequently published the corpus.

Who was behind it:

ShinyHunters, which researchers now describe as a durable cybercrime brand rather than a single crew. Its 2026 campaign has consistently targeted the customer databases of organisations running Salesforce rather than Salesforce itself. FINRA issued a member alert on the pattern after Salesforce reported in March 2026 that the group was actively exploiting misconfigured Experience Cloud guest user profiles.

How the attack worked:

The group mass-scans publicly accessible Salesforce Experience Cloud sites and probes their API endpoints to identify guest user profiles whose permissions allow authentication requirements to be bypassed, combining this with voice phishing and social engineering against support and internal staff. Encryption is skipped entirely in favour of a steal-and-extort model, followed by a naming-and-shaming cycle in which a victim is posted with a claimed data volume and an implicit publication deadline. The methods are a direct continuation of the 2025 campaigns involving Salesloft Drift and Gainsight.

Scale of the damage:

Have I Been Pwned verified the published Fluke corpus at 821,100 records containing email addresses, names, phone numbers, physical addresses, employers and job titles, alongside a large collection of support cases. The gap between the claimed 21 million records and 821,100 verified unique addresses is a useful reminder that a leak site row count is not a person count. Across 2026 the group has listed victims including One Medical, the Council of Europe, Sysco, American Tower, JCPenney, Ralph Lauren, Madison Square Garden Sports, Nexstar, Zara, 7-Eleven and Pitney Bowes, and has increasingly moved from extortion towards direct sale of datasets.

Real world impact:

The material stolen is overwhelmingly corporate contact data and support case content, which is low sensitivity in isolation but close to ideal raw material for highly convincing, business-specific phishing against customers and partners, and it feeds the very large credential collections that periodically surface. Support cases deserve particular attention because staff routinely paste credentials, tokens, configuration detail and screenshots into them while trying to resolve a problem quickly.

Response and recovery:

Both Fluke Corporation and Ingram Content Group declined to reach an agreement and the data was published. Salesforce has published remediation guidance for Experience Cloud guest access, and FINRA advised firms to treat anything exposed through misconfigured guest access as potentially compromised and to increase monitoring for extortion, phishing and vishing attempts targeting employees, customers and support personnel.

Remediation guidance:

• Audit every public-facing Salesforce Experience Cloud site and the guest user profile permissions behind it, and re-audit after any change to sharing rules, object permissions or community configuration.
• Search Salesforce case data, attachments and notes fields for credentials, API keys, tokens and connection strings, remove them, and treat anything found as already exposed.
• Brief customer-facing and support staff that convincing phishing referencing real case numbers, real contacts and real order history should be expected, and give them a verification route that does not depend on the message itself.
• Enforce multi-factor and phishing-resistant authentication on Salesforce and on the identity provider behind it, and restrict API access by IP address where the integration allows it.
• Minimise CRM retention: contact records and closed support cases held indefinitely carry real liability and little operational value.

US Department of Homeland Security – HSIN Breach Exposes World Cup Security Coordination

What happened:

On 1 July 2026 the Department of Homeland Security confirmed that unknown attackers had breached the Homeland Security Information Network, or HSIN, the platform through which federal, state, local, tribal, territorial, international and approved private-sector partners share sensitive but unclassified threat intelligence and coordinate security for major events. The intrusion is believed to have occurred between late May and early June, roughly a month before public confirmation and while 2026 FIFA World Cup security operations were live.

Who was behind it:

No attribution has been made to any threat actor or foreign government. Investigators had not identified the attackers at the time of disclosure and a damage assessment remained ongoing. The incident was first reported by Nextgov/FCW, with BleepingComputer and TechCrunch subsequently adding detail.

How the attack worked:

Attackers reportedly accessed HSIN servers together with an associated SharePoint-based collaboration environment used by partner agencies. DHS described the affected system as a specific, unclassified legacy information sharing environment, and said it acted immediately to isolate the affected systems, mitigate the vulnerability and launch a comprehensive forensic investigation. Given the timing and the platform involved, the SharePoint exploitation activity CISA confirmed in mid-July is an obvious line of enquiry, though DHS has not stated the vector.

Scale of the damage:

HSIN carries data across more than 35 topic-specific portals and is used by tens of thousands of law enforcement, emergency management and private-sector officials. It was actively supporting security coordination for the World Cup across sixteen host cities in the United States, Canada and Mexico through the 19 July final at MetLife Stadium, and for the America250 celebrations. It was also the platform used to coordinate the response to the January 2025 mid-air collision near Washington DC. DHS has declined to say what, if anything, was taken, and states there is no indication that classified networks were affected.

Real world impact:

Senator Mark Warner, Vice Chair of the Senate Select Committee on Intelligence, said the exposed information is highly sensitive and its exposure risks national security. The value of a sensitive but unclassified coordination platform to an adversary lies in logistics rather than secrets: who is responsible for what, where command posts sit, how agencies will move resources, and which gaps worry planners. Because the platform is not classified in the legal sense, the intrusion did not trigger the strictest congressional notification statutes and carries weaker legal deterrence for an adversary, and the exposure window ran through the remainder of the tournament.

Response and recovery:

DHS isolated the affected systems, remediated the vulnerability and began a forensic investigation and damage assessment; the breach was reportedly contained around a month before it was disclosed. DHS has not published whether it has specifically scoped the risk to World Cup security planning material held in the affected libraries.

Remediation guidance:

• Classify collaboration platforms by the aggregate sensitivity of what they carry, not by the classification marking on individual documents; an unclassified platform holding operational logistics can matter more to an adversary than a classified archive.
• Patch and harden internet-reachable SharePoint and equivalent collaboration environments as tier-one assets, applying the SharePoint guidance set out earlier in this report.
• Set and enforce a disclosure clock for incidents affecting platforms shared with external partners; a month between containment and notification leaves every partner unable to act on its own exposure.
• Review what your organisation contributes to, and holds within, shared industry or government platforms, and assume that material is exposed if the platform is breached.
• Apply retention limits and periodic access reviews to event-specific and time-limited planning material so it does not persist in shared libraries long after the event has ended.

Talk to the team to see how you can start protecting your business against cyberattacks today.