SAP’s April 2026 patch cycle addresses a critical ABAP runtime flaw across 13+ enterprise products. Simultaneously, CISA confirmed active exploitation of a 9.1-CVSS SQL injection in Fortinet’s endpoint management server, and the FBI dismantled a phishing-as-a-service platform responsible for $20 million in attempted fraud. The through-line today: the infrastructure defenders rely on — ERP platforms, security management consoles, TLS libraries — is itself the attack surface.

In the News

SAP Patches Critical ABAP Vulnerability Across 13+ Enterprise Products

SAP released 19 security notes in its April 2026 patch cycle, headlined by a critical vulnerability in the Advanced Business Application Programming (ABAP) platform. The flaw affects the core runtime layer — the execution engine beneath SAP ERP, S/4HANA, and more than a dozen adjacent modules. Details on the specific attack vector have not been fully disclosed in the public advisory, but the critical severity rating and breadth of affected products indicate a flaw in shared ABAP infrastructure rather than a single module.

The operational problem is straightforward: most large enterprises run SAP, and most SAP environments are not patched on the same cadence as operating systems or network devices. ERP patching carries change-management overhead — downtime windows, regression testing, business process validation — that routinely pushes critical fixes into monthly or quarterly cycles. That gap between disclosure and remediation is where attackers operate.

This is the 19-note cycle, not a single emergency patch, which means SAP customers need to triage across nearly two dozen fixes simultaneously. The critical ABAP flaw should be at the top of that triage.

What defenders should do: Prioritize the critical ABAP security note from SAP’s April 2026 cycle. Validate that your SAP patching process can execute within days, not weeks. If your organization lacks an automated SAP patch assessment workflow, this is the business case to build one.

Source: SecurityWeek

CISA Adds FortiClient EMS SQL Injection to KEV — CVE-2026-21643

CISA added CVE-2026-21643 to the Known Exploited Vulnerabilities (KEV) catalog, confirming active exploitation of an unauthenticated SQL injection in Fortinet FortiClient Enterprise Management Server (EMS). The CVSS score is 9.1. FortiClient EMS is the centralized management console that deploys, configures, and monitors FortiClient endpoint agents across an organization. An unauthenticated attacker with network access to the management interface can execute arbitrary SQL commands against the backend database.

The irony is structural: the security management plane is the initial access vector. FortiClient EMS typically has network visibility into every managed endpoint and stores configuration data, policy assignments, and potentially credentials. Compromising EMS does not just give an attacker a database — it gives them a map of the entire endpoint estate and a mechanism to push configuration changes.

This follows a pattern. Fortinet management interfaces have appeared in CISA KEV multiple times over the past two years. The recurring lesson is that security management consoles must be treated as crown-jewel infrastructure: segmented onto dedicated management VLANs, restricted to authorized administrator source IPs, and monitored with the same rigor applied to domain controllers.

What defenders should do: Patch FortiClient EMS immediately. If patching requires a maintenance window, restrict network access to the management interface to dedicated admin subnets as a compensating control. Audit FortiClient EMS logs for anomalous SQL query patterns or unexpected administrative actions. Verify that the management console is not exposed to the general corporate network or, worse, the internet.

Source: The Hacker News

FBI Dismantles W3LL Phishing Kit in First US-Indonesia Joint Takedown

The FBI, in coordination with Indonesian law enforcement, dismantled the W3LL phishing-as-a-service operation. W3LL sold turnkey phishing kits for approximately $500 per month and facilitated over $20 million in attempted fraud. The kits were purpose-built to bypass multi-factor authentication (MFA) through real-time adversary-in-the-middle (AiTM) session hijacking — capturing authentication tokens as victims completed legitimate MFA challenges.

This is not a story about a sophisticated threat actor. It is a story about industrialized infrastructure. W3LL operated as a service business: monthly subscriptions, documentation, customer support, and regular kit updates to evade new detection signatures. Its customers did not need to understand how AiTM session hijacking works. They needed $500 and an email list.

The takedown is operationally significant — it disrupts a supply chain used by hundreds of downstream phishing operators. But the defensive takeaway is that AiTM phishing kits are now commodity tools available to low-skill operators. Traditional MFA (push notifications, SMS, TOTP) does not defend against session hijacking at the proxy layer. Phishing-resistant MFA — FIDO2/WebAuthn with hardware tokens or platform authenticators — remains the primary countermeasure because it binds the authentication ceremony to the legitimate origin, preventing proxy interception.

What defenders should do: Evaluate your MFA deployment. If you are still relying on push notifications or TOTP as primary factors for privileged accounts and externally-facing applications, the W3LL takedown is your evidence that commodity kits can bypass them. Accelerate FIDO2 deployment for high-value accounts. Implement token binding or device-bound session credentials where supported.

Source: The Record (Recorded Future)

Critical wolfSSL Flaw Breaks ECDSA Certificate Validation in Embedded Devices

A critical vulnerability in the wolfSSL library allows attackers to forge Elliptic Curve Digital Signature Algorithm (ECDSA) signatures, causing fraudulent TLS certificates to pass validation. wolfSSL is a lightweight TLS library embedded in IoT devices, real-time operating systems, industrial controllers, and hardware appliances from multiple vendors. The flaw is in the signature verification logic itself — meaning any device using an affected wolfSSL version will accept a forged certificate as legitimate.

The impact breaks the TLS trust chain at the library level. An attacker with a network position (or the ability to perform DNS hijacking) can present a forged certificate to an affected device, and the device will complete the TLS handshake as if the certificate were valid. This enables man-in-the-middle interception of encrypted communications, credential theft, and firmware update manipulation for devices that verify update server certificates using wolfSSL.

The remediation challenge is the embedded supply chain. Organizations do not patch wolfSSL directly — they wait for device manufacturers to release firmware updates that include the fixed library version. Many embedded devices have no automated update mechanism. The first step is knowing which devices in your environment use wolfSSL, which requires a software bill of materials (SBOM) or vendor inquiry.

What defenders should do: Audit your asset inventory for devices that may embed wolfSSL — IoT gateways, industrial controllers, network appliances, and embedded Linux systems are common candidates. Contact device vendors to confirm whether their products are affected and when firmware updates will be available. For critical OT or IoT segments, consider network-level TLS inspection or segmentation as a compensating control until firmware patches are deployed.

Source: BleepingComputer

Today’s Deep Dive — The “Storm” Infostealer and Server-Side Session Decryption

A new infostealer variant dubbed “Storm” introduces a technique that shifts encrypted browser data exfiltration and decryption to attacker-controlled infrastructure, bypassing endpoint detection mechanisms that monitor for local credential extraction.

The Mechanism

Traditional infostealers — Raccoon, Vidar, RedLine — follow a well-understood pattern: they extract encrypted browser cookies, saved passwords, and session tokens from the local file system, decrypt them locally using the victim’s DPAPI keys or Chrome’s Local State encryption key, and exfiltrate the plaintext. Endpoint detection and response (EDR) solutions have built detections around this pattern: monitoring access to browser credential stores, flagging processes that call CryptUnprotectData, and detecting anomalous reads of Login Data and Cookies SQLite databases.

Storm bypasses this detection model by skipping the local decryption step entirely. It exfiltrates the encrypted browser data — cookies, session tokens, saved credentials — in their encrypted form, along with the keying material needed to decrypt them. The decryption happens on the attacker’s server. From the endpoint’s perspective, the malware never calls decryption APIs, never produces plaintext credentials in memory, and never exhibits the behavioral signatures that EDR tools are tuned to detect.

The result is session hijacking without triggering MFA re-authentication. Stolen session cookies, once decrypted server-side, allow the attacker to impersonate the victim’s authenticated session in cloud applications, SaaS platforms, and webmail — no password and no MFA prompt required.

This maps to MITRE ATT&CK T1539 — Steal Web Session Cookie and T1555.003 — Credentials from Web Browsers.

Why It Matters for Detection

The defensive gap is real. If your detection stack relies primarily on endpoint behavioral analysis for credential theft — specifically monitoring for local decryption API calls or browser database access patterns — Storm-class stealers will evade it. The exfiltration of encrypted blobs looks like generic data exfiltration, not credential theft, unless you are specifically monitoring for the combination of browser data file access plus outbound data transfer.

The compensating controls are:

  1. Device-bound session credentials — if session cookies are cryptographically bound to the device that created them, stolen cookies are unusable on attacker infrastructure. Google’s Device Bound Session Credentials (DBSC) initiative targets exactly this gap.
  2. Token lifetime reduction — shorter session token lifetimes limit the window of exploitation for stolen cookies.
  3. Anomalous session detection — monitor for session cookies being used from new device fingerprints, IP ranges, or geographies that do not match the authenticated user’s profile.
  4. Network-level exfiltration detection — monitor for bulk encrypted file transfers to uncategorized or newly-registered domains.

Source: BleepingComputer

Detection Spotlight

Detecting browser credential store access followed by outbound data transfer (Storm-class stealer pattern)

Traditional infostealer detections key on decryption API calls. Storm-class stealers skip that step. The detection below targets the precursor behavior: a non-browser process accessing browser credential databases, followed by outbound network activity from the same process within a short time window. This is a Splunk SPL correlation search.

| tstats summariesonly=t count from datamodel=Endpoint.Filesystem
  where Filesystem.file_path IN (
    "*\\AppData\\Local\\Google\\Chrome\\User Data\\Default\\Login Data",
    "*\\AppData\\Local\\Google\\Chrome\\User Data\\Default\\Cookies",
    "*\\AppData\\Local\\Google\\Chrome\\User Data\\Local State",
    "*\\AppData\\Local\\Microsoft\\Edge\\User Data\\Default\\Login Data",
    "*\\AppData\\Local\\Microsoft\\Edge\\User Data\\Default\\Cookies"
  )
  AND NOT Filesystem.process_name IN ("chrome.exe", "msedge.exe", "browser_broker.exe", "GoogleUpdate.exe")
  by Filesystem.process_name Filesystem.process_id Filesystem.dest _time
| rename Filesystem.* as *
| join type=inner process_id dest
  [| tstats summariesonly=t count from datamodel=Network_Traffic.All_Traffic
   where All_Traffic.action=allowed AND All_Traffic.bytes_out > 50000
   by All_Traffic.process_id All_Traffic.dest All_Traffic.dest_ip All_Traffic.dest_port _time
   | rename All_Traffic.* as *
   | where dest_port != 443 OR match(dest_ip, "^(10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.)") = 0]
| where _time < relative_time(now(), "+5m")
| table _time dest process_name process_id file_path dest_ip dest_port bytes_out
| sort - bytes_out

What it catches: A non-browser process reading Chrome or Edge credential databases and then sending more than 50 KB outbound to an external IP. This covers both traditional infostealers (which decrypt locally before exfil) and Storm-class variants (which exfiltrate encrypted blobs). False positives include legitimate browser sync utilities and enterprise browser management tools — tune the NOT Filesystem.process_name exclusion list for your environment.

References

Subscribe to the it-learn Brief

Get the daily cybersecurity brief in your inbox every weekday morning — news, SE angles, and detection queries.