InfoSec Briefing - October 02, 2026

🎧 Audio Briefing

Playback Speed:

Security news from the BlueTeamSec community for Friday the 2nd of October 2026. Starting with something from CISA.

CISA have added CVE-2026-104286 to the Known Exploited Vulnerabilities catalog — it's an unauthenticated path traversal in Fortinet FortiMail that leads to remote code execution. This one's actively exploited against public-facing email security gateways, and given we've just had the NetScaler zero-days last week, there's something of a pattern forming with enterprise security appliances. Patch to the latest minor release for your version, and lock down management interfaces to trusted addresses if you haven't already.

Belnet, Belgium's national research and education network, have published an update on a security incident from the 24th of September — someone exploited a zero-day in external supplier technology. They've contained it, patched the vulnerability, and deployed enhanced detection. Worth noting given the NetScaler timeline we've been following — there's a non-zero chance this is related, though they haven't confirmed the vendor.

FoxIO have released JA4Scan, which is essentially the successor to JARM for active server fingerprinting. It sends seventeen crafted Client Hello probes to TLS and QUIC servers and builds a fingerprint of the implementation. Useful for attributing C2 infrastructure or spotting threat actor servers based on their TLS stack. One for threat hunters and incident responders who need to track infrastructure at scale.

devZero Security have put out redStackPRO — it's a web-based canvas tool for designing red team infrastructure and cyber ranges, then exporting the whole lot as Terraform and Ansible. The interesting bit from a defensive perspective is that tool-generated infrastructure tends to produce consistent signatures, so knowing what legitimate red team tooling looks like can help you distinguish authorised testing from the real thing.

And finally, David Chisnall has written up the design philosophy behind CHERIoT's compartments and libraries — it's about when to use hardware-backed isolation versus treating components as trusted utilities in embedded systems. Adds useful context if you're working with capability-based architectures or evaluating isolation models for constrained devices.

That's everything for today from BlueTeamSec. The articles are the work of their original authors — the analysis here was automated.

📰 Articles Covered

CVE-2026-104286 - CISA KEV

As of October 2, 2026, the following threat intelligence is available regarding CVE-2026-104286.

### Vulnerability Overview
* **Vendor:** Fortinet
* **Affected Product:** FortiMail (email security appliance)
* **Vulnerability Type:** Path Traversal and Improper Neutralization of NULL byte/character
* **Severity:** Critical (CVSS 9.8)
* **Affected Versions:** FortiMail versions 7.0.x through 8.0.x

### Impact and Exploitation
The vulnerability allows an **unauthenticated attacker** to send specially crafted HTTP or HTTPS requests to the appliance, enabling them to **write arbitrary files** on the system .

#### Exploitation (MITRE ATT&CK T1190)
This vulnerability is actively being exploited in the wild . Threat actors are leveraging the path traversal flaw to achieve unauthorized file system access on internet-facing FortiMail appliances. Because the attack does not require authentication, it is highly attractive to automated scanning and exploitation campaigns .

### Known Threat Actors
As of October 2, 2026, specific threat actor attribution has not been publicly confirmed. However, the rapid exploitation following public disclosure and the inclusion of the vulnerability in the **CISA Known Exploited Vulnerabilities (KEV) Catalog** indicate that sophisticated, organized groups are actively targeting this flaw .

### Recommended Actions for Defenders
Immediate action is required to secure vulnerable infrastructure:
1. **Apply Patches:** Upgrade FortiMail appliances to the vendor-recommended patched versions immediately .
2. **Restrict Access:** Limit management interface access to trusted IP addresses or internal networks only, ensuring the management portal is not exposed to the public internet .
3. **Threat Hunting/Compromise Assessment:** Review system logs for signs of suspicious HTTP/HTTPS requests, particularly those containing path traversal sequences (e.g., `../`) or unexpected file creation attempts, and investigate for potential post-exploitation activity .
Introducing JA4Scan: Active Server Fingerprinting for TLS and QUIC - FoxIO-LLC

The release of **JA4Scan** marks a significant advancement in network security, providing a modernized, more effective method for fingerprinting TLS and QUIC implementations on internet-facing servers. Developed as the successor to JARM, JA4Scan addresses the limitations that modern protocols have imposed on previous scanning technologies 【1】.

### What Happened
FoxIO has introduced JA4Scan-TLS and JA4Scan-QUIC as part of their JA4+ suite. These tools are designed to identify the specific TLS/QUIC stacks and configurations running on any given server by actively probing them and analyzing their responses—or even their refusal to respond 【1】.

### Who Is Affected
This tool affects anyone managing or monitoring internet-connected infrastructure. Because it enables high-fidelity identification of server configurations, it is highly impactful for:
* **Defenders:** Security teams, threat hunters, and researchers tracking malicious infrastructure.
* **Infrastructure Managers:** Organizations looking to audit the consistency of their server configurations.
* **Threat Actors:** Malicious servers using specific TLS/QUIC stacks or C2 (command and control) frameworks that can now be more easily identified and grouped 【1】.

### Security Implications
JA4Scan dramatically increases the visibility into the "hidden" or "default" configurations of servers across the internet. By enabling the attribution of servers to specific libraries and implementations, it allows security practitioners to identify malware C2 infrastructure and other suspicious nodes that might otherwise blend in with standard web traffic 【1】.

### Technical Details
* **Probing Methodology:** JA4Scan sends 17 specifically crafted `Client Hello` probes to a target over TCP and QUIC (covering TLS 1.2, 1.3, and QUIC). It records not just the explicit values returned, but the "shape" of how the server responds or refuses the probe, capturing hardcoded structural decisions of the library 【1】.
* **Translation/Attribution:** The tool includes a sidecar engine, `JA4Scan-translate`, which maps these fingerprints to named TLS libraries and QUIC implementations, even if the configurations differ between instances 【1】.

### What Defenders Should Know
* **Beyond JARM:** JARM is increasingly ineffective against modern protocols like TLS 1.3 and QUIC; JA4Scan is the intended replacement for these environments 【1】.
* **High-Fidelity Detection:** JA4+ fingerprints are most effective when used in combination. Defenders are encouraged to combine `JA4Scan` with `JA4X` (which fingerprints the structure of X509 certificates) to identify malicious infrastructure, such as Sliver C2s, with higher accuracy 【1】.
* **Utility:** Beyond security, it serves as a powerful utility for configuration verification across large server groups and for identifying default applications within an organization’s network footprint 【1】.
redStackPRO: A canvas for red team infrastructure and cyber ranges. Compose a topology, export runnable Terraform and Ansible, and deploy it yourself. Your cloud credentials never leave your machine. - devZero Security

The previous response provides a comprehensive precis of the `redStackPRO` tool based on the available documentation. Since `redStackPRO` is a utility tool designed to *generate* infrastructure rather than a vulnerability or a specific cyber incident, the "What happened" aspect refers to the project's development as an automation framework for security professionals.

There is no "incident" to report; rather, this is a tool for building controlled testing environments. To ensure you have all the necessary information, please review the points below:

### Summary of redStackPRO
* **What it is:** A web-based canvas tool for designing and deploying infrastructure for red team operations and cyber range training using Infrastructure-as-Code (Terraform/Ansible).
* **Target Audience:** Authorized security professionals, red teamers, and security trainers.
* **Key Security Implications:** Facilitates the rapid deployment of standardized, "off-the-shelf" offensive infrastructure (C2 redirectors) and vulnerable target environments (Active Directory labs) for authorized testing.
* **Defensive Perspective:** Security teams should be aware that this tool can generate consistent network signatures and infrastructure patterns. Recognizing these patterns can help in identifying authorized lab environments versus potentially unauthorized or malicious deployments in a corporate cloud footprint.

If you have questions about a specific feature, a particular deployment provider (AWS vs. GCP), or how to audit infrastructure generated by tools like this, please let me know!
Why does CHERIoT have compartments and libraries? - David Chisnall

The article discusses the structural design philosophy of the CHERIoT platform, emphasizing the crucial distinction between **compartments** (security-focused) and **shared libraries** (efficiency/engineering-focused).

### What Happened and Who is Affected
The CHERIoT architecture formalizes how developers should structure software to balance security with performance. This framework primarily impacts developers and architects working on embedded systems who need to decide whether a specific module requires robust isolation or if it can be treated as a trusted, shared utility.

### Security Implications
* **Compartments (Security Boundaries):** These are intended for code that must be isolated due to a specific threat model. They provide strong boundaries, enforcing constrained visibility and utilizing hardware-backed hardening measures, such as capability checks and sealed, type-safe opaque types, to protect both data and execution flow 【1】.
* **Shared Libraries (Engineering Boundaries):** These represent software-engineering boundaries rather than security boundaries. Because they are designed to be stateless (avoiding mutable globals), they can be shared across multiple compartments without the performance cost of context switching.

### Technical Details
* **Compartment Invocation:** When a compartment is invoked, the system triggers the "switcher," which clears registers and truncates the stack to maintain isolation.
* **Shared Library Invocation:** These are invoked directly without the switcher. They are fully trusted by the caller, meaning all necessary state must be passed explicitly via function arguments.
* **Interoperability:** The abstractions are designed for flexibility; a shared library can be "promoted" to a compartment by wrapping it, effectively converting a software-engineering boundary into a hardened security boundary if the threat profile changes.

### What Defenders Should Know
* **Avoid Over-compartmentalization:** Not every module requires the overhead of a security compartment. Applying isolation everywhere can impose significant performance costs without adding meaningful security value.
* **Manage Trust Intentionally:** Some utilities (e.g., standard libraries or `memcpy`) are intentionally "porous" for performance reasons. This is an acceptable design choice as long as the developer trusts the implementation and manages the risks associated with those specific functions.
* **Leverage Flow Isolation:** By enforcing the use of stateless libraries and passing state through explicit arguments, developers can achieve "flow isolation." This pattern ensures that even if one instance of a module is compromised, the confidentiality and integrity of other instances remain protected because they do not share mutable state 【1】.
Security and privacy incident affecting Belnet’s IT infrastructure - Update - www.belnet.be

Based on the information available regarding the security and privacy incident reported by Belnet on September 24, 2026, here is a precis of the situation.

### **What Happened**
On September 24, 2026, Belnet, the Belgian national research and education network, identified a security and privacy incident within its IT infrastructure. The incident was triggered by the exploitation of a zero-day vulnerability in technology provided by an external supplier. Upon discovery, Belnet immediately initiated remediation measures to contain the breach and resolve the vulnerability 【1】【3】.

### **Who Is Affected**
The incident affected Belnet’s own IT infrastructure. While specific details on the scope of impact (such as which specific organizations or data sets were compromised) have been managed through their formal disclosure channels, the attack targeted the infrastructure that supports their network services 【1】.

### **Technical Details**
* **Root Cause:** The exploitation of a zero-day vulnerability present in software or hardware supplied by an external vendor.
* **Remediation:** Belnet has confirmed that the vulnerability has been fixed.
* **Incident Response:** Following the detection, Belnet implemented enhanced security protocols, including the deployment of new preventive and detection systems to identify and remove any suspicious actors or malicious programs remaining within their environment 【2】.

### **Security Implications**
The incident underscores the risks inherent in third-party dependencies within IT ecosystems. Because the vulnerability was a "zero-day"—a flaw unknown to the vendor at the time of exploitation—traditional signature-based defenses were insufficient to stop the initial breach. This highlights the ongoing challenge of securing complex, interconnected infrastructure against sophisticated, supply-chain-related threats.

### **What Defenders Should Know**
* **Third-Party Risk Management:** This incident serves as a reminder to conduct rigorous security reviews of all third-party technology and software integrated into core infrastructure.
* **Behavioral Monitoring:** Since zero-days cannot be blocked by pre-existing signatures, defenders should prioritize behavioral analytics and Endpoint Detection and Response (EDR) solutions to detect anomalous activity that might indicate an active compromise.
* **Incident Readiness:** The speed of Belnet’s response—deploying new detection systems immediately upon identification—highlights the necessity of having robust, actionable incident response plans that include the ability to quickly pivot security posture in response to a new, active threat.