Cyber Threat Brief — March 6 2026
Cyber Threat Brief — March 6 2026
Focus: Actionable technical intel for detection engineers. Every entry has MITRE-mapped artifacts and concrete detection coverage notes. Sources verified within 24 hours.
1. Cisco Secure Firewall Management Center (FMC) — critical auth bypass + insecure Java deserialization RCE
Summary
Cisco Secure FMC has two critical, unauthenticated bugs that can result in root-level compromise: an auth bypass in the FMC web interface (via an improper boot-time process) and a separate pre-auth insecure deserialization path that enables arbitrary Java code execution as root. The most defender-useful content in the last 24 hours is practical scoping guidance: exact vulnerable version ranges and a ready-to-run asset query for quickly finding exposed/at-risk FMC instances.
What’s New (Last 24 Hours)
A runZero write-up (published March 5) consolidated affected version cutoffs and provided a deterministic inventory query for locating potentially impacted FMC assets.
Actionable Intel
| Artifact | Type | ATT&CK Technique | Data Source | How to Use |
|---|---|---|---|---|
| Any inbound HTTP requests to the FMC web interface from untrusted networks (especially to rarely-used admin paths) | TTP | T1190 | Reverse proxy / web access logs | Prioritize exposure reduction: confirm whether the FMC management UI is reachable from the Internet or untrusted segments; alert on new/rare source IPs hitting the management UI |
| Delivery of a crafted serialized Java object (user-supplied Java byte stream) to the FMC management interface (pre-auth) | TTP | T1190 | Web access logs / WAF logs | Hunt for anomalous request sizes, binary-looking request bodies, and sudden spikes in 4xx/5xx around management endpoints; treat suspicious serialized-object delivery attempts as high priority |
| Post-exploitation child-process execution from the FMC Java/service context (root-level) | TTP | T1059.004 | EDR process telemetry / Linux auditd | Alert on Java (or FMC service) spawning shells/utilities (e.g., sh, bash, curl, wget) on FMC hosts; correlate to preceding inbound web requests |
| Impacted version cutoffs (examples): FMC prior to 7.0.9; prior to 7.2.11; 7.4.x prior to 7.4.6; 7.6.x prior to 7.6.5; prior to 7.7.12; 10.0.0 (RCE only) | TTP | T1190 | Asset inventory / vuln mgmt | Use these cutoffs to quickly scope patch urgency and isolate/segment management interfaces while patching |
runZero inventory query (string-match): os:="Cisco FMC%" AND os_version:>0 AND ((os_version:>="6.4.0.13" AND os_version:<="6.4.0.18") OR (os_version:>="7.0.0" AND os_version:<"7.0.9") OR (os_version:>="7.1.0" AND os_version:<"7.2.11") OR (os_version:>="7.3.0" AND os_version:<"7.4.6") OR (os_version:>="7.6.0" AND os_version:<"7.6.5") OR (os_version:>="7.7.0" AND os_version:<"7.7.12") OR (os_version:="10.0.0")) | TTP | T1595 | Asset inventory | Use as a fast first pass to identify candidates for patching and to validate you don’t have forgotten FMC instances sitting in flat management networks |
Potential Detection Coverage Based on MITRE ATT&CK Technique
| Source | Detections | Coverage |
|---|---|---|
| Splunk | ConnectWise ScreenConnect Authentication Bypass; CrushFTP Authentication Bypass Exploitation | These are generic web auth-bypass exploitation patterns (T1190) and can be repurposed as scaffolding: tune them to FMC management URIs and to “new/rare source IP → admin interface” access patterns. They do not directly key on FMC-specific endpoints/artifacts, so expect customization work. |
| Elastic | Potential Reverse Shell via Java; Telnet Authentication Bypass via User Environment Variable | The Java reverse-shell rule can help catch the “Java process spawns shell/network egress” post-exploitation shape (T1059). The auth-bypass rules are again generic (T1190) and mainly useful as detection patterns to adapt for FMC web logs rather than as drop-in coverage. |
| Sigma | Java Payload Strings; Process Execution Error In JVM Based Application | These can provide partial coverage for “Java-targeted exploitation indicators in access logs” and “JVM exploitation leading to RCE-like error patterns.” Map them to FMC by pointing them at FMC web access logs and JVM/service logs if available; they won’t be FMC-specific out of the box. |
Sources
- Cisco Secure FMC vulnerabilities: How to find impacted assets (runZero) — Published 2026-03-05
2. pyquokka FlightServer — Apache Arrow gRPC do_action() pickle deserialization RCE (Metasploit PR)
Summary
A new Metasploit PR targets pyquokka’s exposed Apache Arrow Flight gRPC service, where the do_action() handler deserializes attacker-controlled input via pickle.loads() without authentication. The defensive upside is clear: the exploit path is a narrow, high-signal combo (unexpected inbound gRPC/HTTP2 to an Arrow FlightServer + pickle deserialization behavior) that’s worth alerting on anywhere pyquokka is deployed.
What’s New (Last 24 Hours)
A Metasploit module PR was published describing an end-to-end exploit approach: hand-rolled minimal HTTP/2 + gRPC framing to deliver a pickle protocol 2 payload via a set_configs action, using a __reduce__ gadget to trigger os.system().
Actionable Intel
| Artifact | Type | ATT&CK Technique | Data Source | How to Use |
|---|---|---|---|---|
| Apache Arrow Flight gRPC exposure (unexpected inbound HTTP/2 gRPC traffic to a pyquokka FlightServer) | TTP | T1190 | Firewall / NetFlow / NDR | Identify and alert on inbound gRPC to pyquokka services; if pyquokka is not expected to be Internet-facing, treat any external inbound as suspicious |
do_action() handler accepting attacker-controlled data that is passed to pickle.loads() | TTP | T1190 | App/service logs (if instrumented) | If you can instrument/trace Python services, alert on pickle deserialization on network-controlled inputs; otherwise treat as “patch/exposure” priority |
gRPC action name set_configs used as the delivery mechanism for the malicious pickle payload | TTP | T1190 | App/service logs; gRPC telemetry | Hunt for set_configs invocations from unusual clients (new IPs / new certs) and correlate to subsequent process execution |
Python pickle protocol 2 payload with __reduce__ gadget leading to os.system() | TTP | T1059.006 | EDR process telemetry | Alert on the pyquokka service user spawning shell commands shortly after inbound gRPC sessions; correlate to any config-management actions |
Potential Detection Coverage Based on MITRE ATT&CK Technique
| Source | Detections | Coverage |
|---|---|---|
| Splunk | Exploit Public Facing Application via Apache Commons Text | Not pyquokka-specific, but it captures a T1190 “public-facing exploitation” posture. Use it as a model for “unexpected service exposure + suspicious inbound requests” and pivoting to post-exploitation execution on the target host. |
| Elastic | Potential Webshell Deployed via Apache Struts CVE-2023-50164 Exploitation | Again not pyquokka-specific; useful mainly as a template for correlating web-facing exploitation attempts to follow-on file writes / execution. You’ll likely need a custom analytic for Arrow Flight gRPC + Python child-process execution. |
| Sigma | Apache Threading Error | Weak/indirect relevance (Apache keyword match). Treat as “no direct coverage found” for this specific gRPC/pickle exploit chain; prioritize bespoke monitoring around Arrow Flight gRPC exposure and service-child process spawning. |
Sources
- pyquokka FlightServer gRPC pickle deserialization RCE (Metasploit PR #21064) — Published 2026-03-05
3. smolagents RemotePythonExecutor — rogue Jupyter Kernel Gateway triggers pickle RCE on connecting clients (Metasploit PR)
Summary
A Metasploit PR describes a nasty “reverse” exploitation shape: instead of attacking a server, the attacker runs a rogue Jupyter Kernel Gateway and waits for vulnerable smolagents clients (RemotePythonExecutor variants) to connect. Once the client sends an execute_request, the rogue server replies with a malicious pickle payload embedded in a FinalAnswerException, leading to os.system() execution on the client host — effectively a sandbox escape-to-host RCE pattern.
What’s New (Last 24 Hours)
A new Metasploit passive module PR was published detailing the client-side exploitation flow and affected smolagents versions (RemotePythonExecutor subclasses across multiple backends).
Actionable Intel
| Artifact | Type | ATT&CK Technique | Data Source | How to Use |
|---|---|---|---|---|
| Unexpected outbound connections from development/automation hosts to a Jupyter Kernel Gateway (especially to previously unseen endpoints) | TTP | T1071.001 | Proxy / firewall / NDR | Hunt for new/rare outbound destinations on Jupyter-related ports/protocols from CI runners, automation nodes, and developer workstations running agentic tooling |
Jupyter message flow: client execute_request followed by server response containing FinalAnswerException | TTP | T1059.006 | Jupyter gateway logs / app logs (if available) | If you log notebook/gateway traffic, flag abnormal exception-heavy responses and correlate to subsequent process execution on the client |
Client-side pickle.loads() on remote sandbox-provided data | TTP | T1059.006 | Python runtime telemetry / EDR | Where possible, alert on Python processes deserializing pickles sourced from network or IPC that is not explicitly trusted; prioritize hosts running agent frameworks |
Post-connection process execution on the client host (e.g., Python spawning sh/bash) | TTP | T1059.004 | EDR process telemetry | Alert on “python → shell” execution chains immediately following new outbound Jupyter gateway sessions; this is the practical detection anchor |
Potential Detection Coverage Based on MITRE ATT&CK Technique
| Source | Detections | Coverage |
|---|---|---|
| Splunk | None found | No direct technique+artifact matches surfaced for this specific “rogue Jupyter → client pickle RCE” flow. Coverage will likely require custom correlation between outbound Jupyter sessions and subsequent python→shell execution on the client. |
| Elastic | None found | Same gap: prioritize network telemetry for new Jupyter endpoints and EDR lineage on automation/dev hosts rather than relying on existing prebuilt rules. |
| Sigma | None found | No direct Sigma hits for this exploitation pattern via the current technique+term search; treat as a bespoke hunt/correlation scenario. |
Sources
- smolagents RemotePythonExecutor rogue Jupyter server pickle RCE (Metasploit PR #21066) — Published 2026-03-05
4. Sliver C2 — reverse-weaponization PoC: malformed Protobuf triggers server panic (kill-switch)
Summary
A new PoC for Sliver C2 frames CVE-2026-29781 as “reverse-C2 weaponization”: if a defender captures an implant and can extract the client credential material, they can send a malformed Protobuf packet that triggers a nil-pointer dereference and crashes the Sliver server. It’s not your usual detection-engineering story — it’s an infrastructure-denial lever — but it’s still operationally actionable: it describes a concrete failure mode (process terminates with SIGSEGV) and a defender workflow for verifying impact.
What’s New (Last 24 Hours)
A public PoC repo was updated March 5 with exploit steps (mtls_poc.go) and explicit prerequisites (mTLS cert/key + secrets extracted from an implant) to reliably crash a Sliver server via transport-level handler panics.
Actionable Intel
| Artifact | Type | ATT&CK Technique | Data Source | How to Use |
|---|---|---|---|---|
| Sliver server process crash due to nil-pointer dereference in Protobuf handlers (process terminates / service exits) | TTP | T1499 | Linux auth/syslog; systemd journals | Hunt for unexpected Sliver service exits/crash loops; correlate to inbound mTLS/WireGuard/DNS beacon traffic patterns around the crash time |
Observable outcome: Sliver server terminates with SIGSEGV and operators are disconnected | TTP | T1499 | Systemd logs / process crash telemetry | Alert on SIGSEGV-style termination for sliver server processes (where present) as a high-confidence availability-impact indicator |
Defender verification step: systemctl status sliver (service shows failed/stopped after malformed packet) | TTP | T1499 | Host management telemetry | Use as validation during incident response or purple-team testing to confirm whether crash conditions are being hit |
Exploit artifact: mtls_poc.go sending malformed packet after embedding extracted c2Endpoint, client cert/key, and peer key material | TTP | T1588.002 | Code repos / IR tooling inventory | Treat presence of this PoC (or derivatives) in your environment as sensitive tooling; if you find it on non-IR systems, investigate intent |
Potential Detection Coverage Based on MITRE ATT&CK Technique
| Source | Detections | Coverage |
|---|---|---|
| Splunk | None found | No direct coverage found for this specific Sliver “crash the server via malformed Protobuf” pattern. Your best detection is operational: alert on unexpected Sliver process termination + correlated inbound control-channel activity. |
| Elastic | None found | Same: rely on endpoint stability telemetry (process termination/crash) and service health monitoring rather than technique-mapped prebuilt rules. |
| Sigma | None found | No direct Sigma hits for this niche availability-impact workflow; create a local rule for sliver service crash/exit + associated network connection context. |
Sources
- skoveit/CVE-2026-29781 (PoC repo) — Published 2026-03-05