PamStealer Targets macOS, SalesBleed Hijacks Salesforce Agents, and a 14-Year-Old Linux Bug Hits CISA KEV

PamStealer Now Hides Its Payload Behind the Attacker's Server

A new PamStealer variant is targeting macOS users through a fake crypto wallet, and below we walk through how its delivery chain keeps analysts from recovering the payload and what it takes to fully remove it from an infected Mac.

What You Need to Know

Jamf Threat Labs has found a new PamStealer variant that decrypts its payload only with live help from the attacker's server and installs persistence designed to rebuild itself. Once running, it steals keychain material, browser data, and user files. Deleting the obvious malicious app does not clean the host, and any credentials on an affected Mac should be treated as exposed.

How the Attack Works

The lure is wavel[.]app, a fake site advertising a multichain cryptocurrency wallet that doesn't exist. The site offers a macOS disk image containing a compiled AppleScript file. When a user opens the file and follows its instructions in Script Editor, JavaScript for Automation (JXA) decodes and launches a background zsh dropper. Earlier PamStealer campaigns used fake clipboard applications and embedded the decryption material in the dropper itself. This variant changes both the lure and the delivery chain.The dropper downloads a purpose-built utility called pkgunpack along with an encrypted application payload. On each run, pkgunpack generates a fresh key pair and contacts an attacker-controlled command-and-control (C2) server for the material needed to unwrap the payload's decryption key. The server keeps the private key required for that exchange, so researchers can't recover the second stage from the encrypted file alone, and a captured response can't be reused for a later run. After decryption, the malware installs a bundle disguised as Finder.app under the user's Application Support directory. It attempts to suppress the macOS notification that normally appears when a new background item is added.The final stealer is written in Swift, replacing the Rust used in an earlier variant. Still, it keeps PamStealer's habit of validating a captured login password through macOS Pluggable Authentication Modules. Jamf observed it collecting keychain material, browser data, system information, and user files, then assembling and uploading an archive.

How It Stays

A LaunchAgent starts the disguised application at login. A local backup and repair script can restore both the application and its LaunchAgent without contacting the C2 server. That script also runs whenever the user opens an interactive zsh session or performs a Git checkout or commit, so ordinary daily activity keeps giving the infection a chance to come back.

Why This Matters

The server-side key exchange changes how incident response works for this family. A sample pulled from disk tells an analyst very little, which means the useful evidence lives on the live host and in network traffic, not in the file. The persistence design is just as deliberate. Hooking into zsh and Git targets exactly the users most likely to fall for a crypto wallet lure and most likely to hold valuable secrets: developers and technical staff whose Macs carry source code access, cloud tokens, and wallet credentials. A cleanup that stops at the fake Finder app leaves a repair mechanism waiting for the next terminal window.

What to Do

On any suspected host, examine ~/Library/LaunchAgents/com.apple.finder.agent.plist, the corresponding files under ~/Library/Application Support/System/, recent changes to ~/.zshrc, and the global Git core.hooksPath setting. Contain the host first, then remove every persistence component, not just the application bundle. Reset keychain credentials, browser-saved passwords, session tokens, and any other secrets that were reachable on the machine, and do it from a clean device. Block wavel[.]app at the network and DNS layer, and remind users that a downloaded disk image asking them to run something in Script Editor is a red flag regardless of what it claims to be.

Cloudflare Containers Flaw Left One Customer's Data on Another's Disk

Cloudflare has closed an isolation gap in Containers and Sandboxes, and here's how residual data survived disk reuse and what the company did to clean it up.

What You Need to Know

Cloudflare has fixed a vulnerability in its Containers service and in Sandboxes that run on it, which let one paying customer recover data left behind by another customer's deleted container. The flaw didn't expose live workloads and couldn't be aimed at a specific victim, but it broke a basic tenant isolation boundary. Cloudflare finished cleanup on September 19 and says customers don't need to change anything.

What Happened

Oren Yomtov of Accomplish reported the issue through Cloudflare's bug bounty program on September 4, 2026. The root cause was the configuration of Linux device mapper thin provisioning, which Cloudflare used to allocate writable container disks in 64-kilobyte blocks. When a container's disk was deleted, its blocks returned to a pool shared across accounts. Because the pool had skip_block_zeroing enabled, it didn't wipe a reused block before handing it to a different container, potentially one belonging to another account on the same underlying server.The researchers showed the effect by writing 4 kilobytes into an unused region of a new container's disk, then reading the full 64-kilobyte block at the raw-device level. The remaining 60 kilobytes could still hold the previous owner's data. They found residual material in 18 of 24 production placements and on 20 of 22 underlying servers tested across four continents. Recovered blocks included directory structures, database pages, and structurally complete SQLite databases, along with remnants of browser profiles, environment files, and credential files. An attacker couldn't choose a particular victim or host, and testing showed no ability to modify another customer's data or disrupt a live workload.

How Cloudflare Fixed It

Cloudflare first restored block wiping for new allocations, which stopped the reported proof of concept. That alone didn't clear blocks already mapped into running container disks or cached image layers, so the company also retired existing disks, cleared cached snapshots, and restarted hosts, finishing on September 19. A review of retained disk-I/O telemetry found no activity matching the technique beyond authorized researcher and Cloudflare testing. That result reflects the telemetry Cloudflare had available, not a guarantee that no data was ever exposed.

Why This Matters

Most discussions of container isolation focus on what running workloads can see of each other. This case reminds us that isolation also depends on what happens to storage after a workload is gone. Skipping block zeroing is a reasonable performance choice in a single-tenant system and a data leak in a shared one. The types of data recovered, environment files and credential files in particular, are exactly what teams tend to assume disappears when a container is deleted.

What to Do

No configuration changes are required on the Cloudflare side. If you ran sensitive workloads on Containers or Sandboxes before September 19, take stock of what those containers wrote to disk, and consider rotating any credentials, API keys, or secrets that lived in environment files or local databases, depending on your risk tolerance. More broadly, avoid writing secrets to container disks in plain form, encrypt sensitive data at the application layer, and ask your other shared-infrastructure providers how they sanitize storage before reassigning it.

SalesBleed Turned a Public Web Form Into a Way to Hijack Salesforce Agents

Three now-fixed Agentforce vulnerabilities show how attacker-written text in a public form could steer a Salesforce agent, and we break down how each one worked and what customers should review.

What You Need to Know

Zenity Labs disclosed three vulnerabilities, collectively called SalesBleed, that let attackers manipulate Salesforce Agentforce using only text submitted to a public Web-to-Lead form. No login to the target environment was required. The flaws could leak CRM data and let an agent post phishing messages into company Slack threads under its own trusted identity. Salesforce has fixed the issues and found no evidence of real-world exploitation, but customers should review the resulting configuration changes.

How the Attack Works

Web-to-Lead forms collect details from prospective customers, making them an open door for attacker-written text. In SalesBleed, those instructions sat quietly in a lead record until an employee asked an Agentforce agent to work with it. At that point, the agent could mistake the lead's content for directions and use its legitimate access to Salesforce data or connected Slack functions on the attacker's behalf.Two of the weaknesses exposed CRM data by getting around Agentforce's Trusted URLs protections, which are meant to stop agents from sending data to unapproved destinations. In one scenario, the planted instructions caused the agent to pull information beyond the submitted lead and embed it in a request to an attacker-controlled server. The other abused Slack's link-preview behavior: when a crafted link appeared in Slack, Slack automatically fetched it and transmitted whatever data was encoded in the request. Neither path required anyone to click a link. Each request could carry only a limited amount of data, but repeated requests could add up.The third weakness turned the problem into internal phishing. Agentforce agents connected to Slack can take actions for authorized users, but Zenity found the "Reply to a Slack Thread" action lacked the expected user confirmation and attribution controls. A malicious instruction from a Web-to-Lead record could make the agent post into a company Slack thread under its trusted identity, potentially carrying a phishing link.

How Salesforce Fixed It

Salesforce changed the default settings for certain Agentforce Slack actions so they require confirmation before sending a message. It also replaced its earlier pattern-based URL checks with standards-based URL parsing and centralized URL inspection, and it is contacting customers about the related configuration changes.

Why This Matters

SalesBleed shows that an agent's permissions and its exposure to untrusted text can't be evaluated separately. A form built for strangers became a way to steer an internal tool with real data access. The phishing angle is especially pointed: employees are trained to distrust unknown senders, not a company AI agent posting in a familiar Slack thread. Any agent that reads outside input and can write to internal channels carries the same basic risk, regardless of the platform it runs on.

What to Do

Watch for Salesforce's configuration notices and confirm that the new confirmation requirement is in place for Agentforce Slack actions in your environment. Limit agents' access to sensitive records and to messaging actions they don't strictly need, and monitor how agents handle content submitted by outside users, especially lead and case records created through public forms. Beyond Salesforce, inventory any other AI agents that read externally submitted text and check what they're allowed to do with it.

Windows 11 Updates Are Leaving Some Users at a Black Screen After Sign-In

A known issue in recent Windows 11 updates is keeping the desktop from loading on some Azure Virtual Desktop hosts, and we cover which updates are involved and how to apply Microsoft's rollback.

What You Need to Know

Microsoft has confirmed that the August 2026 preview updates and later releases can leave some Windows 11 devices at a black screen or without a usable desktop after sign-in. Most reports involve Azure Virtual Desktop (AVD) hosts using FSLogix. Microsoft lists the issue as mitigated, not resolved, and has published Known Issue Rollback policies while it works on a permanent fix.

What's Affected

The problem shows up mostly in AVD sessions with existing user profiles. Users sign in successfully but never reach a working desktop, and application logs may show Windows Explorer crashing. The affected update sequence starts with the August preview updates, KB5120996 for Windows 11 version 26H1 and KB5120998 for versions 24H2 and 25H2. It includes later updates that carry the same change, including the September security updates KB5122880 and KB5124008. Microsoft's FSLogix documentation separately notes black screens after KB5124008 and attributes them to explorer.exe crashes during shell startup.This is not the same as another issue introduced by the August preview update, which reset some desktop personalization settings and could leave the background solid black. Microsoft resolved that personalization issue in the September updates. The sign-in and shell-loading failure is still under investigation.

Why This Matters

In a pooled AVD environment, one bad update can take out the desktop for an entire user population at once, and the help desk sees it all as the same symptom. The "mitigated" label matters too. The rollback turns off the change behind the failure, but it isn't a fix, so administrators need to track when the real correction ships. With two different black-screen issues tied to the same update cycle, it's easy to chase the wrong one.

What to Do

For an individual affected user, open Task Manager with Ctrl+Shift+Esc, select "Run new task," and start explorer.exe to restore the desktop temporarily. For managed devices, install and configure the Known Issue Rollback group policy for your Windows version: KB5124006 260924_20071 for version 26H1, or KB5124010 260924_20021 for versions 24H2 and 25H2, then restart affected devices so it takes effect. Before rolling it out broadly, identify which session hosts and user profiles are actually failing, check for Explorer crash events, and test the rollback against your AVD and FSLogix configuration. Keeping the response scoped to the affected virtual desktop population helps separate this known issue from unrelated causes of a black screen at sign-in. Watch Microsoft's release health updates for the permanent fix.

A 14-Year-Old Linux Kernel Bug Is Now on CISA's Exploited List

A long-lived flaw in the Linux kernel's AF_ALG crypto interface has been turned into root access and container escape, and we explain how the exploit works and which systems to patch first.

What You Need to Know

CISA added a Linux kernel race condition dating back to 2011 to its KEV catalog on September 18, 2026. Researchers have already shown it can be used to gain root and escape a Docker container. Because an unprivileged process can reach the vulnerable code, shared hosts and container infrastructure should be the patching priority.

What's Vulnerable

Tracked as CVE-2025-39964, the flaw sits in AF_ALG, the kernel interface that lets user-space programs request cryptographic operations through sockets. The vulnerable code dates to Linux 2.6.38, released in 2011, and went unnoticed for roughly 14 years. STAR Labs researcher Muhammad Alifa Ramdhan discovered it in 2025, and Bing-Jhong Billy Jheng helped complete the exploit chain. Their submission to Google's Linux kernel exploitation challenge earned a $113,337 reward. Because AF_ALG is reachable from an unprivileged process, the bug matters for any host running less-trusted local users or containers, not just systems exposing a network service.

How the Exploit Works

The bug is a race condition in af_alg_sendmsg(). The function locks the socket during a write, but the kernel can release that lock while waiting for socket memory. A second thread can then write to the same AF_ALG socket and leave its internal state inconsistent. The researchers combined carefully timed writes with a failed copy from user space to make the kernel treat a nonexistent scatterlist entry as valid. They turned the resulting out-of-bounds access into a controlled write, modified the kernel's core_pattern setting, and triggered a crash so their program ran as the root-privileged core-dump handler.In the tested Docker environment, the container shared the vulnerable host kernel and could reach AF_ALG, so the exploit gained root on the host. That's a demonstrated attack path, not proof that every Docker deployment is equally exploitable. CISA's KEV listing cites evidence of exploitation, but public reporting doesn't establish that the observed activity used the researchers' root-access and container-escape chain. The upstream fix blocks concurrent writers on the same AF_ALG socket, rejecting a second write with EBUSY until the first completes.

Why This Matters

A local privilege escalation bug sounds contained until you remember how many systems run untrusted code locally by design. On container hosts, CI runners, and multi-tenant servers, "local" means any workload that shares the kernel. A flaw in 14-year-old code also means the vulnerable population is huge and includes long-lived systems that rarely get kernel updates. The KEV listing moves this from theoretical to confirmed attacker interest, regardless of the technique used in real-world activity.

What to Do

Apply your distribution's kernel updates. Fixed upstream stable releases include 5.10.245, 5.15.194, 6.1.154, 6.6.108, 6.12.49, and 6.16.9, but check your vendor's advisory rather than relying on the upstream version number, since distributions often backport fixes. Patch shared hosts and container infrastructure first, since a successful local exploit there can compromise workloads well beyond the attacker's initial foothold. For workloads that don't need kernel crypto sockets, consider seccomp or similar policies that deny AF_ALG socket creation as an added layer while patching catches up.