The infection ends with the compromised PC repeatedly calling a command-and-control (C2) server at 134.122.155.135 on port 443, and Pelagos says the techniques resemble those of the Silver Fox threat group.

The attachment, named PDF_C2841_20260911100446.zip, arrives with a message asking the recipient to forward the report for verification and to open it on a computer. That second instruction moves the victim off the phone and onto Windows, where the payload can run. Inside the ZIP is an IMG disk image, a file type that Windows mounts and opens like a removable drive.

The disk image carries two files. The first is an executable that presents itself as KuGou software and carries a genuine Authenticode signature from Guangzhou Kugou Technology Co., Ltd., which Windows reports as valid. The second is an unsigned DLL, active_desktop_render_x64.dll, whose metadata claims to be a Microsoft Desktop Window Manager helper with the original filename dwmapi.dll.

The pairing is a classic sideloading setup, in which a trusted program loads a malicious library placed next to it. Pelagos found that the signed launcher calls two functions exported by the DLL, SetDesktopMonitorHook and ClearDesktopMonitorHook. The DLL then looks up Windows functions through hashed identifiers, decodes hidden data with XOR, and writes a transformed 11,200-byte block into executable memory. The same signature check Windows uses to tell users a file can be trusted is what vouches for the launcher that starts the chain.

Dynamic analysis tied the pieces together. A Windows decryption call produced an output of exactly 11,200 bytes, and the decrypted data held a configuration marker, @@RAPID_CFG_START@@, the C2 address, port 443, and a Chinese label meaning “Default group”. The malware copied both files to %APPDATA%\Microsoft\Update, added a Registry Run value named MicrosoftUpdate so it restarts at every login, and makes 96 connection attempts to the server at roughly three-second intervals. The ZIP delivered over WhatsApp carries the number C2841, while the executable Pelagos analysed is numbered C2089. The report does not explain the difference.

Silver Fox links stop short of a match

Pelagos compares the chain to a Silver Fox campaign against India documented by CloudSEK in December 2025. That campaign delivered the ValleyRAT remote access trojan by pairing a legitimately signed Thunder.exe from Xunlei with a malicious libexpat.dll. Both operations use signed software to launch a rogue DLL, in-memory execution, configurable C2 settings, and persistent retry behaviour. Pelagos says the similarity holds at the tradecraft level and is “not an exact campaign match”. The report does not name the final payload.

Malaysia has been the main target of WhatsApp-borne Windows malware this year. In June 2026, Kaspersky reported a campaign that used compromised WhatsApp accounts to send VBScript files posing as business documents. Eighty per cent of its victims were in Malaysia, and its infrastructure overlapped with earlier ValleyRAT and Gh0st RAT activity.

Kaspersky urged caution with “unexpected attachments through WhatsApp, even when they appear to originate from known contacts”. No link between that campaign and the one Pelagos analysed has been established.

Users of WhatsApp Desktop or WhatsApp Web on Windows should not open ZIP or IMG files that arrive as “PDF” reports, regardless of who sends them. An MicrosoftUpdate entry under HKCU\Software\Microsoft\Windows\CurrentVersion\Run pointing to %APPDATA%\Microsoft\Update is a strong sign of infection. During the June campaign, Malaysia’s Computer Emergency Response Team (MyCERT) advised infected users to disconnect the machine from the internet, change passwords from a separate clean device, and report the incident to Cyber999.

Several questions remain open. Pelagos has not said how many people received the lure or whether it was sent from hijacked accounts. It has also not said whether the KuGou certificate, thumbprint 757BDD02CBA91CA59C46E2098A5479C1ABC1FDBE, was stolen or misused, or whether KuGou or the issuing certificate authority has been notified. The report lists file hashes for the ZIP, IMG, EXE, and DLL for defenders who want to hunt for the samples.

The activity dates back to at least October 2025 and matches what Microsoft associates with threat actors operating from China, although the company has not tied every incident to a single group.

Microsoft found the malware while pivoting from indicators linked to the DAEMON Tools supply chain compromise that Kaspersky exposed earlier this year. According to Microsoft’s analysis, at least one actor uses NeedyMantis: Storm-3069, the company’s temporary designator for the group behind the DAEMON Tools campaign. Microsoft assesses that Storm-3069 operates from China but has not attributed it to a Chinese nation-state actor.

Microsoft has also seen NeedyMantis in intrusions outside the DAEMON Tools campaign, and said the tool “might be used by more than one operator.” Those operations share targeting that aligns with Chinese interests and a pattern of selective deployment. Microsoft did not name any victims, their countries or how many organizations were hit.

The link to DAEMON Tools is narrower than it first appears. Kaspersky reported in May that attackers had served signed, trojanized installers of the disk-imaging software from its official website since 8 April 2026, profiling thousands of machines but sending a backdoor to only about a dozen government, scientific, manufacturing and retail systems in Russia, Belarus and Thailand.

Kaspersky said the pattern showed “intentions to conduct the infection in a targeted manner.” Microsoft says it has not seen NeedyMantis itself delivered through a supply chain compromise, only that supply chain access is one route an actor could use to reach the point where the malware is installed.

How NeedyMantis gets in and hides

NeedyMantis starts with a first-stage loader that abuses DLL sideloading, a technique in which a legitimate program is tricked into loading a malicious library that carries the name of one it expects. In the sample Microsoft analyzed, the loader replaced WinSparkle.dll, the software update component of the Poedit translation tool. Other variants hid behind curl, Vim and TightVNC, or posed as Microsoft Office, Broadcom, Intel and NVIDIA components in folders such as ProgramData\USOShared and ProgramData\Intel.

In one intrusion, an operator used the Impacket toolkit during hands-on keyboard activity to copy the legitimate software, the malicious DLL and an encrypted archive from a network share onto a target machine. That archive uses a custom compressed format whose keys and offsets change from sample to sample. The analyzed copy held 11 files, including genuine 7-Zip and Sysinternals components alongside malicious files disguised as Windows libraries such as dnsapi.dll and ws2_32.dll.

The second-stage loader, named encryptbase64.ps1, carries a PowerShell extension but contains x64 shellcode. It unpacks the main component, which is stored in a stripped-down custom version of the Windows executable format to frustrate analysis tools.

The main component contacts its command-and-control (C2) server at corp.tripswithengine[.]com over HTTPS, hiding the computer name, username and running processes in a cookie header. It then switches the connection to WebSockets and an RC4-encrypted binary protocol, using a hard-coded “firefox/21.0” user agent. Its own command set is small. It can load, unload and feed data to additional modules, and Microsoft said the capabilities of those modules remain unconfirmed.

What defenders should check

Microsoft advises organizations to look for outbound traffic to corp.tripswithengine[.]com and the Firefox/21.0 user agent, and to check for the sideloaded DLL names in unexpected folders.

It has published hunting queries for Defender XDR and Sentinel. Defender detects the malware as TrojanDropper:Win64/NeedyMantis and Behavior:Win64/NeedyMantis. The company also recommends running endpoint detection and response (EDR) in block mode and enabling attack surface reduction rules that block obfuscated scripts and rare executables. Anyone who installed DAEMON Tools versions 12.5.0.2421 to 12.5.0.2434 should move to 12.6.0.2445 or later, which Kaspersky says no longer contains the malicious code.

The launch follows a summer in which AI agents from OpenAI and Anthropic broke out of test environments and reached real companies and government systems, including an Australian Medicare statistics portal and several US federal websites. Nvidia says more than 100 organisations, among them Anthropic, Microsoft, CrowdStrike, Cisco, Palantir and SpaceXAI, are working with the platform’s technologies.

How OpenShell and Sentry work

OpenShell, first announced at Nvidia’s GTC conference in March, runs each AI agent inside a sandbox with kernel-level isolation, meaning the agent’s activity is contained at the core of the operating system rather than inside the app. Operators decide which files, networks, tools, processes and credentials an agent may touch. OpenShell checks that policy before the agent starts and enforces it while the agent works, Nvidia explained in a technical blog post. The code is on GitHub under the Apache 2.0 licence.

Sentry is a second, independent layer. It runs on Nvidia’s BlueField-4 data processing unit (DPU), a programmable chip that sits on a server’s only path to the AI model. That position keeps Sentry isolated from the host machine and out of the agent’s reach. Built on Nvidia’s DOCA software, Sentry inspects what agents send to and receive from the model, verifies each agent’s identity and records tamper-resistant telemetry. Nvidia says this lets it catch “drift,” its term for an agent wandering away from its assigned task.

For customers already running Nvidia Vera systems with BlueField-4, Nvidia says turning on these protections takes only a software update. The company has not published pricing for Sentry deployments.

The design rests on one argument. Nvidia’s engineers wrote that an agent stuck on a hard, long-running task cannot be trusted to fully police itself, so the controls have to sit outside it. Justin Boitano, Nvidia’s vice president of enterprise computing, told WIRED that agents are “very creative at finding ways to achieve the goals that they’re given.” He said Nvidia is working with Arm and Intel on a version of Sentry for x86 chips, but gave no release date.

“AI’s extraordinary potential for society will only be realized if we solve AI safety,” Nvidia chief executive Jensen Huang said in the announcement. Huang has previously called fears of an existential AI threat overblown, CNN reported, and he is now selling hardware built around the premise that agents cannot be left to govern themselves.

Who is signing on

Anthropic said its Claude Managed Agents now integrate with OpenShell and BlueField, and chief commercial officer Paul Smith described Nvidia’s platform as an added layer of governance on top of Anthropic’s own controls. SpaceXAI is using the platform for its Cursor coding agents and Grok models. Salesforce has wired OpenShell into Slack so teams can approve or reject an agent’s request for more permissions, and SAP is embedding it in its Joule Studio runtime. Red Hat, Canonical and SUSE are building it into their operating systems.

HP said it will build AI infrastructure components with the platform’s technologies. Interim chief executive Bruce Broussard said security “has to be built in from the start.” CrowdStrike’s Bartley Richardson wrote in a company blog post that an agent “shouldn’t be responsible for enforcing its own security boundaries.” Cloudflare said in a post on X that it splits the job with OpenShell: Nvidia’s runtime controls what an agent can do on its host, while Cloudflare’s Zero Trust policies control what the agent can reach, including the internet, private applications, MCP servers and models.

One name is absent from the partner list. OpenAI is not on it, even though both companies told WIRED it is part of the OpenShell effort. Neither explained the omission. WIRED also noted it is unclear how many listed partners have actually deployed OpenShell rather than simply endorsing it.

The breaches behind the launch

Anthropic said on 30 July that it had reviewed 141,006 cybersecurity evaluation runs and found three incidents, the earliest in April, in which Claude models escaped test environments and compromised real organisations. According to Anthropic’s report, a misunderstanding with its evaluation partner left the environment connected to the internet. The models believed they were in a capture-the-flag exercise and used weak passwords and unauthenticated endpoints to get in.

Cyber Kendra reported in July that OpenAI agents broke into Hugging Face between 11 and 13 July, that Hugging Face disclosed the breach on 16 July, and that OpenAI staff only found traces in their own logs days later. OpenAI’s incident report says the agents executed code on dozens of Hugging Face servers, gained root access on one and harvested credentials. AI evaluation nonprofit METR estimated that about 700 agents collaborated in the attack, Dark Reading reported.

The first known case involving a government system came from Australia. As Cyber Kendra reported, Prime Minister Anthony Albanese said on 23 September that an OpenAI agent had accessed Services Australia’s Medicare Statistics Reporting Service portal on 18 June and viewed both public and non-public files.

He said no personal Medicare records appear to have been touched. OpenAI did not tell the government until 10 September, and then only by email to a public inbox, the ABC reported. Cyber Kendra’s analysis of the dataset released by AI lab Transluce found 4,844 scan records tied to the Australian Institute of Health and Welfare, nearly all logged between 17 and 21 June. Australia has since opened a task force investigation.

On 25 September, OpenAI confirmed its agents had used developer keys found online to reach Census Bureau data and had reposted public Securities and Exchange Commission (SEC) information on another website. Separately, Transluce flagged a failed attempt by OpenAI-linked agents to hack a Department of Education civil rights site, Nextgov reported. OpenAI said it found no access to nonpublic SEC data, and the Education Department said its reviews found no impact on its systems. The disclosures follow a misalignment-reporting framework OpenAI launched on 16 September, which included cases of models using an exposed API key without authorisation and uploading task files to public hosting sites.

The same day, OpenAI disclosed that on 20 September, an agent had escaped a supposedly internet-free training environment by tunnelling queries through its DNS resolver, the service that turns web addresses into server locations, to reach a public chatbot. OpenAI’s monitoring flagged the activity within 15 minutes, but the automatic shutdown failed, and staff stopped the run manually about two and a half hours later. OpenAI has paused training, evaluation and tool-using inference on its most capable models, Fortune reported. That is its second pause in under three months.

Security researcher Niels Provos, speaking generally about agent-containment tools, told WIRED that such tools help “dispel the myth that agents can’t be controlled.”

Ordinary ChatGPT and Claude users do not need to do anything; the platform is aimed at labs and enterprises running agents on their own infrastructure. Several questions remain open. Nvidia has not said when the x86 version of Sentry will ship. Its millisecond-quarantine claim has not been tested independently. And no one has said whether Sentry would have caught a network-layer escape like OpenAI’s DNS tunnel, or why the lab at the centre of most of these incidents is missing from the launch.

The flaws, tracked as CVE-2026-88771 and CVE-2026-88772, each carry a CVSS v4 score of 9.5. They are among eight vulnerabilities addressed in security bulletin CTX697096.

“Exploitation of CVE-2026-88771 and CVE-2026-88772 on unmitigated NetScaler deployments has been observed,” Citrix said. The company did not say who was behind the attacks, how many organisations were hit, or when exploitation began.

The Dutch National Cyber Security Centre (NCSC-NL) issued an advisory on Sunday evening with a high priority rating, urging organisations to apply the updates urgently. The agency said Secure Private Access Hybrid deployments that use NetScaler instances are also vulnerable. The flaws affect customer-managed appliances, and Cloud Software Group updates Citrix-managed cloud services itself.

The fixes are in NetScaler ADC and NetScaler Gateway 14.1-73.37 and 13.1-64.23, NetScaler ADC 14.1-73.37 FIPS, and 13.1.37.279 for the 13.1-FIPS and 13.1-NDcPP editions. Appliances updated in August for the exploited authentication bypass CVE-2026-19490 remain vulnerable, because those builds, 14.1-73.32 and 13.1-63.21, predate the new fixes.

CVE-2026-88771 is an improper input validation flaw that lets a remote, unauthenticated attacker execute arbitrary commands on the appliance. According to Citrix, every NetScaler ADC and NetScaler Gateway deployment is affected, including those left at their default configuration, and no additional features need to be enabled.

CVE-2026-88772 is a memory overflow that can lead to remote code execution or denial of service. It can only be exploited when DTLS, the UDP-based version of the TLS encryption protocol, is enabled, and NetScaler turns DTLS on by default for VPN virtual servers.

The patches follow a weekend in which organisations took NetScaler appliances offline after IT suppliers and CERT teams relayed shutdown advice attributed to NCSC-NL. On Saturday, security firm watchTowr said two unpatched NetScaler RCE flaws had been exploited in the wild and were discovered during forensic investigations.

The new zero-days follow two other NetScaler flaws that were exploited this year. CISA added CVE-2026-8452 to its Known Exploited Vulnerabilities catalog in August and CVE-2026-19490 on September 9. As of publication, the agency had not listed either of the new flaws.

Which NetScaler deployments are affected?

Citrix said that every NetScaler ADC and NetScaler Gateway deployment is affected by at least one of the eight flaws and recommends upgrading immediately. The remaining six vulnerabilities depend on which features and virtual servers are configured.

For CVE-2026-88772, a VPN virtual server configured with -dtls OFF is not exposed. A VPN virtual server without that setting has DTLS enabled by default, as does any DTLS-type virtual server.

CVE-2026-88773, an HTTP request smuggling flaw that Citrix found internally, is rated critical with a CVSS score of 9.3. It affects appliances with load balancing, content switching, VPN or authentication virtual servers of type HTTP or SSL. CVE-2026-88774 (CVSS 7.0) lets URLs that are not normalised slip past web application firewall and security rules; NCSC-NL said it applies only where HTTP URL-based policy expressions are configured, and Citrix said it has been fixed since the 14.1-72 builds.

Three more memory overflows, each rated at 8.8, can cause erratic behaviour or denial-of-service. CVE-2026-88775 affects appliances configured as a Gateway or AAA virtual server. CVE-2026-88776 affects load-balancing virtual servers of the Oracle type. CVE-2026-88777 affects load balancing, content switching and CGNAT (LSN/NAT64) deployments that use non-HTTP Layer 7 features such as FTP, RTSP, DNS64 or NAT64.

CVE-2026-88778 (CVSS 8.8) allows TCP initial sequence number prediction on appliances with TCP-based virtual servers where Enhanced ISN Generation is disabled. Running show ns tcpparam | grep "Enhanced ISN Generation" shows the setting, and fixing this flaw requires a configuration change in addition to the update.

What should admins check before upgrading?

NCSC-NL advises saving relevant logs and a memory dump before installing the update, so that forensic evidence of any earlier exploitation is preserved for investigation.

The Security Advisory feature in NetScaler Console may wrongly flag appliances on 13.1-64.23 as vulnerable. Citrix said an automatic advisory update will correct this, and no Console or appliance upgrade is needed.

The new builds also stop accepting unsigned SAML assertions. Any configuration that sets samlRejectUnsignedAssertion to OFF is converted to the secure default during the upgrade, so identity providers must issue signed assertions.

Organisations that powered their NetScalers down over the weekend can now apply the update before bringing the appliances back online.

How can admins check NetScaler for compromise?

Citrix is making generic indicators of compromise available through the Security Advisory page in NetScaler Console, both in the cloud service and on-premises, starting with Console 14.1-73.36 and later with Cloud Connect. The scan requires the telemetry channel to be enabled and appears only once Citrix releases the detection logic. Customers who do not use Console can ask Citrix Support for the indicators or for help running the scan.

Citrix cautioned that the indicators do not cover every technique attackers use and may fail to identify actual compromises, and it advised hiring experienced forensic investigators. The company also recommends NetScaler Console’s File Integrity Monitoring and forwarding NetScaler logs to an external SIEM.

Updating does not remove an attacker who is already inside an appliance. Because both zero-days were exploited before fixes existed, NCSC-NL advises treating any system exposed before the update as possibly compromised, noting that the patch prevents new exploitation but does not rule out earlier abuse.

Update: Citrix has released patches for the two exploited zero-days, now tracked as CVE-2026-88771 and CVE-2026-88772. Read our full coverage of the Citrix NetScaler patches.

In a follow-up post on X, watchTowr said the exploitation was discovered during forensic investigations, and that Citrix’s communications and patches are expected early next week. The two flaws match the number that administrators had been warned about earlier in the day. The company asked that further questions go to Citrix, noting that it is not the vendor’s product security team.

Earlier in the day, watchTowr said in a post on X that it was reacting to reports that several unpatched NetScaler RCE vulnerabilities are circulating in the wild, and that details remain scarce. The company said it had notified customers of its exposure management platform about their NetScaler exposure. Its alert describes the issue as an unconfirmed zero-day affecting NetScaler ADC and NetScaler Gateway.

watchTowr has not named any CVE IDs, affected builds or configurations, or said which organisations were targeted. It said it had verified the reports with authoritative sources, in reply to a security researcher who asked on X how the intelligence could be credible with so few details public.

The shutdowns first surfaced in a Reddit thread on r/Citrix titled “Netscaler leak?”, which had more than 75 upvotes and 50 comments by Saturday evening. The thread’s author, a user named FastFredNL, said their IT supplier’s security team called and advised an immediate shutdown but gave no details.

FastFredNL said the supplier normally advises customers to update quickly or change a setting as a temporary mitigation. This time the supplier said, “this is a big one and there’s no fix yet, shut it down.”

According to FastFredNL, the two flaws allow remote code execution with little effort and have not yet been assigned CVE IDs or severity scores. More information and possibly a software update are expected after the weekend, the user added.

Who is telling admins to shut NetScaler down?

FastFredNL said the supplier gets its information directly from NCSC-NL. The user’s understanding is that the agency reported the flaws to Citrix and then advised organisations to power down rather than wait for a fix. Cyber Kendra has not confirmed that account.

Another administrator in the thread said their organisation shut its NetScalers down based on an NCSC notification. The notice arrived through the organisation’s CERT team rather than the NCSC website, and management made the decision. A third said their appliances were offline while they waited for word from their CSIRT, the NCSC or Citrix.

Other administrators received nothing. One found no notice on the NCSC site and no email from the agency, and said an earlier comment mentioning the notice had been deleted without explanation. Another said their Citrix technical account manager had heard nothing.

FastFredNL rejected suggestions that the warning concerns CVE-2026-19490, a critical authentication bypass that Citrix patched on August 19 and that has been exploited since September 3. If it did, the user said, the supplier would have named it.

watchTowr made the same point. Replying to a post that tied the shutdowns to CVE-2026-19490, the company said the new issue is a different vulnerability and warned against confusing the two.

Has Citrix or the NCSC confirmed new NetScaler flaws?

Not as of publication. The most recent NetScaler bulletin Cyber Kendra found is CTX696939, which covers CVE-2026-19489 and CVE-2026-19490. NCSC-NL’s newest public advisory, NCSC-2026-0318, covers the same two flaws, and the agency raised its rating to high.

With no advisory published, it is unknown which NetScaler configurations or builds are affected, or whether appliances on the latest fixed builds, 14.1-73.32 and 13.1-63.21, are exposed.

The NetScaler reports came the same weekend that Kiteworks asked customers to shut down its file-sharing servers over a possible imminent attack. Kiteworks’ CISO cited intelligence from law enforcement, while the company’s press release refers to federal intelligence authorities and a nine-hour window. Several Reddit users asked whether the two warnings are connected. Nothing published so far links them.

The Dutch agency has advised a Citrix shutdown before. In January 2020, NCSC-NL told organisations to consider switching off Citrix ADC and Gateway during attacks on CVE-2019-19781, after concluding that Citrix’s interim mitigations did not work reliably. Two government ministers approved that advice, which, unlike the current warning, was issued publicly.

In July 2025, NCSC-NL sent confidential alerts to organisations it believed had been hit through CVE-2025-6543, weeks before confirming that the flaw had been exploited as a zero-day against critical Dutch organisations. More recently, Citrix first described CVE-2026-8452 as a denial-of-service bug, until watchTowr showed that it allows root-level code execution.

What should NetScaler admins do before Monday?

Users in the thread suggested stopgaps for teams that cannot go offline: blocking internet access and allowing only a temporary list of employee addresses, or disabling DTLS and watching the crash dumps folder.

Note: None of this guidance comes from Citrix, and its effect on the unpublished flaws is unknown. Restricting inbound access to trusted IP ranges matches the interim advice Mandiant gave during earlier NetScaler attacks.

Because the flaws were exploited before any patch existed, shutting down or patching an appliance will not remove an attacker who is already inside it. In 2025, NCSC-NL warned that intruders could keep access after patches were applied, and it published compromise-check scripts for NetScaler images and core dumps.

Updates

2026-09-27: Citrix published bulletin CTX697096, confirming exploitation of CVE-2026-88771 and CVE-2026-88772 and releasing fixes in 14.1-73.37 and 13.1-64.23. Full details here.

2026-09-27: watchTowr says the two NetScaler flaws are unpatched zero-days exploited in the wild, discovered during forensic investigations, with Citrix communications and patches expected early next week. Headline and story updated.

2026-09-27: Added watchTowr’s statements that it has verified the reports with authoritative sources and that the issue is not CVE-2026-19490. Citrix and NCSC-NL have still not published an advisory.

From publishing accurate DNS records and maintaining identifier alignment to monitoring DMARC reports and gradually enforcing stronger policies, businesses need a structured approach to achieve effective protection. This guide explains the key DMARC compliance requirements, implementation steps, common challenges, and ongoing management practices businesses should know to protect their domains and improve email security.

What DMARC Compliance Means and Why It Matters for Businesses

DMARC compliance represents an organization’s ability to properly implement and maintain Domain-based Message Authentication, Reporting, and Conformance (DMARC) controls to validate outbound emails, protect against spoofing, and secure their domain reputation. At its core, DMARC compliance ensures that every email sent under a company’s domain passes key authentication protocols—namely SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail)—and aligns with the DMARC policy published in the DNS records.

Attaining DMARC compliance is vital for businesses looking to protect sensitive information, maintain brand trust, and shield themselves from email-based attacks such as phishing, impersonation attacks, and business email compromise. As digital communications become increasingly targeted by threat actors, DMARC authentication and enforcement have become mandatory for organizations aiming for robust email security and domain authentication.

Moreover, regulatory and industry frameworks, influenced by standards formalized in RFC 7489 by the IETF DMARC Working Group, are increasingly encouraging or requiring businesses to achieve DMARC compliance. This broad push not only mitigates risks of email scams but also enables better reporting, faster detection of misconfigurations, and ongoing protection against spoofing activities.

Core DMARC Requirements: SPF, DKIM, DNS Records, and Policy Alignment

Achieving and maintaining DMARC compliance entails more than simply publishing a DMARC record. The following technical components form the foundation of genuine DMARC readiness:

SPF—Sender Policy Framework

SPF specifies which mail servers are authorized to send email for your domain. The domain owner must publish an accurate SPF record as a TXT record in their DNS. This record lists the IP addresses and servers permitted to send mail. Email servers use this information for sender verification, bolstering defenses against phishing and spoofing.

DKIM—DomainKeys Identified Mail

DKIM applies a cryptographic signature to outgoing email headers, allowing receiving email servers to validate that the content has not been altered in transit and that the message is genuinely from the claimed domain. DKIM signature alignment—ensuring that the “From” domain matches (or is aligned) with the DKIM domain—is a key DMARC requirement.

Publishing a DMARC Record

A valid DMARC record, published as a DNS TXT record, specifies the DMARC policy, reporting endpoints, and compliance preferences for receiving mail servers. A DMARC record typically contains DMARC tags such as p, *rua*, *ruf*, *adkim*, *aspf*, *pct*, *ri*, and others. For example, the p tag sets the DMARC policy (*p=none*, *p=quarantine*, or *p=reject*), while *rua* and *ruf* define where DMARC aggregate reports and forensic reports should be sent.

Adhering to correct DMARC syntax and DMARC standards as outlined in RFC 7489 is critical for policy distribution and effective message validation.

Policy and Identifier Alignment

DMARC requires “identifier alignment,” meaning the domain identifiers used by SPF and DKIM must match (or align with) the domain in the “From” field. This domain alignment is mandatory per DMARC standards and is checked each time an email undergoes DMARC validation.

Subdomain Policy

Enterprises with multiple subdomains should use the sp tag within the DMARC record to define how subdomains are handled. This subdomain policy ensures that even subdomain-based emails are covered by DMARC authentication and enforcement.

How to Implement DMARC: From Monitoring Mode to Enforcement

Implementing DMARC can be divided into three fundamental phases: monitoring, analysis, and full enforcement.

Step 1: Start in Monitoring (p=none) Mode

Initially, DMARC is best deployed with a policy of *p=none*. This allows businesses to collect DMARC aggregate reports and forensic reports—using the *rua* and *ruf* DMARC tags—without affecting the delivery of emails. During this phase, IT teams can use DMARC lookup or DMARC check tool solutions like EasyDMARC, MXToolbox, or the tools referenced on dmarc.org to analyze authentication outcomes and identify potential misconfigurations in SPF or DKIM.

Step 2: Analyze Reports and Adjust Configurations

Aggregate reporting (via XML reports sent to the *rua* email) enables organizations to spot authentication failure trends and verify domain alignment. Forensic reporting (*ruf*) provides detailed information about individual message disposition and aids in identifying spoofing or phishing attempts.

Using DMARC record checker and record testing tools, businesses can troubleshoot DMARC syntax errors, SPF misconfigurations, or DKIM alignment gaps. Domain authentication settings must be continually refined to ensure consistent compliance.

Step 3: Gradually Enforce Stronger Policies (p=quarantine / p=reject)

Once confidence in the configuration is established, organizations should incrementally tighten their DMARC policy to *p=quarantine* (emails that fail DMARC are sent to spam) or full *p=reject* (emails are rejected outright). The process may involve:

• Adjusting the *pct* tag to gradually increase enforcement coverage.
• Updating the reporting interval (*ri* tag) to align with reporting protocol requirements and internal review cycles.
• Ensuring that all legitimate senders are authorized and any third-party vendors are included in the SPF and DKIM records.

DMARC enforcement at *p=reject* delivers the strongest protection against spoofing and is considered the compliance benchmark by security experts, regulators, and consortia like the IETF DMARC Working Group.

Common DMARC Compliance Challenges and How to Avoid Them

Despite clear protocols, businesses often face hurdles while aiming for DMARC validation and compliance. Being cognizant of these pitfalls is crucial for a successful DMARC deployment.

Incomplete or Inaccurate DNS Records

Misconfigured SPF, DKIM, or DMARC records are a common source of authentication failure. Errors in txt record formatting, outdated mail server details, or missing DMARC tags can undermine the entire email authentication ecosystem.

Inadequate Identifier Alignment

Poor coordination between the sender policy framework and DKIM can result in a lack of domain alignment, leading to emails failing DMARC checks even when authentication passes. Close monitoring using a DMARC check tool allows for regular verification and ensures identifier alignment.

Insufficient Reporting and Response Plan

Overlooking DMARC aggregate and forensic reports can leave organizations unaware of fraudulent activities or compliance gaps. A robust compliance action plan should prioritize reviewing XML reports, investigating forensic reporting, and responding to message validation issues quickly.

Third-Party Senders and Policy Distribution

Many businesses rely on third-party platforms. Failure to coordinate policy distribution and ensure third-party authorization in SPF/DKIM records jeopardizes DMARC authentication across the full email ecosystem.

Subdomain Oversight

Not specifying a subdomain policy (sp tag) leaves subdomain emails vulnerable to impersonation attacks and reduces overall brand protection.

Ongoing DMARC Management: Reporting, Audits, and Maintaining Compliance

DMARC compliance is not a one-off project, but an ongoing commitment demanding continuous oversight.

Regular DMARC Record Audits

Routine DMARC lookup and validation—using a DMARC record checker—ensures no new misconfigurations creep in. As the sender or organizational structure changes, DNS records and txt record settings must be kept up-to-date and fully aligned with evolving dmarc policy targets.

Continuous Report Monitoring

Frequent review of dmarc aggregate reports and forensic reports is essential for proactive email security posture management. Monitoring the reporting interval and message disposition outcomes helps organizations identify new risks, track compliance progress, and refine their DMARC enforcement strategy.

Staying Informed on Standards

Staying current with updates to DMARC standards (such as RFC 9989, RFC 9990, and RFC 9991), and referencing leading resources on EasyDMARC, dmarc.org, and Wikipedia ensures that the organization’s dmarc compliance actions are in line with global best practices.

Internal Policy Enforcement and Brand Protection

Comprehensive DMARC deployment enforces effective sender verification, grants protection against spoofing, and assures customers and partners of the organization’s commitment to email security and brand protection. Ongoing training, regular audits, and automated record testing tools should form the backbone of a sustainable dmarc compliance action plan for every business.

A day later, Bitget gave its first account of how the break-in worked. On September 25, Chen said the attackers breached a core backend system behind Bitget’s wallet service. They used it to generate forged transfer requests and ran those requests through the exchange’s own approval-and-signing process, according to Bloomingbit and TechFlow.

She said Bitget has ruled out a private key leak, meaning the attackers did not steal the keys. Instead they got the system that holds those keys to sign transfers it should have rejected. How they first got into that backend is still under review.

Chen said the losses have been fully tallied and there is no further risk of funds leaving the platform. In a live Q&A covered by Cointelegraph, she listed the affected assets as ETH, XRP, USDT, USDC, AVAX, BNB and USDT0 on Arbitrum. The affected networks were Ethereum, the XRP Ledger, Avalanche, BNB Smart Chain and Arbitrum. She said withdrawals could reopen within hours or days. Deposits and trading were never halted.

Bitget’s figure is roughly double what outside researchers first spotted. Pseudonymous analyst DCF GOD, Bubblemaps and Arkham analyst Emmett Gallic flagged $174 million to $183 million moving from Bitget-labeled wallets to a freshly created address. Chen said those early estimates only captured the Ethereum side of the attack.

The on-chain trail shows an attacker in a hurry. A 0.84 ETH test transfer left a wallet labeled “Bitget 6” at 18:31:11 UTC, Forbes reported. It was followed by about $34.75 million in USDT, $19.67 million in USDT0, $12.85 million in USDC and 3,000 XAUT, Tether’s gold-backed token. Tether and Circle can freeze their tokens, so the attacker quickly swapped them into ether, which no issuer can freeze. DCF GOD noted the buyer was “paying up to +5% over spot” on Arbitrum. TechFlow later put the attacker’s holdings at roughly 68,500 ETH.

The same data complicates Bitget’s account of its response. Chen said emergency protocols kicked in immediately. But Forbes traced a final 223 ETH outflow at 21:23 UTC. That was nearly three hours after detection and seven minutes before Chen’s public notice went up.

Several of Bitget’s reassurances also rest on its own word for now. Some early on-chain reports described cold reserves among the drained wallets. Bitget says its offline cold storage was untouched, and that claim has not been independently verified. The protection fund launched in 2022 with a $300 million commitment and averaged $382 million in August, according to the company’s own reports cited by TheStreet. Outside auditors have not confirmed what the fund currently holds. Bitget’s token, BGB, fell as much as 5% as news spread.

Security specialists say this kind of breach rarely involves breaking cryptography. Ido Sofer, CEO of key management firm Sodot, described the pattern behind the Bybit theft and similar cases this way: “Those are off-chain hacks that led to on-chain loss of funds.” His examples included stolen developer credentials, deployment keys and API keys.

Chen, for her part, struck a defiant tone: “We will not run from this.”

What Bitget users should do

Bitget exchange customers don’t need to take action. The company says balances are accurate and withdrawals will resume after its security review. Users of Bitget Wallet, the company’s separate self-custody app, got different advice.

In a post on X, the Bitget Wallet account urged all users to temporarily revoke approvals granted to its smart contracts while it investigates. Approvals are standing permissions that let a contract move tokens from your wallet. The post did not say whether any wallet contracts were compromised. In the app, approvals can be reviewed and revoked under Wallet > More > Approvals.

Within hours of the theft, spoofed tokens named “ETH,” “USDC” and “USDT” began sending transfers from lookalike addresses that differ from the attacker’s only in the middle characters, Forbes reported. Addresses copied from a block explorer right now may be fakes. Treat any “recovery” or “verification” prompt tied to the incident as phishing.

The Bitget breach is the largest exchange loss since Bybit lost $1.4 billion in February 2025. It also tops the roughly $319 million drained from Blockstream’s Liquid Network Liquid Network, which TRM Labs had called 2026’s biggest hack until now.

Bitget has not attributed the attack, and no investigator has publicly tied it to a specific group. Chen said a full incident report with root-cause analysis and corrective actions would follow within 24 hours of her first notice.

The flaw was reported by Accomplish security researcher Oren Yomtov, which also affected Cloudflare Sandboxes.

According to Cloudflare’s disclosure, the company has “no evidence that customer data has been compromised.” Customers don’t need to take any action.

The problem traced back to a single configuration flag. Cloudflare Containers carves each container’s disk out of a shared storage pool using Linux’s dm-thin thin provisioning. Those pools were set to skip_block_zeroing, so storage freed by one customer’s deleted container went to the next customer without being wiped.

Yomtov’s proof of concept wrote tiny 4 KiB chunks into empty regions of a fresh container’s disk. Each write pulled in a recycled 64 KiB block but overwrote only a sliver of it. The other 60 KiB, along with whatever the previous tenant had stored there, stayed readable from the raw disk.

The researchers found residual data on 20 of the 22 servers they landed on, spread across four continents. According to the joint write-up, they recovered directory structures, database pages, and complete SQLite databases.

In its own post, Accomplish goes further, saying the exposed files included Chromium browser profiles, .env files, and credential files. Accomplish also says Cloudflare’s Browser Run service was affected.

An attacker couldn’t pick a victim or read a disk that was still in use, and leftover data wasn’t guaranteed to be there at all. Cloudflare says the researchers’ scripts only counted and format-checked what they found. It adds that the researchers submitted no customer content and have since deleted everything they recovered.

Cloudflare confirmed the issue about three hours after the report and shipped a fix that removed the flag the same evening. Turning the flag off only protected new allocations, though. Old data still sat in running container disks and cached image snapshots, so Cloudflare had to drain hosts, restart every virtual machine, and wipe its image caches. That cleanup didn’t finish until September 19, 15 days after the report was issued.

It built detection signatures from the attack’s telltale pattern of small writes followed by oversized reads and ran them against its retained disk-I/O logs. The only matches came from the researchers and Cloudflare’s own engineers. The company didn’t say how far back those logs go or how long the flag had been enabled in production. Yomtov received a bug bounty, but the amount wasn’t disclosed.

The Cloudflare bug is the sixth sandbox escape Accomplish has published since July. The earlier ones hit Claude Cowork (SharedRoot), Claude Code, Cursor CLI, Docker’s hypervisor, and OpenAI’s Codex sandbox. The firm’s takeaway is that isolation “can fail in many ways.”

Albanese, speaking in New York during the UN General Assembly, said he raised both the delay and the way the notification was sent with OpenAI CEO Sam Altman. The agent had been researching public medical spending when it got past the portal’s protections and “didn’t accept ‘no’ for an answer,” Albanese said. The government says there is no evidence that personal Medicare records were accessed, and no sign of a broader compromise of the Services Australia network.

OpenAI said the activity surfaced during a wider review of misaligned model behaviour, meaning cases where models act against their developers’ intent. The review found several Australian government websites that its models queried while answering questions about Australia in an internal evaluation. The company said its models “took actions we did not intend” and that the material accessed was aggregate health statistics and internal file names. OpenAI says it is giving technical details to the affected agencies.

Services Australia reported the incident to the Australian Signals Directorate’s (ASD) Australian Cyber Security Centre on 15 September. Three more sites may have been involved: the Australian Institute of Health and Welfare (AIHW), the NSW Bureau of Crime Statistics and Research (BOCSAR) and the Victorian Department of Health. Albanese said access to those three has not been confirmed. A taskforce led by the Department of the Prime Minister and Cabinet will review the incident with ASD and the AI Safety Institute.

Defence Minister Richard Marles said the data was of low sensitivity and sat on a site with lighter security than systems holding national security information. “This was really kept behind a fence that the AI agent effectively climbed over,” Marles told ABC Radio National, SBS reported.

What Public Scan Records Show

AI research lab Transluce reported this week that AI agents used urlquery.net as a remote browser to get around access blocks. The public service loads any submitted link in a sandboxed browser and publishes the result. Transluce says agents tried to hack public data providers on three occasions, including an Australian government website, and it directly links the AIHW activity to the agent swarm OpenAI has confirmed as its own. The lab describes those attempts as minor, involving a small number of probe payloads with no evidence of exploitation. It notes the agents were working on ordinary data-retrieval tasks, not security tests.

Cyber Kendra’s analysis of Transluce’s released dataset (version 5, dated 23 September 2026) puts numbers on that episode. Of the 4,844 urlquery.net reports the dataset ties to AIHW, all but one were logged between 17 and 21 June 2026 (UTC), a window that brackets the 18 June Medicare breach. Activity rose from 29 reports on 17 June to 766 on 18 June and peaked at 1,775 on 20 June. Transluce rates 373 of them “significant” because they carried task-specific code that fetched data or submitted forms automatically.

OpenAI has not explained why notifying Australia took three months, named the model involved, or said whether it reached the other three sites. Medicare card holders do not need to take any action as of 24 September 2026, and the government has described the taskforce review as urgent.

One AIHW report, logged at 06:46 UTC on 20 June, is flagged as a reflected-script probe: a test of whether a site will echo injected code back to a browser. The dataset notes that the flag does not mean any data was recovered. Two custom-code requests against NSW BOCSAR appear on 19 June. The dataset has no entries for Services Australia or the Medicare portal, and Transluce labels its entries as candidate evidence rather than confirmed attribution.

Separately, the ABC found archived posts on DseWiki, a German coding site that OpenAI previously confirmed its agents used to communicate. In those posts, more than a dozen agents mentioned AIHW over 300 times while hunting for government spending data on skin medicines across Victorian council areas. After Cloudflare’s bot protection blocked them, the agents traded workarounds including proxies, screenshot services and guessed file names. The DseWiki logs make no mention of Medicare or Services Australia, and neither OpenAI nor the government has said whether the two episodes are connected.

The Medicare disclosure follows the July incident in which OpenAI models running an internal cybersecurity evaluation escaped their sandbox and broke into Hugging Face’s production infrastructure. In that case, OpenAI took about ten days to confirm to Hugging Face that its models were responsible. Transluce says the urlquery.net records show agent activity going back to at least 6 March 2026.

The hackers told [404 Media] they used a zero-day in Oracle PeopleSoft on Monday night, moved into FBI-managed AWS GovCloud servers, and downloaded 2 to 3 TB of data. They also claim to have compromised FBI Criminal Justice, HR, and Medlink services.

ShinyHunters has previously exploited a PeopleSoft zero-day. According to Mandiant, the group exploited CVE-2026-35273 between May 27 and June 9, 2026, before Oracle published its advisory. The flaw carries a CVSS score of 9.8 and lets an unauthenticated attacker execute code over HTTP. It is unclear whether the FBI intrusion used the same bug or a new one.

To back its claim, the group defaced apply.fbijobs.gov with a banner announcing the site had been seized, mimicking the notices the FBI posts on criminal sites it takes down. The jobs site and the Special Agent Applicant Portal remain offline.

ShinyHunters gave 404 Media a sample, which it said covers 5,000 FBI employees, with names, home addresses, phone numbers, dates of birth, and, in some cases, spouse details. 404 Media matched some phone numbers to people of the same name, and some to Justice Department personnel. Reuters found matching details in at least 10 records, including those of FBI Director Kash Patel, but could not determine where the data originated.

The FBI said it is “aware of claims regarding unauthorized activity affecting FBIjobs.gov and is currently investigating.” The bureau has not confirmed a breach yet.

The group says the attack is not financially motivated. On its leak site, it gave the FBI one week to correct or remove a May FLASH report stating that ShinyHunters exaggerates its access, harasses victims’ families with threatening calls and texts, and sometimes carries out swatting. The group denies those claims and any affiliation with The Com.

ShinyHunters also told BleepingComputer it is exploiting the same alleged zero-day against other organizations, including Fortune 500 companies. Oracle advises PeopleSoft customers to apply its June 2026 Critical Security Patch Update, which covers CVE-2026-35273.