CyberStrikeAI compromised 600 FortiGates, Cloudflare shipped always-on WAF detection, RFC 9849 standardized ECH, and VMware Aria landed in KEV

CyberStrikeAI compromised 600 FortiGates with AI orchestration

What the tool is

CyberStrikeAI is a Go-based open-source offensive security tool published on GitHub. It integrates more than 100 security tools and orchestrates them with AI. Its main functions are vulnerability scanning, attack-chain analysis, knowledge retrieval, and result visualization.

Attackers are directly wiring commercial AI APIs into offensive workflows. In this campaign they used Anthropic’s Claude and DeepSeek to automate target selection, vulnerability scanning, attack-step generation, and result analysis. The model was not just helping with search or code generation; it was orchestrating the whole attack workflow.

The developer is a Chinese actor who uses the alias Ed1s0nZ. Researchers note contacts with KnownSec 404, a private security vendor with ties to China’s Ministry of State Security, and assess that the activity likely has some connection to the Chinese government.

Campaign scale

According to Team Cymru, more than 600 Fortinet FortiGate appliances in 55 countries were compromised between January 20 and February 26, 2026. They identified 21 unique IP addresses, with infrastructure concentrated in China, Singapore, and Hong Kong, and some spread into the US, Japan, and Switzerland.

The campaign does not appear to target one specific sector. The selection looked opportunistic.

Attack flow

flowchart TD
    A[CyberStrikeAI<br/>Go OSS tool] --> B[Claude / DeepSeek API<br/>select scan targets]
    B --> C[Automatically scan FortiGate<br/>for vulnerabilities]
    C --> D[AI generates and executes<br/>the attack chain]
    D --> E[Compromise 600+ FortiGates<br/>in 55 countries]
    E --> F[21 C2 IPs<br/>centered on China, Singapore, Hong Kong]

Vulnerabilities used

At the time of reporting, the exact CVEs targeted by CyberStrikeAI were not disclosed. FortiGate has seen active exploitation before, including CVE-2024-21762 (SSL-VPN RCE) and CVE-2024-55591 (auth bypass), and many public-facing appliances remain unpatched.

Because CyberStrikeAI is open source, other attackers could reuse it in future campaigns.

What FortiGate operators should do

update FortiGate firmware to the latest release
remove direct internet exposure of the management interface
regularly check Fortinet advisories and the KEV list to prioritize patching

Cloudflare Attack Signature Detection for always-on WAF inspection

One problem almost every WAF operator hits is the same: if you switch the rule to block mode, you might break legitimate traffic; if you keep it in log mode, the attack gets through.

Cloudflare’s March 2026 Attack Signature Detection tries to solve that trade-off with a design that separates detection from blocking.

The old WAF problem

Traditional WAFs evaluate a rule and then take an action. Once a rule blocks, later rules stop running. That means operators never got a full view of the decision chain while still blocking.

The normal rollout path is also slow: run in log mode, inspect logs for weeks, exclude rules that look too risky, then flip to block mode. It is manual and easy to get wrong.

Separating detection from blocking

flowchart LR
    A[Request received] --> B[700+ signatures<br/>always evaluated]
    B --> C{block rule set?}
    C -- no --> D[Metadata only<br/>async processing]
    C -- yes --> E[Inline decision<br/>block / allow]
    D --> F[Forward to origin]
    E -- allow --> F
    E -- block --> G[Request blocked]
    D --> H[Security Analytics<br/>storage]

Attack Signature Detection is always on. Every request that passes through Cloudflare is evaluated against more than 700 signature rules, and the matched result is attached as metadata.

At that point, nothing is blocked yet. Detection and blocking are fully separate.

The attached fields are:

Field	Meaning
`cf.waf.signature.request.confidence`	aggregated confidence for matching signatures
`cf.waf.signature.request.categories`	aggregated attack categories, such as SQLi, XSS, and RCE
`cf.waf.signature.request.ref`	up to 10 matching signature ref IDs

These fields can be used in Security Analytics or in the Edge Rules Engine. You can inspect how often a signature has fired and then build a blocking rule later.

Latency impact

It is natural to ask whether running signatures on every request will increase latency.

Cloudflare says that when no blocking rule is set, detection can run asynchronously after the request is sent to origin. In that mode there is no user-facing latency hit. If you enable a blocking rule, the relevant detection goes inline and some latency may be added.

Signature confidence

The signatures have a confidence field with High and Medium values.

High means low false-positive risk and behaves like a default managed rule. That fits payloads tied to specific CVEs that are clearly different from normal traffic.

Medium means better detection but higher false-positive risk. On CMS or support systems that allow HTML input, legitimate user HTML may hit an XSS signature. The intended workflow is to watch the Medium signatures in Analytics and then build scoped exceptions.

Full-Transaction Detection, in development

The in-development Full-Transaction Detection extends the same idea to the full HTTP transaction.

Instead of looking only at requests, it correlates requests and responses. That lets it catch things that request-only WAFs miss:

reflected SQL injection
subtle data leakage patterns
dangerous misconfigurations that only become obvious after looking at the response

It should also reduce false positives, because response context improves the confidence that the traffic is actually harmful. Cloudflare is currently taking Early Access signups.

RFC 9849 and TLS Encrypted Client Hello

TLS 1.3 encrypts most of the handshake, but one big hole remained: the ClientHello message. It contains SNI, the Server Name Indication, which reveals the destination domain to anyone on the path.

RFC 9849, TLS Encrypted Client Hello (ECH), closes that hole by encrypting the ClientHello. It became official in early 2026.

Why SNI is a problem

TLS 1.3 encrypts most of the handshake, including the server certificate, but the ClientHello must be sent before the server can choose the right certificate.

SNI therefore exposes the destination in cleartext. ISPs, CDNs, and censorship systems can see which site you are trying to reach even if they cannot read the content.

The privacy issue remained even after HTTPS became ubiquitous: people could not read the traffic, but they could still see where it was going.

How ECH works

ECH solves that by splitting the handshake into ClientHelloInner and ClientHelloOuter.

flowchart TD
    A[Client] --> B[Fetch ECHConfig public key from DNS]
    B --> C[Build ClientHelloInner<br/>with the real destination]
    C --> D[Encrypt it with HPKE<br/>and place it in ClientHelloOuter]
    D --> E[Observers only see the CDN domain]
    E --> F[Server decrypts it<br/>and routes to the real origin]

ClientHelloInner contains the real destination, such as private.example.org. It is encrypted with HPKE using the server’s public key and wrapped into ClientHelloOuter.

From the outside, only the public name is visible, usually the CDN domain. Observers can tell that you connected to Cloudflare, but not which origin behind Cloudflare you reached.

The public key is distributed through HTTPS resource records in DNS. The client fetches the key from DNS, encrypts the ClientHello, and then connects.

Two deployment topologies

The RFC defines two deployment modes.

Shared Mode is for a single server terminating traffic for multiple domains. Think of multiple Cloudflare-hosted services sharing the same IP. The server can decrypt the encrypted ClientHello directly.

Split Mode separates the client-facing server from the backend server. The client-facing server receives the encrypted ClientHello, but only decrypts it to decide which backend to forward to. The backend still terminates the real TLS connection, so even the proxy does not know the real destination in plaintext.

The “do not stick out” rule

One of the main design goals is “Do Not Stick Out.”

ECH clients should look the same as non-ECH clients from the network observer’s point of view. If an observer can detect ECH, that detection can be used to block it. GREASE helps hide that distinction by making non-ECH clients send random-looking ECH extensions too.

Security caveats

ECH fixes SNI leakage, but that does not complete the privacy story.

If the client’s DNS queries are still plain text, observers can still see which domain was resolved. RFC 9849 points out that you need encrypted DNS such as DoH or DoT to hide both SNI and DNS.

Server IP addresses can also still reveal the destination in some cases. ECH is most useful when many origins are fronted by the same CDN or reverse proxy.

Implementation status

Chrome has supported ECH gradually since around Chrome 117 in 2023, and it is now enabled by default. Firefox supports it too. Major CDNs such as Cloudflare already support ECHConfig distribution.

With RFC 9849 now official, the reference standard is settled. That should make interoperability easier for implementers.

CVE-2026-22719: VMware Aria Operations command injection added to KEV

What the bug is

On March 3, 2026, CISA added a command-injection flaw in VMware Aria Operations, CVE-2026-22719, to the Known Exploited Vulnerabilities catalog. The CVSS score is 8.1.

Broadcom’s advisory says that an unauthenticated malicious attacker can run arbitrary commands in VMware Aria Operations during a support-assisted product migration, leading to remote code execution. The attack vector is network-based and does not require privileges.

Broadcom said it had seen reports of exploitation in the wild, though it had not independently confirmed them. CISA still chose to add it to KEV.

Affected products

Product	Fixed version
VMware Aria Operations 8.x	8.18.6
VMware Cloud Foundation 9.x.x.x (including vSphere Foundation)	9.0.2.0

VMware Aria Operations, formerly vRealize Operations, sits in the control layer for hybrid cloud management. If it is compromised, the blast radius can cover the whole infrastructure.

Patch and workaround

Broadcom released a patch on February 24, 2026. It also published a temporary shell-script workaround for organizations that could not patch immediately.

Under CISA’s Binding Operational Directive 22-01, federal civilian agencies had to fix it by March 24, 2026. Private organizations were also told to patch quickly.

Why the trigger condition matters

The bug only fires during support-assisted product migration. That matters because the exploit window lines up with large infrastructure migration or upgrade work. If you are still unpatched, you should consider pausing the migration or disabling the relevant feature until the workaround or patch is in place.

References: