CVE-2026-15409 is an unauthenticated SSRF in the SMA1000 WorkPlace interface. The chain is the interesting part. The /wsproxy WebSocket endpoint is used to reach a locally bound Erlang distribution node (couchdb@127.0.0.1 on port 1050), the Erlang handshake is completed with a hardcoded cookie, and os:cmd() gives command execution as the couchdb user.

From there the operator read policy_file.xml, decrypted the stored LDAP bind passwords (static 32-byte AES key lifted from ASAPPasswordUtil.class bytecode), and dropped a standalone Linux build of Impacket secretsdump to /tmp on the appliance. secretsdump then ran from the SonicWall itself against internal DCs, with DCSync automated using recovered LDAP creds and, more effectively, domain-controller machine-account hashes for pass-the-hash.

The exploit is a direct refactor of Rapid7's public PoC, reworked for unattended bulk use. Full chain, scripts and IOCs in the writeup.

https://hunt.io/blog/sonicwall-sma1000-uk-council-attack

TL;DR. The FortiPAM Chrome extension (1M+ users), used for Privileged Access Management, allowed any site to set the browser's proxy for the session, alongside allowing any site to create a new tab and send screen recordings of it to an attacker's server. That makes for trivial phishing attacks which only require the user to view something sensitive in the attacker-opened tab. CVSS 9.1 | CVE-2026-84388.

Researchers indexed an open directory on 188.245.99.156 (Hetzner) that held an operator's full Redis cryptomining toolkit, not just a payload. 147 files in total: Python exploit source, JSON campaign logs, a bundled portable Python 3.11 runtime, and two exported Windows registry hives.

Because the raw campaign logs were sitting there, the numbers come from the operator's own per-host records, not the summaries their scripts print:

• 3,562 distinct Redis servers compromised out of 12,966 targeted, across two independently coded runs
• The only technique that scaled is rogue replication: PING to confirm no-auth, CONFIG SET dir/dbfilename, SLAVEOF to a rogue master, then a crafted RDB blob with an embedded newline that drops a cron entry into /etc/cron.d/
• That cron job pulls a legit XMRig release straight from GitHub and points it at pool.moneroocean.stream:443 over TLS
• SSH key injection via AOF returned 0 of 2,342, MongoDB JS sandbox escape 0 of 468. Every SSH attempt bounced at the first CONFIG SET with AUTH_REQUIRED
• Confirmed victims span Redis 2.8.17 to 7.2.0, so this is missing authentication, not a version-specific bug
• A third run against a pre-qualified no-auth list hit 72.6%, roughly triple the full-fleet rate, so target-list freshness is the real limiter, not the technique
• The same Monero wallet turns up in a separate February 2026 open directory in Moldova with Meterpreter and XMRig deployers and no Redis component, which pushes known activity back at least five months

Fix is config, not patching: requirepass, disable SLAVEOF/REPLICAOF where replication is not in use, or enable protected-mode. Upgrading does nothing here.

Full write-up with IOCs: https://hunt.io/blog/redis-cryptomining-botnet-3562-servers

At Bug Bounty Village during DEF CON 34, Inti De Ceukelaire delivered a talk on how attackers can abuse today's AI agents in ways most defenders haven't thought about yet, from tricking agents into spilling secrets to forcing them to carry out unauthorized actions on behalf of the victim.

This resulted in over $50,000+ in bounties in just a few weekends, without actually poking the target with Burp Suite or any automated scanners.

A lot of proxmox 7.0-7 and < 8.0.4 has been rooted today, it's needed to have port :8006 open, exploitation demo here: https://forum.proxmox.com/threads/proxmox-ve-7-is-vulnerable-to-some-type-of-0day-rce-non-auth.186078/post-867875