Microsoft’s August Patch Tuesday fixes about 400 security flaws, including an actively exploited Windows zero-day and multiple 9.8-rated RCE bugs.

The post Microsoft’s August Patch Tuesday: 400+ Bugs Fixed, One Zero-Day Already Under Attack appeared first on TechRepublic.

Microsoft fixed a record 570 security flaws in July 2026 Patch Tuesday, including three zero-days and two exploited bugs.

The post Microsoft Fixes Record 570 Security Flaws in Biggest Patch Tuesday Ever appeared first on TechRepublic.

Google’s Chrome 149 security update fixes 18 bugs, including four critical flaws affecting WebGL, Autofill, and Blink components.

The post Update Chrome Now: Google Fixes 18 Security Flaws, Including Critical Bugs appeared first on TechRepublic.

Oracle issued emergency guidance for CVE-2026-35273, a critical PeopleSoft flaw exploited in a ShinyHunters-linked campaign targeting universities.

The post Oracle Warns PeopleSoft Customers After Critical Zero-Day Exploited appeared first on TechRepublic.

A new Windows zero-day reportedly bypasses BitLocker, adding pressure on Microsoft as researchers debate the exploit’s real-world impact.

The post New Windows Zero-Day Claims BitLocker Bypass Amid Microsoft Disclosure Fight appeared first on TechRepublic.

Mitigation Steps

• Deploy June 2026 cumulative updates (KB5094126 for Windows 11, KB5094127 for Windows 10) without delay.
• Prioritise CVE-2026-45657 patching on all internet-accessible Windows systems.
• Apply the IIS/HTTP.sys patch for CVE-2026-49160 on all public-facing web servers.
• Audit BitLocker-protected device inventory and apply CVE-2026-50507 patches before deploying new field hardware.
• Review CTFMON and SYSTEM privilege escalation detections in endpoint security tooling.
• Use the Microsoft Security Update Guide (msrc.microsoft.com) to filter by CVSS >= 9.0 for prioritisation.
• Validate patch deployment through automated compliance reporting within 72 hours.

Google has released its June 2026 Android security update, addressing 124 vulnerabilities, including one actively exploited zero-day. The zero-day — CVE-2025-48595 — is an integer overflow vulnerability in the Android Framework that allows local attackers to escalate privileges on affected devices without requiring user interaction. CVE-2025-48595 is classified as a high-severity integer overflow (CWE-190) in the Android Framework — the set of APIs and system services that applications interact with directly. An integer overflow occurs when an arithmetic operation produces a value that exceeds the maximum size of the data type used to store it, causing the value to wrap around or produce unexpected behaviour that attackers can exploit to gain elevated access.

CVE-2025-48595: The Zero-Day Under Fire

The vulnerability enables a local attacker with basic application permissions to escalate privileges and execute code at a higher permission level, potentially gaining full control of device functions. Crucially, exploitation requires no user interaction beyond running a malicious application on the device. This marks the fourth Android zero-day patched since December 2025. Google noted that CVE-2025-48595 "may be under limited, targeted exploitation" — language the company uses when targeted attacks have been confirmed, but widespread in-the-wild exploitation has not yet been observed. This pattern is frequently associated with commercial spyware vendors or nation-state threat actors targeting high-profile individuals such as journalists, activists, or government officials.

Scope of the June 2026 Update

The June 2026 Android security update is substantial, fixing 124 vulnerabilities across two patch levels. Patch level 2026-06-01 addresses core Android OS components, including the Framework and System, with 18 vulnerabilities rated critical. **Patch level 2026-06-05** includes all fixes from 2026-06-01 plus additional patches for kernel subcomponents and third-party chipset drivers from manufacturers such as Qualcomm and MediaTek. Affected Android versions include Android 14, 15, 16, and Android 16 QPR2. Pixel devices receive updates immediately through Google's update delivery system, while devices from Samsung, OnePlus, Xiaomi, and other manufacturers will receive updates on a rolling timeline that may extend weeks or months after Google's release.

CVSS and Technical Details

• CVE: CVE-2025-48595
• CWE: CWE-190 (Integer Overflow or Wraparound)
• Severity: High
• KEV Status: Not confirmed, added to CISA KEV catalogue as of June 3, 2026
• Affected Versions: Android 14, Android 15, Android 16, Android 16 QPR2

Why It Matters

The pattern of four Android zero-days in under six months reflects an active market for Android exploits among sophisticated threat actors. While Google's characterisation of "limited, targeted exploitation" suggests this is not yet a mass exploitation scenario, targeted use by spyware operators or nation-state actors presents significant risk for high-value individuals and organisations. Mobile devices increasingly serve as primary work devices, accessing corporate email, VPN, and sensitive business applications. A privilege escalation vulnerability on a corporate-enrolled Android device could allow an attacker to capture credentials, intercept MFA codes, access enterprise apps, and exfiltrate sensitive data — all from a device users typically trust implicitly. The trajectory of Android zero-days in 2026 suggests that mobile endpoints are receiving increased attention from sophisticated threat actors," said a threat intelligence analyst. "Organisations with mobile device management (MDM) programmes should treat Android OS updates with the same urgency as Windows Patch Tuesday releases."

Mitigation Steps

• Apply the June 2026 Android security update immediately on all managed Android devices via your MDM or enterprise mobility management (EMM) platform.
• For Pixel devices, install the update via Settings > System > Software update.
• Contact device manufacturers for updated timelines if using non-Pixel Android devices.
• Implement mobile application management (MAM) policies that block installation of applications from unverified sources.
• Enable Google Play Protect scanning on all managed Android devices.
• Restrict sensitive corporate applications to devices meeting a minimum patch level of 2026-06-05 through MDM policy enforcement.
• Monitor for unusual privilege escalation events in your mobile device management console.

Google's June 2026 Android update demonstrates that mobile patch management is now an essential component of enterprise security hygiene, not an optional maintenance activity.

The Litecoin network faced a security breach when a zero-day vulnerability triggered a 13-block reorganization, impacting several major mining pools. This disruption led to a temporary halt in transaction finality, drawing attention to the potential risks within the Litecoin ecosystem. The Litecoin team quickly confirmed the bug on their official X account and assured the community that a patch had been fully deployed to resolve the issue. 

The Zero-Day Bug and Its Impact on the Litecoin Network 

A zero-day vulnerability refers to a flaw that is unknown to the developers at the time of its exploitation. In this case, the bug targeted the handling of MimbleWimble Extension Block (MWEB) transactions, a privacy feature on the Litecoin network. The vulnerability allowed an attacker to exploit the network by triggering a Denial-of-Service (DoS) attack, flooding the network with invalid MWEB transactions. MWEB transactions are designed to offer enhanced privacy for Litecoin users by obscuring transaction details. However, due to the zero-day bug, some Litecoin nodes that had not updated their software accepted invalid MWEB transactions, violating the network’s consensus rules. As a result, a block reorganization (or “reorg”) took place when a competing chain of blocks replaced the existing chain, causing 13 blocks to be reorganized. A block reorg of this magnitude is a rare event and presents significant challenges, including the potential for double-spending and undermined user confidence.

Understanding the Denial-of-Service Attack and Its Impact on Miners 

The core target of the attack was the mining pools, which play a critical role in securing the Litecoin network. Mining pools are groups of miners who pool their computational power to increase their chances of successfully finding a block. By launching a DoS attack, the attacker aimed to disrupt the mining process by overwhelming the network with invalid transactions. The impact on miners was particularly severe. Mining pools that failed to update their nodes were unable to process valid blocks during the attack. This resulted in temporary downtime for these pools, contributing to a short-term drop in the network’s hashrate. While the Litecoin network quickly recovered, the event highlighted the vulnerability of mining operations when software updates are delayed or ignored.

Quick Response and Deployment of the Patch 

Despite the severity of the incident, the Litecoin team responded promptly. Within hours, the development team confirmed the bug and rolled out a patch that effectively closed the attack vector. The patch prevented nodes from accepting invalid MWEB transactions, thus stabilizing the network and mitigating further risks. The team urged all node operators to update their software immediately to ensure the security of their operations. Importantly, the Litecoin team confirmed that no funds were lost as a result of the reorganization. While users’ transactions that were part of the reorganized blocks were reversed, the overall integrity of the network remained intact. The incident, although disruptive, demonstrated the resilience and quick action of the Litecoin team.

The Role of MWEB and Zero-Day Bugs 

Launched in 2011, Litecoin has earned a reputation as one of the oldest and most stable cryptocurrencies. As a fork of Bitcoin, it relies on a proof-of-work consensus mechanism to validate transactions. Over the years, Litecoin has faced relatively few security incidents, but the April 25 event serves as a stark reminder that even established networks are susceptible to vulnerabilities.  The introduction of MWEB in 2022 marked a significant upgrade for Litecoin, providing users with enhanced privacy features. However, as seen with this recent zero-day vulnerability, new features can also introduce unforeseen risks. 

On March 31, 2026, a North Korean state actor hijacked the npm credentials of the primary Axios maintainer and published two backdoored releases that deployed a cross-platform remote access trojan (RAT) to Windows, macOS, and Linux systems. Axios is the most widely used HTTP client in the JavaScript ecosystem, with approximately 100 million weekly downloads and a presence in roughly 80% of cloud and code environments. The malicious versions were live for approximately three hours. An estimated 600,000 downloads occurred during that window with no user interaction required beyond a routine npm install.

SentinelOne protects against this attack, demonstrating why autonomous, layered defense at machine speed is not optional when adversaries operate at this velocity. In this attack, the first infection was observed 89 seconds after publication. At that pace, manual workflows do not have a response window. They have a spectator seat.

For SentinelOne’s customers and partners, here’s a quick overview of the compromise, SentinelOne’s response, and steps you can take to further protect your environment.

What Happened: The Anatomy of a State-Level Supply Chain Weapon

The attacker, tracked as UNC1069 by Google Threat Intelligence and Sapphire Sleet by Microsoft, compromised maintainer credentials and published axios@1.14.1 (tagged “latest”) and axios@0.30.4 (tagged “legacy”). Each version introduced a single new dependency: plain-crypto-js@4.2.1, a purpose-built trojan. The malicious package’s postinstall hook silently deployed a cross-platform RAT communicating over HTTP to C2 infrastructure at sfrclak[.]com (142.11.206[.]73), commonly being referred to as WAVESHAPER.V2.

The operational sophistication was striking. The attacker pre-staged a clean version of plain-crypto-js 18 hours before detonation to evade novelty-based detection. Publication occurred just after midnight UTC on a Sunday to maximize the response window. The malware self-deleted after execution, swapping its malicious package.json for a clean stub, leaving forensic evidence only in lockfiles and audit logs.

Most critically, Axios had adopted OIDC Trusted Publishing, the post-Shai-Hulud hardening measure npm promoted as the solution to credential-based attacks. But the OIDC configuration coexisted with a long-lived npm access token. npm’s authentication logic prioritizes environment variable tokens over OIDC when both are present. The attacker stole the legacy token and bypassed every modern control the project had in place.

The issue is architectural: security controls that coexist with the mechanisms they are meant to replace provide a false sense of protection. Axios had Trusted Publishing, SLSA provenance, and GitHub Actions workflows. None of it mattered because the old key was still under the mat.

How SentinelOne Is Protecting Customers

Behavioral Detection via the Lunar Engine

SentinelOne’s Lunar behavioral engine detects the renamed binary execution technique central to the Windows attack chain, in which PowerShell is copied to %PROGRAMDATA%\wt.exe and executed under a disguised process. The RenamedBinExecution logic catches this behavior regardless of the specific payload hash, providing durable detection against variants.

Global Hash Blocklist

All known stage payloads, malicious npm package tarballs, and RAT binaries across Windows, macOS, and Linux have been added to the SentinelOne Cloud blocklist with a globally blocked reputation status. This provides immediate protection for all customers with cloud-connected agents.

Wayfinder Threat Hunting

The Wayfinder Threat Hunting team executed proactive hunts across all MDR regions and operating systems using Axios-specific IOCs, including DNS queries to sfrclak[.]com, file artifacts (com.apple.act.mond, /tmp/ld.py, wt.exe), and consolidated hash sets. All true positive findings generate console alerts, with MDR customers receiving direct analyst engagement and escalation.

Sustained Research on This Threat Actor

SentinelLABS has tracked BlueNoroff, the DPRK-linked threat cluster with significant overlap to UNC1069, across multiple campaigns targeting macOS and credential theft operations. The WAVESHAPER.V2 macOS binary recovered from the Axios compromise carries the internal project name “macWebT,” a direct lineage marker to BlueNoroff’s documented webT module. SentinelLABS published detailed analysis of this tooling family in 2023 when RustBucket first emerged as a macOS-targeted campaign, and again in 2024 when BlueNoroff shifted to fake cryptocurrency news as a delivery mechanism with novel persistence techniques.

• BlueNoroff: How DPRK’s macOS RustBucket Seeks to Evade Analysis and Detection
• BlueNoroff Hidden Risk: Threat Actor Targets Macs with Fake Crypto News and Novel Persistence

The initial access vector matters here, too. In March 2026, Google Threat Intelligence reported that UNC1069 leverages ClickFix, a social engineering technique that weaponizes user verification fatigue, as an initial access vector for credential harvesting. SentinelLABS had already published a detailed analysis of ClickFix techniques and their use in delivering RATs and infostealers before Google’s attribution dropped.

• How ClickFix Is Weaponizing Verification Fatigue to Deliver RATs and Infostealers

The behavioral detections that caught the Axios compromise were built on this accumulated intelligence, not written after the fact.

Live Security Updates (LSU)

Customers with LSU enabled receive real-time detection updates without waiting for agent releases, ensuring coverage evolves as fast as the threat intelligence does. This is critical for rapidly evolving supply chain campaigns where new IOCs emerge hourly.

What You Should Do Now

Supply chain compromise exploits the inherent trust enterprises place in their software delivery infrastructure. When that trust is weaponized by a state-level actor, the response must be both immediate and structural.

1. Audit and contain. Search all environments for axios@1.14.1 and axios@0.30.4. Treat any system that installed either version during the exposure window as fully compromised. Rebuild from known-good images rather than attempting in-place cleanup.
2. Rotate every credential the endpoint could reach. npm tokens, SSH keys, CI/CD secrets, cloud provider keys, and API tokens accessible from impacted systems must be rotated immediately. The RAT was designed to harvest exactly these credential types.
3. Pin dependencies and enforce lockfiles. Use npm ci (not npm install) in all CI/CD pipelines. Commit and audit lockfiles. Organizations using strict lockfile discipline were protected even during the three-hour exposure window. This is the single most actionable control.
4. Eliminate legacy npm tokens. Inventory all long-lived tokens across the organization. Migrate to OIDC Trusted Publishing and revoke legacy tokens entirely. Do not leave them as fallbacks. The coexistence of old and new authentication is what this attack exploited.
5. Harden detection policy. Ensure Behavioral AI and Documents & Scripts engines are set to Protect (On Execute). Avoid broad exclusions for developer tools like node.exe or npm. Enable LSU for real-time detection updates.
6. Extend endpoint coverage to developer workstations and CI runners. These environments have access to production secrets, deployment credentials, and code signing infrastructure. They are typically less monitored than production servers. DPRK has recognized this asymmetry and is systematically exploiting it.
7. Hunt proactively. Use Deep Visibility to search for DNS queries to sfrclak[.]com, connections to 142.11.206[.]73, and the presence of plain-crypto-js in any node_modules directory. SentinelOne’s 2025 Annual Threat Report documents how supply chain attacks are part of a broader pattern where adversaries are “shifting left” to subvert the build process itself, compromising software before it ever reaches production.

Practitioner Investigative Guide

In addition to the strategic recommendations above, here are some specific queries, file paths, and commands you can execute now to protect your environment.

Determine Blast Radius

Your first job is to answer one question: did any system in my environment pull a compromised Axios version during the March 31 exposure window (00:21 – 03:25 UTC)?

In the SentinelOne Console:

• Open the Wayfinder alert queue. Look for the alert name “Axios NPM Supply Chain Compromise” (Wayfinder retroactive rule). If these alerts are not visible under default filters, switch the alert type from “EDR” to “All”, as these surface as Custom/STAR alerts.
• For each alert, review the Storyline and process tree. The typical chain looks like this:
  • Developer process (VS Code, Electron, Node, Yarn, npx) → node → setup.js under plain-crypto-js → curl download from sfrclak[.]com:8000/6202033 → OS-specific payload execution
• Classify the affected asset: developer workstation, CI/CD runner, or production server. This drives urgency. Shared CI runners imply wider blast radius because multiple teams and credential sets may be exposed.

Deep Visibility / Event Search hunts to run immediately:

What You’re Looking For	Query Pattern
C2 DNS resolution	#dns contains:anycase 'sfrclak.com'
C2 IP connection	#ip contains '142.11.206.73'
Malicious dependency on disk	File path contains node_modules/plain-crypto-js/ or */plain-crypto-js/setup.js
macOS RAT binary	File path: /Library/Caches/com.apple.act.mond
Linux loader	File path: /tmp/ld.py
Windows payload	File path: %PROGRAMDATA%\wt.exe
Renamed PowerShell execution	Lunar detection: RenamedBinExecution

Run hash hunts against consolidated IOC lists even if the global blocklist is already active. Historic hits help you quantify which systems were exposed and when.

Contain and Kill

For every system with confirmed Axios-related activity:

• Mark the Storyline as Threat in the SentinelOne Console. Confirm that remediation commands (Kill + Quarantine) executed successfully.
• Network-isolate the endpoint if the C2 connection succeeded (outbound to sfrclak[.]com or 142.11.206[.]73). Check for any secondary tooling or persistence beyond the initial RAT.
• Block at the perimeter. Add the following to your firewall, proxy, and DNS blocklists:
  • Domain: sfrclak[.]com
  • IP: 142.11.206[.]73
  • Port: 8000
• Check for persistence mechanisms:
  • Windows: Registry key “Microsoft Update” (used by the RAT for persistence), presence of 6202033.vbs or 6202033.ps1
  • macOS: Any process spawned from /Library/Caches/com.apple.act.mond, AppleScript execution from /var/folders/.../6202033
  • Linux: Active python3 processes running /tmp/ld.py, nohup wrappers

Credential Rotation and Dependency Cleanup

Assume every credential accessible from a confirmed-compromised endpoint is stolen. The RAT was built to harvest them.

Credential rotation checklist:

• npm access tokens (revoke and reissue)
• SSH keys (regenerate keypairs, update authorized_keys on all targets)
• CI/CD pipeline secrets (GitHub Actions secrets, GitLab CI variables, Jenkins credentials)
• Cloud provider keys (AWS access keys, GCP service account keys, Azure SPN secrets)
• API keys and .env file contents
• Git signing keys and code signing certificates if accessible from the endpoint

Dependency cleanup (all environments):

• Pin Axios to known-good versions: axios@1.14.0 (1.x branch) or axios@0.30.3 (legacy branch)
• Delete node_modules/plain-crypto-js/ wherever it exists
• Run npm cache clean --force (or equivalent for Yarn/pnpm) on all affected build environments
• Reinstall cleanly using npm ci --ignore-scripts during the cleanup period to prevent any other postinstall hooks from executing
• Audit your package-lock.json / yarn.lock / pnpm-lock.yaml for any reference to plain-crypto-js. Its presence in a lockfile is a forensic indicator that the compromised version was resolved, even if the malware self-deleted.

Harden and Validate

Policy hardening:

• Confirm Behavioral AI engine is set to Protect (On Execute), not Detect-only
• Confirm Documents & Scripts engine is set to Protect (On Execute)
• Review and remove any broad exclusions for node.exe, npm, yarn, python3, or developer IDEs
• Verify LSU (Live Security Updates) is enabled. Customers on Fed/OnPrem environments without LSU access should confirm they are on the latest Service Pack
• Confirm the SentinelOne agent is deployed on all developer workstations and CI/CD runners, not just production servers

Validation sweep:

• Run a full disk scan on every endpoint that was in the blast radius
• Verify no new users, services, or scheduled tasks were created during the exposure window
• Confirm that network blocks for C2 infrastructure are active and logging hits
• Re-run the Deep Visibility hunts from Hour 0-1 to verify no new activity has appeared

Key IOC Reference Card

Keep this card accessible for your team during the response.

Malicious packages:

Package	SHA-1
axios@1.14.1	2553649f2322049666871cea80a5d0d6adc700ca
axios@0.30.4	d6f3f62fd3b9f5432f5782b62d8cfd5247d5ee71
plain-crypto-js@4.2.1	07d889e2dadce6f3910dcbc253317d28ca61c766

C2 infrastructure:

Indicator	Value
Domain	sfrclak[.]com
IP	142.11.206[.]73
Port	8000
URL pattern	hxxp[://]sfrclak[.]com:8000/6202033
RAT User-Agent	mozilla/4.0 (compatible; msie 8.0; windows nt 5.1; trident/4.0)

File artifacts by OS:

OS	Artifact	Path
macOS	RAT binary	/Library/Caches/com.apple.act.mond
macOS	Temp script	/var/folders/.../6202033
Windows	Renamed PowerShell	%PROGRAMDATA%\wt.exe
Windows	Stage 1	system.bat
Windows	Stage 2	6202033.ps1
Windows	VBS launcher	6202033.vbs
Linux	Python loader	/tmp/ld.py

RAT beacon behavior: HTTP POST every 60 seconds, Base64-encoded JSON, two-layer obfuscation (reversed Base64 + XOR with key OrDeR_7077, constant 333). The IE8/Windows XP User-Agent string is anachronistic and serves as a strong network-level detection indicator.

SentinelLABS Expanded Indicators:

Indicator	Value	Note
Email	nrwise@proton[.]me	Involved in supply chain compromise.
Email	ifstap@proton[.]me	Involved in supply chain compromise.
Domain	callnrwise[.]com	Domain overlaps with email scheme and infrastructure design from confirmed C2 domain.
Domain	focusrecruitment[.]careers	Overlapping domain registration details and timeline. Medium Confidence
Domain	chickencoinwin[.]website	Overlapping domain registration details and timeline. Medium Confidence

The Structural Problem Is Bigger Than Axios

The progression from event-stream (2018, individual actor) to Shai-Hulud (2025, self-replicating worm across 500+ packages) to Axios (2026, DPRK state actor with multi-vendor attribution from SentinelOne, Google, and Microsoft) is not a series of isolated incidents. It is a clear escalation in adversary sophistication and strategic intent. North Korean threat actors stole $2.02 billion in cryptocurrency in 2025 alone, a 51% increase year-over-year, and the Axios RAT harvests exactly the credential types that feed that revenue pipeline.

Developer environments are now a Tier 1 attack surface. The organizations that treat them as anything less are operating with a structural blind spot that state-level adversaries have already mapped.

SentinelOne’s Autonomous Security Intelligence framework delivers what this moment requires: AI-native protection that detects and contains threats at machine speed, human expertise through Wayfinder MDR that translates alerts into confident action, and a unified platform that eliminates the fragmented visibility where supply chain attacks hide. When the next three-hour window opens, the question is whether your defense moves faster than the attacker. With SentinelOne, it does.

Disclaimer: All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third party.

On March 24, 2026, SentinelOne’s autonomous detection caught what manual workflows never could have: a trojaned version of LiteLLM, one of the most widely used proxy layers for LLM API calls, executing malicious Python across multiple customer environments. The package had been compromised hours earlier. No analyst wrote a query. No SOC team triaged an alert. The Singularity Platform identified and blocked the payload before it could run, across every affected environment, on the same day the attack was launched.

The LiteLLM supply chain compromise is not an anomaly. It is the new pattern: multi-stage, multi-surface, designed to evade manual workflows at every turn. A compromised security tool led to a compromised AI package, which led to data theft, persistence, Kubernetes lateral movement, and encrypted exfiltration, all within a window measured in hours.

SentinelOne detected and blocked this attack autonomously, on the same day it was launched, across multiple customer environments. No manual triage. No signature update. No analyst in the loop for the initial containment. This is what autonomous, AI-native defense looks like when it meets a real-world threat at machine speed.

The gap between the velocity of this attack and the capacity of human-driven investigation is the gap where organizations get compromised. Closing that gap is not a feature request. It is an architectural decision. This is what happens when AI infrastructure gets targeted by a multi-stage supply chain campaign, and what it looks like when autonomous, AI-native defense is already in position.

Here is what we detected, how the attack was structured, and why this is the class of threat that the Singularity Platform was built to stop.

SentinelOne’s macOS agent identified and preemptively killed a malicious process chain originating from Anthropic’s Claude Code running with unrestricted permissions (claude --dangerously-skip-permissions). No human developer ran pip install, an autonomous AI coding assistant updated LiteLLM to the compromised version as part of its normal workflow.

The AI engine classified the behavior as MALICIOUS and took immediate action: KILLED (PREEMPTIVE) across 424 related events in under 44 seconds. The agent didn’t need to know the package was compromised, it watched what the process did and stopped it based on behavior, regardless of what initiated the install.

The macOS agent caught the trojaned LiteLLM package mid-execution. The process summary tells the story: python3.12 launching with a command line containing import base64; exec(base64.b64decode(... , the exact bootstrap mechanism described in the attack’s first stage, decoding and executing the obfuscated payload in a child process.

The agent didn’t need a signature for this specific package. It recognized the behavioral pattern, a Python interpreter executing base64-decoded code in a spawned subprocess, classified it as MALICIOUS, and killed it preemptively before the stealer, persistence, or lateral movement stages could deploy.

Zooming out on the same detection reveals the full scope of what the autonomous AI agent was doing when the payload fired. The process tree expands from Claude Code (2.1.81) into a sprawling chain: zsh, bash, node, uv, ssh, rm, python3.12, mktemp, with hundreds of child events still loadable (304 events captured). This is what unrestricted AI agent activity looks like at the endpoint level: a single command spawning an entire dependency management workflow that pulled, installed, and attempted to execute the trojaned package.

The SentinelOne macOS agent traced every branch of this tree, correlated the events back to the root cause, and killed the malicious execution; all while preserving the full forensic record for investigation.

The Compromise Was Indirect. That’s What Makes It Dangerous.

The attacker, operating under the alias TeamPCP, never attacked LiteLLM directly. They first compromised Trivy, a widely trusted open-source security scanner, on March 19. From there, they obtained the LiteLLM maintainer’s PyPI credentials and used them to publish two malicious versions: 1.82.7 and 1.82.8.

A security tool, built to find vulnerabilities, became the vector that enabled the compromise of an AI infrastructure package used by thousands of organizations. The same actor went on to compromise Checkmarx KICS and AST on March 23, and Telnyx on March 27. This was not a smash-and-grab. It was a coordinated campaign that exploited the transitive trust woven through open-source supply chains.

For security leaders asking, “Could this have reached us?” the more pressing question is: “How fast could we have answered that?”

A New Attack Surface: AI Agents With Unrestricted Permissions

In one customer environment, SentinelOne detected the infection arriving through an unexpected vector: an AI coding assistant running with unrestricted system permissions autonomously updated LiteLLM to the trojaned version without human review. The update pulled the infected package, and the payload attempted to execute. Our agent blocked it.

This is a new class of attack surface that most organizations have not yet scoped. AI coding agents operating with full system permissions can become unwitting vectors for supply chain compromises. The speed and automation that make these tools valuable are the same properties that make them dangerous when the packages they pull have been weaponized. Organizations that have not yet established governance policies for AI assistant permissions are carrying risks they cannot see.

SentinelOne’s behavioral detection operates below the application layer. It does not matter whether a malicious package is installed by a human, a CI pipeline, or an AI agent. The platform monitors process behavior via the Endpoint Security Framework, which is why this detection fired regardless of how the infected package arrived.

Two Infection Vectors, One Designed to Run Without You

Version 1.82.7 embedded its payload in proxy_server.py, which executes every time the litellm.proxy module is imported. For anyone using LiteLLM as a proxy layer for LLM API calls, this fires constantly during normal operations.

Version 1.82.8 escalated. The attacker placed the payload in a .pth file, litellm_init.pth. Files with the .pth extension are processed by the Python interpreter at startup, regardless of which modules are imported. Any Python script running on a system with this version installed would trigger the malicious code, even if that script had nothing to do with LiteLLM.

If version 1.82.7 was a targeted shot, version 1.82.8 was a blast radius expansion. The attacker removed the requirement that the victim actually use the compromised library.

What the Payload Did Once Inside

The attack was structured as a multi-stage delivery system, each stage decoding, decrypting, and executing the next. The first stage was a minimal bootstrap, a single line of base64-decoded Python launched in a detached subprocess with stdout and stderr suppressed. Lightweight enough to slip past signature-based tools. Quiet enough to avoid raising flags.

The second stage was a comprehensive data stealer. It harvested system and user information, cryptocurrency wallets, cloud credentials, application secrets, and system configurations. For practitioners wondering what the blast radius looks like if a developer workstation is compromised, this is the answer: the attacker collects everything needed to move from a laptop to production infrastructure.

The third stage established persistence through a systemd user service at ~/.config/systemd/user/sysmon.service, executing a script at ~/.config/sysmon/sysmon.py. The naming convention, “sysmon,” was deliberately chosen to mimic legitimate system monitoring tools. It is designed to survive casual inspection and blend into environments where dozens of services run as expected background noise. This is precisely the kind of evasion that signature-based detection misses and behavioral AI catches: the process looks normal until you observe what it actually does.

The persistence mechanism included a 5-minute initial delay before any network activity, a technique specifically designed to outlast automated sandbox analysis. After that, the script contacted its C2 server every 50 minutes, fetching dynamic payload URLs. This sparse communication pattern makes behavioral detection through network monitoring significantly harder, and gives the attacker the ability to push new tooling without ever re-compromising the target.

It Moved Laterally Through Kubernetes

The attack did not stop at the workstation. It created privileged pods across Kubernetes cluster nodes in the kube-system namespace, using standard container images like alpine:latest, with hostPID, hostNetwork, and a privileged security context. By mounting the host filesystem directly, these pods gained root-level access to underlying nodes.

Each pod deployed persistent backdoors as systemd services on the host system. The pods operated in legitimate namespaces, used standard images, and ran with privileges that many production workloads legitimately require. For SOC practitioners asking whether their admission control and runtime detection would have caught this: the attack was designed specifically so they might not. Detecting this requires runtime visibility into container behavior after deployment, not just policy enforcement at the admission gate. This is the difference between cloud security that checks configuration and cloud security that watches execution.

Exfiltration Was Encrypted and Camouflaged

Stolen data was encrypted using a hybrid RSA and AES-256-CBC scheme. A random 32-byte AES session key encrypted the data, then the session key itself was protected with RSA encryption using a hardcoded public key. This meant the malware could encrypt and exfiltrate without first communicating with the C2 server. The encrypted payload was packaged as tpcp.tar.gz and transmitted via a single HTTP POST to models.litellm.cloud, a domain chosen to blend with legitimate LiteLLM API traffic and slip past network monitoring that whitelists expected destinations.

What This Attack Proves

The LiteLLM supply chain compromise is not an anomaly. It is the new pattern: multi-stage, multi-surface, designed to evade manual workflows at every turn. A compromised security tool led to a compromised AI package, which led to data theft, persistence, Kubernetes lateral movement, and encrypted exfiltration, all within a window measured in hours.

SentinelOne detected and blocked this attack autonomously, on the same day it was launched, across multiple customer environments. No manual triage. No signature update. No analyst in the loop for the initial containment. This is what autonomous, AI-native defense looks like when it meets a real-world threat at machine speed.

The gap between the velocity of this attack and the capacity of human-driven investigation is the gap where organizations get compromised. Closing that gap is not a feature request. It is an architectural decision.

Why This Detection Worked: Architecture, Not Luck

The LiteLLM detection wasn’t a one-off. It’s what happens when autonomous, behavioral AI is built into the foundation, not bolted on after the fact. The Singularity Platform’s visibility across endpoint, cloud, identity, and AI workloads is why the agent saw this regardless of whether the install came from a human, a CI pipeline, or an AI coding assistant.

For teams that need the human expertise layer on top, Wayfinder MDR extends that autonomous detection with 24/7 investigation and response, closing the gap between detection and resolution.

This is the Autonomous Security Intelligence (ASI) framework in practice: AI that acts at machine speed, backed by human expertise when it matters, across every surface the attack can reach. See how the Singularity Platform protects AI infrastructure and request a demo today.