Weekly Threat Bulletin – April 29th, 2026

Apple Patches Exploited Notification Flaw

Apple has released iOS/iPadOS 26.4.2 and iOS/iPadOS 18.7.8 to address a single Notification Services vulnerability, identified as CVE-2026-28950. This flaw allowed notifications marked for deletion to be unexpectedly retained on devices due to a logging issue, which has now been resolved with improved data redaction. Although Apple did not officially mark the vulnerability as exploited, reports indicate that the FBI leveraged this specific vulnerability to extract Signal messages from a seized device. Signal, an end-to-end encrypted messaging application designed to avoid storing retrievable data, was affected because it utilizes Apple's Notification Services framework. These notifications, which can display sender usernames and message content, were not properly deleted by iOS even when marked for removal, highlighting a potential mismatch between the threat models of secure messaging applications and underlying operating system libraries and APIs.

Severity: Critical

Threat Details and IOCs

Mitigation Advice

• Use your Mobile Device Management (MDM) solution to enforce an immediate update of all managed iPhones and iPads to iOS/iPadOS 26.4.2 or 18.7.8, or the latest available version.
• Issue a security advisory to all employees, instructing them to immediately change the notification settings for all messaging applications (like Signal, Teams, Slack) on their mobile devices to hide message content and sender details from the lock screen and notification center.

Compliance Best Practices

• Review and strengthen Mobile Device Management (MDM) policies to enforce a minimum required OS version for all mobile devices accessing corporate resources, ensuring timely and automatic deployment of critical security updates.
• Incorporate modules into the annual security awareness training program that specifically address mobile device security hygiene, including the risks of displaying sensitive information in notifications and how to configure these settings securely.
• Establish a formal application vetting process that includes a security review of how any new application proposed for corporate use handles sensitive data, specifically its interaction with OS-level features like notifications, clipboard, and backups.

Bitwarden CLI Hijacked to Steal Your AWS, GitHub, and SSH Secrets

Bitwarden CLI version 2026.4.0, distributed via npm, was compromised through a hijacked GitHub Action within Bitwarden's CI/CD pipeline, leading to the theft of developer credentials. This malicious package, part of a broader supply chain campaign, replaced the legitimate CLI binary entry point with a custom loader, ``bw_setup.js`,` which silently executed a heavily obfuscated payload, `bw1.js`, after downloading the Bun JavaScript runtime. The payload aggressively collected SSH keys, `.git-credentials`, `.npmrc`, `.env` files, shell history, AWS, GCP, and Azure credentials, GitHub CLI tokens, and AI coding assistant configuration files like `~/.claude.json`. A notable aspect of the attack was the weaponization of stolen GitHub tokens to enumerate repositories, create new branches, commit malicious workflow files, execute them, and then delete the evidence. Stolen data was encrypted and exfiltrated to `audit.checkmarx.cx` or staged within the victim's own GitHub repositories. Immediate actions for those who installed `@bitwarden/cli 2026.4.0` include running `npm uninstall -g @bitwarden/cli` and `npm cache clean --force`, rotating all GitHub PATs, npm tokens, AWS access keys, GCP, and Azure secrets, auditing GitHub Actions workflows, blocking `audit.checkmarx.cx` and `94.154.172.43`, and reviewing shell history and AI tooling configuration files for sensitive data exposure.

Severity: Critical

Threat Details and IOCs

Mitigation Advice

• Scan all developer workstations and CI/CD environments for the npm package `@bitwarden/cli`. If version `2026.4.0` is found, immediately run `npm uninstall -g @bitwarden/cli` and `npm cache clean --force` to remove it.
• Add `audit.checkmarx.cx` and `94.154.172.43` to the network firewall and DNS sinkhole blocklists to prevent communication with the attacker's command and control infrastructure.
• Force the rotation of all GitHub Personal Access Tokens (PATs) on any machine where the malicious package was or could have been installed.
• On all potentially affected systems, identify and immediately rotate all AWS IAM user access keys.
• On all potentially affected systems, identify and immediately rotate all Google Cloud Platform (GCP) service account keys and other secrets.
• On all potentially affected systems, identify and immediately rotate all Azure service principal credentials and other secrets.
• Initiate a rotation of all SSH keys stored on developer workstations that may have been compromised by the malicious package.
• Conduct an immediate audit of GitHub repositories and Actions logs for any unauthorized commits, branches, or workflow executions originating from potentially compromised developer accounts.

Compliance Best Practices

• Implement a private artifact repository (e.g., JFrog Artifactory, Sonatype Nexus) to proxy, vet, and cache approved versions of third-party software packages used in development.
• Enforce mandatory peer review for all changes to CI/CD workflow configuration files (e.g., via GitHub's CODEOWNERS) to prevent unauthorized modifications.
• Phase out the use of static IAM user access keys for developers and migrate to a system that provides short-lived credentials, such as AWS IAM Identity Center (SSO).
• Deploy and mandate the use of a centralized secrets management tool (e.g., HashiCorp Vault, AWS Secrets Manager, Bitwarden) to inject secrets into applications and developer environments at runtime.
• Configure and tune Endpoint Detection and Response (EDR) policies to generate high-priority alerts for suspicious process activity, such as a package manager downloading and executing a new binary for the first time.
• Implement a network egress filtering strategy for developer workstations and CI/CD environments that denies outbound traffic by default and only allows connections to explicitly approved domains and IP addresses.

CISA Warns of FIRESTARTER Malware Targeting Cisco ASA Including Firepower and Secure Firewall Products

CISA has released a malware analysis report on FIRESTARTER, a threat enabling remote access and control by malicious actors targeting Cisco Firepower and Secure Firewall products running Adaptive Security Appliance (ASA) or Firepower Threat Defense (FTD) software. An Advanced Persistent Threat (APT) actor exploited CVE-2025-20333 and CVE-2025-20362 in Cisco ASA firmware to gain initial access and deploy FIRESTARTER, which can persist on devices even after firmware patching. In response, CISA updated Emergency Directive 25-03, requiring Federal Civilian Executive Branch (FCEB) agencies to identify affected devices, collect forensic data, and apply new vendor-provided updates. Organizations using these Cisco products are urged to review the FIRESTARTER report, assess their devices for compromise, implement mitigations, and report any findings to CISA.

Severity: Critical

Threat Details and IOCs

Mitigation Advice

• Create and verify an inventory of all Cisco Firepower, Secure Firewall, ASA, and FTD devices on the network.
• Apply vendor-supplied patches to all identified Cisco devices to remediate CVE-2025-20333 and CVE-2025-20362.
• Hunt for indicators of compromise (IOCs) associated with FIRESTARTER malware on all Cisco ASA and FTD devices by reviewing logs and system files for anomalies as described in the CISA malware analysis report.
• For any Cisco device confirmed to be compromised with FIRESTARTER, isolate the device from the network, collect forensic data, and reimage it using a verified, clean firmware version before restoring a sanitized configuration.

Compliance Best Practices

• Establish a formal vulnerability management program for network infrastructure that defines specific timelines for patching critical devices based on CVSS scores and threat intelligence.
• Implement enhanced logging and network flow monitoring for traffic to and from the management interfaces of all network security appliances and establish alerts for anomalous connections.
• Develop and implement a network segmentation strategy to create security zones that restrict communication between critical servers and user workstations, limiting lateral movement from a compromised network device.
• Institute a quarterly review process to audit and harden the configurations of all internet-facing network appliances, ensuring that unused services are disabled and administrative access is restricted to a secure management network.

Critical Spring Authorization Server Issue Exposes Systems to XSS and SSRF Attacks

A critical vulnerability, tracked as CVE-2026-22752, has been disclosed in Spring Security Authorization Server, affecting organizations that utilize Dynamic Client Registration endpoints. This flaw arises from insufficient validation of client metadata when Dynamic Client Registration is explicitly enabled, allowing an attacker with a valid Initial Access Token to register a malicious OAuth client with specially crafted metadata. Exploitation can lead to Stored Cross-Site Scripting (XSS), Privilege Escalation, and Server-Side Request Forgery (SSRF) attacks. The vulnerability is network-exploitable, requires low privileges, and has a CVSS vector of AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N. Affected versions include Spring Security 7.0.0 through 7.0.4, and Spring Authorization Server 1.3.0 through 1.3.10, 1.4.0 through 1.4.9, and 1.5.0 through 1.5.6. Immediate upgrades to Spring Security 7.0.5, Spring Authorization Server 1.3.11, 1.4.10, or 1.5.7 are strongly advised, with disabling Dynamic Client Registration endpoints serving as a temporary mitigation if patching is not immediately feasible. Compromise of an Authorization Server, which is central to modern application authentication, can result in full organizational account takeover, lateral movement, and sensitive data exfiltration, making this vulnerability particularly dangerous for cloud-native and microservice environments.

Severity: Critical

Threat Details and IOCs

Mitigation Advice

• Use asset inventory and dependency analysis tools to identify all applications using vulnerable versions of Spring Security (7.0.0 – 7.0.4) and Spring Authorization Server (1.3.0 – 1.3.10, 1.4.0 – 1.4.9, 1.5.0 – 1.5.6).
• Upgrade all identified instances of Spring Security 7.0.x to version 7.0.5 or later.
• Upgrade all identified instances of Spring Authorization Server to the appropriate patched version: 1.3.x to 1.3.11, 1.4.x to 1.4.10, or 1.5.x to 1.5.7.
• For any vulnerable Spring Authorization Server instance that cannot be patched immediately, disable the Dynamic Client Registration feature.
• Review application and server logs for all Spring Authorization Servers, looking for unusual or suspicious client metadata in dynamic client registration requests, especially those created after the vulnerability disclosure.

Compliance Best Practices

• Implement and maintain a comprehensive software asset inventory, including a Software Bill of Materials (SBOM) for all developed and third-party applications, to accelerate future vulnerability identification and response.
• Establish a security baseline for application configurations that disables all non-essential features and endpoints by default and regularly audit applications against this baseline.
• Implement default-deny egress filtering policies on application servers to restrict outbound network connections to only explicitly approved destinations, mitigating the impact of potential SSRF vulnerabilities.
• Deploy and configure a Web Application Firewall (WAF) with rules to inspect, detect, and block malicious payloads in client metadata, such as those used in XSS and other injection attacks.

Snow Flurries: How UNC6692 Employed Social Engineering to Deploy a Custom Malware Suite

The UNC6692 threat group executed a multistage intrusion campaign leveraging persistent social engineering, a custom modular malware suite, and adept internal pivoting to achieve deep network penetration. The attack began with a large email campaign followed by a Microsoft Teams phishing message, where attackers impersonated IT helpdesk personnel to trick victims into downloading a renamed AutoHotKey binary and script from an AWS S3 bucket. This initial compromise led to the installation of SNOWBELT, a malicious Chromium browser extension that established persistence via Windows Startup folders and scheduled tasks, acting as the primary command-and-control (C2) relay. Subsequently, SNOWGLAZE, a Python-based tunneler, created secure WebSocket tunnels to a Heroku subdomain for SOCKS proxy operations, while SNOWBASIN, a Python bindshell, provided remote command execution, screenshot capabilities, and data staging on infected systems. Post-initial access, UNC6692 performed internal reconnaissance, moved laterally using PsExec and RDP, escalated privileges by extracting LSASS process memory, and exfiltrated sensitive data, including Active Directory database files (NTDS.dit), SAM, SYSTEM, and SECURITY registry hives, along with screen captures, via LimeWire. This campaign highlights the abuse of legitimate cloud services for payload delivery, exfiltration, and C2, making detection challenging due to malicious traffic blending with high volumes of encrypted, reputably sourced cloud traffic.

Severity: Critical

Threat Details and IOCs

Mitigation Advice

• Block all network indicators of compromise (domains and URLs) listed in the article at the network firewall, web proxy, and in DNS blocklists.
• Use your Endpoint Detection and Response (EDR) or antivirus solution to scan all endpoints and servers for the file hashes provided in the article.
• Deploy the YARA rules provided in the article to your EDR, SIEM, or other scanning tools to hunt for the SNOW malware ecosystem across your environment.
• In your EDR or SIEM, hunt for process execution events where `msedge.exe` is launched with command-line arguments containing both '--headless' and '--load-extension'.
• Create a high-priority alert in your EDR or SIEM to detect and investigate any process that attempts to read the memory of the LSASS process (lsass.exe).
• Hunt for executions of AutoHotKey (`AutoHotkey.exe` or renamed variants) in your environment, paying close attention to processes launched by non-administrative users or originating from download or temporary folders.

Compliance Best Practices

• Implement a recurring security awareness training program that specifically teaches employees how to identify and report impersonation and phishing attempts on collaboration platforms like Microsoft Teams.
• Configure Microsoft Teams external access policies to either block communication from all external tenants or restrict it to an explicit allowlist of trusted partner organizations.
• Use Group Policy (GPO) or a Mobile Device Management (MDM) solution to enforce a browser extension allowlist, preventing users from installing any extensions that are not explicitly approved by the security team.
• Implement an application allowlisting solution, such as Windows Defender Application Control (WDAC) or AppLocker, to restrict executable files, scripts, and installers to only approved software on workstations and servers.
• Implement a network segmentation strategy using host-based firewalls and network access control lists (ACLs) to prevent client workstations from initiating connections to each other and to sensitive servers on ports like SMB (445) and RDP (3389).
• Enable LSA Protection (as a Protected Process Light) via Group Policy or Intune on all supported Windows devices to prevent credential dumping from LSASS memory.
• Enable comprehensive PowerShell logging, including Script Block Logging, Module Logging, and Transcription, and forward these logs to your SIEM for monitoring and analysis.
• Deploy a forward proxy capable of TLS inspection to monitor and filter outbound web traffic, blocking connections to unsanctioned cloud storage and Platform-as-a-Service (PaaS) providers.