XCSSET v40: malware for macOS developers, delivered through compromised Xcode projects

Palo Alto Networks Unit 42 has documented a new variant of the XCSSET malware — version 40 — that targets macOS developers. The infection model is what makes it dangerous: it does not arrive by email or a website, but through compromised Xcode projects and GitHub repositories, and the trigger is a developer’s normal action — a build. Below: how it works and what to do.

In brief

• XCSSET v40 — a macOS malware active since at least 2021, resurfaced after months of inactivity. Documented by Palo Alto Networks Unit 42.
• Target: macOS developers using Xcode.
• Vector: compromised Xcode projects and GitHub repos with injected downloader scripts; the infection triggers on build and propagates to the other Xcode projects on the system.
• 17 modules: credential theft, keylogging, clipboard manipulation, browser hijacking, exfiltration.
• New in v40: a Chrome hijacker (via the Chrome DevTools Protocol), a Telegram trojanizer, and a fileless reverse shell.
• Attack waves: mid-April and early May 2026. Microsoft had warned since September 2025 about compromised projects.

How the attack works

A developer downloads an Xcode project or clones a GitHub repo that looks legitimate. Inside the project, downloader scripts are injected, hidden in the build phases. When the developer hits Build, the script runs with their privileges and pulls in the malware. From there, XCSSET propagates to the other Xcode projects on the same system — so a single poisoned project can contaminate everything you build afterwards.

Once installed, XCSSET has, in v40, 17 modules: credential theft, keystroke logging, clipboard manipulation, browser hijacking, and data exfiltration.

What is new in v40

• Chrome hijacker. It wraps the browser in a malicious launcher and enables the Chrome DevTools Protocol on a local port, through which it fetches attacker-controlled JavaScript. That lets it intercept web traffic, credentials, cookies and MetaMask transactions — with the ability to manipulate them.
• Telegram trojanizer. It replaces the legitimate Telegram app with a malicious version.
• Fileless reverse shell. It allows running commands on the system without writing a file to disk.

Why it is hard to catch

XCSSET v40 is built explicitly to evade detection and analysis:

• It recompiles. The loader is periodically recompiled on the C2 server, so its signature changes.
• Separate encryption keys for inbound and outbound communications.
• Obfuscation of function names, variables and strings, with build-unique ciphers.
• It disables Apple’s protections: it tries to turn off XProtect, MRT, TCC and Rapid Security Response, and terminates the CloudTelemetryService process.

The last point is useful defensively: an attempt to touch or disable these protections is, in itself, a compromise signal.

Our recommendations

If you have macOS development teams or use dependencies and projects from external sources, here is what directly reduces the risk:

• Development supply-chain hygiene. Do not build Xcode projects from sources you do not trust, and scan open-source dependencies before building. Same pattern as typosquatting in package registries: third-party code runs with your privileges. Part of the security audit.
• Endpoint hardening and monitoring. Alert on AppleScript activity, on unauthorized browser modifications, on suspicious defaults values, and on ad hoc-signed applications — plus on any attempt to touch XProtect/MRT/TCC. Monitoring and periodic review catch exactly this kind of behavior.
• Test the real surface. A security test checks what an attacker can inject into your build flow and how exposed the chain is, from clone to artifact.

Want to check how exposed your development pipeline is? Get in touch and we start with an audit.