Loading story…
A high-severity flaw tracked as CVE-2026-25075 affects strongSwan versions 4.5.0 through 6.0.4 in the EAP-TTLS AVP parser. The bug stems from subtracting 8 from attacker-controlled AVP length fields without confirming the value is at least 8, creating an integer underflow that can wrap to a large unsigned value. During IKEv2 authentication, a remote unauthenticated attacker can send crafted AVP data to trigger excessive memory allocation, heap corruption, or a NULL pointer dereference, causing the charon IKE daemon to crash and resulting in denial of service.
Bishop Fox reported that exploitation may occur in one request on some systems, while others may require a second connection after heap metadata is corrupted before a segmentation fault occurs. The issue is limited to deployments that run affected strongSwan versions, have EAP-TTLS enabled, and expose the vulnerable IKEv2 code path. strongSwan disclosed the vulnerability and fixed it in version 6.0.5 by adding bounds checks, while Bishop Fox also published a non-disruptive detection approach and a GitHub test script to help identify exposed servers without crashing production systems.
Map this exposure pattern across your cloud, code, and identities.
3 events from the most recent confirmed update back to the earliest known activity.
On 2026-03-26, Bishop Fox published a technical analysis of CVE-2026-25075, including exploitation details such as possible two-phase crashing behavior on some systems. The company also released a safe detection method and GitHub test script to identify vulnerable deployments without crashing production servers.
strongSwan addressed the vulnerability in version 6.0.5 by adding bounds checking to prevent invalid AVP length handling. The fix remediates the integer underflow that could otherwise lead to excessive memory allocation, NULL dereference, or heap corruption.
On 2026-03-23, strongSwan disclosed CVE-2026-25075, an integer underflow in the EAP-TTLS AVP parser affecting versions 4.5.0 through 6.0.4. The flaw allows unauthenticated remote attackers to crash the charon IKE daemon during IKEv2 authentication, causing denial of service.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See where this exposure pattern shows up across your cloud, code, supply chain, and non-human identities.
2 references tracked. Mallory keeps watching after this page renders.
Map indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Wireshark disclosed **CVE-2026-15165**, a flaw in TLS Encrypted Client Hello (ECH) transcript reconstruction affecting versions 4.6.0 through 4.6.6. A specially crafted packet capture containing repeated `ech_outer_extensions` entries can trigger a heap-based buffer overflow when Wireshark or `tshark` decrypts and processes the embedded TLS data, causing the application to crash when the capture is opened. The proof of concept uses a Decryption Secrets Block in the capture to provide the HPKE secret needed to decrypt and validate the malicious inner ClientHello, removing the need for separate victim-side decryption configuration. The reported overflow can write attacker-controlled data beyond the allocated buffer and may present memory-corruption and potential code-execution risk, although Wireshark said no exploitation is known. Wireshark fixed the issue in version 4.6.7; organizations should upgrade analysis workstations and automated `tshark` processing environments.
Sep 24, 2026
Wireshark disclosed and fixed **CVE-2026-15166**, a stack-based buffer overflow in 802.11 EAPOL-Key decryption handling within `Dot11DecryptDecryptKeyData()`. The flaw stems from attacker-controlled EAPOL length fields reaching a `memcpy` into a fixed 1024-byte stack buffer without proper bounds checking on the decrypt path, allowing a malformed frame to corrupt the stack. The issue was reported in Wireshark's `tshark` processing and was reproduced with AddressSanitizer against commit `b260b00b861aef491d11043d2a8c9dd2615cdb9e` using the shipped `wpa-Induction.pcap` test capture. Wireshark said the vulnerability affects versions **4.6.0 through 4.6.6** and **4.4.0 through 4.4.16**, and could let an attacker crash the application by convincing a user to open a malformed packet trace file. The original report said that, when WPA decryption is enabled and a valid Security Association exists for the BSSID, a single crafted EAPOL-Key frame can overflow the buffer by roughly 1000 bytes, creating potential **RCE-class** impact in addition to denial of service. Wireshark released fixes in **4.6.7** and **4.4.17** and said it was not aware of active exploitation.
Aug 21, 2026
Cisco has disclosed and patched **`CVE-2026-20349`**, a high-severity zero-day in **Cisco Secure Firewall ASA** and **Secure Firewall Threat Defense (FTD)** that is being actively exploited to trigger denial-of-service conditions. The flaw is caused by insufficient error checking when processing HTTP requests in the **Remote Access SSL VPN** service, allowing a remote, unauthenticated attacker to crash and reload affected devices. Impacted deployments include systems with SSL listen sockets enabled, such as **SSL VPN**, **IKEv2 Remote Access VPN with client services**, and **Zero Trust Network Access** on FTD devices, while **Secure Firewall Management Center** is not affected. Cisco released fixed software and hotfixes for multiple ASA and FTD versions and said there is **no workaround** other than upgrading. **CISA** added the bug to its **Known Exploited Vulnerabilities** catalog, alongside newly listed flaws in Microsoft Windows and Metabase, and directed federal agencies to remediate the Cisco issue by **August 14, 2026** under **BOD 26-04**. Cisco said it became aware of exploitation in August but did not identify the threat actor, targets, or indicators of compromise.
Aug 16, 2026