Before we get to the data, however, let’s briefly recap what the headers in question do and why they are important.

Both headers basically serve the same fundamental purpose – they inform a browser whether the content of a given web page may be embedded in an iframe or similar object on another web page. Without either of these headers in place, any web page may freely load any other web page in an iframe, which can be quite beneficial in some instances, but also provides a functionality that is commonly abused by phishing actors[3].

The most common abuse scenario is related to a generic framing attack, and leads to what is sometimes called an “overlay phishing”. It is based on an attacker creating a malicious page which loads a legitimate website (usually the official company website of the recipient of the phishing) in a full-screen iframe, then overlays a fake login prompt on top of it. The result is that the victim sees what may appear to be the real login page. Setting either X-Frame-Options or CSP with the frame-ancestors directive on the legitimate site effectively mitigates this approach, because the browser will refuse to load the page inside an iframe in the first place, and all that would be displayed would be a fake login form over a browser message informing the user that a page cannot be loaded (which should make the credential stealing form apper less than trustworthy to most people).

This is a good reason why these headers are worth implementing on any organization's web site, regardless of how prominent or otherwise “interesting” the organization might consider itself to be. 

For completeness’ sake, it should be mentioned that although the two security headers serve a similar purpose, they are not exactly equal. The X-Frame-Options header is the older of the two mechanisms and, while functional, is relatively limited in what it can express. It supports three directives: DENY (the page may not be framed by anyone), SAMEORIGIN (the page may only be framed by pages on the same origin/domain), and ALLOW-FROM (the page may be framed by a specific origin/domain).

Although the header in general is still widely supported and does its job well, its ALLOW-FROM directive was never universally supported by all browsers and is now considered obsolete[4]. More importantly, however, the X-Frame-Options header as a whole has been basically superseded by the Content Security Policy frame-ancestors directive.

The CSP frame-ancestors directive offers considerably more flexibility than X-Frame-Options. It supports the same basic use cases (frame-ancestors 'none' being equivalent to DENY, frame-ancestors 'self' being equivalent to SAMEORIGIN), but also enables some additional ones (such as  supporting wildcard matching for subdomains etc.). Modern browsers therefore generally treat frame-ancestors as the authoritative directive, ignoring X-Frame-Options entirely when both are present[5]. That said, X-Frame-Options remains relevant for legacy browser compatibility and – in practice – both headers can be sent simultaneously without any harm, which is what many HTTP servers actually do.

With this context in mind, let us look at how the use of these headers has evolved since 2023.

The data was gathered using the same approach that I used in 2023 – I used a simple Python script that went through the current Tranco list of the 1 million most popular domains and attempted to connect to each one over HTTPS, recording which security-related headers were present in the response. The script performed no retries on failure, and the following numbers are therefore not completely precise. Nevertheless, based on a few tests, I would estimate the error rate to be significantly less than 0.5%, which I consider sufficient for our purposes of seeing whether and how the use of both “framing protection” headers has changed over time.

And as you may see from the following charts, which include both the 2023 and 2026 data for comparison, the numbers have indeed moved in an interesting way over the past three years (and the direction of movement is not entirely consistent across different sample sizes).

In the top 1 thousand most popular domains, the overall coverage by either X-Frame-Options or CSP frame-ancestors directive has actually decreased – from 27.1% in 2023 to 23.1% in 2026. On the other hand, in the top 100 thousand domains, the coverage has increased significantly – from 20.6% to 37.4% – and in the full top 1 million domains it has grown from 14.4% to 29.7%. The divergence between the top 1k and the larger samples is somewhat puzzling at first glance, though it likely reflects the fact that the composition of the top 1k list has changed quite a bit over three years, with domains of some security-conscious organizations dropping out of the top 1k and being replaced by domains that don't serve web content in the traditional sense (CDN endpoints, infrastructure domains, API backends, and so on) and therefore don't send security headers at all.

Looking at the breakdown of specific X-Frame-Options directives in use, SAMEORIGIN remains the most common choice across all sample sizes, which is not surprising, as it is generally the most practical option for most web applications.

In the top 1 thousand domains, SAMEORIGIN has actually declined (from 19.4% to 15.3%), while in the top 100 thousand and top 1 million, it has increased notably – from 16.9% to 20.8% and from 12.4% to 19.4% respectively. The DENY directive has seen modest increases across all sample sizes, and the ALLOW-FROM directive remains at negligible levels in the larger samples and is completely absent from the 1k sample.

When it comes to CSP with the frame-ancestors directive, the numbers tell an encouraging story across all sample sizes. In the top 1k, usage has grown from 7.9% to 9.4%. In the top 100k, it has more than doubled – from 3.8% to 7.9%. And in the full 1 million sample, the increase is even more dramatic, from 1.9% to 7.1%.

This, next to the aforementioned more than doubling of domains that use either CSP frame-ancestors or X-Frame-Options, is one of the two the most positive findings in the entire dataset. As discussed above, CSP frame-ancestors is the currently recommended approach for preventing framing attacks, so its growth relative to X-Frame-Options, as well as in absolute terms, is a welcome trend.

Looking at the specific values used in the frame-ancestors directive, 'self' remains the most common choice, which is consistent with the 2023 findings. The 'none' directive, which provides the strictest protection by disallowing framing entirely regardless of origin, has seen notable growth in the larger sample sizes – from 0.43% to 1.29% in the top 100k, and from 0.20% to 2.49% in the top 1 million. This suggests that at least some administrators are becoming more deliberate in their framing policies, choosing to explicitly disallow all framing rather than merely restricting it to the same origin. The use of specific domain(s) in the frame-ancestors value has remained relatively flat or slightly decreased across all sample sizes, which is expected, as this configuration requires more deliberate setup, and is generally only applicable to specific deployment scenarios (e.g. embedded widgets, single sign-on flows etc.).

To sum up, despite the slight regression in the top 1k, the overall picture that emerges from the 2026 data is noticeably more positive than the 2023 one. Both X-Frame-Options and CSP frame-ancestors are more widely deployed across the 1 million most popular domains – and one can therefore assume that across the internet as a whole as well – than they were three years ago. CSP frame-ancestors in particular has seen a very significant growth, which is encouraging.

On the other hand, even with these improvements, the data still shows that even the majority of the most popular domains on the internet do not use either of these headers at all, leaving their users potentially exposed to framing-based attacks, including the phishing techniques discussed at the beginning of this diary. Given how straightforward these headers are to implement (for most web applications, adding the appropriate response header is a matter of a single line of server configuration), there is clearly still considerable room for improvement across the industry as a whole.

Then again, this also means that it will be that much more interesting to see where things stand in another two or three years…

[1] https://isc.sans.edu/diary/29698
[2] https://tranco-list.eu/
[3] https://isc.sans.edu/diary/29638
[4] https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Frame-Options#allow-from_origin
[5] https://w3c.github.io/webappsec-csp/#frame-ancestors-and-frame-options

-----------
Jan Kopriva
LinkedIn
Nettles Consulting

This is certainly a busier-than-usual patch Tuesday. In particular, the large number of patched Chromium/Edge vulnerabilities underscores the impact of AI tools on vulnerability discovery. 

Some noteworthy vulnerabilities:

CVE-2026-49160: This vulnerability was made public a week ago. As implemented, the "HPACK" compression algorithm in HTTP/2 and HTTP/3 can lead to a "compression bomb" that consumes excessive resources. Many HTTP/2 implementations are vulnerable. Microsoft addressed this issue by adding a "MaxHeadersCount" registry setting that limits the amount of allocated resources.

CVE-2026-47291: Affecting the Microsoft web server engine http.sys, just like CVE-2026-49160, this vulnerability is rated critical and allows for remote code execution. The integer overflow requires an oversized request to trigger it. Microsoft recommends restricting the "MaxRequestBytes" to prevent exploitation until the patch can be rolled out.

CVE-2026-45648: A stack-based buffer overflow in Active Directory Domain Services. A successful attack requires authentication, and Microsoft considers exploit development as "unlikely".

Microsoft fixed three different BitLocker security feature bypass vulnerabilities. One of the vulnerabilities was already publicly known. An "anonymous" researcher is credited with the discovery, but I assume it is one of the "Nightmare Eclipse" vulnerabilities. 

Several critical vulnerabilities affect Microsoft Office, Outlook, and Word.

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

Bottom line up front

Two developments stand out since the last update. First, the federal response that prior coverage flagged as conspicuously absent arrived in a roughly 48-hour burst: on 2026-05-27 CISA added the campaign's primary tracking vulnerabilities to its Known Exploited Vulnerabilities catalog, and on 2026-05-28 it issued its first standalone advisory naming the Nx Console and GitHub repository compromises. Second, the leaked Mini Shai-Hulud framework produced its first significant in-the-wild npm wave: beginning 2026-06-01, a credential-stealing worm that Wiz named "Miasma" compromised dozens of @redhat-cloud-services packages, followed two days later by a "Phantom Gyp" variant that reached 57 more. Vendors trace the malware to the TeamPCP lineage but now explicitly caution that a copycat using the public toolkit cannot be ruled out. The affiliated extortion channels stayed frozen, so this period's activity was ecosystem-scale worming rather than named-victim extortion.

How this developed

The last update closed with two open questions: whether CISA would act on a campaign it had so far left out of the KEV catalog, and whether the framework TeamPCP published to GitHub would produce copycat attacks. Both resolved in the affirmative. CISA's KEV addition and standalone advisory closed the government-silence gap within roughly a day of each other. A week later, the Red Hat npm compromise demonstrated that the open-sourced code is now operational in other hands. The throughline is that the campaign has entered a phase where its tradecraft outlives any single operator: the same techniques, subverted build pipelines that emit validly signed artifacts and install-time credential theft, now arrive from attackers who may have no direct connection to TeamPCP at all.

What changed, by theme

CISA formally caught up

On 2026-05-27, CISA added three vulnerabilities to the KEV catalog, including %%cve:2026-45321%% (the TanStack / Mini Shai-Hulud tracking identifier) and %%cve:2026-48027%% (the malicious code embedded in the Nx Console v18.95.0 build), both carrying a federal remediation due date of 2026-06-10, alongside %%cve:2026-8398%% (DAEMON Tools Lite). This resolved the multi-week KEV omission that earlier coverage tracked as an open question. The additions were corroborated by SC Media and Security Affairs.

The next day, 2026-05-28, CISA published its first standalone advisory on the campaign, Supply Chain Compromises Impact Nx Console and GitHub Repositories. The advisory documents the poisoned Nx Console VS Code extension auto-distributed through the editor update mechanism, the exfiltration of approximately 3,800 GitHub-internal repositories, the assignment of %%cve:2026-48027%%, and a separate "Megalodon" campaign that injected malicious GitHub Actions workflows to harvest CI/CD secrets and cloud credentials in public repositories. CISA urges forensic review of CI/CD logs and cloud audit trails and rotation of all CI/CD-accessible secrets. TechRadar Pro and Cybersecurity Dive carried the advisory to a wider audience.

The leaked framework produced its first major wave: Red Hat npm

On 2026-06-01, a supply chain attack that Wiz named "Miasma" compromised at least 32 packages (across roughly 90 or more versions) published under the @redhat-cloud-services npm scope, with the affected packages cumulatively averaging about 80,000 weekly downloads. The attacker used a compromised Red Hat employee GitHub account to inject malicious GitHub Actions workflows into RedHatInsights repositories, so the malicious releases carried valid SLSA provenance attestations: the pipeline genuinely ran Red Hat code that contained attacker-injected steps. The payload was a credential-stealing worm with a preinstall script and new cloud-identity collectors for GCP and Azure, and the obfuscated index.js grew from roughly 200 KB to about 4.29 MB. Corroborated by BleepingComputer and Cybersecurity Dive.

Microsoft Threat Intelligence published its analysis on 2026-06-02, confirming the 32 packages across more than 90 versions and characterizing the payload as a lightly reskinned descendant of the Mini Shai-Hulud worm. Unit 42 folded the compromise into its running npm tracker the same day.

Install-time tradecraft advanced within days: Phantom Gyp

On 2026-06-03, a follow-on variant that StepSecurity named "Phantom Gyp" compromised 57 additional packages across 286 or more malicious versions in under two hours. Rather than modifying the package.json scripts field, the variant weaponized binding.gyp files to trigger node-gyp execution at install time, evading monitors that watch only package.json. The largest named victim was @vapi-ai/server-sdk, the official server SDK for the Vapi.ai voice platform, with over 408,000 monthly downloads. See TechTimes, corroborated by Wiz and Protos Labs.

Attribution is now genuinely ambiguous

Wiz, Microsoft, and Unit 42 all describe the Red Hat payload as Mini Shai-Hulud derived while explicitly warning that a copycat leveraging the public toolkit cannot be excluded. Wiz states the similarities should be treated as evidence of TTP overlap rather than definitive attribution to TeamPCP. This is the practical materialization of the copycat risk flagged when TeamPCP open-sourced its framework: the defender takeaway is unchanged, but single-incident attribution to the operators is now weaker than it was during the operator-run phase earlier in the campaign.

Signed provenance still does not save you

As with the earlier TanStack incident, the Red Hat packages shipped valid provenance attestations because the build pipeline itself was subverted from within. Trade reporting this period foregrounded the point that signed attestations cannot block a pipeline hijack. Build-provenance attestation confirms that an artifact came from a given pipeline; it does not confirm that the pipeline was free of attacker-injected steps.

Monetization stayed frozen

The affiliated extortion channels posted nothing in this period. Per direct checks of ransomware.live, the Vect leak site remained at 25 victims with its most recent listing dated 2026-04-15, and CipherForce remained at 6 victims with last activity dated 2026-02-23. The contrast from earlier in the campaign holds: the supply chain operation draws government and vendor attention while the affiliate-ransomware channel remains dormant.

What defenders should do now

• Treat the 2026-06-10 CISA remediation deadline for %%cve:2026-45321%% and %%cve:2026-48027%% as binding. Confirm no exposed Nx Console v18.95.0 install remains and that TanStack-related exposure is remediated.
• Rotate all CI/CD-accessible secrets and cloud credentials, and review CI/CD logs and cloud audit trails, per the CISA advisory. Assume any token reachable from a build pipeline is potentially exposed.
• Inventory use of the affected scopes (@redhat-cloud-services, and the earlier @antv) and packages such as @vapi-ai/server-sdk. Pin to known-good versions and rebuild from a trusted state.
• Monitor install-time execution beyond the package.json scripts field. Include binding.gyp and node-gyp hooks in detection, since Phantom Gyp moved specifically to evade scripts-only monitors. Consider running install with scripts disabled in CI where feasible.
• Do not rely on SLSA provenance attestations alone. Valid provenance does not defend against a compromised build environment; pair it with build-environment integrity controls and behavioral monitoring of install steps.
• Enforce two-factor authentication on registry maintainer accounts, scope publish tokens narrowly, and alert on anomalous workflow changes in source repositories.

Watch items

• A formal Red Hat post-incident statement and a definitive package and version inventory, including confirmation of the compromised employee-account vector and any downstream notification to consumers.
• Convergence or divergence on attribution. Watch for whether Mandiant or the Google Threat Intelligence Group issues a dedicated note either claiming the Miasma and Phantom Gyp waves as UNC6780 or designating a separate copycat cluster.
• Further binding.gyp and node-gyp install-time abuse beyond the @redhat-cloud-services scope, and whether registry-side or scanner-side detection adapts to install hooks outside package.json.
• The CISA KEV remediation deadline of 2026-06-10. Watch for deadline-driven follow-on guidance, KEV additions covering the Red Hat activity, or disclosure of federal-agency exposure as the date passes.
• Resumption of named-victim extortion. Watch the Vect and CipherForce leak sites for any end to their multi-month dormancy, which would signal a shift back from ecosystem worming to monetization.

Often, the WeTransfer brand is abused in phishing emails. Here, it's was an official link: 

hxxps://we[.]tl/t-R4Wv1JkvFfC4Awus

The thread-actor shared the initial file via this platform. The file is a piece of Javascript called "Remittance Advice.js" (SHA256:8a83de81fbac4eb0961f3d58982f299664a5fa4c874c7469e69f85f3fc5bd33f).

The contains a lot of junk code that will just do nothing:

Every for-loop will just move to the next line. In the middle of the file (>2MB), we have the interesting code that will perform the following tasks:

It will decode the next payload in an environment variable:

[Environment]::SetEnvironmentVariable("INTERNAL_DB_CACHE", <encoded_payload>)

The obfuscation technique used is ROT13, old but still very efficient:

cbjrefuryy.rkr -RkrphgvbaCbyvpl Olcnff -AbCebsvyr -JvaqbjFglyr Uvqqra -Pbzznaq

Decoded, it becomes:

powershell.exe -ExecutionPolicy Bypass -NoProfile -WindowStyle Hidden -Command

PowerShell is executed throug WMI:

• winmgmts:root\cimv2: connect to WMI
• Win32_ProcessStartup: configure process startup (hidden window)
• Win32_Process.Create(): spawn the process

The full command is:

powershell.exe -ExecutionPolicy Bypass -NoProfile -WindowStyle Hidden -Command [ScriptBlock]::Create(${env:INTERNAL_DB_CACHE})

This code will fetch an MSI background JPEG file from this location:

hxxp://icy-lab-0431[.]guilherme-telecomunicacoes2024[.]workers[.]dev/mCSlB

Note that the threat-actor likes to use well-known services to store his/her payloads. workers.dev is the default, free subdomain provided by Cloudflare for deploying serverless applications[2].

The technique to hide the next payload is the same as my previous diary. The Base64-encode payload is delimited here with "IN-" and "-in1". To defeat simple Base64 lookups, all "A" characters have been replaced by "#". Once decoded, the payload is a .Net DLL (SHA256:184a3008adff54cb345a599b4f3ca0c7bde29d8ac8379783ff40cd4e7ecc931b). It's a modified version of the Microsoft.Win32.TaskScheduler, an open-source .NET library for managing Windows Task Scheduler[3].

The PowerShell payload will also fetch another file that will be passed to the loaded malicious DLL:

hxxps://pub-a06eb79f0ebe4a6999bcc71a2227d8e3[.]r2[.]dev/snake.png

Here again, a legit online service is used. r2.dev is the default domain used by Cloudflare R2 to serve files and assets stored in public cloud-native buckets. It is a globally distributed, S3-compatible object storage service that allows developers to store large amounts of unstructured data[4].

The file looks to be another background and contains probably another payload protected by steganograpy (very common with the .Net loaders):

I'm now reversing the .Net loader. Stay tuned for more details soon!

[1] https://isc.sans.edu/diary/Malicious+Script+Delivering+More+Maliciousness/32682
[2] https://developers.cloudflare.com/workers/
[3] https://github.com/dahall/taskscheduler
[4] https://developers.cloudflare.com/r2/buckets/public-buckets/

Xavier Mertens (@xme)
Xameco
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

Microsoft has just released their coreutils version for Windows.

You can install them with a winget command (winget install Microsoft.Coreutils) or with the installer released on GitHub.

It takes just a few clicks:

It installs a single executable compiled with Rust (coreutils.exe) in the program files folder:

And each individual command is a hard link to this executable:

Here is the full list of commands:

arch.cmd
b2sum.cmd
base32.cmd
base64.cmd
basename.cmd
basenc.cmd
cat.cmd
cksum.cmd
comm.cmd
cp.cmd
csplit.cmd
cut.cmd
date.cmd
df.cmd
dirname.cmd
du.cmd
echo.cmd
env.cmd
expr.cmd
factor.cmd
false.cmd
find.cmd
fmt.cmd
fold.cmd
grep.cmd
head.cmd
hostname.cmd
join.cmd
link.cmd
ln.cmd
ls.cmd
md5sum.cmd
mkdir.cmd
mktemp.cmd
mv.cmd
nl.cmd
nproc.cmd
numfmt.cmd
od.cmd
pathchk.cmd
pr.cmd
printenv.cmd
printf.cmd
ptx.cmd
pwd.cmd
readlink.cmd
realpath.cmd
rm.cmd
rmdir.cmd
seq.cmd
sha1sum.cmd
sha224sum.cmd
sha256sum.cmd
sha384sum.cmd
sha512sum.cmd
shuf.cmd
sleep.cmd
sort.cmd
split.cmd
stat.cmd
sum.cmd
tac.cmd
tail.cmd
tee.cmd
test.cmd
touch.cmd
tr.cmd
true.cmd
truncate.cmd
tsort.cmd
unexpand.cmd
uniq.cmd
unlink.cmd
uptime.cmd
wc.cmd
xargs.cmd
yes.cmd

Didier Stevens
Senior handler
blog.DidierStevens.com