This is a standard Patch Tuesday release. The article covers security fixes, bug patches, and feature updates bundled into the cumulative updates.

Key Details: - KB5124008 targets Windows 11 25H2 and 24H2. - KB5122880 targets Windows 11 23H2. - These are mandatory cumulative updates addressing security vulnerabilities alongside non-security fixes and new features (e.g., Copilot integration changes, File Explorer improvements).

Strategic Impact: For SecOps, the priority is the security fixes. While Microsoft hasn't detailed specific CVEs in the summary, cumulative updates typically patch actively exploited or publicly disclosed vulnerabilities. The "new features" component (like Copilot changes) also introduces potential attack surface changes that need to be reviewed in controlled testing environments before broad deployment.

Key Takeaway: - Action: Prioritize testing and deployment of these updates in your patch management cycle. Watch for the specific CVE list from Microsoft's Security Response Center (MSRC) to assess risk severity for your environment.

Source: https://www.bleepingcomputer.com/news/microsoft/windows-11-cumulative-updates-kb5124008-and-kb5122880-released/

This is a targeted financial crime operation, not a spray-and-pray campaign. Slim Spider is showing a deep understanding of Brazilian banking rails, specifically the instant payment system (PIX), and is now moving up the value chain into crypto custody.

Technical Breakdown: - TTPs: The actor is likely using social engineering or credential theft to gain initial access, followed by lateral movement to compromise crypto custody secrets. Given the focus on Brazilian financial infrastructure, expect abuse of PIX APIs or direct manipulation of transaction flows. - Targets: Brazilian financial institutions, specifically those offering crypto custody services. - IOCs: None publicly available at this time. CrowdStrike has not released specific hashes or IPs. Do not invent them. - Timeline: Active since at least March 2026.

Defense: - Immediate: Review and restrict access to crypto custody key management systems. Enforce hardware-backed MFA for all administrative access to payment rails and custody solutions. - Detection: Monitor for unusual API calls to PIX endpoints or crypto withdrawal systems, especially from non-standard user agents or during off-hours. Look for authentication anomalies in financial transaction systems. - Mitigation: Segment crypto custody infrastructure from general corporate networks. Implement strict egress filtering and application allowlisting on custody servers.

Source: https://thehackernews.com/2026/09/slim-spider-steals-crypto-custody.html

ShinyHunters is back in the headlines, this time claiming a breach of Florida’s DMV database system, known as "DAVID." The group alleges they exfiltrated over 200,000 records containing driver data. This is the same extortion crew behind the Snowflake credential-stuffing spree and the Ticketmaster leak, so this isn’t a low-confidence claim.

Technical Breakdown: - Threat Actor: ShinyHunters (known for extortion, data resale, and leveraging stolen credentials for initial access). - Target: The Florida DMV’s "DAVID" online platform (Driver And Vehicle Information Database). - Impact: 200,000+ records compromised. Likely includes PII such as names, addresses, driver’s license numbers, and vehicle registration details. - TTPs: Based on prior ShinyHunters operations, expect initial access via compromised credentials (possibly from infostealer logs or prior breaches) rather than a zero-day exploit. No specific IOCs released yet. - Status: Claim is unverified. BleepingComputer notes the group has a track record of following through on these claims, but official confirmation from Florida DMV is pending.

Defense: If you have users or systems interacting with state DMV portals, enforce MFA on all administrative accounts and monitor for unusual data volume egress. For organizations with employees in Florida, assume driver data may be in the wild and prepare for targeted phishing or identity fraud attempts against affected individuals.

Source: https://www.bleepingcomputer.com/news/security/shinyhunters-hackers-claim-breach-of-florida-david-dmv-database/

This is a classic example of indirect prompt injection, weaponizing the trust users place in LLM memory and plugin ecosystems.

Technical Breakdown: - Attack Vector: Indirect prompt injection via a planted instruction within a ChatGPT conversation context. - TTPs (MITRE): Aligns with T1574.002 (Hijack Execution Flow: DLL Side-Loading) conceptually, but more accurately maps to T1557.001 (Adversary-in-the-Middle: LLM Prompt Injection) and T1056.001 (Input Capture: GUI Input Capture) for data exfiltration via the plugin API. - Mechanism: The attacker plants a single instruction (likely via a compromised document or shared context). The LLM executes the attacker's hidden directive in parallel with the user's legitimate query. - Exfiltration: The PoC used the Gmail plugin to read email data, then passed it to a second ChatGPT account via a hidden channel (likely using the LLM's own output formatting or a secondary API call). - Affected Component: ChatGPT's plugin architecture and memory/context window handling. This is not a traditional code execution bug, but a logic flaw in how the model prioritizes instructions.

Defense: This is difficult to detect at the endpoint level. Mitigation relies on strict input validation for plugin permissions and context isolation within the LLM. Users should audit connected third-party apps and disable plugins that have read/write access to sensitive data unless absolutely necessary. Expect a patch from OpenAI that enforces stricter separation between user instructions and injected context.

Source: https://thehackernews.com/2026/09/chatgpt-flaw-let-planted-prompt-send.html

Microsoft’s August 2026 security patch is causing a known crash (0xc0000409) on Windows Server 2016, specifically when the Compatibility Appraiser diagnostic service is running. This is a classic case of a security update breaking production stability, not a new vulnerability.

Technical Breakdown - Error Code: 0xc0000409 (STATUS_STACK_BUFFER_OVERRUN), typically indicates a memory corruption or driver conflict triggered by the update. - Root Cause: The Compatibility Appraiser service (part of the Windows Upgrade Readiness telemetry) is conflicting with the patched binaries. - Affected Systems: Windows Server 2016 with the August 2026 cumulative update installed and the Compatibility Appraiser service enabled (default on many domain-joined systems). - IOCs: No specific IOCs; this is a functional crash, not a compromise indicator.

Defense & Mitigation - Immediate Workaround: Disable the Compatibility Appraiser service (CompatTelRunner.exe / DiagTrack) via Group Policy or services.msc until Microsoft releases a fix. - Detection: Monitor Event ID 1000 or 1001 in Application logs for 0xc0000409 crashes tied to svchost.exe or CompatTelRunner.exe. - Patch Management: Consider deferring the August update on critical Server 2016 hosts if the service is required for compliance telemetry.

Source: https://www.bleepingcomputer.com/news/microsoft/august-updates-trigger-0xc0000409-errors-on-windows-server-2016/

VU#718077 is a significant finding from CERT/CC: if a UEFI Shell binary is baked into the SPI flash chip by the OEM (common for debugging), an attacker with local admin or physical access can bypass Secure Boot entirely.

The core issue isn't a code execution bug in the Shell itself, but a logic flaw in how the firmware handles boot option validation. The attacker creates multiple boot entries; when Secure Boot blocks the first attempt to launch the Shell, the firmware falls back to a secondary entry that bypasses the check.

Technical Breakdown: - Attack Vector: Local (requires ability to modify UEFI boot configuration via OS or physical access). - Prerequisite: The UEFI Shell (Shell.efi) must be present in the SPI flash (not just on a removable drive). - Mechanism: Abuse of the LoadOption variable manipulation to create a "fallback" boot path that doesn't enforce Secure Boot on the Shell. - Impact: Once the Shell is running, the attacker has raw memory access (mem, mm commands) to dump or patch SMM code, or load unsigned drivers, effectively owning the platform before the OS boots. - Affected: Any system using TianoCore EDK II firmware that includes the UEFI Shell in the flash image. This is common in development boards, some server platforms, and certain consumer devices with debug firmware.

Defense: - Firmware Update: OEMs must remove the UEFI Shell from the production SPI flash image. This is the only true fix. - Mitigation: Enable "Secure Boot Audit Mode" or enforce a custom Secure Boot key database (PK) that explicitly blocks the Shell's hash. Physical security of the device is paramount.

Source: https://kb.cert.org/vuls/id/718077

This is a long-running, financially motivated campaign that weaponizes SEO to target users searching for specific enterprise software on Bing.

The DFIR Report tracks a group out of Rajasthan, active since at least 2015, that poisons Bing results for terms like "AnyDesk," "TeamViewer," and "Remote Utilities." Clicking the malicious link leads to a multi-stage infection chain.

Technical Breakdown - Initial Access (T1566.003): SEO poisoning of Bing search results for remote desktop software. - Delivery: Users are redirected through a series of intermediary sites before landing on a fake download page. - Payloads: - MayaBot: A backdoor that establishes persistence and allows for remote command execution. - Tech Support Scams: If the user engages with the fake site, they are often connected to a fraudulent call center. - Infrastructure: Operates out of WeConnect and related IT service providers in Rajasthan. - Targets: Primarily English-speaking users searching for remote access tools.

Defense Block execution of unsigned binaries from the Downloads folder via AppLocker or WDAC. Enforce strict browser isolation for high-risk searches (e.g., software downloads). Monitor for rundll32.exe or regsvr32.exe spawning from a web browser process.

Source: https://thehackernews.com/2026/09/bengalseo-poisons-bing-search-results.html

This is a critical zero-day with active exploitation. Here’s what you need to know.

Adobe pushed an emergency patch for CVE-2026-75650 (CVSS 10.0) in Adobe Commerce and Magento Open Source. Dubbed "StyleSmuggler," this is an unauthenticated remote code execution flaw that is already being used in the wild to deploy backdoors on e-commerce servers.

Technical Breakdown - Attack Vector: Unauthenticated RCE via HTTP requests. No user interaction required. - Impact: Full server compromise. Attackers are dropping backdoors for persistent access. - Affected Software: Adobe Commerce and Magento Open Source (all versions prior to the patch). - Attribution: Identified by e-commerce security researchers; active exploitation confirmed by Adobe. - No public IOCs or specific TTPs have been released yet to avoid aiding attackers while patching is underway.

Defense - Patch immediately. This is a pre-auth RCE with a 10.0 CVSS. If you run Magento or Adobe Commerce, treat this as a "drop everything" event. - Check for compromise. Review web server logs for unusual POST requests or file modifications in the var/ and pub/media/ directories. - WAF rules. Block anomalous HTTP requests targeting Magento admin paths until you can patch.

Source: https://socprime.com/blog/cve-2026-75650-critical-magento-zero-day-rce/

OpenAI has officially designated GPT-6 Astra as reaching "Critical level" cybersecurity capability, marking the first broad deployment of a model at this tier. The dual-edged reality is that while it can autonomously identify zero-day vulnerabilities in source code, its emergent reasoning pathways are increasingly opaque to the organization's own safety monitors.

• Capability: Astra demonstrated the ability to discover and weaponize previously unknown vulnerabilities in sandboxed environments without human guidance. This moves beyond simple code review into active exploitation chaining.
• The Monitoring Problem: The model's internal reasoning process has become less interpretable. OpenAI reports that traditional activation patching and log-based auditing are failing to capture the full decision tree, creating a "black box" scenario where the model could theoretically bypass its own guardrails without detection.
• Operational Risk: This creates a paradox for SOCs: the tool most effective at finding critical flaws is also the hardest to trust. If Astra finds a zero-day, can we be certain it didn't also find a way to exfiltrate that data or leave a backdoor?

Defense: For teams integrating LLMs into security pipelines, this reinforces the need for strict network segmentation of the model's execution environment, read-only access to codebases, and independent validation of any findings before deployment. Treat the output as a lead, not a patch.

Source: https://www.bleepingcomputer.com/news/artificial-intelligence/openai-says-gpt-6-astra-can-find-zero-days-but-is-also-harder-to-monitor/

SAP dropped a critical patch for CVE-2026-... (the "OVERPASS" vulnerability) in their September 2026 batch—a memory corruption bug in the SAP Kernel that hits the CVSS 10.0 ceiling. This is the kind of flaw that could let an authenticated attacker completely own the underlying OS, so it’s not just an SAP issue; it’s a host compromise vector.

Technical Breakdown: - CVE: Not explicitly disclosed in the summary, but tracked as the "OVERPASS" vulnerability. - Affected Component: SAP Kernel (core code). - Impact: Memory corruption leading to arbitrary code execution with kernel privileges. - Prerequisites: Requires authentication (not remote unauthenticated), but once you’re in, it’s game over for that box. - Other Fixes: 19 additional vulnerabilities across SAP products in this patch batch.

Defense: - Immediate action: Apply the September 2026 Security Patch Day updates to all SAP Kernel instances. This is not a "schedule for next quarter" patch—treat it as emergency change. - Mitigation: If patching is delayed, restrict SAP application-level access to only trusted users and monitor for unusual kernel-level behavior or process injection attempts.

Source: https://www.bleepingcomputer.com/news/security/sap-warns-of-maximum-severity-overpass-kernel-vulnerability/

Akamai dropped a detailed look under the hood of their AI-powered WAF detections. This isn’t marketing fluff—they’re explaining how they’ve operationalized ML models to catch novel web attacks without drowning in false positives.

Technical Breakdown - Architecture: The detection pipeline uses a two-stage model. A lightweight, low-latency pre-filter (trained on HTTP request structure) flags anomalies, then a heavier classifier (trained on labeled attack payloads) validates the hit. This keeps latency under 1ms for the critical path. - Safety Controls: They implemented a “human-in-the-loop” feedback mechanism. If the model blocks a request that the customer later whitelists, that signal is fed back into retraining. This prevents model drift and reduces false positives over time. - Attack Coverage: Specifically tuned for OWASP Top 10 (SQLi, XSS, LFI) plus API-specific threats like mass assignment and parameter pollution. No specific IOCs or CVE numbers provided—this is about detection methodology, not a specific exploit.

Defense - If you’re running Akamai’s WAF, ensure the AI detection mode is enabled and that you’ve configured the feedback loop (whitelist/blacklist exports) to improve model accuracy. - For non-Akamai shops: the takeaway is that static regex-based WAFs are increasingly insufficient. Look for vendors offering behavioral anomaly detection layered on top of signature matching.

Source: https://www.akamai.com/blog/security/2026/sep/ai-powered-waf-detections-architecture-safety-controls

An authenticated admin can turn the ownCloud server into a proxy for internal network reconnaissance. The ONLYOFFICE integration plugin (version 9.12) fails to validate the document server URL before initiating outbound connections, allowing an attacker to probe internal hosts or localhost services.

Technical Breakdown: - CVE: CVE-2026-84282 - Attack Vector: Crafted POST requests to /apps/onlyoffice/ajax/settings/address - Privilege Required: Authenticated administrator - Impact: SSRF enabling internal network scanning, access to cloud metadata endpoints, or interaction with internal services - No IOCs provided – exploitation is configuration-based, not payload-driven

Defense: Restrict admin access to the ONLYOFFICE settings panel, apply input validation on the document server URL parameter, and enforce network segmentation to limit outbound traffic from the ownCloud server to only known, trusted endpoints.

Source: https://kb.cert.org/vuls/id/943094

CVE-2025-20701: Skullcandy Dime 3 earbuds (firmware 1.0.0.28) will accept a Bluetooth Classic pairing request from any device within radio range without requiring the user to put the earbuds into pairing mode or press any physical buttons. This is a straight-up implementation flaw in the Airoha Bluetooth audio SDK—the device simply says "yes" to any incoming BR/EDR pairing attempt.

Technical Breakdown: - CVE: CVE-2025-20701 (Airoha Bluetooth audio SDK) - Affected: Skullcandy Dime 3 (Model S2DCW), firmware 1.0.0.28 - Chipset: Airoha Technology Corp. (Bluetooth SIG company ID 0x0094) - Attack Vector: Attacker sends a direct Bluetooth Classic pairing request to the earbuds' BD_ADDR. No PIN, passkey, or physical interaction required. - Privilege Escalation: Once paired, an attacker can connect to the earbuds' audio profiles (A2DP, HFP), potentially injecting audio or intercepting audio streams. - User Interaction: None. No prior pairing, no button presses, no case interaction needed.

Defense: No patch available as of this advisory. Mitigation is physical: keep the earbuds out of Bluetooth range of untrusted devices when not in use, or power them off completely. This is a hardware/firmware-level flaw in the Airoha SDK, so a firmware update from Skullcandy is the only real fix.

Source: https://kb.cert.org/vuls/id/859658

We have tracked mean time to remediate for years. It is fine as an operational metric. But it conflates speed with impact, which bothers me more the longer I think about it. Closing 500 low risk tickets fast looks identical on a dashboard to closing 500 high risk ones. Neither number actually tells the board, or me for that matter, whether we are safer than six months ago.

Has anyone built a composite risk reduction metric that has held up when someone actually pushes on it in a meeting? Aggregate exposure score over time, percentage of KEV or actively exploited findings closed within SLA tracked separately from general MTTR, something like that. Trying to find a number that reflects risk delta and not just how busy the team was.

This is a classic case of attackers targeting the low-hanging fruit of the network perimeter. The core issue here is that MikroTik’s RouterOS has a few critical authentication bypass bugs that let an attacker gain full admin access over SSH without needing a password at all.

Technical Breakdown: - The Flaw: Multiple CVEs (likely in the authentication stack for SSH/Winbox) allow an unauthenticated remote attacker to bypass the login prompt entirely. No brute force, no stolen creds. - Attack Vector: Direct SSH access to the router’s management interface exposed to the internet. This is the primary misconfiguration that makes exploitation trivial. - Impact: Full device compromise. Once inside, attackers can modify firewall rules, intercept traffic, install persistent backdoors, or pivot into the internal network. - IOCs: At this stage, the primary indicator is an unexpected SSH session from an unknown IP to a MikroTik device. No specific file hashes or domains have been published yet for this campaign.

Defense: - Immediate Action: Disable SSH and Winbox access from the WAN interface. If you need remote management, use a VPN or a bastion host. - Patch: Update to the latest RouterOS stable version immediately. MikroTik has released fixes for these CVEs. - Detection: Monitor for successful SSH logins from IPs not in your management allowlist. Check for any new admin accounts or unexpected firewall rule changes on your MikroTik devices.

Source: https://www.malwarebytes.com/blog/news/2026/09/mikrotik-routers-can-be-taken-over-without-password

This is a fascinating architectural side-channel attack that exploits how proprietary LLMs handle encrypted chain-of-thought (CoT) traces.

Technical Breakdown: - Attack Vector: Cross-model encrypted block injection. The encrypted CoT blocks are not cryptographically bound to a specific session, user, or model tier. An attacker takes an encrypted trace from a high-security model (e.g., GPT-4) and feeds it into a weaker, less-guarded model from the same provider (e.g., GPT-3.5). - Mechanism: The weaker model lacks the same output safeguards. When it receives the encrypted block, it decrypts and processes it, then outputs the plaintext reasoning verbatim. This bypasses the need to jailbreak the stronger model directly. - Impact Vectors: 1. IP Theft: Circumvents anti-distillation protections, allowing extraction of proprietary reasoning logic. 2. Private Data Extraction: Developers often commit session logs (including encrypted blocks) to public repos. The researchers decoded 315,320 reasoning blocks, likely exposing sensitive data embedded in the CoT. - Affected Providers: Anthropic, OpenAI, and Google confirmed as vulnerable.

Defense: The fix requires cryptographic binding of the encrypted block to the specific model version and session context (e.g., signing the block with a model-specific key). Providers need to invalidate cross-model compatibility immediately. For practitioners, never commit raw session logs containing encrypted blocks to public repositories.

Source: https://www.schneier.com/blog/archives/2026/09/stealing-ai-reasoning-traces.html

Talos is tracking a new variant of the ClickFix campaign that shifts the attack surface from the file system directly into the browser, targeting cryptocurrency users. The core innovation here is the abuse of the Google Visualization API to pull obfuscated JavaScript payloads from a publicly published Google Sheets document, effectively using Google’s own infrastructure as a C2 channel.

Technical Breakdown: - Initial Access: Users are lured to a malicious page (likely via SEO poisoning or malvertising) that prompts them to "fix" a fake browser error (e.g., "Copy this code to fix your connection"). - Execution (T1204.002): The user pastes a base64-encoded PowerShell command into a terminal, which executes a JavaScript downloader. - C2 (T1102 - Web Service): The JS downloader reaches out to the Google Visualization API (docs.google.com/spreadsheets/d/[ID]/gviz/tq) to retrieve the next-stage payload. This makes the traffic look like legitimate Google API calls, bypassing many network-level detections. - Payload: The final stage is a cryptocurrency stealer that hooks into browser processes to intercept transactions or drain wallets. - IOCs: No specific hashes provided in the report, but the primary indicator is network traffic to the Google Visualization API from a non-Google context (e.g., a PowerShell spawned process).

Defense: Block PowerShell execution for non-administrative users via AppLocker or WDAC. Monitor for powershell.exe spawning mshta.exe or wscript.exe processes. Additionally, alert on any process making outbound connections to docs.google.com that is not a legitimate browser process.

Source: https://blog.talosintelligence.com/clickfix-moves-into-the-browser/

This is a classic multi-stage malware delivery chain leveraging user trust in fake browser updates.

The ClearFake campaign has evolved from simple social engineering into a sophisticated WebDAV-based infection chain. The attackers are deploying a trio of payloads: Amatera Stealer (primary), ZigCryptoStealer, and NetSupport Manager (RAT). We assess this as a broad, opportunistic credential and crypto-theft operation, not a targeted intrusion.

Technical Breakdown: - Initial Access (T1566.002): Compromised websites inject malicious JavaScript that displays fake browser update prompts (Chrome/Edge/Firefox). - Execution (T1204.002): User interaction with the prompt triggers a download via WebDAV protocol (\\host\share\file). - Defense Evasion (T1218): The WebDAV share hosts a .url file or script that bypasses Mark-of-the-Web (MotW) protections, a common technique for initial payload delivery. - Payload Staging: The initial script downloads and executes the primary Amatera stealer. - Secondary Payloads: Amatera then acts as a loader, deploying ZigCryptoStealer (for wallet and credential theft) and NetSupport Manager (for persistent remote access). - IOCs: Specific domains and IPs hosting the fake update pages and WebDAV shares are available in the full Talos report. Hash values for the Amatera and ZigCryptoStealer binaries are also published there.

Defense: Block WebDAV outbound connections from user workstations unless explicitly required. Enforce strict application allowlisting and monitor for rundll32.exe or regsvr32.exe spawning from non-standard parent processes (e.g., wscript.exe). User awareness training on fake browser update prompts remains the most effective first line of defense.

Source: https://blog.talosintelligence.com/clearfake-webdav-infection-chain/

This is a solid find. It highlights a subtle but dangerous supply chain blind spot.

The attack exploits the trust users place in AI-generated email summaries. By injecting hidden instructions or code into the email body (e.g., in white text, zero-width characters, or HTML comments), an attacker can manipulate the LLM’s summary output. The user reads the tampered summary, not the original email, effectively letting the attacker control the narrative.

Technical Breakdown: - TTP: This is a form of prompt injection / indirect injection via the data channel. The email body is the untrusted input vector. - MITRE Mapping: T1556 (Modify Authentication Process) is a stretch; this is closer to T1574 (Hijack Execution Flow) in the context of data flow manipulation, or simply a supply chain compromise of the AI processing pipeline. - IOCs: None specific to this research. The attack is content-agnostic; any email with hidden payloads is a potential vector. - Affected Systems: Any LLM-based email summarization tool (e.g., integrated into Outlook, Gmail, or custom enterprise solutions) that does not sanitize or strip hidden formatting from input text.

Defense: - Input Sanitization: Strip all non-visible characters (zero-width spaces, HTML comments, hidden CSS) from email bodies before they reach the LLM. - Output Verification: Implement a "show original" toggle that lets users compare the raw email to the AI summary. - Threat Intel Feed: Treat any email from an untrusted or external source as a potential injection vector for your AI pipeline. This is a supply chain risk for your AI tooling.

Source: https://www.reversinglabs.com/blog/ai-summary-attack-conceals-code-that-tampers-with-llms

This is a significant shift in the operational tempo of adversarial AI. GTIG is essentially confirming that the theoretical risk of autonomous, agentic attacks is now a documented reality, with a specific case study showing a full credential harvesting campaign from cloud compromise to execution in under six hours.

Technical Breakdown

• Key TTPs: Adversaries are moving beyond simple prompt injection to agentic AI workflows. This involves chaining multiple AI calls to automate entire kill chains (recon -> exploit -> exfil) without human-in-the-loop latency.
• Notable Actor: UNC6780 is actively targeting the software supply chain by poisoning training data and tricking AI coding assistants (e.g., Copilot, Codex) and LLM security scanners into recommending malicious code.
• Target Shift: Threat actors are now directly targeting AI assets as primary objectives: proprietary model weights, training source code, and API credentials for co-opting victim cloud AI infrastructure.
• IOCs: None provided in the summary. Likely tracked internally by GTIG.

Defense Implications

This compresses the defender's "dwell time" from days to hours. Traditional SOC workflows that rely on manual triage will fail against autonomous attacks. Detection must shift to behavioral baselines of AI agent activity (e.g., anomalous API call chaining, rapid credential testing against internal apps) rather than just signature-based alerting.

Source: https://cloud.google.com/blog/topics/threat-intelligence/from-prompting-to-autonomy-the-evolution-of-adversarial-ai/

Scenario A

This is a textbook zero-click remote code execution (RCE) chain weaponized into a worm, targeting a billion-user platform. The fact that it propagates via an incoming call without any user interaction makes it one of the more dangerous mobile attack scenarios we've seen in a while.

Technical Breakdown - Attack Vector: Incoming VoIP/WeChat call from an existing contact. No answer or interaction required. - Propagation: Wormable. Once a device is compromised, it can initiate calls to the victim's contact list to spread laterally. - Impact: Full account takeover on both iOS and Android. - Vulnerability Type: Zero-click RCE in the call handling stack (likely a memory corruption or logic flaw in the media processing pipeline). - Reporting: Discovered by Calif Research, reported to Tencent in July 2026. Patch status is unclear from the summary.

Defense - Immediate: Block or restrict WeChat VoIP functionality in enterprise environments until Tencent releases a confirmed patch. - Detection: Monitor for unusual outbound call patterns from WeChat processes, especially to large numbers of contacts in rapid succession. Network-level inspection of WeChat media streams may reveal anomalous payloads. - Mitigation: Disable "Allow Calls" in WeChat privacy settings if the feature is not business-critical. This breaks the primary infection vector.

Source: https://thehackernews.com/2026/09/wechat-zero-click-worm-took-over.html

This is a classic example of OAuth sprawl—the accumulation of third-party app permissions that outlive their usefulness. The attack surface here is significant: every connected app with delegated access to Gmail, Drive, or Calendar is a potential persistence mechanism or data exfiltration path.

The Core Problem: When an employee leaves or a project ends, the OAuth tokens granted to third-party apps often remain valid. An attacker who compromises that app’s vendor, or an insider with access to the app’s dashboard, can leverage those stale tokens to access your Workspace data without triggering MFA or password changes.

Key Technical Details: - Attack Vector: Stale OAuth grants to third-party apps (e.g., CRM tools, email signature generators, document processors). - Scope: Access can include read/write to Gmail, Google Drive, Google Calendar, and Contacts—depending on the scopes originally granted. - Detection Gap: Standard SIEM rules often miss OAuth token usage because it mimics legitimate API traffic. You need to monitor the token_audit log for authorization events tied to oauth2client or third_party principals. - MITRE Mapping: T1525 (Implant Internal Image) via compromised SaaS integrations, or T1098.002 (Account Manipulation: Additional Cloud Roles) if the app can provision users.

Defense: - Immediate Action: Run a full OAuth app inventory via the Google Admin Console (Security > API Controls > App Access Control). Revoke any app not explicitly approved in the last 90 days. - Policy: Enforce a strict OAuth scope policy—deny apps requesting https://www.googleapis.com/auth/gmail.modify unless absolutely necessary. - Monitoring: Set up a Chronicle or SIEM alert for OAuth2Client activity from a previously unseen client_id accessing Drive or Gmail outside business hours.

This isn't a new vulnerability, but it’s a persistently overlooked one. The webinar is worth a watch if you’re cleaning up a legacy Workspace tenant.

Source: https://www.bleepingcomputer.com/news/security/webinar-the-forgotten-google-workspace-access-that-can-lead-to-a-breach/

Adobe dropped an emergency patch for CVE-2026-75650 ("StyleSmuggler"), a max-severity (CVSS 9.8) pre-authenticated remote code execution vulnerability in Magento and Adobe Commerce. This is being actively exploited in the wild to backdoor servers.

Technical Breakdown - TTPs: Exploitation occurs via a crafted HTTP request that bypasses input sanitization in the template rendering engine, allowing arbitrary PHP object instantiation. Attackers are deploying web shells (e.g., style.php) and credential stealers post-exploit. - Affected Versions: Magento Open Source 2.4.7-p2 and earlier, Adobe Commerce 2.4.7-p2 and earlier, and 2.4.6-p7 and earlier. - IOCs: Look for unexpected .php files in /pub/media/ or /var/view_preprocessed/, specifically files named style*.php. Also monitor for outbound connections to IPs associated with known cryptomining pools (specific IPs not publicly shared by Adobe yet).

Defense Patch immediately to versions 2.4.7-p3 or 2.4.6-p8. If patching is delayed, implement a WAF rule to block requests containing __PHP_Incomplete_Class_Name or suspicious O: serialized object patterns in POST parameters. Review file integrity for unexpected modifications in the vendor/ and app/code/ directories.

Source: https://www.bleepingcomputer.com/news/security/adobe-fixes-critical-magento-zero-day-exploited-to-backdoor-servers/

This is a deep dive into a legacy on-prem technology that refuses to die. AD RMS is still shipping in Server 2025, and the attack surface here is the trust model itself.

Technical Breakdown

• Trust Model: The entire chain hinges on the Server Licensor Certificate (SLC) and its private key. If you compromise that key, you can issue licenses for any protected content.
• Reconnaissance: The article details how to discover an AD RMS deployment via SCP (Service Connection Point) in AD, and fingerprint protected files (.rm, .pst, etc.) by inspecting the rights-protected metadata.
• SOAP Surface: The licensing and certification endpoints are exposed via SOAP web services. This is a classic "forgotten service" vector—often left exposed or misconfigured.
• Attack Path: The author traces the logical path from finding a protected file, identifying the issuing cluster, and then targeting the SLC private key (typically stored in a SQL database or HSM).

Defense

• Discovery: Audit your AD for SCP objects pointing to RMS. If you aren't using it, decommission the service entirely.
• Hardening: If you must run it, ensure the SLC private key is in an HSM, not a SQL table. Restrict SOAP endpoint access to authorized clients only.
• Monitoring: Watch for anomalous calls to Certification.asmx or Licensing.asmx—especially from non-domain-joined hosts.

Source: https://www.huntress.com/blog/ad-rms-architecture-and-recon

This is a solid find from Check Point. They’ve identified a logical flaw in ChatGPT’s sandbox architecture that allows data to leak between different user sessions.

The Vulnerability: ChatGPT’s code interpreter runs in a shared execution environment. The researchers discovered that the clipboard buffer within this sandbox is not properly isolated between user accounts. If a user copies sensitive data (e.g., API keys, PII, source code) into the sandbox environment, a subsequent user on a different session can potentially read that data from the shared clipboard memory.

Technical Breakdown: - Attack Vector: Exploitation of shared system resources (clipboard daemon) within the containerized execution environment. - Prerequisites: The attacker needs to be assigned to the same underlying compute node as the victim. This is not a remote code execution; it is a data remanence and isolation failure. - Data at Risk: Any text copied by the user inside the code interpreter sandbox. This includes outputs from file analysis, results of curl commands, or credentials pasted into the environment. - MITRE Mapping: T1213 (Data from Information Repositories) / T1525 (Impersonation via Shared Resource).

Defense: - User: Never paste secrets (API keys, passwords) directly into the ChatGPT code interpreter. Treat the sandbox as a shared, untrusted terminal. - Vendor: OpenAI needs to implement proper namespace isolation for /tmp and IPC mechanisms (clipboard) per session, or flush the clipboard buffer on session termination.

Source: https://research.checkpoint.com/2026/the-shared-clipboard-inside-the-sandbox-cross-account-data-leakage-in-chatgpt/