Less than two weeks after the public disclosure of the Copy Fail vulnerability (CVE-2026-31431), another local privilege escalation (LPE) vulnerability in the Linux kernel has been revealed. Referred to as "Dirty Frag," this vulnerability was discovered and reported by Hyunwoo Kim (@v4bel) [1]. In this diary, I will provide a brief background on Dirty Frag, and discuss its relationship to Copy Fail. I will then discuss how to mitigate Dirty Frag and outline recommended next steps for system owners.

The existence of Dirty Frag was revealed after the coordinated disclosure embargo was broken by an unrelated third party [1]. Just like Copy Fail [2], Dirty Frag allows an unprivileged local user to escalate to root on most major Linux distributions. Due to the premature disclosure of Dirty Frag, no CVE IDs were assigned [3].

Dirty Frag chains two distinct vulnerabilities:

1. xfrm-ESP Page-Cache Write - residing in the IPsec ESP decryption fast paths (esp4, esp6)
2. RxRPC Page-Cache Write - residing in the RxRPC module

Both sub-vulnerabilities share a common root cause: on a zero-copy send path where splice() plants a reference to a page cache page that an attacker only has read access to into the frag slot of the sender-side skb, the receiver-side kernel code performs in-place crypto on top of that frag. As a result, the page cache of files that an unprivileged user only has read access to (such as /etc/passwd or /usr/bin/su) is modified in RAM, and every subsequent read sees the modified copy [1].

While both Dirty Frag and Copy Fail belong to the same broad vulnerability class (page-cache corruption via kernel crypto in-place operations), they were discovered by different researchers and reside in different kernel subsystems. Copy Fail (CVE-2026-31431) was discovered by researchers at Theori and abuses the algif_aead module in the AF_ALG crypto interface. Dirty Frag, on the other hand, exploits the ESP and RxRPC in-place decryption fast paths directly.

With reference to Table 1, the key differences of each vulnerability are shown.

Factors	Copy Fail (CVE-2026-31431)	Dirty Frag
Kernel Subsystem	AF_ALG / algif_aead	xfrm ESP (esp4, esp6) and RxRPC
CVE Assigned	Yes (CVE-2026-31431)	No (embargo broken before allocation)
Controlled Bytes Written	4 bytes	4 bytes (per sub-vulnerability)
Chaining Required	No (single vulnerability)	Yes (two sub-vulnerabilities chained)
Discoverer	Theori (Research Team)	Hyunwoo Kim (@v4bel)
Public Disclosure Date	29 April 2026	7 May 2026

An interesting factor of Dirty Frag is that chaining the two sub-vulnerabilities covers each other's blind spots. As described in the write-up, neither the xfrm-ESP Page-Cache Write nor the RxRPC Page-Cache Write alone provides a sufficiently reliable primitive for full root escalation. However, when combined, the chained exploit achieves immediate root on most distributions.

The Dirty Frag vulnerability is significant (beyond its possible utility in Capture-the-Flag challenges). Firstly, the vulnerability affects many major Linux distributions with kernels dating back to approximately 2017, similar to Copy Fail. Secondly, due to the unfortunate embargo breach, the working exploit code is publicly available. Thirdly, since no CVE identifier was assigned, any automated workflow or systems tracking vulnerabilities by CVE identifers would not be able to show Dirty Frag automatically. Finally, in the case of containerized environments, an adversary may be able to leverage Dirty Frag, override relevant binaries in the base layer and escape to host.

Currently, patched kernels and live patches are in active build and testing for several distributions [4, 5]. Until a patched kernel or live patch is installed, the following mitigations could be applied:

1. Denylist and unload vulnerable kernel modules

This is the most immediate mitigation available. The vulnerable modules (esp4, esp6, rxrpc) can be denylisted to prevent them from being loaded:

# Unload modules if currently loaded
modprobe -r esp4 esp6 rxrpc

# Denylist modules to prevent loading on boot
echo "Denylist esp4" >> /etc/modprobe.d/dirtyfrag-mitigation.conf
echo "Denylist esp6" >> /etc/modprobe.d/dirtyfrag-mitigation.conf
echo "Denylist rxrpc" >> /etc/modprobe.d/dirtyfrag-mitigation.conf

Important caveat: Denylisting esp4 and esp6 will disable IPsec ESP functionality. If your environment relies on IPsec VPN tunnels or IPsec-encrypted communication, this mitigation will cause disruption. Similarly, unloading rxrpc will affect services that depend on RxRPC (such as AFS filesystems). System administrators should assess the impact before applying this mitigation.

2. Apply live patches where available

CloudLinux KernelCare live patches are being made available for affected CloudLinux versions [4]. This allows patching without rebooting, which may be preferable for production environments where downtime windows are limited.

3. Install patched kernels from testing repositories

AlmaLinux has published patched kernels in their testing repository [5]. Once stable kernels are released for your distribution, apply them promptly and reboot.

4. Revert denylists after patching

After a patched kernel is installed and the system has been rebooted, the denylists can be removed:

rm /etc/modprobe.d/dirtyfrag-mitigation.conf

Dirty Frag joins a growing list of universal Linux LPE vulnerabilities that exploit kernel page-cache handling or memory management primitives. Notable related vulnerabilities include:

• Dirty COW (CVE-2016-5195): Exploited a race condition in copy-on-write memory handling to modify read-only file mappings
• Dirty Pipe (CVE-2022-0847): Exploited uninitialized flags in pipe_buffer to overwrite page cache pages of read-only files
• Copy Fail (CVE-2026-31431): Exploited AF_ALG crypto interface to write controlled bytes into page cache

It appears that kernel optimizations which perform in-place operations on shared page-cache-backed pages without verifying exclusive ownership introduce exploitable primitives (the ability to corrupt the global page cache by tricking the kernel into treating a shared/read-only page as a private, writable buffer). This suggests that closer attention to zero-copy and in-place operation paths in the kernel are required.

As Dirty Frag does not have a CVE ID yet, defenders have to rely on distribution advisories and direct monitoring of security mailing lists rather than automated CVE-based alerting. If you have not yet addressed Copy Fail (CVE-2026-31431), now would be a good time to treat both vulnerabilities as a combined remediation effort, given their similarity and overlapping mitigation steps.

References:
[1] https://github.com/V4bel/dirtyfrag/blob/master/assets/write-up.md
[2] https://xint.io/blog/copy-fail-linux-distributions
[3] https://www.openwall.com/lists/oss-security/2026/05/07/8
[4] https://blog.cloudlinux.com/dirty-frag-mitigation-and-kernel-update
[5] https://almalinux.org/blog/2026-05-07-dirty-frag/

-----------
Yee Ching Tok, Ph.D., ISC Handler
Personal Site
Mastodon
Twitter

[This is a Guest Diary by Eric Roldan, an ISC intern as part of the SANS.edu BACS program]

Through the expansion of Large Language Models (LLMs), cybersecurity has exploded with a variety of tools for both offensive and defensive purposes. A majority of software and cyber tools are integrating Artificial Intelligence (AI) solutions into their applications, largely in the form of chatbots, automation tools through Model Context Protocol (MCP), or ingestion to prompt response type interfaces.

An overlooked and underestimated aspect of AI that is slowly arising is the creation of bespoke user interfaces (UI). That is simply put — a UI that is created custom fit to the specific needs and data provided impromptu from the user. With the ability for these models to ingest large amounts of data, it can orchestrate the appropriate elements for a UI that will be tailored to the ingested dataset.

Rather than the user having to adjust their queries or layouts for the logs that they are analyzing, the LLM will determine the proper UI elements to give to the user. This allows the user to focus on analyzing rather than tool setup.

Over days of web traffic on the DShield webhoneypot, there are large variations of intent behind the interactions. Some days, some actors may focus only on scanning and recon. Other days may be heavy on stealing credentials or trying to get a web shell exploit.

As a regular user would try to identify patterns then use their discretion to find the next proper 'grep', 'jq', or other similar pattern recognizing POSIX tools, the LLM does the same.

Before this type of bespoke UIs in cyber analytics, analysts would have to spend extensive time and energy to understand what to look for and how to use the appropriate tools. With LLM's able to do this heavy lifting, more analysts will be able to recognize attacks on their web servers with little to no cyber experience.

When developers have to manage feature implementations, documentation updates, meetings (which are always productive of course...), and dreaded bugs - security and active monitoring become an afterthought. To make the internet a safer place, we have to lower the barrier to entry for recognizing web attacks.

Okay enough selling you on how much potential this has, let's talk about how it actually works.

It works like this: the system reads your DShield web honeypot log file, then a Python analyzer goes through the entries and turns them into a clean summary of what happened instead of dumping raw attacker text into the AI. That summary includes things like top IPs, top URLs, time patterns, and tags for probe/attack types such as WordPress probes, SSRF, path traversal, CGI abuse, and other recognizable patterns. Then Claude looks at the cleaned summary and writes a React dashboard component that fits the shape of the attack activity for that day, so the UI can change depending on whether the logs are mostly one big campaign or a mix of background internet noise.

The safe part is that the LLM never gets the raw malicious strings directly, and the generated UI never gets to run loose in the main page. Instead, the app serves the generated dashboard through a backend API, caches it so it does not constantly change, and renders it inside a sandboxed iframe. If the generated code is broken, the system validates it and falls back to a static dashboard. So the whole flow is basically: logs came in -> analyzer summarizes them -> Claude generates a matching UI -> frontend loads it safely and pulls chart data from the backend.

Let's take a look at some examples now! On days where there is more noise we do not see any dominant patterns highlighted on the UI

However, on days where there is a clear pattern from certain actors we see an immediate highlight…

Furthermore, it is able to recognize and highlight attack signatures that were most obvious (or would be obvious to an experienced analyst) at the very top of the UI’s dashboard

There are sometimes some interesting quirks like the LLM creating a dashboard with light mode instead of dark mode.

Nonetheless it is interesting to see how the LLM adapts to each day’s attack logs. I imagine if I could “vibe code” this idea in a few hours, it could become a full-blown platform and toolkit for major organizations and analysts. So yea…I didn’t write the code for all this madness, I simply took a problem that I constantly face when looking at attack logs - what is it that I’m actually looking for? And created a unique bespoke UI for each day’s scenario.

Shout out to Claude Code for agentically writing the repo which can be found here.

Shout out to ChatGPT for helping me write the ‘how it works’ section of this blog.

And a special shout out to my Internship mentor Guy Bruneau for helping me think bigger in terms of recognizing interesting attacks on my webhoneypot.

Be sure to subscribe to my youtube channel for more edgy tech content and cyber insights.
youtube.com/@gnarcoding

[1] https://github.com/gnarcoding/bespoke-ui-cyber-analytics/
[2] https://isc.sans.edu/tools/honeypot/
[3] https://www.sans.edu/cyber-security-programs/bachelors-degree/

-----------
Guy Bruneau IPSS Inc.
My GitHub Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

I just got an email from SSL.com last night, they are rotating  out their root certificate today (May 5,2026).  This is normal, business as usual stuff for a CA, but certificates get used for all kinds of things, and sometimes they aren't used like they should be, so sometimes hiccups happen.

If you are using them for basic cert+website stuff, there's no need to worry.  But if you go past that basic implementation, you should read their note to make sure that this change won't be affecting any of your services.  Even if you don't use ssl.com, it's a good read, as every certificate expires, which means that everyone's root cert rotates out eventually - so forewarned if forearmed and all that ..

In particular (from the email):

• If you have pinned trust anchors, custom trust stores, or certificate validation logic tied to the 2016 roots, please audit those configurations promptly to avoid disruptions.
• Use cross-certificates. If you need backward compatibility with the 2016 root hierarchy during the transition, cross-certificates can bridge the gap.
• Migrate to dedicated Client Certificates. These are purpose-built for client authentication and are unaffected by Google Chrome's upcoming server authentication requirements, which impact SSL/TLS certificates with the ClientAuth EKU.

Their full post is here:

https://www.ssl.com/article/what-ssls-root-migration-means-for-you    

===============
Rob VandenBrink
rob@coherentsecurity.com

Yup, that is for real.

For me, this started with a post in X at hxxps://x.com/intcyberdigest/status/2051406295828250963?s=61 , which highlighted research by @L1v1ng0ffTh3L4N that found exactly this issue.  Edge stores all of your browser passwords in clear text, even if you haven't used them in this session, y'know, just in case.

I figured, it couldn't be that easy, right?  But like so many things, yes, yes it was.

To reproduce this

• Open Edge.  Don't browse anywhere, just open it
• Flip out to Task Manager, search for Edge, then expand that task
• Highlight the "browser" sub-task, right click, and choose "Create Memory Dump"

 

Navigate to where the DMP file is stored.  

If you haven't used strings before, you're in for a treat.  Strings is of course just part of most Linux distros, but you can easily get a copy for Windows as part of MS Sysinternals, at https://learn.microsoft.com/en-us/sysinternals/downloads/strings

Now let's look for passwords!  You could use strings and look for known credentials, just search for a known password and you will certainly find it.  Or you can take advantage of the format of the saved data:

<url of the site><protocol>< ><userid>< >password>

So, searching for "<tld><protocol>", which in most cases is "comhttps" (no spaces) will find most of them, and they'll all be in one nicely formatted group no less.  The command for that will be:

strings -n 8 msedge.DMP | find "comhttps"

looking a bit down in the output (since comhttps does match more stuff in the memory dump than just the credential list), I see:

As you can see, Edge isn't  my primary browser, but I do use it a fair bit for Azure work.  And yes, this is a real session, so I cropped/blurred out sensitive accounts and of course passwords.

It really is that easy.

And the ironic thing?  To view these same credentials in the browser, there's a whole security theatre process where Edge wants your biometrics as proof before disclosing even the userid and site names - you know, "for security".  All the while, the whole shot is in clear text, free for the looking ..

Also as noted in the X post, Microsoft classifies this as "intended behaviour".  I'm not sure what manager or lawyer decided that, hopefully it wasn't anyone in their security team.

Anyway, if the intent of this is to get me to use Firefox or Chrome, it's working!!

Have you seen a similar "strong front door / open window" security example in your forensics, please share in the comments (keeping any NDA's etc in mind of course)

=================

Update: 

Tom Jøran Sønstebyseter Rønning (@L1v1ng0ffTh3L4N) just posted with more detail on his research at: x.com/l1v1ng0ffth3l4n/status/2051308329880719730  (follow the comment thread for all the info)

The main thrust of it remains the same.  The logged in Windows user can dump all of their stored Edge credentials with no additional rights.  Which means that the malware that user executes also has those credentials for the asking

===============
Rob VandenBrink
rob@coherentsecurity.com

Summary

The most significant development of the week was the April 29 to 30 Mini Shai-Hulud worm, a self-propagating supply chain campaign that compromised four official SAP npm packages, two PyTorch Lightning PyPI versions, two intercom-client npm versions, and the intercom-php Packagist package across three package ecosystems. OX Security tracked roughly 1,800 GitHub repositories created with stolen credentials by the worm during the two day campaign, and Wiz attributed the operation to TeamPCP at high confidence based on a shared RSA public key with the prior Bitwarden CLI and Checkmarx KICS operations. Reporting suggests the campaign has now demonstrated cross-ecosystem worm propagation in production (npm to PyPI to Packagist), realizing the theoretical CanisterSprawl-style ecosystem-jump risk flagged in the W17 weekly. Separately, Check Point Research disclosed on April 27 to 28 that TeamPCP's extortion partner Vect ships a ChaCha20-IETF nonce-reuse flaw that effectively turns Vect 2.0 into a data wiper for any file larger than 128 KB, a finding analysts assess materially weakens the credibility of TeamPCP's Trivy-credential-trove monetization channel.

Dated event log

• 2026-04-27: Check Point Research published "VECT: Ransomware by design, Wiper by accident", a primary technical analysis of TeamPCP-affiliated extortion partner Vect 2.0. Check Point documents that Vect's encryption routine reuses a single ChaCha20-IETF nonce buffer across each 128 KB chunk; only the last nonce written to disk is recoverable, so any file larger than 131,072 bytes (VM disks, databases, document stores) is permanently destroyed even if the ransom is paid. The report ships six SHA-256 hashes for Vect Windows, Linux, and ESXi variants, and confirms the prior Vect-TeamPCP partnership announcement on BreachForums targeting the Trivy, LiteLLM, Telnyx, Checkmarx, and European Commission credential pools. Source: Check Point Research, https://research.checkpoint.com/2026/vect-ransomware-by-design-wiper-by-accident/.
• 2026-04-28: BleepingComputer, The Register, and HelpNetSecurity independently covered the Vect 2.0 wiper-bug disclosure within 24 hours of Check Point's report. Each outlet emphasized that paying the ransom does not recover files larger than 128 KB and that the bug is operationally indistinguishable from a deliberate wiper for the most valuable data classes. No public Vect operator response was identified. Source: BleepingComputer, https://www.bleepingcomputer.com/news/security/broken-vect-20-ransomware-acts-as-a-data-wiper-for-large-files/ and The Register, https://www.theregister.com/2026/04/28/dont_pay_vect_a_ransom/ and HelpNetSecurity, https://www.helpnetsecurity.com/2026/04/29/vect-ransomware-bug/.
• 2026-04-28: CISA added CVE-2024-1708 (ConnectWise ScreenConnect path traversal, exploited by Kimsuky) and CVE-2026-32202 (Microsoft Windows Shell spoofing, no specific threat actor identified in the KEV entry) to the KEV catalog. Neither addition is TeamPCP-related; the entry is logged here to document that the federal silence on TeamPCP-tied artifacts continued into W18 despite the W17 cascade. Source: CISA, https://www.cisa.gov/news-events/alerts/2026/04/28/cisa-adds-two-known-exploited-vulnerabilities-catalog.
• 2026-04-29: Four official SAP npm packages were poisoned between approximately 09:55 and 12:14 UTC: mbt 1.2.48, @cap-js/db-service 2.10.1, @cap-js/postgres 2.2.2, and @cap-js/sqlite 2.2.2. Combined weekly downloads exceed 500,000 across SAP's Cloud Application Programming (CAP) model and Cloud MTA build tooling. The malicious preinstall hook downloads the Bun runtime from the legitimate oven-sh GitHub release path and executes execution.js, an obfuscated information stealer that targets npm and GitHub tokens, SSH keys, AWS, Azure, and GCP credentials, Kubernetes configs, CI/CD secrets, and environment variables. The malware uniquely weaponizes .claude/settings.json and .vscode/tasks.json for AI coding agent persistence, which Wiz characterizes as the first observed supply chain attack to target AI coding agent configurations. Command and control resolves to the malicious endpoint hxxps://zero[.]masscan[.]cloud:443/v1/telemetry. Wiz attributes the operation to TeamPCP at high confidence based on a shared RSA public key with the Bitwarden and Checkmarx operations, a Russian-locale evasion check ("Exiting as russian language detected!"), and a shared PBKDF2 cipher salt ("ctf-scramble-v2", 200,000 iterations) consistent with prior TeamPCP malware. Source: Wiz Blog, https://www.wiz.io/blog/mini-shai-hulud-supply-chain-sap-npm and Socket, https://socket.dev/blog/sap-cap-npm-packages-supply-chain-attack and StepSecurity, https://www.stepsecurity.io/blog/a-mini-shai-hulud-has-appeared and BleepingComputer, https://www.bleepingcomputer.com/news/security/official-sap-npm-packages-compromised-to-steal-credentials/.
• 2026-04-30: The Mini Shai-Hulud worm spread from the SAP npm compromise into PyTorch Lightning (PyPI versions 2.6.2 and 2.6.3, approximately 2.1 million weekly downloads) and intercom-client (npm versions 7.0.4 and 7.0.5, approximately 300,000 weekly downloads). OX Security tracked the running count of stolen-credential GitHub repositories from approximately 1,200 (post-SAP wave) to 1,800 by April 30. The Lightning packages were published April 30; intercom-client's compromise is documented by OX as a downstream effect of its Lightning dependency being infected during a local install, demonstrating live worm propagation through ordinary developer activity. Source: OX Security, https://www.ox.security/blog/lightning-python-package-shai-hulud-supply-chain-attack/ and SecurityWeek, https://www.securityweek.com/sap-npm-packages-targeted-in-supply-chain-attack/.
• 2026-04-30: Socket reported that Mini Shai-Hulud also reached Packagist via intercom-php 5.0.2 (over 20.7 million lifetime installs, approximately 285,000 installs per month). The Packagist payload uses Composer's plugin system for install-time execution rather than the npm preinstall hook, and Socket published five SHA-256 hashes plus the same C2 endpoint. This converts the worm's cross-ecosystem capability from theoretical to demonstrated across npm, PyPI, and Packagist within a single 36 hour operational window. Source: Socket, https://socket.dev/blog/mini-shai-hulud-packagist-malicious-intercom-php-package-compromise.
• 2026-04-30: Dark Reading published "TeamPCP Hits SAP Packages With Mini Shai-Hulud Attack", returning TeamPCP to Tier 1 mainstream coverage for the second consecutive week. The article ties the Mini Shai-Hulud worm to the late-2025 Shai-Hulud npm worm lineage and to TeamPCP's prior 2026 Trivy and Checkmarx operations, and lists additional GitHub commit dead-drop strings ("beautifulcastle", "EveryBoiWeBuildIsAWormyBoi") plus the repository description marker "A Mini Shai-Hulud has Appeared". Source: Dark Reading, https://www.darkreading.com/cloud-security/teampcp-sap-packages-mini-shai-hulud.
• 2026-05-01: Five Eyes joint guidance "Careful Adoption of Agentic AI Services" was released by CISA, NSA, ASD ACSC (Australia), CCCS (Canada), NCSC-UK, and NCSC-NZ, with the underlying PDF dated April 30. The document covers supply-chain risk for agentic AI deployments at category level but does not name TeamPCP, UNC6780, Trivy, Checkmarx KICS, Bitwarden CLI, xinference, CanisterSprawl, or Mini Shai-Hulud. It is the only six-nation cyber product of W18. Source: CISA, https://www.cisa.gov/news-events/news/cisa-us-and-international-partners-release-guide-secure-adoption-agentic-ai.
• 2026-05-01: SecurityWeek published "Over 1,800 Hit in Mini Shai-Hulud Attack on SAP, Lightning, Intercom", aggregating the four SAP packages, two Lightning PyPI versions, two intercom-client npm versions, and intercom-php Packagist into a single attributed wave with approximately 1,800 GitHub repositories created from harvested credentials across the two day campaign. Source: SecurityWeek, https://www.securityweek.com/1800-hit-in-mini-shai-hulud-attack-on-sap-lightning-intercom/.
• 2026-05-01: CISA added CVE-2026-31431 (Linux Kernel "Copy Fail" local privilege escalation) to the KEV catalog. Not TeamPCP-related; included to document the second of two W18 KEV updates that did not act on TeamPCP artifacts. Source: CISA, https://www.cisa.gov/news-events/alerts/2026/05/01/cisa-adds-one-known-exploited-vulnerability-catalog.

Themes and trends

• Mini Shai-Hulud realized the cross-ecosystem worm risk in production. The W17 weekly's third watch item flagged that CanisterSprawl carried PyPI-jump logic without observed execution. In W18 a separate but TTP-aligned worm (Mini Shai-Hulud) executed a complete three-ecosystem chain (npm SAP packages to PyPI Lightning to Packagist intercom-php) within roughly 36 hours. Reporting suggests this is the first observed instance in this campaign of a single worm payload propagating across three package managers within one operational window. Analysts assess the cross-ecosystem capability is now empirically demonstrated and should be treated as table-stakes for future TeamPCP-attributed supply chain operations rather than a future threat.
• AI coding agent configuration files emerged as a new target surface. Wiz, Socket, and StepSecurity all flag that Mini Shai-Hulud explicitly weaponizes .claude/settings.json and .vscode/tasks.json to gain persistence inside developers' AI coding agents. Reporting suggests this is the first documented supply chain attack to target AI agent configuration as an execution vector, which has direct implications for any organization whose developers run Claude Code, Cursor, Continue, Cline, or similar tools with project-scoped trusted-paths. The choice of these specific files indicates the operators researched AI tool conventions before payload design rather than treating AI agents as incidental.
• TeamPCP's monetization arm took a serious technical hit. Check Point Research's April 27 to 28 disclosure that Vect 2.0 is effectively a wiper for files larger than 128 KB undermines the credibility of TeamPCP's primary extortion channel. Multiple Tier 1 outlets immediately framed the disclosure as "do not pay; recovery is not possible". Vect's victim count remained at 25 throughout W18 with no new TeamPCP-tagged listings, and Guesty data (deadline projected near April 24 in the W17 weekly) was not published. Analysts assess this is the third consecutive instance of TeamPCP-affiliated extortion failing to translate access into observable monetization, and the first instance of a fundamental cryptographic flaw being publicly disclosed in TeamPCP-affiliated tooling.
• Tier 1 coverage held for the second consecutive week. BleepingComputer, SecurityWeek, Dark Reading, The Register, and HelpNetSecurity all carried original W18 reporting on either the Mini Shai-Hulud SAP wave, the Vect wiper-bug disclosure, or both. This is the longest sustained Tier 1 cadence in the campaign since the original Trivy disclosure in March, consistent with the W17 observation that mainstream coverage tracks novel technical events rather than victim disclosures.
• The institutional response gap widened. Mini Shai-Hulud crossed three package ecosystems and named SAP (a Fortune 100 enterprise software vendor) as a victim publisher. Despite this, no CISA standalone advisory, no CISA KEV addition for any TeamPCP artifact, no FBI alert, and no Five Eyes product explicitly naming TeamPCP appeared in W18. The Five Eyes "Careful Adoption of Agentic AI Services" guidance dropped on May 1 and addresses supply-chain risk for AI agents categorically but is conspicuously silent on the TeamPCP campaign that demonstrated AI-agent-config weaponization 48 hours earlier. Analysts assess the gap between the operational tempo of the campaign and the cadence of public-sector response is now the single most striking feature of the campaign.

Watch items

• Additional Mini Shai-Hulud-attributed package compromises. Wiz, Socket, and StepSecurity all assess that the worm's stolen-token harvest will continue producing downstream compromises for as long as those tokens remain valid. Watch for new SAP, PyTorch Lightning, Intercom, or transitive-dependent package compromises in W19, and for any victim organization that publicly discloses pulling one of the malicious versions during the April 29 to 30 window.
• Mandiant or GTIG attribution statement on Mini Shai-Hulud and on xinference. Wiz claims TeamPCP attribution at high confidence via the shared RSA public key; Socket and StepSecurity hedge to medium confidence based on shared cipher salt and dead-drop string lineage. The xinference question (formal UNC6780 attribution by Mandiant or GTIG) remained unresolved through W18. Watch for any Mandiant, GTIG, or Microsoft Threat Intelligence publication that formalizes attribution for either the Mini Shai-Hulud wave or xinference.
• Vect operator response to the wiper-bug disclosure. Check Point's report fundamentally undercuts Vect's bargaining position. Watch for any Vect statement on the leak site, any patched Vect 2.1 release that fixes the nonce reuse, or any silent operational shift away from Vect toward an alternative TeamPCP-affiliated ransomware operator. A CipherForce return after approximately 70 days of silence would be analytically significant in this context.
• SAP, Lightning AI, and Intercom victim disclosures. Each of the three publisher organizations has stayed publicly quiet beyond noting that a security note was issued. Watch for SEC filings (SAP files Form 6-K), data-protection-authority notifications, or Lightning AI public statements regarding the scope of harvested credentials and the disposition of stolen tokens. The 36 hour cross-ecosystem window means downstream forensic disclosures are likely to materialize on a 7 to 21 day delay.
• CISA standalone TeamPCP advisory. The W18 institutional silence is now the longest such gap in the campaign. Watch for any CISA emergency directive, standalone advisory, KEV addition tied to a TeamPCP artifact, or named-actor product that finally breaks the federal silence. The combination of three-ecosystem worm propagation, AI-agent persistence weaponization, named SAP impact, and a publicly disclosed cryptographic flaw in the affiliated extortion tooling creates substantial pressure for a coordinated federal response in W19.

Source index

Tier 1 (major security publications)

• BleepingComputer (SAP npm compromise): https://www.bleepingcomputer.com/news/security/official-sap-npm-packages-compromised-to-steal-credentials/
• BleepingComputer (Vect wiper bug): https://www.bleepingcomputer.com/news/security/broken-vect-20-ransomware-acts-as-a-data-wiper-for-large-files/
• SecurityWeek (SAP npm): https://www.securityweek.com/sap-npm-packages-targeted-in-supply-chain-attack/
• SecurityWeek (Mini Shai-Hulud 1,800 repos): https://www.securityweek.com/1800-hit-in-mini-shai-hulud-attack-on-sap-lightning-intercom/
• Dark Reading (TeamPCP SAP): https://www.darkreading.com/cloud-security/teampcp-sap-packages-mini-shai-hulud
• Dark Reading (Vect wiper design error): https://www.darkreading.com/threat-intelligence/vect-ransomware-wiper-design-error
• The Register (Vect wiper): https://www.theregister.com/2026/04/28/dont_pay_vect_a_ransom/
• The Register (Mini Shai-Hulud): https://www.theregister.com/2026/04/30/supply_chain_attacks_sap_npm_packages/
• HelpNetSecurity (Vect bug): https://www.helpnetsecurity.com/2026/04/29/vect-ransomware-bug/
• The Record by Recorded Future: searched, no W18 TeamPCP coverage identified
• Ars Technica: searched, no W18 TeamPCP coverage identified
• CyberScoop: searched, no W18 TeamPCP coverage identified

Tier 2 (vendor threat intelligence)

• Wiz Blog (Mini Shai-Hulud SAP attribution): https://www.wiz.io/blog/mini-shai-hulud-supply-chain-sap-npm
• Socket (SAP CAP analysis): https://socket.dev/blog/sap-cap-npm-packages-supply-chain-attack
• Socket (Packagist intercom-php): https://socket.dev/blog/mini-shai-hulud-packagist-malicious-intercom-php-package-compromise
• StepSecurity (Mini Shai-Hulud Has Appeared): https://www.stepsecurity.io/blog/a-mini-shai-hulud-has-appeared
• OX Security (Lightning extension): https://www.ox.security/blog/lightning-python-package-shai-hulud-supply-chain-attack/
• Check Point Research (Vect wiper analysis): https://research.checkpoint.com/2026/vect-ransomware-by-design-wiper-by-accident/
• Aviatrix Threat Research Center (SAP npm coverage): https://aviatrix.ai/threat-research-center/official-sap-npm-packages-compromised-to-steal-credentials-2026/
• Mandiant / Google Threat Intelligence: searched, no W18 TeamPCP publication identified
• Unit 42 (Palo Alto Networks): searched, no W18 TeamPCP publication identified
• Elastic Security Labs: searched, no W18 TeamPCP publication identified
• CrowdStrike Blog: searched, no W18 TeamPCP publication identified
• SentinelOne / SentinelLabs: searched, no W18 TeamPCP publication identified
• Microsoft Security Blog: searched, no W18 TeamPCP publication identified
• Arctic Wolf: searched, no W18 TeamPCP publication identified

Tier 3 (government or institutional)

• CISA KEV addition (Apr 28, ConnectWise plus Windows, NOT TeamPCP-related): https://www.cisa.gov/news-events/alerts/2026/04/28/cisa-adds-two-known-exploited-vulnerabilities-catalog
• CISA KEV addition (May 1, Linux LPE, NOT TeamPCP-related): https://www.cisa.gov/news-events/alerts/2026/05/01/cisa-adds-one-known-exploited-vulnerability-catalog
• CISA / Five Eyes joint guidance (Agentic AI, May 1, does NOT name TeamPCP): https://www.cisa.gov/news-events/news/cisa-us-and-international-partners-release-guide-secure-adoption-agentic-ai
• CCCS Canada AL26-009 (Linux Copy Fail, NOT TeamPCP-related): https://www.cyber.gc.ca/en/alerts-advisories/al26-009-vulnerability-affecting-linux-cve-2026-31431
• ISC SANS diary 32926 (Update 008, internal author, included for completeness): https://isc.sans.edu/diary/32926
• CERT-EU, FBI / IC3, BSI Germany, Singapore CSA, NCSC UK, ACSC Australia, ENISA: searched, no new W18 TeamPCP-specific advisory identified beyond the prior March advisories of record

Tier 4 (social and dark web signal)

• ransomware.live Vect tracker (verified by direct fetch on 2026-05-04, victim count steady at 25, no new TeamPCP-tagged listings): https://www.ransomware.live/group/vect
• ransomware.live CipherForce tracker (verified by direct fetch on 2026-05-04, approximately 70 days dark, 6 victims): https://www.ransomware.live/group/cipherforce
• @pcpcats X account claim text referenced via SANS diary 32926 https://isc.sans.edu/diary/32926
• BreachForums and DarkForums: searched indirectly via aggregator services, no W18-window TeamPCP-specific posts surfaced

This week, I will release a few updates to our DShield honeypot. The update should happen automatically if you have "automatic updates" enabled on your system. There will be two major changes:

Compatibility with Ubuntu 26.04 / new versions of Raspberry Pi OS

Ubuntu released version 26.04 LTS about a week ago. It will pretty much work already, but I made some adjustments if you are using the "minimum server install". 24.04 will continue to be supported. There have been some issues with 26.04, particularly with some tools that were converted to Rust. You will be ok staying with 24.04 LTS for now. Earlier versions of Ubuntu (22.04, 20.04) will no longer be supported.

Whenever you upgrade your operating system to a new major version, I recommend you reinstall the honeypot from scratch. You may want to retain the "dshield.ini" file to simplify the reinstall. Reinstalling from scratch ensures that all required dependencies are installed.

For older Ubuntu versions, Python dependencies make support rather difficult. For in-place upgrades, I will try to maintain compatibility as much as possible, but new installs should use either 24.04 or 26.04.

The next update will also fix any issues with new versions of Raspberry Pi OS. The goal is to maintain compatibility with the 32- and 64-bit versions of "trixie" and "bookworm".  Testing for Raspberry Pi OS is a bit more complex because it requires physical devices. If anybody has a good way to virtualize Raspberry Pi OS: Please let me know :)

Updating Cowrie

The next update will also include an updated version of Cowrie. We have fallen quite a bit behind, and I hope to add some new features. If you currently do not see any Cowrie (ssh/telnet) logs in your account, please update your API key ("Auth Key"). Some older API keys are not compatible with the current version of Cowrie. Newer keys are random hexadecimal strings, while older keys are base64 encoded random strings.

As always, please use our contact form if you are running into any problems.

--
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

Wireshark release 4.6.5 fixes 43 vulnerabilities (38 CVEs) and 35 bugs.

This high number of fixes is due to AI:

"This release fixes quite a few vulnerabilities. This is due to to a recent trend in AI-assisted vulnerability reports."

 

Didier Stevens
Senior handler
blog.DidierStevens.com

Introduction

As macbooks and mac minis become more popular, we're seeing more campaigns targeting these macOS hosts. Malicious ads have popped up in search results that can lead potential victims to pages that present themselves as legitimate malware but instead are malware. This diary presents one such example from a malicious ad for a page that impersonates Homebrew we saw on Thursday, 2026-04-30.

Homebrew is a third-party package manager for macOS, and this page pushes MacSync Stealer malware. As I write this today (2026-05-01), the fake Homebrew page at hxxps[:]//sites.google[.]com/view/brewpage is still active.

Images

Shown above: Malicious ad in search results leading to fake Homebrew page.

Shown above: Information about the advertiser for the malicious ad.

Shown above: Fake Homebrew page with script to copy/paste for potential victims to download malware.

Shown above: Script from fake Homebrew page pasted to a terminal window on a macOS host.

Shown above: After running the script, this popup appears, and it collects the victim's password.

Shown above: After running the entering the password, this popup appears for the Terminal app to access the Finder app in macOS.

Shown above: This is the final popup that appears after running the script.

Shown above: During the infection, MacSync Stealer collects information from the host, temporarily saves it to /tmp/osalogging.zip and sends that file to the C2 server.

Shown above: Traffic from the infection filtered in Wireshark.

Shown above: Traffic from the infected host sending the /tmp/osalogging.zip file to the C2 server.

Indicators of Compromise

Example of URL from malicious ad:

hxxps[:]//www.google[.]com/aclk?sa=L&
ai=DChsSEwi24vK_v5aUAxXZS38AHRAFIWAYACICCAIQABoCb2E&
co=1&
gclid=EAIaIQobChMItuLyv7-WlAMV2Ut_AB0QBSFgEAMYASAAEgKrq_D_BwE&
cid=CAASugHkaEZtQvhFJBWvSVo_oMtlq6lKBxptjJBacaXOdzM28vxFNm3V2vrefacF48NMD0YvBIV9PCmn_d6X0uiMYDt5bwJYXaT6Lt7Mf3F-Mc3OK-0ugNt4GfcvQ0lOKkP1Sf8WVDXTMPeVMsHE8qxoG43Ta5BRER_Sre0RfChP39oVqtwRkowlKUUojM12uBAYWvejqokVOa_j7-uGyN1XrQ1ae6Tfaijfc9OvMC9QKQovm7p0DBitWtBJ_d4&
cce=1&
sig=AOD64_2EqeARnVjOoYvCwtJyl1AsolQe7g&q&
adurl&
ved=2ahUKEwjyq-2_v5aUAxU3g2oFHc28JOUQ0Qx6BAhnEAE

Example of fake Homebrew site URL:

hxxps[:]//sites.google[.]com/view/brewpage?gad_source=1&
gad_campaignid=23806351087&
gbraid=0AAAAACJ6-Kb3hWjjAWCyYLIj0YO5oQvtp&
gclid=EAIaIQobChMItuLyv7-WlAMV2Ut_AB0QBSFgEAMYASAAEgKrq_D_BwE

Domain used by C2 server for the MacSync infection:

glowmedaesthetics[.]com

Files from the infection:

SHA256 hash: a4fcfecc5ac8fa57614b23928a0e9b7aa4f4a3b2b3a8c1772487b46277125571

• File size: 225 bytes
• File type: ASCII text, with no line terminators
• File description: Copy/paste script from the fake Homebrew page.

SHA256 hash: 0d58616c750fc8530a7e90eee18398ddedd08cc0f4908c863ab650673b9819dd

• File size: 1,448 bytes
• File type: Paul Falstad's zsh script text executable, ASCII text
• File location: hxxp[:]//glowmedaesthetics[.]com/curl/63810ee8b478575f3b2c6c46160c1fd338b213c6fc11bb0069dac9bbb7db237d
• File description: Initial download from the copy/paste script

SHA256 hash: 86d0c50cab4f394c58976c44d6d7b67a7dfbbb813fbcf622236e183d94fd944f

• File size: 2,647 bytes
• File type: Paul Falstad's zsh script text executable, ASCII text
• File description: Shell script extracted from base64 text in the initial download

---
Bradley Duncan
brad [at] malware-traffic-analysis.net