CyberSip™ — Issue 116 — August 25, 2026

Today's picture

Check Point Research published BTR Reforged at Black Hat USA 2026, a technique that repurposes Microsoft Defender's own legitimately signed boot-time remediation driver to perform arbitrary kernel-level file and registry operations on every Windows version from Windows 7 through Windows 11 25H2, without exploiting any software vulnerability, without introducing any external driver, and without leaving a path to block the technique through Microsoft's Vulnerable Driver Blocklist or Windows Defender Application Control because the driver is a required Defender component. Splunk patched a critical CVSS 9.1 remote code execution vulnerability in its MCP Server app and a CVSS 8.8 unsafe model deserialization flaw in its AI Toolkit, alongside ten additional AI Toolkit vulnerabilities affecting access control, privilege management, and experiment isolation in environments where the toolkit loads AI models or manages Splunk searches. Atlassian released 100 security bulletins addressing critical and high-severity flaws in third-party dependencies across Bamboo, Bitbucket, Confluence, Jira, and Jira Service Management, with critical issues in Axios, Apache Tomcat, and Netty components used across all affected products.

Today's intelligence

3 items

01 HighBTR ReforgedCheck Point / Black Hat

BTR Reforged turns Microsoft Defender's own signed driver into a kernel-level file deletion and registry manipulation tool on every Windows version, with no way to blocklist it

No vulnerability is exploited. No external driver is introduced. The technique uses BTR.sys, a required Defender component already present on every Windows machine, by reverse-engineering its undocumented transaction protocol. An administrator with SeLoadDriverPrivilege can use it to delete security software at boot, before Defender user-mode services start. Check Point found no in-the-wild use. Specific Sysmon detection rules are published.

TechniqueBTR Reforged
Check Point Research

CVENone (no vulnerability
exploited)

RequiresAdministrator
SeLoadDriverPrivilege

AffectsWindows 7 through
Windows 11 25H2

Block pathNone via WDAC or
Vulnerable Driver
Blocklist

Sources The Hacker News Check Point Research

What happened

Check Point Research published BTR Reforged on August 20, 2026, alongside a main-stage presentation at Black Hat USA 2026 and DEF CON 34 by threat researcher Jiří Vinopal. The research describes a technique for abusing BTR.sys, Microsoft's Boot Time Removal Tool, a digitally signed kernel-mode driver that is a required component of Windows Defender. BTR.sys is not present as a persistent file on disk. It is embedded inside MpEngine.dll, the main Defender engine, and dropped, loaded, and then deleted when Defender needs to perform remediation operations, such as removing a detected malware file that is locked during normal system operation. Because the driver is loaded at boot during a window after the filesystem becomes writable but before Defender's user-mode services start, it can operate before any user-mode security monitoring is active. Vinopal reverse-engineered BTR.sys's undocumented transaction protocol. The protocol uses RC4 encryption with a hard-coded key that is consistent across all Windows versions from Windows 7 through Windows 11 25H2. Using this knowledge, Check Point built BTR_CLI, a proof-of-concept tool that extracts BTR.sys from the local MpEngine.dll, constructs encrypted transaction commands, registers the driver as a system service, and loads it. Once loaded in kernel mode, BTR.sys can delete arbitrary files, move files, and modify registry keys on the host. This includes deleting the binary files of competing security products or modifying security product registry configurations, all during the boot window before those products' self-protection mechanisms activate. The technique requires administrative privileges and SeLoadDriverPrivilege. It does not exploit any software vulnerability in BTR.sys. The driver behaves exactly as intended. The technique repurposes that intended functionality for attacker-controlled operations. Because BTR.sys is a required Defender component with a valid Microsoft digital signature, it cannot be added to Microsoft's Vulnerable Driver Blocklist without preventing Defender from functioning. Windows Defender Application Control cannot be used to block a Defender-required driver. Check Point found no evidence of real-world use of this technique in threat actor tooling or telemetry at the time of disclosure.

Why it matters

The class of attack BTR Reforged describes, using a legitimate, trusted, required system component to perform operations that would be blocked if performed by attacker-controlled code, is known as living-off-the-land. What distinguishes BTR Reforged from most living-off-the-land techniques is the combination of kernel-mode execution and the absence of any traditional patch path. Most living-off-the-land techniques use user-mode Windows tools or PowerShell. BTR Reforged operates at the kernel level, before user-mode security products are active, using a driver that cannot be removed from the system without removing Defender. The defensive implication is that traditional driver blocklisting, WDAC policies targeting unsigned or vulnerable drivers, and signature-based detection of malicious drivers do not apply here. The driver is legitimately signed. The driver is legitimately present. The driver is doing exactly what it was designed to do. The only observable signal is behavioral: the driver being loaded under unusual circumstances, with unusual transaction content, outside the normal Defender remediation workflow.

Don't miss

Check Point published specific Sysmon-based detection rules for BTR Reforged. The indicators are: Sysmon Event ID 15 (FileCreateStreamHash) where the target filename ends in .sys:changelist, capturing the encrypted configuration written to the driver's alternate data stream; a RegistryEvent creating a service key whose Args value contains :changelist and whose Group is Boot Bus Extender, especially without an accompanying Windows Event ID 7045 (Service Installed) entry; Sysmon Event IDs 11 and 23 logging rapid creation and deletion of the path \SystemRoot\Temp\BootClean.log by the System process at PID 4, a log path hardcoded in the driver that fires regardless of who called it; and Sysmon Event ID 6 (DriverLoad) immediately followed by Sysmon Event ID 23 (FileDelete) attributed to the System process, the kernel-mode execution fingerprint of a live BTR.sys trigger. These are behavioral rules that fire on the operational pattern of BTR.sys abuse rather than on signatures or driver hashes, which means they remain valid regardless of whether an attacker modifies the tool.

Potential actions

Implement the Check Point Sysmon detection rules for BTR Reforged in your endpoint detection configuration. The specific event IDs and conditions are documented in Check Point's BTR Reforged research paper. These rules detect the behavioral fingerprint of the technique rather than driver signatures, which is the only viable detection approach given that the driver itself is legitimately signed and required.
Enforce the principle of least privilege around SeLoadDriverPrivilege. The BTR Reforged technique requires this privilege, which should not be held by routine user or administrator accounts in production environments. Audit which accounts hold SeLoadDriverPrivilege using the Local Security Policy or group policy audit and restrict it to accounts with a documented operational need.
Configure behavioral EDR rules to alert on security-tool driver loads outside their expected process lineage and context. The BTR.sys driver should only be loaded in the context of a Defender-initiated remediation operation. Loads initiated by non-Defender processes or under non-standard service configurations are the detection target, as the Check Point research notes.

The Sip

No vulnerability. No external driver. Defender's own component, doing exactly what it was designed to do, under attacker-controlled instructions. Cannot be blocklisted. Cannot be WDAC-blocked without breaking Defender. No in-the-wild use yet. Implement the Sysmon rules Check Point published. Audit SeLoadDriverPrivilege. Do it before someone weaponizes the PoC.

02 HighSplunkMCP Server + AI Toolkit

Splunk patched a critical MCP Server RCE and twelve AI Toolkit vulnerabilities including unsafe model deserialization that runs arbitrary code from a loaded model file

CVE-2026-76404 in the Splunk MCP Server app gives an admin-level attacker arbitrary OS command execution. CVE-2026-76395 in the AI Toolkit lets a power-role user load a crafted model file that triggers unsafe pickle deserialization and runs arbitrary code on the Splunk server. Ten additional AI Toolkit flaws affect access control across experiment history, container management, and scheduled search privileges.

MCP Server RCECVE-2026-76404
CVSS 9.1
Fixed: 1.2.1

AI Toolkit RCECVE-2026-76395
CVSS 8.8
Fixed: 6.0.0

Other AI Toolkit10 more vulns
access control
privilege escalation

AdvisorySVD-2026-0808
August 19, 2026

ExploitationNot confirmed
in wild

Sources CybersecurityNews SecurityWeek

What happened

Splunk published advisory SVD-2026-0808 on August 19, 2026, addressing 17 vulnerabilities across the Splunk MCP Server app, Splunk AI Toolkit, Splunk Connect for Kafka, Cisco Talos Intelligence for Enterprise Security Cloud, and Splunk On-Call. CVE-2026-76404 is the most severe: a CVSS 9.1 remote code execution vulnerability in the Splunk MCP Server app versions before 1.2.1. The flaw is an unsafe deserialization vulnerability in the credential management component of the MCP Server. An authenticated attacker with the admin role can exploit it to execute arbitrary OS commands on the underlying system hosting the MCP Server. Splunk's advisory recommends disabling or removing the MCP Server app entirely if immediate patching to 1.2.1 is not possible. CVE-2026-76395 is a CVSS 8.8 unsafe deserialization vulnerability in the Splunk AI Toolkit's Model Loading REST API. It affects versions before 6.0.0. A user with the power role can submit a crafted model-loading request containing a malicious sparse matrix file with embedded pickle data. The AI Toolkit's model loading routine deserializes the pickle content without adequate validation, executing attacker-controlled code in the context of the Splunk service. Pickle deserialization vulnerabilities in machine learning frameworks are a recurring class: MLflow CVE-2026-64849 from Issue 112 had a related SSRF path for accessing cloud metadata. The present flaw converts model loading into code execution. Ten additional AI Toolkit vulnerabilities address access control gaps: improper privilege management allowing lower-privileged users to perform searches at system-level privilege, missing authorization for container and connection management, insecure access controls for experiment history visible across user accounts, and risky permissions for scheduled searches that run under the search owner's permissions rather than the scheduler's permissions. The Cisco Talos Intelligence component carries CVE-2026-76389, a high-severity SSRF vulnerability, addressed in the same release.

Why it matters

Splunk is the security information and event management platform for many enterprise environments, meaning it ingests logs, alerts, and telemetry from across the infrastructure it is supposed to protect. An attacker with code execution on the Splunk server does not only have code execution on one server. They have access to every log forwarded to Splunk, which includes authentication logs, network flow data, endpoint telemetry, and security alerts. They can modify alert rules to suppress detections, delete log data to destroy forensic evidence, exfiltrate aggregated security telemetry, and pivot to any system that the Splunk forwarder credentials have access to. The AI Toolkit flaws are separately significant because they extend the attack surface to the model-loading workflow: any Splunk user with power-role access who can submit a model file to the AI Toolkit can achieve code execution, which widens the precondition from admin to power-role, a significantly larger set of users in most Splunk deployments.

Don't miss

The Splunk MCP Server app is a relatively new component. The MCP Server app implements the Model Context Protocol inside the Splunk environment, allowing Splunk data and tools to be exposed to AI agents or AI-assisted workflows. It was introduced as Splunk began integrating with AI systems that use the MCP standard for tool connectivity. A CVSS 9.1 RCE in the MCP Server app's credential management component in a version released less than a year ago reflects the security challenge of rapidly deployed AI-integration components: they expand the attack surface of an already-sensitive security analytics platform while potentially carrying immature code quality in components that have not yet had broad security review. The AI Toolkit pickle deserialization flaw follows a similar pattern: the model loading feature that enables power-role users to load and run AI models in Splunk is an AI-integration capability that opened a code execution path. Both flaws are examples of the attack surface expansion that accompanies AI system integrations in enterprise platforms.

Potential actions

Update the Splunk MCP Server app to version 1.2.1 or later. If immediate update is not possible, disable or remove the MCP Server app from the Splunk instance as Splunk recommends. The CVE-2026-76404 flaw in the credential management component requires the app to be running; removal eliminates the attack surface entirely until the update can be applied.
Update the Splunk AI Toolkit to version 6.0.0 or later. The model loading deserialization flaw and the majority of the access control vulnerabilities are addressed in this release. Review which users in your Splunk deployment hold the power role and audit their model loading activity if the AI Toolkit was in use before August 19.
Review the full SVD-2026-0808 advisory for the complete list of affected components and version requirements. The Splunk Connect for Kafka, Cisco Talos Intelligence for Enterprise Security Cloud, and Splunk On-Call components have separate fix versions documented in the advisory that should be applied alongside the MCP Server and AI Toolkit updates.

The Sip

Admin-level MCP Server access gives OS command execution. Power-role model loading gives code execution through pickle deserialization. Both are in Splunk: the platform watching everything else. Update the MCP Server app to 1.2.1 and the AI Toolkit to 6.0.0. If the MCP Server cannot be updated today, remove it. The access it provides to the credential management layer is too broad to leave exposed.

03 HighAtlassian100 Bulletins

Atlassian released 100 security bulletins covering critical flaws in Axios, Apache Tomcat, and Netty across Bamboo, Bitbucket, Confluence, Jira, and Jira Service Management

All critical-severity issues in this release affect third-party libraries embedded in Atlassian Data Center and Server products, not Atlassian's own code. The critical Tomcat and Netty flaws can lead to remote code execution and man-in-the-middle attacks. The Axios flaws affect how Atlassian products make outbound HTTP requests. No exploitation of these specific instances confirmed.

Bulletins100 released
August 2026

Affected productsBamboo, Bitbucket
Confluence, Jira
Jira Service Mgmt
Fisheye/Crucible
Crowd

Critical libsAxios (3 CVEs)
Apache Tomcat (5)
Netty (1)

ExploitationNot confirmed
in wild (Atlassian
deployments)

Sources SecurityWeek News4Hackers

What happened

Atlassian published 100 security bulletins in its August 2026 security advisory cycle, addressing critical and high-severity vulnerabilities in third-party dependencies across its Data Center and Server product lines. All seven Atlassian product families received updates: Bamboo Data Center and Server, Bitbucket Data Center and Server, Confluence Data Center and Server, Crowd Data Center and Server, Fisheye and Crucible, Jira Data Center and Server, and Jira Service Management Data Center and Server. The critical-severity vulnerabilities all reside in third-party library components embedded in these products. Three critical CVEs affect the Axios HTTP client library used for outbound HTTP requests in Atlassian products: CVE-2026-42043, CVE-2026-40175, and CVE-2026-42264. Exploitation of the Axios flaws could enable server-side request forgery or man-in-the-middle attacks on outbound HTTP requests made by the affected Atlassian application. Five critical CVEs affect the Apache Tomcat application server embedded in Atlassian products: CVE-2026-41293, CVE-2026-43512, CVE-2026-43513, CVE-2026-43515, and a second instance of CVE-2026-41293 listed across multiple products. Successful exploitation of critical Tomcat vulnerabilities can lead to remote code execution in the context of the Tomcat service. One critical CVE affects the Netty network framework: CVE-2026-42584. Netty flaws can lead to man-in-the-middle attacks or denial-of-service conditions. No exploitation of these vulnerabilities specifically targeting Atlassian deployments has been confirmed. The vulnerabilities are in the underlying libraries; exploitation paths against the Atlassian embedding context may differ from standalone library deployments depending on how each product exposes the vulnerable component.

Why it matters

Atlassian's DevOps platform products, Confluence, Jira, Bitbucket, and Bamboo, are the development coordination and source code management infrastructure for many enterprise software teams. Critical vulnerabilities in the Tomcat and Netty components embedded in these platforms represent potential RCE paths against the servers running project management data, sprint tracking, code repositories, and CI/CD pipeline configurations. Atlassian has historically been a high-value target: Confluence has appeared on CISA KEV twelve times, Jira and Bitbucket have each appeared multiple times. Third-party library vulnerabilities in Atlassian products, while not direct Atlassian code flaws, have been exploited through the Atlassian attack surface in prior campaigns. The 100-bulletin volume reflects how broadly the underlying library flaws affect Atlassian's embedded component stack, not 100 distinct Atlassian vulnerabilities.

Don't miss

Atlassian's advisory guidance is explicit: organizations should update to a patched version of each affected product as soon as possible. The specific patched versions for each product and CVE combination are listed in the individual bulletins on Atlassian's security advisory page. The number of bulletins, 100, can make the update appear more complex than it is in practice: each product requires a single version update that addresses all the applicable bulletins for that product. The operational task is to identify which Atlassian products are running in the environment, check the current version against the minimum patched version in the applicable bulletins, and plan the upgrade. For organizations that update Atlassian products on a defined cycle, the August 2026 advisory cycle should be treated as a standard update event rather than an emergency, given the absence of confirmed exploitation targeting Atlassian deployments specifically.

Potential actions

Review Atlassian's August 2026 security bulletins on the Atlassian Support portal for each product deployed in your environment: Bamboo, Bitbucket, Confluence, Crowd, Fisheye, Jira, and Jira Service Management. Identify the current version in use and the minimum patched version listed for the applicable bulletins. Plan an upgrade to the patched version within your standard Atlassian update cycle, with earlier scheduling for internet-facing instances.
Prioritize update scheduling for Confluence and Bitbucket deployments that are accessible over external networks. These two products have the longest KEV history among Atlassian's portfolio and are the most likely targets for exploitation once a viable attack path against the embedded Tomcat or Netty components is established by researchers or threat actors.

The Sip

100 bulletins, all third-party library flaws, critical Tomcat and Netty issues that can reach code execution. No confirmed exploitation of Atlassian instances yet. Standard update cycle applies. Update each product to the minimum patched version in the bulletins. Prioritize internet-facing Confluence and Bitbucket first.

Cross-source standouts

BTR Reforged and the living-off-the-land ceiling: what happens when the tool is both required and unpatchable

Living-off-the-land techniques repurpose legitimate system tools and binaries to avoid detection. Most living-off-the-land defenses focus on monitoring the use of known dual-use tools: PowerShell, certutil, mshta, wmic, and similar binaries that are monitored specifically because attackers use them. The Microsoft Vulnerable Driver Blocklist and WDAC policies target a parallel class: malicious or vulnerable drivers. BTR Reforged represents a category that neither defensive approach addresses. BTR.sys is not a dual-use administrative tool: it is a Defender component. It is not a third-party driver that could be removed: it is required for Defender to function. It is not a vulnerable driver in the traditional sense: no vulnerability is being exploited. The driver is doing exactly what it was designed to do, under instructions that an attacker constructed. The defensive response Check Point documented, behavioral detection through Sysmon rules targeting the operational fingerprint of BTR.sys abuse, is the correct approach. But it requires that Sysmon is deployed, that the specific event IDs are being collected, that the detection rules are implemented and tuned, and that someone is watching the alerts. Organizations that rely on WDAC policies, driver blocklisting, or signature-based endpoint detection as their primary Windows security layers are not protected against this technique by those controls. The technique is also not theoretical: a complete proof-of-concept tool, BTR_CLI, was published at Black Hat USA 2026 and DEF CON 34. The gap between a public PoC presented at two of the largest security conferences and threat actor weaponization has historically been measured in weeks, not months.

Pickle deserialization in AI components: the recurring code execution pattern in enterprise AI integrations

CVE-2026-76395 in the Splunk AI Toolkit is a pickle deserialization flaw in the model loading REST API. An attacker with power-role access loads a crafted model file containing malicious pickle data, which executes when the AI Toolkit deserializes it. This pattern has appeared in multiple AI platform vulnerabilities this year. MLflow CVE-2026-64849, covered in Issue 112, involved SSRF through the webhook endpoint that could reach cloud metadata. Prior MLflow versions have been documented with pickle deserialization issues in model loading. Hugging Face's model loading ecosystem has documented pickle-based model file risks in its security guidance. The pattern is structural: machine learning model files, including pickle-format files used by Python's scikit-learn, PyTorch, and similar frameworks, are executable objects masquerading as data files. A model file can contain arbitrary Python code that executes when deserialized by the Python pickle module. Any AI toolkit or platform that accepts model files from users or external sources and deserializes them without sandboxing, format validation, or safe alternatives like safetensors, is exposed to this class of attack. The Splunk AI Toolkit flaw extends this risk into the security analytics platform itself: a power-role Splunk user can achieve code execution on the Splunk server by submitting a model file. Enterprise security teams evaluating AI toolkit integrations should treat model file loading from untrusted sources as a code execution risk equivalent to running arbitrary scripts, and should assess whether the toolkit enforces safe deserialization formats before allowing model loading from non-administrative users.

Still watching

Days 2–5

ShieldBreak CVE-2026-69414 (Issue 113 · patch in progress per August 21) — low privilege to SYSTEM on fully patched Windows 10, 11, and Server 2025. Patch confirmed in development. Monitor MSRC and apply the day it ships. Verify endpoint detection is current for CVE-2026-69414 specifically, not prior RoguePlanet detections.

Day 7+

GitLab CVE-2026-19478 (Issue 111/114 · confirmed exploited, NSA/CISA joint advisory) — upgrade to 19.2.4, 19.1.6, 19.0.8, or 18.11.11. Hunt @gl_introduced in web server logs from August 17 onward. Versions 18.2 through 18.10 have no patch; restrict /api/graphql as an interim control.

Day 7+

GeoServer zero-day (no CVE, no patch) (Issue 108 · active probing, jsonArrayContains SQL injection) — no patch as of August 25. Restrict public WFS endpoint access. Limit SQL Server backend permissions to block xp_cmdshell. Monitor for injection patterns in jsonArrayContains filter requests since August 12.

Day 7+

M365 Copilot prompt injection (Issue 98 · Hakon Maloy, reported March 7, 2026) — no CVE, no complete patch, 171 days. Enterprise Copilot prompt injection path remains open. Scope Copilot connector access tightly. Treat Copilot memory as a potential persistence mechanism requiring periodic review of stored contents.

Day 7+