❌

Normal view

The Model Has Preferences, but the Harness Got Controls - Part 1

26 October 2026 at 23:14

The Model Has Preferences. The Harness Has Controls.

This is another collaboration between Usman Chaudhary and myself (his version); this time we decided to explore the mystery of “is harness a security boundary?”

Part 1 of 3 on securing agents. The theme here is: we think that despite alignment efforts, models will make mistakes. The fix is not a better prompt or more more more alignment work. The fix includes a hard boundary around the model, and that boundary is the harness, in some cases.

TL;DR

  • Agent = Model + Harness. The model reasons and expresses preferences. The harness executes, and it is the primary execution boundary between model intent and real-world action.
  • The model cannot be the security boundary. It is non-deterministic, it treats untrusted text as instructions, and it cannot police itself. A second “guard” model is a useful filter, not a wall.
  • The harness is the boundary, the way a firewall and OS sandbox are boundaries for an application. It sits between the model and the enterprise gateway, and today it is the least mature and least watched layer in the stack.
  • Fixing it requires two things: controlling what the agent can do through the harness (sandbox [which nobody should trust as a sole security boundary!], narrow identity, egress allowlists) and securing the harness itself as production software (configs, dependencies, and SIEM telemetry). This would be annoying to hear for some.

1. The Incident: A Database Gone in Nine Seconds

Nine seconds. That is how long it took an AI coding agent at PocketOS in late April 2026 to delete the company’s production database and take the attached backups offline right alongside it.

What happened, per Railway’s technical write-up:

  • The agent hit a credential mismatch and went looking for a fix.
  • It found a cloud API token that let it do far more than fix anything.
  • It deleted the production database volume and made the attached snapshots unavailable — leaving PocketOS with three-month-old backups and a 60-hour recovery.

Its own summary afterward was painfully candid, for a 2026 AI:

“I guessed instead of verifying, I ran a destructive action without being asked.”

The tempting question is the wrong one.

  • ❌ Why did the model make a bad decision? Models will make bad decisions. Humans do too, and we have spent decades building controls that assume exactly that. “AI as insider” thinking works well here.
  • ✅ Why was a bad decision allowed to become an irreversible action? This to us shows lack of security engineering, not “OMG is AI evil or what?” lamentations.

This post argues that the answer lives in the agent harness, not the model.

2. How Agents Work: Model + Harness

The most useful mental model for securing AI agents is also the simplest: Agent = Model + Harness.

  • The model reasons. It is probabilistic. It predicts tokens, plans steps, and expresses preferences. It can be persuaded, confused, and tricked.
  • The harness executes. It is everything that turns reasoning into action: the agent loop, shell and tool executors, MCP servers, repo config files, approval prompts, the OS sandbox, and (crucially) the credentials the agent runs with. Claude Code, Cursor, Codex CLI, Gemini CLI, and GitHub Copilot’s agent mode are all harnesses.

👉 A model that declines an action is expressing a preference. A harness that will not execute it is enforcing a control. That sentence is the thesis of this post.

None of this is new security philosophy. Least privilege, isolation, identity, and audit logging are decades old. What agents change is where those principles must be enforced and how fast.

Figure 1. Agent = Model + Harness. The model proposes actions; the five harness zones around it permit, block, or constrain them.

3. Why the Model Cannot Be the Security Boundary

Let’s be blunt about something the industry keeps dancing around: the model will never be a reliable security boundary, and it is pointless to treat it as one.

Three reasons, none fixable with a better system prompt:

  • It is non-deterministic. The same input can produce a different action tomorrow. A boundary that holds 97% of the time is not a boundary; it is a statistic [I think Claude said this, sounds like it :-)]. Security boundaries are supposed to be boring and repeatable, not fun and adventurous.
  • It consumes untrusted text as instructions. Agents read attacker-controlled text all day in READMEs, issues, PR comments, web pages, and tool descriptions, and models fail to reliably separate retrieved data from instructions. The UK NCSC calls LLMs “inherently confusable”; OpenAI and Google both say prompt injection is “unlikely to ever be fully ‘solved’”. Model refusals help [as long as they reject attackers, not defenders, duh!], but they do not hold: in the Nx supply-chain attack, guardrails rejected roughly a quarter of Claude invocations and the attack still succeeded.
  • It cannot police itself (self-review). Asking the actor model whether its own next action is safe is asking the suspect to run the investigation. And you do not need a rogue-AI scenario to see the risk: well-intentioned agents have already wiped production databases at Replit during a declared code freeze and at PocketOS, simply because their judgment failed and their blast radius was too wide. Maybe in the future it will, but not it cannot.

“What about a second model that checks the first?” Simple, beautiful, “secure” model, right?

Independent guard and reviewer models (Google’s Model Armor and the reviewer models OpenAI and Anthropic now ship inside their harnesses, as do many other security vendors) are a real risk-reduction layer, and we recommend them. But a reviewer model is still a probabilistic filter, not a final authorization boundary. You have stacked a second set of preferences on top of the first set: Anthropic’s own reviewer publishes a 17% false-negative rate across 52 real overeager actions. A useful filter, but not a wall, and not “a security invariant” for sure.

The Appsec vs. Firewall Analogy

We have been here before with web applications. Application security (secure coding, input validation, code review) makes the app harder to exploit, but every serious app still ships bugs — so we put runtime boundaries (firewalls, WAFs, OS sandboxes, IAM) around the app to enforce rules it cannot violate even when it is buggy or actively exploited. Agents work the same way:

  • Model alignment, safety training, and prompting ≈ agent “appsec”/modelsec (fewer bad decisions, never zero).
  • The harness ≈ runtime enforcement (sandbox [usually porous], tool policy, and IAM that keep bad decisions from becoming irreversible actions).

👉 The harness is the security boundary for the model, exactly as the firewall and sandbox are boundaries for the app — not because the model is bad, but because software fails.

4. Defense in Depth: Model, Harness, and Gateway

Saying “the harness is the primary execution boundary” does not mean “only the harness matters.” In practice, an enterprise running agents relies on three control layers with distinct jobs:

  • 1. The model (alignment, safety training, refusals). Run by the model vendor to reduce the rate of bad decisions. Probabilistic.
  • 2. The harness (OS sandbox, tool policy, scoped identity, secrets handling, egress allowlist, approval gates, hooks, telemetry). Shipped by the AI vendor and configured by the customer to constrain all execution — both local and remote.
  • 3. The enterprise agentic gateway (policy, identity brokering, MCP proxying, DLP, and logging across external model, tool, and data traffic). Run by the enterprise security team to centralize policy and SOC visibility across agents.
Figure 2. Three control layers — and why local actions bypass the gateway. The harness mediates every proposed action; the enterprise gateway only sees traffic that leaves the endpoint.

The layers are not interchangeable:

  • ❌ A gateway does not see local endpoint execution. If a harness runs as the developer with — dangerously-skip-permissions, the gateway never sees a local rm -rf or secret read on a laptop.
  • ❌ A harness alone does not give the SOC a cross-team control plane.

And the harness is the least mature of the three. The model gets the research attention. The gateway is where enterprise vendors (ours included) are converging. The harness sits in the middle: shipped by AI vendors, configured by developers, treated as a productivity plugin, and mostly invisible to security.

BTW, one of us (Anton) will revisit defense in depth in the age of AI soon (this is one for cloud).

👉 If the harness is the execution boundary, it has to be built, configured, and watched like one.

5. Where the Harness Fails Today

Once you look at the harness as a security boundary rather than a developer convenience, three specific gaps stand out in how harnesses are deployed today.

1. Approval fatigue and bypass modes ( — yolo)

  • A coding agent makes hundreds of tool calls in a single session. Ask a human to approve each one at machine speed and they stop reading within the hour: Anthropic measured users approving 93% of permission prompts before it introduced auto mode. A control that everyone clicks through is not a control.
  • When friction gets too high, developers turn it off, and most major coding-agent harnesses expose an explicit bypass mode for exactly that ( — dangerously-skip-permissions in Claude Code, — yolo in Gemini CLI and Codex).

2. Over-privileged credentials and shared identity

  • Today, local harnesses typically inherit the developer’s ambient git keys, cloud tokens, and MCP connections into Slack, GitHub, and production consoles.
  • Unless sessions carry a separate agent identity, the agent’s blast radius equals the human’s — and the SOC cannot easily tell human and agent apart.

3. The harness itself is an unmonitored software attack surface

Harness CVEs and bypasses

  • Cursor’s MCPoison bound trust to a server’s name rather than its contents (Tenable).
  • A GitHub Copilot exploit used prompt injection to flip on its own auto-approve setting (Embrace The Red).
  • Even actively maintained harnesses ship bugs fast: Anthropic’s claude-code repository lists more than 30 security advisories.

Weaponized configs and flags

  • Agent config files are executable. In June 2026, the Miasma worm planted malicious configs across 73 Microsoft repositories that ran on open. No CVE required.
  • In the Nx attack, which leaked 2,000+ verified secrets, the malware invoked victims’ own AI CLIs with bypass flags to do its reconnaissance.

SOC blindness

  • Harness telemetry is opt-in and redacts prompts and tool arguments by default (Elastic Security Labs).
  • Copilot’s audit log omits local prompts entirely (GitHub).
  • Raw chain-of-thought is never released to customers (Anthropic).

👉 The first two gaps are failures to contain what the agent can do. The third is a failure to protect and monitor the harness itself.

6. How to Secure the Harness: Three Architectural Moves

Closing those gaps means doing two jobs at once:

  • Controlling what the agent can do (security within the harness): enforcing hard limits on execution and reach so a bad model decision cannot become a catastrophe.
  • Protecting the boundary itself (security for the harness): governing the harness’s code, configs, dependencies, and telemetry. A firewall with a remote code execution bug is not a boundary; neither is a harness whose config file can be rewritten by a README.

In practice, that comes down to three architectural moves:

  • Move A: Take enforcement out of the model. Run commands inside an OS sandbox with deterministic tool policy — backed by an independent, reasoning-blind reviewer model for judgment calls (stripped of the actor’s chain-of-thought so the agent cannot talk its way past the check) — with structured steering on blocked actions and human prompts reserved for irreversible ones.
  • Move B: Shrink what the agent can reach. Give the agent its own identity, short-lived scoped tokens, secrets kept outside the sandbox, and an egress allowlist — breaking Simon Willison’s “lethal trifecta” of private data, untrusted content, and an outbound channel.
  • Move C: Govern and watch the harness itself. Put agent config files under branch protection, pin MCP dependencies, and stream action telemetry and hooks to the SIEM.
Figure 3. Where harnesses fail — and the three moves that fix them. Moves A and B contain what the agent can do; Move C governs the harness itself.

Each move gets its own deep dive in Part 2 (hopefully!)

7. What the Harness Cannot Solve (Ever?)

A boundary is only trustworthy if you are honest about where it ends.

  1. Prompt injection at the model layer remains unsolved. That is not a gap in the harness story; it is the premise of it. Every harness control assumes injection can succeed and asks what happens next.
  2. Bugs inside the vendor’s harness are the vendor’s to fix. Pick vendors who publish advisories and ship fixes fast, and treat harness updates like browser updates.
  3. The endpoint remains the thinnest layer. AI detection and response on developer laptops, where most harnesses actually run, is immature. Cloud-hosted sessions sidestep part of this; local agents do not.

In other words, if you endpoints are owned, you need better host security, not “unbeatable” AI security (translation: it will get beaten anyway)

Conclusion & What’s Next

Strip away the new vocabulary and harness security is least privilege, isolation, identity, and logging, applied to a process that reads untrusted text and acts at machine speed. AI changes the speed of the attack, not the fundamentals of defense.

👉 The model will keep having preferences. The harness is where the controls go, and today it is the least watched layer in the stack.

Coming next (hopefully!):

  • Part 2: Three moves to secure the harness. Moves A, B, and C in detail: OS sandboxing and reviewer models (with the error and prompt-reduction rates vendors have published); dedicated identity, scoped tokens, and egress allowlists that break the lethal trifecta; and agent config as code, pinned MCP dependencies, and action telemetry in the SIEM.
  • Part 3: Nobody owns the whole problem. The shared-responsibility split between model providers and enterprises, which vendors ship which control today, the prerequisites that have to be true first, and five actions for this quarter.

Got comments? What stands between a coding agent’s bad decision and your production environment today? If the honest answer is “the model’s judgment,” you have a preference in a place where you need a control.

P.S. This blog is ended up being very overengineered, but you can forgive us for this perhaps :-)


The Model Has Preferences, but the Harness Got Controls - Part 1 was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

VU#645818: Xerj Console API authentication bypass leads to unauthorized credential minting

Overview

An authentication bypass vulnerability in the Xerj Console API allows sessions to bypass passkey-backed requirements during token issuance. By exploiting this flaw, an attacker with an existing valid token can create independent, persistent successor credentials directly through the console API. This allows the attacker to maintain access and potentially escalate privileges within the Xerj ecosystem, even if the initial token is revoked.

Description

Xerj is an open-source search and indexing engine tailored specifically for AI agents utilizing the Elasticsearch API, allowing AI models to query a structured index.

The vulnerability, CVE-2026-97406, stems from a flaw in how session states are authenticated and handled within the Xerj system architecture. According to the documented security contract, the issuance of new API tokens must be strictly authorized by a passkey-backed session. However, the Xerj implementation converts both standard browser sessions and API bearer tokens into the same generic AuthSession object. The token creation handler then accepts this generalized principal without verifying whether the session was authenticated via a passkey.
Because of this architectural oversight, an attacker who obtains or intercepts a valid Xerj API token can directly invoke the token creation endpoint, allowing them to create independent successor credentials with the same access levels of the original token. Furthermore, the Xerj platform lacks hierarchical revocation logic; consequently, revoking a compromised parent token has no effect on any descendant tokens spawned from it.

Impact

Exploiting this vulnerability allows an attacker to gain persistent, unauthorized access that completely bypasses multi-factor controls. The security risk escalates significantly if the compromised token belongs to a Xerj account owner. In this scenario, the newly created successor token retains full administrative authority. An attacker can use this persistent access to issue a new account invitation, redeem it in their own browser, and successfully enroll an entirely independent, attacker-controlled passkey. This grants the attacker permanent control over the Xerj instance and its sensitive data indices, rendering the revocation of the initial token completely ineffective.

Solution

The vendor could not be reached to coordinate this vulnerability and an official patch has not been made available at the time of this writing. Users are advised to monitor the project's GitHub repository for updates and install the latest version of this library once a fix has been released.

Acknowledgements

Thanks to the reporter, Shiran Guez, a Principal Application Security Architect.

This document was written by Laurie Tyzenhaus.

Vendor Information

One or more vendors are listed for this advisory. Please reference the full report for more information.

Other Information

CVE IDs: CVE-2026-97406
Date Public: 2026-10-20
Date First Published: 2026-10-20
Date Last Updated: 2026-10-27 14:47 UTC
Document Revision: 2

#StopRansomware: SafePay Ransomware

By: CISA
19 October 2026 at 21:18

Advisory at a Glance

Title #StopRansomware: SafePay Ransomware
Original Publication  October 20, 2026
Executive Summary

This advisory details recent activity by the SafePay ransomware group. SafePay actors have been highly active since August 2024, targeting businesses and critical infrastructure across North America, South America, Europe, and Australia. SafePay actors typically gain access to networks by stealing or guessing passwords, exploiting vulnerabilities in security systems, and using phishing tactics. 

Once inside the network, SafePay actors establish control by creating new accounts or taking over existing ones. They then use legitimate system tools to move through the network, identify valuable files, and disable security protections to avoid detection. Next, they encrypt the victim’s files, making them inaccessible, and leave a ransom note demanding payment in cryptocurrency. This advisory urges organizations to follow recommended security measures to reduce the risk and impact of SafePay ransomware attacks.

Affected Products
Key Actions
  • Regularly patch and update systems, especially firewalls, and other edge devices.
  • Implement Zero Trust Principle.
  • Restrict administrative tools and privileges to necessary users only.
  • Strengthen account security by implementing identity, credential, and access management (ICAM) policies and multifactor authentication (MFA).
Indicators of Compromise

For a downloadable copy of indicators of compromise, see: 

Intended Audience

Organizations: Government; Federal Civilian Executive Branch (FCEB); State, Local, Tribal, and Territorial (SLTT); Critical Infrastructure

Roles: Defensive cybersecurity analysts, vulnerability analysts, security systems managers, and operational technology (OT) owners and operators

Introduction

Note: This joint Cybersecurity Advisory is part of an ongoing #StopRansomware effort to publish advisories for network defenders that detail various ransomware variants and ransomware threat actors. These #StopRansomware advisories include recently and historically observed tactics, techniques, and procedures (TTPs) and indicators of compromise (IOCs) to help organizations protect against ransomware. Visit stopransomware.gov to see all #StopRansomware advisories and to learn more about other ransomware threats and no-cost resources. 

The Federal Bureau of Investigation (FBI), Cybersecurity and Infrastructure Security Agency (CISA), United States Secret Service (USSS), Germany’s Landeskriminalamt Rheinland-Pfalz, the United Kingdom’s National Crime Agency, and the United Kingdom’s North West Regional Organised Crime Unit—hereafter referred to as the authoring agencies—are releasing this joint advisory to disseminate known SafePay ransomware TTPs and IOCs identified through FBI, USSS, and Landeskriminalamt Rheinland-Pfalz investigations as recently as August 2026.

Since August 2024, SafePay ransomware group’s operations have affected a wide range of businesses and critical infrastructure in North America, South America, Europe, and Australia. SafePay ransomware was among the most active ransomware groups in 2026. The SafePay threat actors have impacted at least 600 separate victims from multiple critical infrastructure sectors.

The authoring agencies encourage organizations to implement the recommendations in the Mitigations section of this advisory to reduce the likelihood and impact of SafePay ransomware incidents.

Download the PDF version of this report:

For a downloadable copy of IOCs, see:

AA26-293A-STIX XML (XML, 40.23 KB )
AA26-293A-STIX JSON (JSON, 37.49 KB )

Technical Details

Note: This advisory uses the MITRE ATT&CK® Matrix for Enterprise framework, version 20. See MITRE ATT&CK Tactics and Techniques section of this advisory for a table of the threat actors’ activity mapped to MITRE ATT&CK tactics and techniques.

Initial Access

The FBI, USSS, and cybersecurity researchers observed SafePay threat actors obtaining initial access [TA0001] to organizations through various means, including credential exposure, implementing brute force password attacks [T1110], and exploiting virtual private network (VPN) access. SafePay threat actors use the IP addresses of the VPN provider “Mullvad” to attain initial access—specifically, SafePay threat actors use phished account profiles to access victim networks to exploit the following known Common Vulnerabilities and Exposures (CVEs) for edge device products:

Additionally, the authoring agencies observed SafePay threat actors exploiting the following vulnerabilities across internet-exposed systems [T1190] for initial access through automated scripts:

Execution, Persistence, Stealth, and Defense Impairment

After SafePay threat actors gain access to a victim network, they establish persistence by gaining administrative privileges on existing accounts [T1098], or on newly created accounts [T1136], using built-in administrative tools consistent with living off the land (LOTL) techniques. Once SafePay threat actors establish a foothold in a victim’s network, they use LOTL binaries (LOLBins) [T1218], such as PsExec [T1021.002] and Windows Remote Management (WinRM) [T1021.006], to execute commands on remote systems. In several instances, SafePay threat actors used ShareFinder.ps1—a PowerShell script function used for enumerating network file shares in Windows Active Directory environments—to identify valuable assets for exfiltration [T1059.001, T1059.003]. Additionally, SafePay threat actors used SharpShares.exe, a tool used to identify and enumerate network file shares.

As SafePay threat actors prepare for lateral movement, they commonly disable security software [T1685] to avoid detection. In some cases, the threat actors changed the passwords of system users, making valid logins impossible. SafePay threat actors have also been observed using software packing or virtual machine software protection to conceal their code [T1027.002].

Privilege Escalation

The authoring agencies observed SafePay threat actors using a User Account Control (UAC) Bypass Privilege Escalation technique [T1548.002] that creates an elevated process through a specified component object model, enabling the execution of malicious commands or binaries [T1059]. SafePay threat actors have also been observed using token impersonation methods [T1134.001].

Lateral Movement

To pivot laterally through a network and identify files for exfiltration [TA0010] and encryption, SafePay threat actors use legitimate tools like PsExec, WinRM, and Remote Management and Monitoring [T1569.002] software. They also employ Remote Desktop Protocol (RDP) [T1021.001, T1133] to expand their presence within the compromised network [T1021]. As SafePay threat actors move laterally through a network, they look for credentials to gain admin access and will create accounts, if needed.

Collection, Exfiltration, and Impact

SafePay threat actors use legitimate tools, such as FileZilla, 7-Zip, RClone, and WinRAR to compress files and collect data [T1560.001], and WinSCP and RClone to facilitate the exfiltration of data [T1048] from the compromised network to actor-controlled accounts. In some instances, SafePay threat actors use OneDrive to exfiltrate data [T1567]. In other instances, the SafePay threat actors installed legitimate remote desktop tools like AnyDesk or TeamViewer on the victim’s systems. SafePay threat actors use these tools to transfer ransomware and other software onto a victim’s system. Additionally, SafePay threat actors halt the Volume Shadow Copy Service and reset Network Attached Storage containing victim backup data to initial factory settings to inhibit system recovery attempts [T1490].

Following exfiltration, SafePay threat actors encrypt files [T1486] using a sophisticated hybrid encryption scheme to lock data. This involves combining a ChaCha20 stream cipher with an RSA public-key cryptosystem for a fast and secure key exchange. This multilayered approach customizes encryption methods based on file type and size and enables full or partial encryption. Data encrypted with the SafePay ransomware variant (appended with .SafePay) cannot be recovered without the decryption key. SafePay threat actors hold the encrypted data for ransom and typically demand a subset of company revenue in cryptocurrency in exchange for decryption software. SafePay threat actors leave a ransom note on the victim’s system, typically on the desktop or root directory, advising them that SafePay locked their system and to reach out over a chat portal at a TOR .onion website link with a victim ID as the login. To put pressure on the victim, a representative makes phone calls on behalf of the ransomware group. If the victim does not pay, SafePay posts the exfiltrated data to their SafePay leak website, which is linked in the ransom note. Following encryption, SafePay may delete itself from the victim’s filesystem [T1070.004].

Leveraged Tools

Table 1 lists publicly available tools and applications used by SafePay threat actors, including legitimate tools repurposed for their operations.
Note: These tools and applications should not be attributed as malicious without analytical evidence to support threat actor use and/or control.

Table 1. Tools Leveraged by SafePay Threat Actors
Tool Name Description
7-Zip An open source software that enables users to compress various file formats. SafePay threat actors maliciously use 7-Zip for data packaging and movement.
FileZilla An open source client that enables users to transfer files between servers. SafePay threat actors use FileZilla maliciously for data exfiltration.
Mimikatz A credential dumper that enables users to view and save authentication credentials, such as Kerberos tickets [T1550.002]. SafePay threat actors use Mimikatz for password exfiltration.
PowerShell A cross-platform task automation solution used for various malicious activities, including command execution. It is composed of a command-line shell, a scripting language, and a configuration management framework—which runs on Windows, Linux, and macOS. 
PsExec A tool designed to run programs that SafePay threat actors use to execute commands on remote systems.
RClone A legitimate command-line program used to sync files with cloud storage services, such as Mega. SafePay threat actors maliciously use RClone for data packaging and movement.
ScreenConnect A remote support, access, and meeting software that allows users to control devices remotely over the internet. SafePay threat actors use ScreenConnect for persistence and access.
ShareFinder.ps1 A PowerShell script used to scan an Active Directory network for shared folders. SafePay threat actors use ShareFinder.ps1 for exfiltration hunting.
WinRAR Archive utility used to split compromised data into segments and to compress [T1560.001] files into a .RAR format prior to exfiltration. SafePay threat actors use WinRAR for data packaging and movement.
WinRM A Windows-based protocol designed to facilitate remote management and automation. SafePay threat actors use WinRM for command execution.
AnyDesk and TeamViewer Legitimate remote desktop tool used for accessing and controlling computers over the internet. SafePay threat actors use AnyDesk and TeamViewer to transfer malware to the victim’s system.
AcronisDiskDirector A legitimate disk management tool.
SharpShares.exe A network scanning tool used for host discovery and enumeration.
NetExec A legitimate network assessment tool to enumerate systems, validate credentials, and manage remote operations across private networks.
Backblaze A command-line tool for file management within Backblaze B2 cloud storage. SafePay threat actors executed commands via b2.exe to exfiltrate a victim’s data.

Indicators of Compromise

Table 2 through Table 5 list IOCs associated with SafePay ransomware that allowed for the identification of malicious activity.
Disclaimer: The authoring agencies recommend organizations investigate or verify IP addresses prior to taking action, such as blocking. These IOCs were observed between November 2024 and August 2026.

Table 2. IP Addresses
IP Address Description
104.26.2[.]223 SafePay victim intrusion
140.82.114[.]4 SafePay victim intrusion
185.199.108[.]133 SafePay victim intrusion
77.37.49[.]40 SafePay victim intrusion
173.194.194[.]94 Hosting victim data
167.235.225[.]149 Client login panels
5.255.11[.]134 Used in exfiltration
88.119.167[.]239 soc.dll command and control
37.10.71[.]188 Used in exfiltration


Note: Some of these files are legitimate tools. The authoring organizations recommend organizations investigate or verify tool use prior to taking action, such as blocking.

Table 3. Malicious Files
Filename Description
1 - Copy.bat A batch script likely used to copy, stage, or move files during lateral movement or data collection.
CCleaner.exe/ CCleaner64.exe A legitimate system utility; however, it is suspicious if deployed in enterprise environments for file cleanup or anti-forensics.
CCleaner*.exe / *.dll A file used for potential masquerading or abuse of CCleaner components for execution or persistence.
dcsync.exe A tool used to perform DCSync operations to extract Active Directory credentials; high-confidence credential theft activity.
domains.txt An output file likely containing enumerated domain information.
DYRasWtb.exe A suspected malicious executable.
libsmb2.dll A library associated with Server Message Block (SMB) communication; may support lateral movement or file transfer.
Libwa*.dll A suspicious library set; likely part of a custom toolset or malware framework; requires further analysis.
License.txt A benign file that may accompany tool packages or be used for masquerading. In one instance, it accompanied the tool “S.P_Network Scanner.”
locker.dll A potential ransomware or encryption-related component.
netscan.exe A network scanning tool used for host discovery and enumeration.
netscan.lic / netscan.xml Output or configuration files associated with network scanning activity.
netscanNEW.zip Archive file potentially used to stage or transfer scanning tools.
nltest.exe Legitimate Windows tool used for domain trust enumeration; suspicious when used outside admin workflows.
oui.txt A MAC address vendor lookup output—network reconnaissance artifact.
ping.txt An output file from network connectivity testing.
portable.dat A potential configuration or staging file (context-dependent).
scan.xml An output file from scanning/enumeration tools.
sharefinder.ps1 A PowerShell script used to enumerate network shares (reconnaissance).
Socks.exe A tool used to establish SOCKS proxy for tunneling traffic.
Socks_werfault.exe A binary likely masquerading to blend with Windows processes.
subs.txt A possible staging file or list of targets/data for exfiltration.
svchost.exe A legitimate Windows process; suspicious if located outside System32 or used for masquerading.
wa_3rd_party_host_*.exe A file of suspicious binaries—likely part of SafePay threat actor toolset or masquerading components.
winrar.exe A legitimate archiving tool frequently used for data staging prior to exfiltration.
AnyDesk.exe A legitimate remote desktop tool for accessing and controlling computers over the internet; most of the time it is used to transfer malware to a victim’s system.
SharpShares.exe A network scanning tool used for host discovery and enumeration.
AcronisDiskDirector-12.5 / acro.exe / DiskDirector.exe / Acronis.exe A legitimate disk management tool.
b2.exe A command-line tool for data exfiltration to Backblaze B2 cloud storage.
nxc.exe The executable for NetExec, a legitimate network assessment tool used to enumerate systems, validate credentials, and manage remote operations across private networks.
Table 4. SHA-1 Hash Values
Hash File/Description
07353237350c35d6dc2c8f143b649cd07c71f62b 1.exe (ransomware binary)
b498a2683640c983bb069fa2ea9e67cef4a3797d Locker.dll PE32 executable
BBFED53E3BB1F306F4DA97D995CF4AE5B73AD081 locker.dll
d711a5af5aed48a3b36b98f4fcf52809aebef7a2 nxc
Table 5. SHA-256 Hash Files
Hash File/Description
921df888aaabcd828a3723f4c9f5fe8b8379c6b7067d16b2ea10152300417eae soc.dll
6c1d36df94ebe367823e73ba33cfb4f40756a5e8ee1e30e8f0ae55d47e220a6a RunPE bundled DLL
e79608cf1d6b51324c14bef8883054c1238ed5f080222cc464810e6e14adc346 Injected PE
327b8b61eb446cc4f710771e44484f62b804ae3d262b57a56575053e2df67917 locker.dll PE32 executable
a0dc80a37eb7e2716c02a94adc8df9baedec192a77bde31669faed228d9ff526 locker.dll
BBDD3620A67AEDEC4B9A68B2C9CC880B6631215E129816AEA19902A6F4BC6F41 SharpShares.exe

The following are IOC hostnames:

  • WIN-SBOE3CPNAL
  • WIN-3IUUOFVTQAR
  • WIN-DK18BI83M0S
  • WIN-I1HRRJHCEIV

MITRE ATT&CK Tactics and Techniques 

See Table 6 through Table 16 for all referenced threat actor tactics and techniques in this advisory. For assistance with mapping malicious cyber activity to the MITRE ATT&CK framework, see CISA and MITRE ATT&CK’s Best Practices for MITRE ATT&CK Mapping and CISA’s Decider Tool. 

Table 6. Initial Access
Technique Title ID Use
External Remote Services T1133 SafePay threat actors use external remote services, such as VPNs or other tools, to externally connect to an internal network.
Exploit Public-Facing Application T1190 SafePay threat actors attempt to exploit a vulnerability within a system to gain access. Common vulnerabilities include software bugs, glitches, or misconfigurations.
Table 7. Execution
Technique Title ID Use
Command and Scripting Interpreter: PowerShell T1059.001 SafePay threat actors use PowerShell, an interactive command-line interface and scripting environment contained within Windows, to identify code within a targeted network.
Command and Scripting Interpreter: Windows Command Shell  T1059.003 SafePay threat actors use the Windows command shell prompt to gain control of a component on a system that requires specific permissions depending on the command executed.
System Services: Service Execution T1569.002 SafePay threat actors use tools, such as PsExec, to execute commands on remote systems.
Command and Scripting Interpreter T1059 SafePay threat actors use Windows UAC to elevate a program’s privileges, enabling the execution of malicious commands or binaries.
Table 8. Persistence
Technique Title ID Use
Account Manipulation T1098 SafePay threat actors establish persistence by gaining administrative privileges on existing accounts.
Table 9. Privilege Escalation
Technique Title ID Use
Abuse Elevation Control Mechanism: Bypass User Account Control  T1548.002 SafePay threat actors use Windows UAC to elevate a program’s privileges and execute a task on an administrator-level permission scale.
Table 10. Stealth
Technique Title ID Use
Obfuscated Files or Information: Software Packing T1027.002 SafePay threat actors use software packing to conceal malicious code by means of encrypting an executable to avoid detection.
Indicator Removal: File Deletion T1070.004 SafePay threat actors delete files associated with the intrusion activity to minimize their digital footprint and obfuscate malicious activities.
System Binary Proxy Execution T1218 SafePay threat actors proxy the execution of malicious content with a trusted binary, often a Microsoft-signed file, to bypass signature-based network defenses.
Table 11. Defense Impairment
Technique Title ID Use
Disable or Modify Tools  T1685 SafePay threat actors disable security features, modify or delete registry keys or configuration files to impair functionality, and disable updates such as security patches on a system or network.
Table 12. Credential Access
Technique Title ID Use
Brute Force T1110 SafePay threat actors gain access to accounts by implementing brute force password attacks.
Table 13. Lateral Movement
Technique Title ID Use
Remote Services: Remote Desktop Protocol T1021.001 SafePay threat actors gain access to a valid account using RDP and typically disable cybersecurity features, such as Windows Defender, while using LOLBins.
Remote Services: SMB/Windows Admin Shares T1021.002 SafePay threat actors gain access to a valid account using SMB to enable lateral movement throughout a network.
Remote Services T1021 SafePay threat actors employ remote services to expand their presence within the compromised network.
Remote Services: Windows Remote Management T1021.006 SafePay threat actors use tools, such as WinRM, to execute commands on remote systems.
Table 14. Collection
Technique Title ID Use
Archive Collected Data: Archive via Utility T1560.001 SafePay threat actors use utilities to compress or encrypt collected data prior to exfiltration to change the format of the data to one compatible for transportation.
Archive Collected Data: Archive via Library T1560.002 SafePay threat actors use credential dumpers, such as Mimikatz, for password exfiltration.
Table 15. Exfiltration
Technique Title ID Use
Exfiltration Over Alternative Protocol T1048 SafePay threat actors exfiltrate data over an alternative protocol, including file transfer protocol, simple mail transfer protocol, HTTP/S, domain name system, SMB, or another network protocol variation that is not the main or current command and control channel.
Exfiltration Over Web Service T1567 SafePay threat actors exfiltrate data over web services, such as OneDrive.
Table 16. Impact
Technique Title ID Use
Data Encrypted for Impact  T1486 SafePay threat actors encrypt data on targeted systems to disrupt access to a particular system or network service. They then demand a ransom payment in exchange for a decryption key.
Inhibit System Recovery  T1490 SafePay threat actors disable services designed to assist in recovery of a corrupted system. In some cases, SafePay threat actors deleted all network-attached backups of company data.

Incident Response

If a potential compromise is detected, but ransomware actors have not (yet) encrypted items, organizations should take the following actions:

  1. Determine which hosts were compromised and isolate them by quarantining or taking them offline.
  2. Initiate threat hunting activities to scope the intrusion. Collect and review relevant artifacts, logs, and other data to identify threat actor TTPs, compromised devices and accounts, a timeline of activity, etc.
  3. Report the suspected compromise to the FBI and other agencies as appropriate (if located within the U.K., report the compromise to Report Fraud or local police force) (see the Reporting section for contact information).
  4. Apply eviction countermeasures, including those listed below, to contain the incident and eradicate the threat actor from the network (Note: Start applying countermeasures after collecting enough threat hunting data to inform effective countermeasure selection; this will likely overlap with threat hunting activities). 
    1. Use CISA’s Eviction Strategies Tool to assemble countermeasures for a systematic eviction plan—the tool comprises Playbook-NG (a web application) and COUN7ER (a database of post-compromise countermeasures mapped to adversary TTPs). 
      1. Use Playbook-NG and COUN7ER together to assemble a systematic eviction plan, or playbook, that leverages distinct countermeasures to contain and evict cyber threat actors. The playbook features a list of recommended response actions based on threat actor TTPs and includes each action’s intended outcome, preparatory steps, and associated risks. For more information, see CISA’s Eviction Strategies Tool fact sheet.
  5. Harden the network to prevent additional malicious activity (see Mitigations for guidance).

If compromise is detected and items have been encrypted, see the “Ransomware and Data Extortion Response Checklist” in CISA’s joint #StopRansomware Guide.

Mitigations

The authoring agencies recommend organizations implement the mitigations below to improve their cybersecurity posture on the basis of the threat actors’ activity. These mitigations align with the Cross-Sector Cybersecurity Performance Goals (CPGs) developed by CISA and the National Institute of Standards and Technology (NIST). The CPGs provide a minimum set of practices and protections that CISA and NIST recommend all organizations implement. CISA and NIST based the CPGs on existing cybersecurity frameworks and guidance to protect against the most common and impactful threats, tactics, techniques, and procedures. Visit CISA’s CPGs webpage for more information on the CPGs, including additional recommended baseline protections.

Organizations should implement the following mitigations:

  • Prioritize remediating known exploited vulnerabilities (KEVs) and keep all operating systems, software, and firmware up to date, as timely patching is one of the most efficient and cost-effective steps an organization can take to minimize its exposure to cybersecurity threats; specifically, prioritize patching KEVs in internet-facing systems. [CPG 2.B].
    • Additionally, using Binding Operational Directive 26-04 offers a framework for patch prioritization based on technology type and steps for forensics triage. Under its implementation guidance, it offers guidance and steps to perform forensic triage for severe vulnerability cases.
  • Implement identity, credential, and access management (ICAM) policies across the organization and require MFA for all services to the greatest extent possible—particularly for webmail, VPNs, and accounts that access critical systems [CPG 3.F].
  • Require all accounts with password logins (e.g., service accounts, admin accounts, and domain admin accounts) to comply with NIST’s digital identity guidelines; require employees to use long passwords and consider not requiring recurring password changes, as these can weaken security [CPG 3.B].
    • Use longer passwords consisting of at least 15 characters and no more than 64 characters in length.
    • Store passwords in a hashed format using industry-recognized password managers.
    • Add password user “salts” to shared login credentials.
    • Avoid reusing passwords [CPG 3.C].
    • Implement multiple failed login attempt account lockouts [CPG 3.E].
    • Disable password “hints.”
    • Refrain from requiring password changes more frequently than once per year.
      Note: NIST guidance suggests favoring longer passwords instead of requiring frequent password resets. Frequent password resets are more likely to result in users developing password patterns cyber threat actors can easily decipher.
  • Maintain offline backups of data and regularly test and maintain backup and restoration processes [CPG 3.O]; implementing this practice helps organizations avoid severe operational interruptions and prevents scenarios in which data is irretrievable.
  • Ensure all backup data is encrypted, immutable (i.e., cannot be altered or deleted), and covers the entire organization’s data infrastructure [CPG 3.K].
  • Implement a recovery plan to maintain and retain multiple copies of sensitive or proprietary data and servers in a physically separate, segmented, and secure location (e.g., hard drives, storage devices, or the cloud) [CPG 3.I, 3.O, 1.C].
  • Segment networks to prevent the spread of ransomware, as network segmentation can help control traffic flows between, and access to, various subnetworks and restrict adversary lateral movement [CPG 3.I].
  • Identify, detect, and investigate abnormal activity and potential traversal of the indicated ransomware with a network monitoring tool [CPG 4.B].
    • To aid in detecting ransomware, implement a tool that logs and reports all network traffic, including lateral movement activity on a network.
    • Endpoint Detection and Response (EDR) tools are particularly useful for detecting lateral connections as they have insight into common and uncommon network connections for each host.
  • Filter network traffic by preventing unknown or untrusted origins from accessing remote services on internal systems—this prevents threat actors from directly connecting to remote access services that they have established for persistence.
  • Review domain controllers, servers, workstations, and Active Directories for new, unactive and/or unrecognized accounts.
  • Disable unused ports.
  • Consider adding an email banner to emails received from outside of your organization. 
  • Audit user accounts with administrative privileges and configure access controls according to the principle of least privilege [CPG 3.G].
  • Implement time-based access for accounts set at the admin level and higher; for example, the Just-in-Time (JIT) access method provisions privileged access when needed and can support enforcement of the principle of least privilege (as well as the Zero Trust Maturity Model).
    • This is a process where a network-wide policy is set in place to automatically disable admin accounts at the Active Directory level when the account is not in direct need.
    • Individual users may submit their requests through an automated process that grants them access to a specified system for a set timeframe when they need to support the completion of a certain task.
  • Disable command-line and scripting activities and permissions, since privilege escalation and lateral movement often depend on software utilities running from the command line; if threat actors cannot run these tools, they will have difficulty escalating privileges and moving laterally [CPG 3.M].

These mitigations align with principles provided in the joint guide Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software. CISA urges software manufacturers to take ownership of improving the security outcomes of their customers by applying these and other secure by design tactics. By implementing secure by design tactics, software manufacturers can make their product lines secure “out of the box” without requiring customers to make additional configuration changes, purchasing product security add-in software and logs, monitoring, and making frequent security updates.

Validate Security Controls

In addition to applying mitigations, the authoring agencies recommend exercising, testing, and validating your organization's security program against the threat behaviors mapped to the MITRE ATT&CK for Enterprise framework in this advisory.

To get started:

  1. Select an ATT&CK technique described in this advisory (see Table 6 to Table 16).
  2. Align your security technologies against the technique.
  3. Test your technologies against the technique.
  4. Analyze your detection and prevention technologies’ performance.
  5. Repeat the process for all security technologies to obtain a set of comprehensive performance data.
  6. Tune your security program, including people, processes, and technologies, based on the data generated by this process.

The authoring agencies recommend continually testing your security program, at scale, in a production environment to ensure optimal performance against the MITRE ATT&CK techniques identified in this advisory.

Resources

Reporting

Your organization has no obligation to respond or provide information to the FBI and other authoring agencies in response to this joint advisory. If, after reviewing the information provided, your organization decides to provide information to the FBI or other authoring agencies, reporting must be consistent with applicable state and federal laws.

The FBI and other authoring agencies are interested in any information, to include boundary logs showing communication to and from foreign IP addresses, a sample ransom note, communications with threat actors, Bitcoin wallet information, decryptor files, and/or a benign sample of an encrypted file.

Additional details of interest include a targeted company point of contact, status and scope of infection, estimated loss, operational impact, transaction IDs, date of infection, date detected, initial attack vector, and host- and network-based indicators.

The authoring agencies do not encourage paying ransom as payment does not guarantee victim files will be recovered. Furthermore, payment may also embolden adversaries to target additional organizations, encourage other criminal actors to engage in the distribution of ransomware, and/or fund illicit activities. Regardless of whether you or your organization have decided to pay the ransom, the FBI and CISA urge you to promptly report ransomware incidents to the FBI’s Internet Crime Complaint Center (IC3), a local FBI field office, a local USSS Field Office, or CISA via the agency’s Incident Reporting System or its 24/7 Operations Center (contact@cisa.dhs.gov) or by calling 1-844-Say-CISA (1-844-729-2472).

In the U.K., report incidents of a cybercrime or fraud at the UK’s Home for Reporting Cyber Crime & Fraud or 0300-123-2040, your local police force, or use the non-emergency number 101.

Disclaimer

The information in this report is being provided “as is” for informational purposes only. CISA and the FBI/USSS do not endorse any commercial entity, product, company, or service, including any entities, products, or services linked within this document. Any reference to specific commercial entities, products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply endorsement, recommendation, or favoring by the FBI, CISA, or USSS.

The authoring agencies recognize that infrastructure used for malicious activity may be hosted on cloud or virtualized platforms where IP addresses can be dynamically or temporarily assigned. As a result, an address associated with malicious activity at one point in time may later be reassigned to benign services. Accordingly, these indicators should be interpreted as historically observed infrastructure within the activity window and should be corroborated with current network telemetry or additional intelligence sources when used for defensive or investigative purposes.

Version History

October 20, 2026: Initial version.

VU#410595: Google BoringSSL Name Constraints bypass in SAN validation logic

Overview

Five Name Constraints findings in BoringSSL (VU#410595.8–.12) describe cases where certificate names may not be constrained as intended. Records .8, .9, .10 and .12 concern the legacy crypto/x509 path; .11 concerns the newer pki path. Two have been fixed, one is accepted, one is disputed, and one was declined.

Description

Name Constraints limit the names a subordinate certificate authority may issue. The reports concern how BoringSSL applies those limits to certain SAN (Subject Alternative Name) forms. The records do not share one status, and they do not all affect the same validation path.

VU#410595.8 (Fixed 2026-03-04): A wildcard DNS name may not be treated as covering a specifically excluded host.

VU#410595.9 (Accepted): A URI with a colon before @ may cause the wrong host to be used when matching URI constraints.

VU#410595.10 (Disputed): The finding concerns first-@ domain extraction in rfc822Name constraint matching. How consuming mail applications interpret the submitted multi-@ input, and whether that creates deployment exploitation, was not established.

VU#410595.11 (Rejected): Trailing-dot handling in rfc822Name domains. The BoringSSL team declined this on 2026-02-28 as below its security threshold.

VU#410595.12 (Fixed 2026-03-04): Trailing-dot DNS names were not always normalized on the legacy validation path.

Using BoringSSL in a product does not mean that product invokes an affected path or name form.

Impact

These findings matter only where Name Constraints are enforced on an affected path, a trusted signature can be obtained over attacker-chosen SAN fields, and the accepted name is used for authorization. Mixed-library environments may accept or reject the same certificate differently. Presence of BoringSSL does not, by itself, mean that Chrome, Android, or other products are affected.

Solution

BoringSSL fixes land in the upstream repository and reach products through each product's own update process.

  • VU#410595.8 and .12 were fixed in commit 5774eca on 2026-03-04.
  • VU#410595.9 is accepted and under coordination.
  • VU#410595.10 is disputed.
  • VU#410595.11 was declined.

CERT/CC is not coordinating BoringSSL fixes. For vendor status, contact the BoringSSL team through the Google Issue Tracker. Operators should confirm whether their deployment uses an affected path, apply available updates, and keep issued SANs well formed. A second validator helps only when it uses the same inputs and fails closed.

Acknowledgements

Thanks to Oleh Konko for discovering and reporting these issues. This document was prepared with AI assistance by Timur Snoke.

Vendor Information

One or more vendors are listed for this advisory. Please reference the full report for more information.

References

  • [RFC 5280 §4.2.1.10 — Name Constraints](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.10)
  • [RFC 1035 — Domain Names: Implementation and Specification](https://datatracker.ietf.org/doc/html/rfc1035)
  • [RFC 3986 §3.2 — URI Authority Component](https://datatracker.ietf.org/doc/html/rfc3986#section-3.2)
  • [BoringSSL Source Repository](https://boringssl.googlesource.com/boringssl/)
  • [Google Issue Tracker](https://issuetracker.google.com/issues?q=componentid:187143)
  • [BoringSSL commit 5774eca — wildcard and trailing-dot fixes](https://boringssl.googlesource.com/boringssl/+/5774eca6004ed7c7467bd644c057797ca96b65f2)
  • [Same Certificate. Different Answers.](https://paperlock.org/findings/)

Other Information

CVE IDs:
Date Public: 2026-10-14
Date First Published: 2026-10-14
Date Last Updated: 2026-10-27 14:49 UTC
Document Revision: 5

VU#948176: Multiple TLS libraries can bypass delegation enforcement

Overview

This note covers thirteen library-specific records (VU#948176.6, .8–.19) of how widely used TLS libraries apply X.509 Name Constraints. The records describe cases where a constrained name may be accepted by one library and rejected by another. Some are fixed, some remain under review, and some were not accepted as security issues.

Description

Name Constraints are meant to keep a subordinate CA inside an allowed namespace. The records cover several name forms and do not all have the same classification. VU#948176.7 does not exist.

DNS case-sensitivity and wildcards. While RFC 5280 requires case-insensitive DNS matching, it does not explicitly define wildcard Subject Alternative Name (SAN) matching, leading to varied implementation behaviors. For instance, GnuTLS was found to perform case-sensitive comparisons on certain names (CVE-2026-3833, fixed in 3.8.13). Similar discrepancies regarding case handling in wildcard parent-constraint lookups were reported in Go, as well as wildcard inconsistencies in LibreSSL and wolfSSL. Additionally, pyca/cryptography was identified to check DNS Name Constraints against certificate SANs but failed to validate them against the requested peer name (CVE-2026-34073, fixed in 46.0.6).

IP addresses. Some libraries treat IPv4 and IPv4-mapped IPv6 forms as different when matching constraints. The Go security team determined that report did not meet its security bar; similar reports exist for Apple's Security.framework and Mozilla NSS and are included as comparative evidence.

URIs. Libraries can differ on which host they extract from a URI SAN. OpenSSL merged PR #30319 for an @ in the path, query, or fragment; a separate userinfo-colon report remains in triage. Related URI reports exist for Apple, NSS, and wolfSSL (CVE-2026-3547, fixed in 5.9.0). A well-formed single @ is handled per RFC 3986 by most implementations.

Common Name fallback. AWS-LC was reported to apply DNS constraints inconsistently when a leaf has no SAN and uses a wildcard Common Name (CN). The AWS-LC wildcard CN issue and a separate Unicode CN issue have been fixed.

Non-critical constraints. In the reported Mbed TLS configuration, non-critical Name Constraints are not enforced. RFC 5280 requires conforming CAs to mark the extension critical, and the reviewed Mbed TLS 3.x configuration rejects unsupported critical extensions. The vendor treats adding support as a feature request; the reporter's concern remains disputed.

Impact

These records matter only when an attacker can obtain a trusted signature over chosen certificate fields, reach an affected validation path, and the application uses the accepted identity for authorization. Validator disagreement alone is not exploitation. Effects, if any, are deployment-specific and may include acceptance of a name outside the intended namespace.

Solution

CERT/CC is coordinating remediation across the affected projects. The following summarizes available status; individual entries reflect different reporting and confirmation dates.

GnuTLS — CVE-2026-3833 fixed in 3.8.13.

pyca/cryptography — CVE-2026-34073 fixed in 46.0.6.

wolfSSL — CVE-2026-3547 fixed in 5.9.0. The wildcard was addressed in PR# 9991.

Go's crypto/x509 — Two reports are in triage. The IPv4-mapped IPv6 report was not accepted as meeting the project's security bar.

OpenSSL — PR #30319 was merged and, as confirmed on 10 September 2026, is present in all then-current publicly supported versions. The separate userinfo-colon report remains in triage.

Apple's Security.framework — Three reports submitted on 2026-03-16 remain in triage.

Mozilla NSS — IP-address report under coordination.

LibreSSL — Wildcard report under coordination.

AWS-LC — The wildcard-CN and Unicode-CN name-constraints issues are both fixed in AWS-LC v1.71.0 (released 2026-03-19); Rust bindings fixed in aws-lc-sys v0.39.0.

Mbed TLS — Non-critical Name Constraints are not enforced in the reported configuration. Marking the extension critical causes such chains to fail closed rather than adding enforcement.

Until updates are widely deployed, operators who depend on Name Constraints should confirm the behavior of the libraries they actually run, keep leaf certificates to explicit SANs, and treat issuance policy as the first control. A second validator helps only when it uses the same inputs and fails closed.

Acknowledgements

Thanks to Oleh Konko for discovering and reporting these issues. This document was prepared with AI assistance by Timur Snoke.

Vendor Information

One or more vendors are listed for this advisory. Please reference the full report for more information.

References

  • [RFC 5280 §4.2.1.10 — Name Constraints](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.10)
  • [RFC 5280 §4.2.1.6 — Subject Alternative Name](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.6)
  • [RFC 5280 §6.1.3 — Basic Certificate Processing](https://datatracker.ietf.org/doc/html/rfc5280#section-6.1.3)
  • [RFC 3986 §3.2 — URI Authority Component](https://datatracker.ietf.org/doc/html/rfc3986#section-3.2)
  • [CVE-2026-3833 — GnuTLS Name Constraints case-sensitivity (VU#948176.6)](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-3833)
  • [GnuTLS 3.8.13 Security Advisory](https://www.gnutls.org/news.html)
  • [CVE-2026-34073 — pyca/cryptography wildcard Name Constraints](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-34073)
  • [GHSA-m959-cc7f-wv43 — pyca/cryptography wildcard advisory(https://github.com/pyca/cryptography/security/advisories/GHSA-m959-cc7f-wv43)
  • [GHSA-3jrg-j22w-mpmc](https://github.com/aws/aws-lc/security/advisories/GHSA-3jrg-j22w-mpmc)
  • [GHSA-394x-vwmw-crm3 / RUSTSEC-2026-0044] (https://github.com/aws/aws-lc-rs/security/advisories/GHSA-394x-vwmw-crm3)
  • [CVE-2026-3547 — wolfSSL URI Name Constraints bypass](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-3547)
  • [pyca/cryptography v46.0.6](https://cryptography.io/en/latest/changelog/)
  • [wolfSSL 5.9.0 Release Notes](https://www.wolfssl.com/docs/release-notes/)
  • [wolfSSL PR# 9991](https://github.com/wolfssl/wolfssl/pull/9991)
  • [OpenSSL PR #30319 — URI authority parsing (VU#948176.12)](https://github.com/openssl/openssl/pull/30319)
  • [OpenSSL PR #30318 — smtpUTF8Mailbox](https://github.com/openssl/openssl/pull/30318)
  • [Mbed TLS Documentation](https://mbed-tls.readthedocs.io/)
  • [Same Certificate. Different Answers.](https://paperlock.org/findings/)

Other Information

CVE IDs: CVE-2026-34073
Date Public: 2026-10-14
Date First Published: 2026-10-14
Date Last Updated: 2026-10-27 17:01 UTC
Document Revision: 5

VU#166125: Bisheng has authentication bypass vulnerabilities

Overview

Bisheng contains three vulnerabilities: a pre-authentication account takeover mechanism via a legacy single sign-on (SSO) endpoint; an Insecure Direct Object Reference (IDOR) vulnerability that exposes cross-user workflow data; and prior to version 2.5.0, authenticated attackers could perform cross-user LLM credential abuse and data disclosure due to missing service-layer access checks. Together, these flaws could allow unauthenticated attackers to gain administrative control while enabling authenticated users access to sensitive data and hardcoded credentials.

Description

Bisheng is an open-source Large Language Model (LLM) application DevOps platform, developed by DataElement, designed to assist in building, managing, and scaling LLMs.

CVE-2026-96679 (Legacy SSO Bypass) A vulnerability resides in the legacy SSO endpoint (POST /user/sso). The application processes incoming JSON payloads containing arbitrary usernames and issues a valid JSON Web Token (JWT) without enforcing any form of caller authentication, such as signature verification, shared secrets, or network allowlisting. Furthermore, if the provided username does not exist, the system automatically registers the account. If this newly generated account matches the configured administrative username or is the first user in the system, it is automatically granted super-administrator privileges.

CVE-2026-96681 (IDOR Workflow Exposure) There are missing authorization controls across multiple version retrieval endpoints. The underlying source code retrieves flow and workflow version records based on user-supplied parameters without performing any data ownership or permission validation. Any authenticated user can query and read the complete Domain-Specific Language (DSL) configurations belonging to other accounts.

CVE-2026-100156 (Credential Abuse & Access Control Skip) Within the assistant service's prompt auto-optimization feature, endpoints accept an assistant identifier from the caller without verifying whether the caller owned that assistant. An assistant identifier is a mechanism that lets users or systems recognize that content or interactions come from an AI assistant rather than a human.

Impact

Authentication Bypass / Account Takeover: The legacy SSO vulnerability (CVE-2026-96679) allows unauthenticated attackers to bind their session to an existing victim's profile by completely skipping JWT validation, potentially granting full super-administrative access, leading to full application compromise.

Unauthorized Data Disclosure: The IDOR vulnerability (CVE-2026-96681) causes a breach of data confidentiality, as the system fails to properly validate whether the authenticated user has permission to access the resource.

Resource and Credential Abuse: The assistant service vulnerability (CVE-2026-100156) allows authenticated attackers to run unauthorized AI inferences billed directly to another user's provider account (such as OpenAI, Azure, or Anthropic), while also leaking the victim assistant's configured tools and workflows.

Solution

The vendor has addressed two of the three discovered vulnerabilities in subsequent software releases. CERT/CC recommends upgrading to patched releases.

CVE-2026-100156: The vendor has remediated the assistant service vulnerability in version 2.5.0.

CVE-2026-96681: The vendor has remediated the IDOR workflow vulnerability in version 3.0.0.

For the remaining unpatched vulnerability (CVE-2026-96679), DataElement/Bisheng has not responded to multiple coordination efforts. CERT/CC suggests implementing the manual mitigations below until an official update becomes available.

CVE-2026-96679 Legacy SSO Vulnerability: Administrators should consider the following defensive measures:

  • Avoid setting BISHENGPRO=true in the environment configuration.
  • Disable or deprecate the legacy SSO endpoint entirely, or enforce global JWT validation. The affected function is sso(), located in src/backend/bisheng/user/api/user.py, affecting the API endpoint POST /user/sso.
  • Restrict access to the POST /user/sso network path to loopback/same-origin to provide defense-in-depth.

Acknowledgements

Thanks to Louis Sanchez, Voke Cyber, for reporting these vulnerabilities.

This vulnerability note was prepared by Laurie Tyzenhaus.

Vendor Information

One or more vendors are listed for this advisory. Please reference the full report for more information.

Other Information

CVE IDs: CVE-2026-96681 CVE-2026-100156 CVE-2026-96679
Date Public: 2026-10-14
Date First Published: 2026-10-14
Date Last Updated: 2026-10-14 16:42 UTC
Document Revision: 2

VU#456950: Komodo Periphery agent contains an OS command injection vulnerability

Overview

Versions <= 2.2.0 of Periphery, an agent within the Komodo server management platform, is vulnerable to OS command injection due to missing validation of container names, through two vectors: container destruction and container log searches. This allows an authenticated attacker to execute arbitrary commands as root on the underlying host, enabling persistent compromise of infrastructure.

Description

Komodo is an open-source server and deployment manager, maintained by mogh.tech, widely used in self-hosted and Docker multi-server environments. Periphery is an agent service installed on servers to give Komodo control over Docker environments.

In vulnerable versions of Komodo, Periphery does not properly validate user-supplied Docker container names before those values are interpolated into shell commands used by the agent. Two operations exhibit this vulnerability: container destruction (DestroyContainer / RemoveContainer) and container log searches (SearchContainerLog / GetContainerLogSearch). Through both avenues, raw container names are directly inserted into sh -c command lines without any shell escaping or validation. These commands then run with Periphery's root privileges on the host OS and Docker socket.

Impact

An authenticated non-admin user can escalate privileges through OS command injection via a maliciously crafted container name. Successful exploitation enables arbitrary command execution as root on a target server within a Komodo deployment. Ultimately, this enables an attacker to establish persistence, achieve lateral movement, and completely compromise a user or organization's managed infrastructure.

Solution

Fortunately, Komodo was reached to coordinate this vulnerability, and a patch has been implemented to remediate the issue in versions 2.3.0 and higher. The CERT/CC recommends that all users update immediately.

Acknowledgements

Thanks to Muhammadjon Ahmadjonov for reporting this vulnerability. This document was written by Alex Lewis.

Vendor Information

One or more vendors are listed for this advisory. Please reference the full report for more information.

Other Information

CVE IDs: CVE-2026-110005
Date Public: 2026-10-13
Date First Published: 2026-10-13
Date Last Updated: 2026-10-27 14:41 UTC
Document Revision: 2

VU#382143: Lowcoder Query Library API contains cross-tenant authorization bypass allowing for data exfiltration

Overview

Lowcoder, version 2.4.10, contains an authorization bypass vulnerability in its Query Library feature’s API. Authenticated users with an admin or dev role can access private library-query data from other organizations within a multi-tenant Lowcoder instance.

Description

CVE-2026-16753 Lowcoder is an open-source low-code platform that allows individuals with minimal coding experience to build web applications through a visual drag-and-drop interface. Each Lowcoder project contains a centralized Query Library which stores the workspace’s data queries and sources for quick reuse; however, the LibraryQuery API service layer lacks organization-scope checks at two endpoints: metadata retrieval and query execution.

While the application features a role-based access mechanism (requires admin or dev), it only checks the role’s validity against the user’s own organization. The vulnerable endpoints do not validate whether the requested resource belongs to the requester's organization.

Impact

Any authenticated attacker with an admin or dev role in any organization on a multi-tenant Lowcoder instance can access other tenants’ Query Libraries. Note that these roles are granted by default for any self-signup account when LOWCODER_EMAIL_SIGNUP_ENABLED and LOWCODER_CREATE_WORKSPACE_ON_SIGNUP are TRUE. This allows an attacker to do the following:

  • Read the full Domain Specific Language (DSL) of any other organization’s library queries, including complete query configuration and each referenced datasourceId.

  • Execute any library query available on the instance, receiving response data directly from the affected organization’s backend data source.

Potential impacts include cross-tenant data exposure, modification, or destruction, as well as cost abuse via querying paid data sources using another tenant’s finances. By bypassing organization-level authorization, Lowcoder instances effectively function as shared environments for attackers, violating data isolation between organizations.

This vulnerability was confirmed against Lowcoder version 2.4.10.

Solution

Unfortunately, Lowcoder could not be reached to coordinate this vulnerability. To mitigate, Lowcoder administrators should restrict access to the affected Query Library API endpoints until an official security update is available. Administrators can reduce exposure by limiting application access to trusted users and reviewing admin and dev role assignments. Organizations operating multi-tenant Lowcoder deployments should consider isolating tenants into separate instances to prevent cross-organization data access. Where source-code modifications are possible, administrators should implement organization-level authorization checks for Query Library metadata retrieval and query execution.

Acknowledgements

Thanks to Louis Sanchez, member of Voke Cyber, for reporting this vulnerability. This document was written by Alex Lewis.

Vendor Information

One or more vendors are listed for this advisory. Please reference the full report for more information.

Other Information

CVE IDs: CVE-2026-16753
Date Public: 2026-10-13
Date First Published: 2026-10-13
Date Last Updated: 2026-10-14 16:02 UTC
Document Revision: 2
❌