Threat actors have been exploiting a zero-day vulnerability in legacy Sitecore deployments to deploy WeepSteel reconnaissance malware.

The flaw, tracked under CVE-2025-53690, is a ViewState deserialization vulnerability caused by the inclusion of a sample ASP.NET machine key in pre-2017 Sitecore guides.

Some customers reused this key in production, allowing attackers with knowledge of the key to craft valid, but malicious ‘_VIEWSTATE’ payloads that tricked the server into deserializing and executing them, leading to remote code execution (RCE).

The flaw isn’t a bug in ASP.NET itself, but a misconfiguration vulnerability created by reusing publicly documented keys that were never meant for production.

Exploitation activity

Mandiant researchers, who discovered the malicious activity in the wild, report that threat actors have been leveraging the flaw in multi-stage attacks.

The attackers target the ‘/sitecore/blocked. aspx’ endpoint, which contains an unauthenticated ViewState field, and achieve RCE under the IIS NETWORK SERVICE account by leveraging CVE-2025-53690.

The malicious payload they drop is WeepSteel, a reconnaissance backdoor that gathers system, process, disk, and network information, disguising its exfiltration as standard ViewState responses.

Mandiant observed the execution of reconnaissance commands on compromised environments, including whoami, hostname, tasklist, ipconfig /all, and netstat -ano.

In the next stage of the attack, the hackers deployed Earthworm (a network tunneling and reverse SOCKS proxy), Dwagent (a remote access tool), and 7-Zip, which is used to create archives of the stolen data.

Subsequently, they escalated their privileges by creating local administrator accounts (‘asp$,’ ‘sawadmin’), cached (SAM and SYSTEM hives) credentials dumping, and attempted token impersonating via GoTokenTheft.

Persistence was secured by disabling password expiration for these accounts, giving them RDP access, and registering Dwagent as a SYSTEM service.

Mitigating CVE-2025-53690

CVE-2025-53690 impacts Sitecore Experience Manager (XM), Experience Platform (XP), Experience Commerce (XC), and Managed Cloud, up to version 9.0, when deployed using the sample ASP.NET machine key included in pre-2017 documentation.

XM Cloud, Content Hub, CDP, Personalize, OrderCloud, Storefront, Send, Discover, Search, and Commerce Server are not impacted.

Sitecore published a security bulletin in coordination with Mandiant’s report, warning that multi-instance deployments with static machine keys are also at risk.

The recommended actions for potentially impacted administrators are to immediately replace all static values in web.config with new, unique keys, and ensure the element inside web.config is encrypted.

In general, it is recommended to adopt regular static machine key rotation as an ongoing security measure.

More information on how to protect ASP.NET machine keys from unauthorized access can be found here.

Apple released iOS 18.6.2 and iPadOS 18.6.2 on Aug. 20, 2025, along with macOS Sequoia 15.6.1, Sonoma 14.7.8, and Ventura 13.7.8, to fix a zero-day in the ImageIO framework that was exploited in the wild.

Per Apple, processing a malicious image could corrupt memory, enabling code execution, and the company is aware of a report of use in an extremely sophisticated attack targeting specific individuals.

The flaw sits in ImageIO, the component that parses common image formats, which makes delivery via everyday channels, including messaging apps and web content, straightforward from an attacker’s perspective. As security outlets reported, the bug is tracked as CVE-2025-43300 and stems from an out-of-bounds write that Apple addressed with improved bounds checking.

The crypto angle is direct. Wallet owners often copy and paste recipient addresses, and many keep recovery phrases in screenshots or photo storage for convenience. Research this year documented families of mobile spyware and stealers that scan galleries using optical character recognition and exfiltrate images with seed phrases, as well as strains that monitor the clipboard to swap addresses during a transaction.

As Kaspersky reported, SparkCat and its successor SparkKitty used OCR to harvest seed phrases from photos on both iOS and Android, including samples observed on official app stores.

A compromise achieved through a booby-trapped image can, therefore, act as an initial foothold to enable gallery scraping for recovery phrases, surveillance of crypto app activity, and clipboard hijacking during on-chain transfers. Previous research on clipboard hijackers explains how address strings are silently replaced to redirect funds during copy-paste, a tactic long used by drainer operations.

The current incident also fits a pattern of high-value iOS exploit chains used against targeted users. In 2023, Citizen Lab documented a zero-click chain, dubbed Blastpass, used to deliver commercial spyware, demonstrating how image and message parsing bugs can be linked for device takeover without user interaction.

That historical baseline, coupled with Apple’s acknowledgment of real-world use in the present case, frames the risk for crypto users who rely on mobile devices as primary signing endpoints.

Impact spans recent iPhone models and iPads covered by iOS 18 and iPadOS 18, including iPhone XS and later, plus supported Macs on Sequoia, Sonoma, and Ventura. Users can verify protection by confirming iOS or iPadOS 18.6.2, macOS Sequoia 15.6.1, Sonoma 14.7.8, or Ventura 13.7.8 in Settings, then rebooting after installation.

Security outlets urged immediate updates following Apple’s release and disclosure.

For a crypto-savvy audience, the operational takeaway is to close exposure by updating and to reduce post-exploit blast radius by moving seed storage off photo libraries, reviewing app photo permissions, limiting clipboard access, and treating mobile wallets as hot environments with strict hygiene.

Apple’s notes state the root cause was an out-of-bounds write in ImageIO that is now mitigated with stricter bounds checks, and the company confirmed exploitation reports when shipping the patch.

Mentioned in this article

A massive spike in brute-force attacks targeted Fortinet SSL VPNs earlier this month, followed by a switch to FortiManager, marked a deliberate shift in targeting that has historically preceded new vulnerability disclosures.

The campaign, detected by threat monitoring platform GreyNoise, manifested in two waves, on August 3 and August 5, with the second wave pivoting to FortiManager targeting with a different TCP signature.

As GreyNoise previously reported, such spikes in deliberate scanning and brute-forcing precede the disclosure of new security vulnerabilities 80% of the time.

Often, such scans aim at enumerating exposed endpoints, evaluating their significance, and estimating their exploitation potential, with actual attack waves following shortly after.

“New research shows spikes like this often precede the disclosure of new vulnerabilities affecting the same vendor — most within six weeks,” warned GreyNoise.

“In fact, GreyNoise found that spikes in activity triggering this exact tag are significantly correlated with future disclosed vulnerabilities in Fortinet products.”

Due to this, defenders shouldn’t dismiss those spikes in activity as failed attempts to exploit old, patched flaws, but rather treat them as potential precursors to zero-day disclosure and strengthen security measures to block them.

The Fortinet brute-force attacks

On August 3, 2025, GreyNoise recorded a spike in brute-forcing attempts targeting Fortinet SSL VPN as part of a steady activity it has been monitoring since earlier.

JA4+ fingerprint analysis, a network fingerprinting method for identifying and classifying encrypted traffic, linked the spike to June activity originating from a FortiGate device on a residential IP address associated with Pilot Fiber Inc.

“This overlap doesn’t confirm attribution, but it suggests possible reuse of tooling or network environments,” commented GreyNoise in its bulletin.

Two days later, on August 5, a new brute-force campaign from the same attacker emerged, which switched targeting from FortiOS SSL VPN endpoints to FortiManager’s FGFM service.

“While the August 3 traffic has targeted the FortiOS profile, traffic fingerprinted with TCP and client signatures — a meta signature — from August 5 onward was not hitting FortiOS,” explained GreyNoise.

“Instead, it was consistently targeting our FortiManager – FGFM profile albeit still triggering our Fortinet SSL VPN Bruteforcer tag.”

This shift suggested that either the same attackers or the same toolset/infrastructure moved from trying to brute-force VPN logins to trying to brute-force FortiManager access.

The IP addresses associated with this activity, and which should be placed on blocklists, are:

• 31.206.51.194
• 23.120.100.230
• 96.67.212.83
• 104.129.137.162
• 118.97.151.34
• 180.254.147.16
• 20.207.197.237
• 180.254.155.227
• 185.77.225.174
• 45.227.254.113

GreyNoise notes that the tracked malicious activity is evolving with time and is associated with a specific origin cluster that most likely performs adaptive testing.

In general, this activity is unlikely to be researcher scans, which are typically broader in scope and limited in rate, and wouldn’t involve credential brute-forcing, which is seen as an apparent intrusion attempt.

Hence, defenders should block the listed IPs, increase login protection on Fortinet devices, and harden external access where possible, restricting access only to trusted IP ranges and VPNs.

CrushFTP is warning that threat actors are actively exploiting a zero-day vulnerability tracked as CVE-2025-54309, which allows attackers to gain administrative access via the web interface on vulnerable servers.

CrushFTP is an enterprise file transfer server used by organizations to securely share and manage files over FTP, SFTP, HTTP/S, and other protocols.

According to CrushFTP, threat actors were first detected exploiting the vulnerability on July 18th at 9AM CST, though it may have begun in the early hours of the previous day.

CrushFTP CEO Ben Spink told BleepingComputer that they had previously fixed a vulnerability related to AS2 in HTTP(S) that inadvertantly blocked this zero-day flaw as well.

“A prior fix by chance happened to block this vulnerability too, but the prior fix was targeting a different issue and turning off some rarely used feature by default,” Spink told BleepingComputer.

CrushFTP says it believes threat actors reverse engineered their software and discovered this new bug and had begun exploiting it on devices that are not up-to-date on their patches.

“We believe this bug was in builds prior to July 1st time period roughly…the latest versions of CrushFTP already have the issue patched,” reads CrushFTP’s advisory.

“The attack vector was HTTP(S) for how they could exploit the server. We had fixed a different issue related to AS2 in HTTP(S) not realizing that prior bug could be used like this exploit was. Hackers apparently saw our code change, and figured out a way to exploit the prior bug.

“As always we recommend regularly and frequent patching. Anyone who had kept up to date was spared from this exploit.”

The attack occurs via the software’s web interface in versions prior to CrushFTP v10.8.5 and CrushFTP v11.3.4_23. It is unclear when these versions were released, but CrushFTP says around July 1st.

CrushFTP stresses that systems that have been kept up to date are not vulnerable.

Enterprise customers using a DMZ CrushFTP instance to isolate their main server are not believed to be affected by this vulnerability.

Administrators who believe their systems were compromised are advised to restore the default user configuration from a backup dated before July 16th. Indicators of compromise include:

• Unexpected entries in MainUsers/default/user.XML, especially recent modifications or a last_logins field
• New, unrecognized admin-level usernames such as 7a0d26089ac528941bf8cb998d97f408m.

Spink says that they are most commonly seeing the default user modified as the main IOC.

“In general we have seen the default user modified as the main IOC. In general, modified in very invalid ways that were still useable for the attacker but no one else,” Spink told BleepingComputer.

CrushFTP recommends reviewing the upload and download logs for unusual activity and taking the following steps to mitigate exploitation:

• IP whitelisting for server and admin access
• Use of a DMZ instance
• Enabling automatic updates

However, cybersecurity firm Rapid7 says using a DMZ may not be a reliable strategy to prevent exploitation.

“Out of an abundance of caution, Rapid7 advises against relying on a demilitarized zone (DMZ) as a mitigation strategy,” warned Rapid7.

At this time, it is unclear if the attacks were used for data theft or to deploy malware. However, managed file transfer solutions have become high-value targets for data theft campaigns in recent years.

In the past, ransomware gangs, usually Clop, have repeatedly exploited zero-day vulnerabilities in similar platforms, including Cleo, MOVEit Transfer, GoAnywhere MFT, and Accellion FTA, to conduct mass data theft and extortion attacks.

VMware fixed four vulnerabilities in VMware ESXi, Workstation, Fusion, and Tools that were exploited as zero-days during the Pwn2Own Berlin 2025 hacking contest in May 2025.

Three of the patched flaws have a severity rating of 9.3, as they allow programs running in a guest virtual machine to execute commands on the host. These flaws are tracked as CVE-2025-41236, CVE-2025-41237, and CVE-2025-41238.

These flaws are described in the security advisory as:

• CVE-2025-41236: VMware ESXi, Workstation, and Fusion contain an integer-overflow vulnerability in the VMXNET3 virtual network adapter. Nguyen Hoang Thach of STARLabs SG used this flaw at Pwn2Own.
• CVE-2025-41237: VMware ESXi, Workstation, and Fusion contain an integer-underflow in VMCI (Virtual Machine Communication Interface) that leads to an out-of-bounds write. This flaw was used by Corentin BAYET of REverse Tactics at Pwn2Own.
• CVE-2025-41238: VMware ESXi, Workstation, and Fusion contain a heap-overflow vulnerability in the PVSCSI (Paravirtualized SCSI) controller that leads to an out of-bounds write. A malicious actor with local administrative privileges on a virtual machine may exploit this issue to execute code as the virtual machine’s VMX process running on the host. Thomas Bouzerar and Etienne Helluy-Lafont of Synacktiv at Pwn2Own used this flaw.

The fourth flaw, tracked as CVE-2025-41239, received a 7.1 rating as it is an information disclosure. It was also discovered by Corentin BAYET of REverse Tactics, who chained with CVE-2025-41237 during the hacking contest.

VMware has not provided any workarounds, and the only way to fix these vulnerabilities is to install the new versions of the software.

It should be noted that CVE-2025-41239 impacts VMware Tools for Windows, which requires a different upgrade process.

These vulnerabilities were demonstrated as zero-days during the Pwn2Own Berlin 2025 hacking contest, where security researchers collected $1,078,750 after exploiting 29 zero-day vulnerabilities.

Google has released an emergency security update to fix the third Chrome zero-day vulnerability exploited in attacks since the start of the year.

“Google is aware that an exploit for CVE-2025-5419 exists in the wild,” the company warned in a security advisory published on Monday.

This high-severity vulnerability is caused by an out-of-bounds read and write weakness in Chrome’s V8 JavaScript engine, reported one week ago by Clement Lecigne and Benoît Sevens of Google’s Threat Analysis Group.

Google says the issue was mitigated one day later by a configuration change the company pushed to the Stable channel across all Chrome platforms.

On Monday, it also fixed the zero-day with the release of 137.0.7151.68/.69 for Windows/Mac and 137.0.7151.68 for Linux, versions that are rolling out to users in the Stable Desktop channel over the coming weeks.

While Chrome will automatically update when new security patches are available, users can speed up the process by going to the Chrome menu > Help > About Google Chrome, letting the update finish, and clicking the ‘Relaunch’ button to install it immediately.

​While Google has already confirmed that CVE-2025-5419 is being exploited in the wild, the company will not share additional information regarding these attacks until more users have patched their browsers.

“Access to bug details and links may be kept restricted until a majority of users are updated with a fix,” Google said. “We will also retain restrictions if the bug exists in a third party library that other projects similarly depend on, but haven’t yet fixed.”

This is Google’s third Chrome zero-day vulnerability since the start of the year, with two more patched in March and May.

The first, a high-severity sandbox escape flaw (CVE-2025-2783) discovered by Kaspersky’s Boris Larin and Igor Kuznetsov, was used to deploy malware in espionage attacks targeting Russian government organizations and media outlets.

The company released another set of emergency security updates in May to patch a Chrome zero-day that could let attackers take over accounts following successful exploitation.

Last year, Google patched 10 zero-days that were either demoed during the Pwn2Own hacking competition or exploited in attacks.

SAP has released patches to address a second vulnerability exploited in recent attacks targeting SAP NetWeaver servers as a zero-day.

The company issued security updates for this security flaw (CVE-2025-42999) on Monday, May 12, saying it was discovered while investigating zero-day attacks involving another unauthenticated file upload flaw (tracked as CVE-2025-31324) in SAP NetWeaver Visual Composer that was fixed in April.

“SAP is aware of and has been addressing vulnerabilities in SAP NETWEAVER Visual Composer,” a SAP spokesperson told BleepingComputer. “We ask all customers using SAP NETWEAVER to install these patches to protect themselves. The Security Notes can be found here: 3594142 & 3604119.”

ReliaQuest first detected the attacks exploiting CVE-2025-31324 as a zero-day in April, reporting that threat actors were uploading JSP web shells to public directories and the Brute Ratel red team tool after breaching customers’ systems through unauthorized file uploads on SAP NetWeaver. The hacked instances were fully patched, indicating the attackers used a zero-day exploit.

This malicious activity was also confirmed by cybersecurity firms watchTowr and Onapsis, who also observed the attackers uploading web shell backdoors on unpatched instances exposed online. Forescout’s Vedere Labs has linked some of these attacks to a Chinese threat actor it tracks as Chaya_004.

Onyphe CTO Patrice Auffret told BleepingComputer in late April that “Something like 20 Fortune 500/Global 500 companies are vulnerable, and many of them are compromised,” adding that there were 1,284 vulnerable instances exposed online at the time, 474 already compromised.

The Shadowserver Foundation is now tracking over 2040 SAP Netweaver servers exposed on the Internet and vulnerable to attacks.

New flaw also exploited in zero-day attacks

While SAP did not confirm that CVE-2025-42999 was exploited in the wild, Onapsis CTO Juan Pablo Perez-Etchegoyen told BleepingComputer that the threat actors were chaining both vulnerabilities in attacks since January.

“The attacks we observed during March 2025 (that started with basic proves back in January 2025) are actually abusing both, the lack of authentication (CVE-2025-31324) as well as the insecure de-serialization (CVE-2025-42999),” Perez-Etchegoyen told BleepingComputer.

“This combination allowed attackers to execute arbitrary commands remotely and without any type of privileges on the system. This residual risk is basically a de-serialization vulnerability only exploitable by users with VisualComposerUser role on the SAP target system.”

SAP admins are advised to immediately patch their NetWeaver instances and consider disabling the Visual Composer service if possible, as well as restrict access to metadata uploader services and monitor for suspicious activity on their servers.

Since the attacks started, CISA has added the CVE-2025-31324 flaw to its Known Exploited Vulnerabilities Catalog, ordering federal agencies to secure their systems by May 20, as mandated by Binding Operational Directive (BOD) 22-01.

“These types of vulnerabilities are frequent attack vectors for malicious cyber actors and pose significant risks to the federal enterprise,” CISA warned.

SAP has released out-of-band emergency NetWeaver updates to fix a suspected remote code execution (RCE) zero-day flaw actively exploited to hijack servers.

The vulnerability, tracked under CVE-2025-31324 and rated critical (CVSS v3 score: 10.0), is an unauthenticated file upload vulnerability in SAP NetWeaver Visual Composer, specifically the Metadata Uploader component.

It allows attackers to upload malicious executable files without needing to log in, potentially leading to remote code execution and full system compromise.

Though the vendor’s bulletin isn’t public, ReliaQuest reported earlier this week about an actively exploited vulnerability on SAP NetWeaver Visual Composer, specifically the ‘/developmentserver/metadatauploader’ endpoint, which aligns with CVE-2025-31324.

ReliaQuest reported that multiple customers were compromised via unauthorized file uploads on SAP NetWeaver, with the attackers uploading JSP webshells to publicly accessible directories.

These uploads enabled remote code execution via simple GET requests to the JSP files, allowing command execution from the browser, file management actions (upload/download), and more.

In the post-exploitation phase, the attackers deployed the ‘Brute Ratel’ red team tool, the ‘Heaven’s Gate’ security bypassing technique, and injected MSBuild-compiled code into dllhost.exe for stealth.

ReliaQuest noted in the report that exploitation did not require authentication and that the compromised systems were fully patched, indicating that they were targeted by a zero-day exploit.

Security firm watchTowr also confirmed to BleepingComputer they are seeing active exploitation linked to CVE-2025-31324.

“Unauthenticated attackers can abuse built-in functionality to upload arbitrary files to an SAP NetWeaver instance, which means full Remote Code Execution and total system compromise,” stated watchTowr CEO Benjamin Harris.

“watchTowr is seeing active exploitation by threat actors, who are using this vulnerability to drop web shell backdoors onto exposed systems and gain further access.”

“This active in-the-wild exploitation and widespread impact makes it incredibly likely that we’ll soon see prolific exploitation by multiple parties.”

BleepingComputer contacted SAP with questions about the active exploitation but has not received a response at this time.

Protect against attacks now

The vulnerability impacts the Visual Composer Framework 7.50 and the recommended action is to apply the latest patch.

This emergency security update was made available after SAP’s regular ‘April 2025’ update, so if you applied that update earlier this month (released on April 8, 2025), you’re still vulnerable to CVE-2025-31324.

Moreover, the emergency update includes fixes for two more critical vulnerabilities, namely CVE-2025-27429 (code injection in SAP S/4HANA) and CVE-2025-31330 (code injection in SAP Landscape Transformation).

Those unable to apply the updates that address CVE-2025-31324 are recommended to perform the following mitigations:

1. Restrict access to the /developmentserver/metadatauploader endpoint.
2. If Visual Composer is not in use, consider turning it off entirely.
3. Forward logs to SIEM and scan for unauthorized files in the servlet path.

ReliaQuest recommends performing a deep environment scan to locate and delete suspect files before applying the mitigations.