A Wi-Fi flaw that requires no password - just standing close enough. A backup product that became a bridge into MSP customer tenants. A web application firewall that handed attackers root access through the exact attack class it was built to prevent. Three stories today that share a common thread: the trust boundary failed at the component everyone assumed was safe.

In the News

Broadcom Wi-Fi Chipset Flaw Gives Root Access via Radio Range - No Password Required

An unpatched vulnerability in Broadcom Wi-Fi chipsets allows an attacker within radio range to execute arbitrary code as root on affected devices. The critical detail: no network password, no WPA handshake, no pairing step, and no user interaction are required. Physical proximity to the target device is the only prerequisite.

Broadcom Wi-Fi chipsets are embedded in millions of ISP-supplied home gateways, consumer routers, and some enterprise access points. The vulnerability was demonstrated against ISP-supplied hardware in a live proof of concept, confirming that the attack is not theoretical. There is no vendor patch available at time of writing. The flaw targets the chipset firmware layer - meaning host-level endpoint protection on devices behind the router provides no mitigation against the initial compromise of the gateway itself.

For organizations with branch offices or remote workers relying on consumer-grade or ISP-supplied routers, this vulnerability collapses the assumption that the network perimeter provides meaningful isolation. An attacker in a parking lot, a shared office building, or an apartment adjacent to a home office is within exploitation range. Until a patch ships, the compensating controls are wireless intrusion prevention systems that detect anomalous RF-layer activity, network access control that limits lateral movement from a compromised gateway, and - where possible - replacing unmanaged ISP hardware with managed access points running known-good firmware.

What defenders should do: Inventory deployed Wi-Fi hardware to identify Broadcom chipset exposure. Segment networks so that a compromised gateway cannot provide direct access to internal resources. Monitor for anomalous wireless management frames if WIPS capability is available.

Source: The Hacker News

ConnectWise Cloud Backup Compromise Exposes MSP Microsoft 365 Tenants

ConnectWise has disabled seven application identities and suspended its Cloud Backup service after attackers used those identities to compromise MSP customer Microsoft 365 tenants. The attack is a textbook supply chain scenario: a trusted vendor integration with broad delegated permissions becomes the vector that bypasses every access control the downstream customer had in place.

The mechanism is worth understanding precisely. ConnectWise Cloud Backup requires OAuth application registrations with permissions to read mail, files, and other M365 data in customer tenants - that access is the product’s core function. When those application identities were compromised, the attacker inherited every permission the backup product held. No phishing of end users was required. No credential stuffing. The trusted integration itself was the door.

MSPs running ConnectWise Cloud Backup should immediately audit their M365 tenant admin consent logs for the suspended app IDs, review sign-in logs for anomalous OAuth token usage, and scope whether any data was accessed or exfiltrated during the exposure window. The broader takeaway for any MSP or enterprise is that third-party SaaS integrations with delegated M365 permissions require the same scrutiny as privileged user accounts - conditional access policies should restrict which app registrations can access tenant data, and consent grants should be reviewed on a recurring cadence.

What defenders should do: Review Azure AD enterprise application consent grants. Restrict tenant-wide admin consent to approved applications only. Enable alerts for new OAuth app registrations and consent events in M365 Unified Audit Log.

Source: The Hacker News

SiteGuard WAF Zero-Day Exploited - The Security Product Is the Initial Access Vector

Attackers are actively exploiting an OS command injection vulnerability in SiteGuard Server Edition - a web application firewall - to execute commands as root on Linux and SYSTEM on Windows. The vulnerability is in the WAF’s management interface, and active exploitation has been confirmed by multiple sources.

The structural irony is worth stating plainly: a product deployed specifically to detect and block injection attacks against web applications contains an injection vulnerability in its own management plane. For the attacker, compromising the WAF provides a privileged position - the device sits inline, sees all traffic, and runs with the highest system privileges. Post-exploitation, the attacker has a vantage point that most implants can only dream of.

Patches are available from the vendor. Organizations running SiteGuard Server Edition should patch immediately. As a compensating control, restricting access to the WAF management interface to a dedicated out-of-band management network - not accessible from the internet or the general production network - would have prevented remote exploitation of this flaw. This incident reinforces a principle that is easy to forget: security products are software, and they require the same vulnerability management discipline as every other component in the stack. Endpoint detection agents should run on WAF hosts. Management interfaces should be segmented. Security tooling should be included in vulnerability scanning scope - not excluded from it.

What defenders should do: Patch SiteGuard Server Edition immediately. Restrict WAF management interfaces to out-of-band management networks. Ensure security infrastructure hosts are covered by endpoint detection and included in vulnerability scanning scope.

Source: BleepingComputer

Defender Action Items

  • Broadcom Wi-Fi: Inventory all deployed Wi-Fi hardware for Broadcom chipset exposure, especially ISP-supplied gateways at branch and remote sites. Segment networks behind consumer-grade routers. Monitor for anomalous wireless management frames via WIPS.
  • ConnectWise Cloud Backup: Audit Azure AD enterprise application consent grants in all M365 tenants. Search sign-in and unified audit logs for the seven suspended ConnectWise app IDs. Restrict tenant-wide admin consent to pre-approved applications.
  • SiteGuard WAF: Apply vendor patch immediately. Move WAF management interfaces to out-of-band management networks. Add security appliance hosts to endpoint detection and vulnerability scanning scope.
  • FortiGate (Threat Pulse): Verify that the previously disclosed Fortinet CVE is patched on all FortiGate appliances. Review FortiGate logs for indicators of memory-resident implant activity, particularly in telecom and critical infrastructure environments (SecurityWeek).
  • AI Developer Supply Chain: If developers use npm packages from unfamiliar Web3 or AI accelerator projects, audit dependencies with software composition analysis tools. Rotate any API keys for Claude, Gemini, or OpenAI that were stored in OpenCode Console (The Hacker News).

Today’s Deep Dive - When Security Products Become the Attack Surface

The SiteGuard WAF exploitation is not an isolated case. Security appliances - firewalls, VPN concentrators, WAFs, and endpoint management servers - have become a preferred target class for sophisticated threat actors. The FortiGate memory-resident implant disclosed this week against a telecom provider follows the same pattern: exploit a vulnerability in the security device itself, then use its privileged network position for persistent access.

The reason is straightforward. Security appliances run with elevated privileges, sit at trust boundaries, inspect or proxy all traffic, and are frequently excluded from the organization’s own vulnerability management and endpoint detection programs. They are the plumber’s leaky pipes. When a threat actor compromises a FortiGate, a SiteGuard WAF, or a Palo Alto GlobalProtect gateway, they gain a position that is architecturally superior to compromising any single endpoint behind it.

MITRE ATT&CK maps this pattern across several techniques: Exploit Public-Facing Application (T1190) for initial access, and in the FortiGate case, Implant Internal Image (T1601.001) for persistence in network device firmware. The detection challenge is that many of these appliances run proprietary operating systems with limited endpoint telemetry - you cannot deploy a standard EDR agent on a FortiGate or a SiteGuard box.

The primary mitigations are consistent across these cases:

  1. Patch security appliances with the same urgency as internet-facing servers. They are internet-facing servers.
  2. Segment management interfaces. The SiteGuard exploitation required access to the management plane. If that plane is reachable only from a dedicated jump host on an out-of-band management VLAN, the attack surface shrinks to near zero for remote exploitation.
  3. Deploy detection where you can. For appliances that support it, run endpoint detection agents on the host OS. For those that do not, monitor for anomalous outbound connections, unexpected process execution, and changes to firmware or configuration files via netflow and syslog correlation.
  4. Include security tooling in vulnerability scanning scope. If your vulnerability scanner excludes your firewalls, your WAFs, and your VPN concentrators, you have a blind spot at the exact point an attacker wants to be.

Detection Spotlight

For organizations monitoring FortiGate appliances for signs of the memory-resident implant, the following Splunk SPL query identifies anomalous outbound connections from FortiGate management interfaces - a common post-exploitation indicator when an implant establishes command and control from a compromised appliance:

index=firewall sourcetype=fortigate_traffic
| where src_zone="mgmt" AND direction="outbound"
| stats count by src_ip, dest_ip, dest_port, app
| where count > 5
| sort -count
| lookup known_mgmt_destinations dest_ip OUTPUT is_known
| where is_known!="true"

This query isolates outbound traffic originating from the FortiGate management zone, aggregates by destination, and filters against a lookup of known-good management destinations (firmware update servers, syslog collectors, NTP, SNMP managers). Any unknown outbound destination from a FortiGate management interface warrants immediate investigation. False positive rate is low if the known_mgmt_destinations lookup is maintained - management interfaces should have a very short list of legitimate outbound peers.

For SiteGuard WAF hosts, monitor for unexpected child processes spawned by the WAF service process. On Linux, any sh, bash, curl, wget, or python process with the WAF service as the parent process is a high-fidelity indicator of command injection exploitation.

References

Subscribe to it-learn Brief

Get it-learn Brief in your inbox (Mon–Fri) - Daily cybersecurity news, SE angles, and detection queries.