DEV Community: Anoymask

Elementor 4.3.0 and 4.3.1: CSRF Enables Administrator Account Creation via a Flawed REST Route Check

Anoymask — Sat, 26 Sep 2026 02:29:01 +0000

1. Basic Information

Title: Cross-Site Request Forgery in Elementor Plugin Affecting 2 Million+ Sites
Source: Patchstack
Published: September 25, 2026
Updated: N/A
Severity: critical
Severity Basis: When an authenticated administrator opens a crafted link, an attacker can create an administrator account on sites running Elementor 4.3.0 or 4.3.1 with Editor Events enabled. Patchstack rates this as CVSS 8.8, but we assess it as critical due to the impact on site administrative privileges. No active exploitation has been reported in the wild.
Original: Cross-Site Request Forgery in Elementor Plugin Affecting 2 Million+ Sites
Related Sources: BleepingComputer: Elementor WordPress flaw lets attackers create admin accounts
Revision Notes: Clarified the omission of nonce validation and authorization differences, the scope of success in research environments, and the ATT&CK mapping for administrator creation.

2. Overview

The Editor Events experimental feature in Elementor bypassed REST API nonce validation via a URL partial match, allowing attackers to create an administrator account simply by having an administrator open a crafted link.

3. Attack Flow

The following outlines the validation and implementation paths indicated by public sources. Refer to Attack Success Determination for the scope of observation in real-world environments.

One-Click Administrator Account Creation

An attacker constructs a single URL combining a REST route, a fake Elementor path, _method=POST, and an administrator creation payload.
A WordPress administrator opens the link in a browser where they are currently logged in.
Elementor mistakes the partial match within the REQUEST_URI for a legitimate event route and returns true in the authentication filter, thereby bypassing WordPress REST nonce validation.
The WordPress REST API processes the user creation route using the victim's cookie authentication and administrator privileges, creating an attacker-controlled administrator account.

4. Attacker Position and Execution Location

The attacker sends the link from an external source, and the request itself is sent to WordPress from the victim administrator's browser.
The side effect occurs within the WordPress REST API under the victim's authenticated privileges.

5. Victim and Administrator Perspective

Victim

When an authenticated administrator opens a crafted link, a JSON response containing user information may be displayed.

Administrator

Unintended administrator accounts or REST API write operations using existing administrator sessions appear. Log coverage depends on the audit configuration.

6. Conditions for Success and Failure

Success Conditions

Elementor 4.3.0 or 4.3.1 must be installed with the Editor Events experimental feature enabled.
The administrator must open the crafted URL while logged into WordPress.

Failure Conditions and Mitigation Measures

Update Elementor to version 4.3.2 or later.
Monitoring administrator creation or permission changes is a supplementary measure for early detection. Alerts or disabling accounts after creation do not prevent CSRF itself.

7. Outcome upon Success

An administrator account for the attacker is created.
Inference: Depending on the acquired administrative privileges and site-level restrictions, this may lead to subsequent compromises such as content defacement or plugin manipulation. These subsequent actions are distinct from the validation results in the proof of concept.

8. Observable Logs

The following are investigation perspectives for your organization. Not all items indicate that actual damage has been observed.

Email: Check the source of the crafted link and the click timestamp.
Web / Proxy / WAF: Review web server, reverse proxy, or WAF request logs for GET requests containing elementor/v1/events/ and _method=POST, as well as requests to user creation routes.
Endpoint / EDR: Check for WordPress/PHP process and plugin modifications, as well as web shell installation.
Identity / IdP: Check for new administrators, sessions, and password changes.
SaaS / Cloud: Check WordPress audit logs and hosting management configuration changes.
Network: Check for abnormal REST write operations originating from the administrator browser IP followed by subsequent use of the newly created account.

9. Attack Success Determination

Confirmed in Public Information

User Interaction Confirmed: Public Information: the proof of concept described by Patchstack confirmed the action of an administrator opening a link. (Scope: Research environment. In-the-wild exploitation unconfirmed)
Subsequent Compromise Confirmed: Public Information: The same proof of concept confirmed the creation of a new administrator account. (Scope: WordPress administrator privileges in a research environment)

10. Investigation Playbook

The following are investigation and response recommendations for organizations based on public information:

Starting Point: Initiate investigations upon detecting unintended administrator creation, access to crafted links, or the presence of vulnerable versions.
Initial Response: Verify the Elementor version, the enabled state of Editor Events, and the administrator session status during the operation.
Endpoint: Preserve processes, files, services, persistence mechanisms, and EDR telemetry.
Identity / Cloud: Check tokens, keys, logins, and SaaS/cloud audit logs.
Follow-up Verification: Track information theft, lateral movement, additional payloads, and configuration changes.
Containment: Update to version 4.3.2 or later, investigate and remove unauthorized accounts and modifications, revoke sessions for compromised accounts, and rotate exposed credentials.
Outcome Classification: Distinguish link delivery, the administrator's click, REST request processing, unauthorized account creation, and subsequent account use.

11. Defense and Detection Ideas

Single Events: Investigate unintended administrator creation or requests containing fake Elementor paths and _method=POST.
Timeline: Correlate link access, REST API requests, administrator creation, and the subsequent use of created accounts in a chronological timeline.
Hunting: Cross-reference the affected period and asset inventory to retroactively hunt for identical IOCs and behaviors.
Log Deficiencies: A lack of necessary records limits the ability to determine success stages. The absence of logs does not necessarily mean execution did not occur.
Prioritized Mitigations: Prioritize patching, least privilege, monitoring unauthorized administrator account creation, and retaining audit logs.

12. Facts, Inference, and Hypothesis

Facts

The affected Editor Events module is present in Elementor 4.3.0 and 4.3.1. It is enabled by default on sites whose first Elementor installation was version 3.32.0 or later. This hidden experiment does not appear on the Experiments screen.
Elementor registers a filter callback on rest_authentication_errors at priority 0, returning true and bypassing WordPress REST nonce validation whenever the attacker-controlled REQUEST_URI contains elementor/v1/events/ anywhere within it.
Attackers can inject _method=POST and a fake Elementor path into GET request queries, sending administrator creation payloads to the actual /wp-json/wp/v2/users route.
In-browser JavaScript or forms on attacker sites are not required; opening the link displays a JSON response.
Version 4.3.2 uses resolved rest_route checks to verify that requests begin with permitted routes.
The REST nonce bypass does not disable authorization for all routes, but rather produces side effects within the scope of REST the victim's existing permissions. Directing an administrator leads to administrator creation.

Inference

No additional inferences.

Hypothesis

No additional hypotheses. Unverified items are listed in Unknowns and Additional Investigation.

13. MITRE ATT&CK Mapping

ID	Technique	Confidence	Basis
T1204.001	User Execution: Malicious Link	high	Patchstack's verification requires an authenticated administrator to open a crafted link.
T1136	Create Account	high	Patchstack verified the creation of a WordPress administrator account. Because there is no evidence it is a cloud account, it is mapped to the parent technique.

14. Unknowns and Additional Investigation

The presence of in-the-wild exploitation and the number of operational deployments of vulnerable versions 4.3.0 and 4.3.1.
The environment-specific impact of other REST endpoints, including those added by third-party plugins, for each victim role.

15. Impact on SOCs and Organizations

WordPress sites using Elementor 4.3.0 or 4.3.1 must be updated to version 4.3.2 or later, and organizations should not rely solely on operational policies preventing administrators from opening external links prior to patching. SOCs should correlate REST operations where GET requests within administrator sessions were overridden to POST with subsequent administrator creation.

16. Summary by Persona

SOC: Correlate administrator session _method=POST, fake Elementor paths, /wp-json/wp/v2/users, and new administrator creation.
Administrators: Update Elementor to version 4.3.2 or later, audit for suspicious administrators, force logouts, and rotate credentials.
Users: Avoid opening suspicious links while logged into administrative dashboards, and notify administrators if an unintended JSON screen appears.

TDengine CVE-2026-42542: Unauthenticated Integer Underflow Crashes taosd with a Single Packet

Anoymask — Sat, 26 Sep 2026 02:25:24 +0000

1. Basic Information

Original Title: One Packet Can Take Down the Database Behind Industrial Operations: Ridge Security Discovers CVE-2026-42542
Source: Ridge Security
Published: September 23, 2026
Updated: None
Severity: High
Basis of Severity: A single unauthenticated packet sent to TCP/6030 can crash the database, and repeated transmission of crafted packets can sustain a restart loop and telemetry gaps. The confirmed impact is a Denial of Service (DoS); remote code execution (RCE) and active exploitation have not been confirmed.
Original Article: One Packet Can Take Down the Database Behind Industrial Operations: Ridge Security Discovers CVE-2026-42542
Related Sources: TDengine Official Security Advisory, GHSA-vg95-j2hf-hvjx
Revision Note: Separated the DoS verification results from unconfirmed RCE, and organized official affected/fixed versions, observable logs, and ATT&CK mapping.

2. Executive Summary

In TDengine's unauthenticated RPC processing, the calculation subtracts both sizeof(STransMsgHead) and the required user-information offset from msgLen. If the message is too short, conversion to an unsigned type causes the subtraction to wrap around to a very large value. This extremely large length is passed to memcpy, causing an out-of-bounds heap access and abnormal termination of the taosd process.

3. Attack Flow

The validation and implementation paths identified in public sources are outlined below. For the scope of observation in real-world environments, refer to "Attack Success Determination."

Continuous DoS via Unauthenticated Packets

An attacker sends a crafted RPC message whose declared length is insufficient for the header and required user information.
Signed and unsigned subtraction in the unauthenticated parser wraps around into a large positive number.
memcpy accesses memory outside the allocated heap boundary, causing taosd to crash due to a segmentation fault.
Even if the service automatically restarts, the attacker continues to send packets to maintain a restart loop and telemetry gaps.

4. Attacker Positioning and Execution Location

The attacker is positioned on a network that can reach the TDengine RPC port. Internet exposure is not required; the attack can also originate from a compromised internal host that can reach the RPC port, particularly on a flat OT network.
The anomaly occurs during pre-authentication connection processing in the taosd process.

5. Victim and Administrator Perspective

Victims

Missing data or halted updates on monitoring screens, along with application connection errors, may occur.

Administrators

taosd segmentation faults, core dumps, repeated automatic restarts, and gaps in data ingestion serve as investigation clues.

6. Success and Failure Conditions

Success Conditions

Reachability to TCP/6030 of an unpatched TDengine instance.
The crafted header reaches the length calculation in uvConnMayGetUserInfo().

Failure Conditions and Mitigations

Update to TDengine version 3.4.1.6 or later.
Keep TCP/6030 private from the internet and restrict network ACLs to authorized clients only.

7. Impact upon Success

Abnormal termination of taosd may lead to lost uncommitted writes, stopped data collection, or halted alerts. Repeated crashes via repeated transmission of crafted packets prolong the outage. This does not indicate the loss of durably committed data or code execution.

8. Observable Logs

The following items represent investigation viewpoints for organizations. They do not imply that every item was observed in an actual attack.

Email: No reports indicate email was used as an initial access vector.
Proxy / SWG / DNS: Standard Web proxy or DNS logs alone cannot inspect the contents of TCP/6030 RPC requests. Correlate with network logs capable of capturing the target traffic.
Endpoint / EDR: Identify taosd segmentation faults, core dumps, and restarts initiated by systemd.
Identity / IdP: Successful authentication is not required, so the absence of successful-login events does not rule out exploitation.
SaaS / Cloud: Check for data ingestion gaps and service state events in monitoring platforms.
Network: If connections and packet capture for TCP/6030 are available, inspect msgLen and correlate with crash timestamps.

9. Attack Success Determination

Confirmed in Public Information

DoS Success Verified in Research Environments: Ridge Security verified that taosd can be stopped using crafted packets. Real-world exploitation and successful RCE have not been confirmed.

Organization-Specific Determination Criteria

Attack Attempt Observed (Success Unconfirmed): Criteria: The observation of suspicious RPC requests alone does not constitute a successful DoS. It must be supported by a corresponding taosd abnormal termination and service outage matching the connection timestamp. While Ridge Security verified DoS success in a research environment, real-world exploitation remains unconfirmed. (Scope: Internal investigation criteria; distinct from research-environment DoS success).

10. Investigation Playbook

The following outlines an investigation and response plan for organizations based on public information:

Starting Point: Begin with taosd abnormal terminations, restart loops, and gaps in data ingestion.
Initial Response: Verify whether TDengine versions 3.4.0.0 through 3.4.1.5 are in use and check the reachability scope to TCP/6030.
Endpoint: Preserve taosd logs, core dumps, service restart records, and any available RPC communication records.
Identity / Cloud: Check tokens, keys, logins, and SaaS/cloud audit logs.
Follow-up Verification: Track repeated crashes after restart and missing ingested data. Judge RCE and credential theft based on separate evidence.
Containment: Restrict RPC connections to authorized clients only and update to supported versions containing the fix in 3.4.1.6. Account for the impact of updates and restarts on monitoring outages.
Outcome Classification: Distinguish suspicious connections, malformed requests, confirmed crashes, service outages, and any separately evidenced subsequent compromise.

11. Defense and Detection Ideas

Single Event: Detect taosd segmentation faults, core dumps, and abnormally frequent restarts.
Timeline: Correlate connections to TCP/6030, taosd abnormal terminations, restarts, and data ingestion gaps.
Hunting: Cross-reference the impact period with asset inventories to retroactively hunt for matching IoCs and behaviors.
Logging Gaps: A lack of required logs limits the ability to determine success stages. The absence of logs alone does not confirm non-execution.
Priority Actions: Prioritize patching, restricting inbound access to the RPC port, monitoring service availability, and retaining crash and network logs.

12. Facts / Inference / Hypothesis

Facts

TDengine versions 3.4.0.0 through 3.4.1.5 are affected, and the issue is resolved in 3.4.1.6.
TDengine's custom binary RPC protocol uses TCP/6030 by default, where the pre-authentication function uvConnMayGetUserInfo() subtracts an unsigned header/offset from a signed 32-bit integer msgLen supplied by the attacker.
The vulnerable calculation subtracts both sizeof(STransMsgHead) and the required user-information offset from msgLen. If the message is too short, conversion to an unsigned type causes the subtraction to wrap around to a very large value near 2^64 on 64-bit environments. This value is passed to the length argument of memcpy, causing out-of-bounds heap access and a segmentation fault.
The confirmed impact is an unauthenticated remote DoS. Even if the taosd process restarts, repeated transmission of crafted packets can sustain a crash loop.
Ridge Security has not confirmed real-world exploitation telemetry or published exploit code, and has not publicly released a PoC.

Inference

Heap corruption could theoretically be the subject of RCE research, but public evidence is limited to a stable DoS, making it impossible to conclude that RCE is feasible.

Hypothesis

No additional hypotheses. Unconfirmed items are listed under "Unknowns and Additional Investigation."

13. MITRE ATT&CK Mapping

ID	Technique	Confidence	Basis
T1499.004	Endpoint Denial of Service: Application or System Exploitation	High	Ridge Security verified taosd termination using crafted RPC packets. Real-world exploitation is unconfirmed.

14. Unknowns and Additional Investigation

Whether active exploitation has occurred on the internet or inside OT networks.
Whether the heap corruption can be leveraged into code execution.
The number of unrecognized TDengine instances embedded within OEM products or appliances.

15. Impact on SOCs and Organizations

Organizations using TDengine in factories, energy systems, IoT, or vehicle telemetry should update to version 3.4.1.6 or later and restrict port 6030/TCP exclusively to authorized application hosts. SOCs should correlate these indicators by host and time, and investigate related events as a suspected DoS incident.

16. Audience-Specific Summary

SOC: Correlate 6030/TCP short connections, taosd segmentation faults, core dumps, restart loops, and data ingestion gaps.
Administrators: Update to version 3.4.1.6 or later and restrict 6030/TCP to authorized clients via ACLs or host firewalls.
Users: General user actions cannot prevent this issue. Report missing or halted monitoring dashboards to operations management.

File Change Notification Side Channel: Estimating Keystroke Timing and Browsing Activity on Linux, Android, and Windows

Anoymask — Sat, 26 Sep 2026 02:18:44 +0000

1. Overview

Original Title: File Notification Attacks: Side-Channel Leakage from the File-Notification System on Linux, Android, Windows, and macOS
Source: Graz University of Technology (File Notification Attacks Research Team)
Publication Date: 2026-09-24 (Public disclosure date by researchers)
Updated: None
Severity: High
Basis for Severity: While local execution is required, unprivileged actors can estimate the activities of other users or apps with high precision. On Linux, this is also used for UI spoofing. A proof-of-concept is publicly available, but active exploitation in the wild has not been confirmed.
Original Link: File Notification Attacks: Side-Channel Leakage from the File-Notification System on Linux, Android, Windows, and macOS
Related Sources: Research Paper (Evaluation Conditions and Measurement Results), Microsoft: Access Check Enhancements to Prevent Unauthorized Disclosure of File Paths, Public Disclosure by Researchers, Windows, Linux, Android File Notification Systems Leak User Activity, Proof-of-concept code
Reason for Revision: The research material was used as the primary source to clarify OS-specific prerequisites, F1 scores, partial mitigations on Linux, and disabled-by-default mitigations on Windows.

2. Executive Summary

Researchers demonstrated that unprivileged local processes and Android apps without special permissions can use file change notifications to infer keystroke timings, browsing destinations, and WhatsApp media interactions without reading the file contents. Leaked information and prerequisites vary by operating system.

3. Attack Flow

The validation and implementation paths indicated by public sources are organized below. See "Attack Success Verification" for the scope of the researchers' demonstrations and the status of in-the-wild exploitation.

Path A: Activity Monitoring on Linux, Windows, and Android

An attacker executes unprivileged code on the target device and registers notifications for monitorable directories depending on the operating system.
Researchers verified monitoring of readable parent directories on Linux, drive roots on Windows, and specific app media areas via FileObserver on Android.
Activity is inferred from the acquired path names and event timestamps. On Windows browser storage, site names included in paths may leak directly.

Path B: Spoofed Authentication Prompt in the Victim's Linux User Session

The attacker's process runs under the victim's user account within the same graphical session.
Notifications detect when the KDE Plasma 6 authentication screen appears, and a spoofed screen is overlaid.
Credentials entered by the victim into the fake screen are captured. This differs from the separate-user monitoring permission conditions in Path A.

4. Attacker Position and Execution Location

Activity monitoring requires unprivileged code execution on the device. On Android, validation used apps that do not request additional permissions.
Credential theft via the KDE fake authentication screen assumes the attacker's process runs under the victim's user account within the same graphical session.

5. Victim and Administrator Perspective

Victim

For activity monitoring alone, there are no noticeable screen changes. In the KDE PoC, a fake screen resembling the legitimate authentication prompt appears.

Administrator

File notification APIs are also used by normal applications. Identifying suspicious monitoring targets or spoofed screen processes requires appropriate endpoint telemetry.

6. Success and Failure Conditions

Success Conditions

The attacker can execute code on the target host and monitor parent directories or roots.
Observable path and timing patterns exist that link notification events to user actions.
Credential theft via the KDE fake authentication screen additionally requires the attacker's process to run under the victim's user account within the same graphical session and user input into the fake screen.

Failure Conditions and Risk Reduction Measures

Apply Linux kernels containing the fix for CVE-2025-68788. This fix is a partial mitigation that suppresses access and modify notifications for special files, and does not resolve all information leaks demonstrated in the research.
Install the applicable Windows updates released on or after April 8, 2025, then enable EnforceDirectoryChangeNotificationPermissionCheck according to Microsoft's guidance after testing compatibility. This is disabled by default and adds access checks to NTFS/ReFS change notifications.
Review local execution privileges, app installations, and user isolation on shared hosts.

7. Impact Upon Success

Keystroke timings, web browsing destinations, WhatsApp media filenames and operations, and app launches are inferred.
The Linux same-user PoC displays a fake authentication dialog at an opportune time to proceed with password theft.

8. Observable Logs

The following items are investigation perspectives for your organization. They do not indicate that every item was observed in actual attacks.

Email: No reports indicate email was used as an initial access vector.
Proxy / SWG / DNS: Check for outbound transmission of inferred results or credentials.
Endpoint / EDR: If corresponding telemetry is enabled, inspect monitored targets of inotify, FileObserver, or ReadDirectoryChangesW, executing processes, and fake authentication screens. Standard EDR logs may not capture all API calls.
Identity / IdP: Verify creation of separate local users, interactive logins, and sudo failures.
SaaS / Cloud: Check MDM app installation history and VDI user allocations. These records alone do not confirm actual use of FileObserver.
Network: Check for external transmission of observation results or credentials. Local directory monitoring itself does not appear in network logs.

9. Attack Success Verification

Confirmed in Public Information

Initial Execution Confirmed: Public Information: Researchers executed side-channel PoCs on Linux, Android, Windows, and macOS. (Scope: Controlled experiments. Active exploitation in the wild unconfirmed)
Information Theft or Session Compromise Confirmed: Public Information: Researchers demonstrated credential acquisition via fake authentication dialogs in a Linux KDE PoC. (Scope: Research environment under same-user privileges)

10. Investigation Playbook

The following are investigation and response recommendations for your organization based on public information:

Starting Point: Begin with suspicious local processes, fake authentication screens, or unusual file monitoring.
Initial Response: Check OS and update status, executing user, monitorable directories, and Windows access check settings.
Endpoint: Preserve available notification API and process records, fake screen executables, and app lists.
Identity / Cloud: Check tokens, keys, logins, and SaaS/cloud audit logs.
Follow-up Verification: Track information theft, lateral movement, additional payloads, and configuration changes.
Containment: Isolate and remove suspicious apps or processes, and verify OS-specific mitigations. If input into a fake screen is suspected, rotate the relevant credentials from a trusted device.
Determination: Record contact, initial execution, successful authentication/malware, information compromise, and subsequent compromise separately.

11. Defense and Detection Ideas

Single Events: Inspect available endpoint logs for unusual notification registration targets or authentication processes impersonating legitimate screens. Notification API usage alone does not indicate maliciousness.
Timeline: Correlate process execution, notification registration, fake authentication prompts, and outbound communications within a short timeframe.
Hunting: Cross-reference impact periods and asset inventories to proactively hunt for matching IoCs and behaviors.
Log Gaps: Notification API monitored targets and calls may not appear in standard audit logs. Verify measurement capabilities and do not treat a lack of logs as proof of non-execution.
Priority Actions: Verify Linux partial mitigations and Windows optional settings, and restrict unnecessary local code execution and app installations.

12. Facts / Inference / Hypothesis

Facts

In a Linux research environment, monitoring readable parent directories to obtain child file notifications yielded F1 scores of 93.1% to 100% in local keystroke timing detection across seven users. These notifications reveal keystroke timing, not the characters typed. In the separate SSH-based attack using /dev/pts, inputs that produce no terminal output, such as sudo password entry with echo disabled, do not generate the required notifications.
On Linux, font access notifications for Firefox top 100 site classification reported an open-world evaluation F1 score of 87.9%. Credential acquisition via fake authentication screens was also demonstrated on KDE Plasma 6 under the same user privileges.
On Android, apps requiring no additional permissions used FileObserver to observe filenames, transmissions, and deletion timestamps in WhatsApp's private media folders.
On Windows, monitoring the drive root via ReadDirectoryChangesW revealed full paths including other users' areas. Evaluating 975 responsive sites out of the top 1,000, browsing destination detection F1 scores were 97.8% for Firefox and 48.5% for Edge.
Linux features a partial mitigation via CVE-2025-68788. Microsoft initially stated the behavior was by design, but researchers later confirmed mitigation via Windows access check settings that are disabled by default. Research sites do not list fixes for Android and macOS.
On macOS, observed leakage was limited to information about globally readable files. Researchers did not identify an unreadable-file bypass comparable to those found on Linux, Windows, and Android.

Inference

Because path names and event timelines become sensitive even if file contents cannot be read, directory read permissions alone cannot be treated as low risk.

Hypothesis

No additional hypotheses. Unverified items are listed under "Uncertainties and Additional Investigation".

13. MITRE ATT&CK Mapping

ID	Technique	Confidence	Basis
T1056.002	Input Capture: GUI Input Capture	High	Researchers captured input into a fake authentication screen during the KDE same-user privilege PoC. Keystroke timing observation alone is not mapped to character keylogging or screen capture.

14. Uncertainties and Additional Investigation

Reproduction scope across various Android vendors and OS versions, and future platform patches.
Compatibility when enabling Windows settings and confirmation of active exploitation in operational environments.

15. Impact on SOCs and Organizations

On shared Linux servers and VDIs, activity may leak from notification path names and timelines even if reading file contents is prohibited. Because notification APIs are used by normal apps, decisions must combine monitoring targets, the processes and user accounts performing the monitoring, spoofed screens, and outbound communications. Differentiate the scopes of Linux partial mitigations and Windows optional settings, and evaluate isolation between endpoints and users.

16. Summary by Role

SOC: Check for mass monitoring registrations, C:\ or /dev monitoring, browser cache/font path events, and outbound communications.
Administrators: Apply Linux patches, verify Windows settings and local access restrictions, and strengthen isolation between users and workloads on shared hosts.
Users: Activity can be inferred even by apps requesting no additional permissions. Do not add unnecessary apps or local accounts to devices.

MemTensor MemOS Supply Chain Attack: sckit Triggered by Python Imports and OpenClaw Runtime Hooks

Anoymask — Sat, 26 Sep 2026 02:13:59 +0000

1. Basic Information

Original Title: The AI Ecosystem Has Worms Now: Inside the MemTensor Compromise
Source: Semgrep
Published Date: September 23, 2026
Updated Date: None
Severity: critical
Severity Basis: Binaries targeting Windows, Linux, and macOS are launched from compromised packages from the legitimate MemOS AI memory framework, scanning for tokens belonging to npm, PyPI, GitHub, cloud services, Slack, and others. While self-propagation code is included, spread to public repositories has not been confirmed.
Original Link: The AI Ecosystem Has Worms Now: Inside the MemTensor Compromise
Related Sources: Aikido: supplychain.local MemTensor npm/PyPI, StepSecurity: Sckit supply chain worm
Revision Note: Clarified execution conditions during import and application startup, the distinction between implementation analysis and individual victim impact, and the targets of credential rotation.

2. At a Glance

sckit was embedded in legitimate MemTensor MemOS npm and PyPI distributions. According to implementation analysis by researchers, it does not execute during installation, but rather activates during Python imports or OpenClaw execution to scan for and transmit credentials. The number of successful thefts in individual victim environments has not been publicly disclosed.

3. Attack Flow

The verification and implementation paths indicated by public sources are organized below. For the scope of observation in real environments, refer to "Attack Success Determination."

From Legitimate Package to Credential Scanning and Exfiltration

An attacker includes sckit in legitimate npm and PyPI releases.
Payload execution is triggered by importing the affected Python package, starting the OpenClaw gateway, or invoking a memory-recall hook in the affected plugin.
Platform-specific sckit binaries launch, scanning for credentials from the home directory and tool configurations.
Credentials and selected prompt data are sent to destinations under skyleen.fr.

4. Attacker Positioning and Execution Environment

Attackers placed malicious releases within official package registry distribution channels.
Execution occurs with user privileges on developer workstations, CI runners, and OpenClaw hosts.

5. Victim and Administrator Perspective

Victims

Because installation shows no noticeable activity and the payload triggers during normal imports or application startup, successful installation alone does not guarantee safety.

Administrators

Indicators for investigation include sckit launching from Python or OpenClaw, heavy file access within the home directory, and network traffic directed toward skyleen.fr.

6. Success and Failure Conditions

Success Conditions

Payload execution is triggered by importing the affected Python package, starting the OpenClaw gateway, or invoking a memory-recall hook in the affected plugin.
Successful credential exfiltration additionally requires the execution privileges to read credential files and the ability to transmit collected data externally.

Failure Conditions and Risk Mitigation

Block malicious versions and verify hashes/provenance against gitHead/tag mappings.
Use short-lived credentials on developer workstations and in CI pipelines. Restrict execution of untrusted binaries and outbound connections to unapproved domains.

7. What Happens Upon Success

The implementation includes logic to scan and exfiltrate development, cloud, package registry, and SaaS tokens, along with SSH keys and prompt text. Depending on the privileges of the stolen credentials, this could lead to secondary compromise of repositories or releases. This does not describe confirmed success in individual victim environments.

8. Observable Logs

The following items represent investigation guidance for your organization. Not all items indicate that actual victimization occurred.

Email: No reports identify email as the initial access vector.
Proxy / SWG / DNS: Check for DNS queries and HTTPS traffic directed toward skyleen.fr.
Endpoint / EDR: Look for the sckit binary, memos._stage0, OpenClaw child processes, and heavy read operations under the HOME directory.
Identity / IdP: Verify the usage origins of tokens for GitHub, npm, PyPI, AWS, Slack, and similar services.
SaaS / Cloud: Review anomalies in CI workflow modifications, package publication, and release provenance.
Network: Correlate outbound traffic immediately following package execution with registry operations.

9. Attack Success Determination

Confirmed in Public Information

Malicious Distribution and Execution Path Confirmed: Researchers analyzed implementations where sckit launches from Python imports or OpenClaw execution. Execution records and successful theft counts per organization have not been made public.

Internal Organization Evaluation Criteria

Malware Execution or Authentication Success Confirmed: Criteria: Verify through process or file records that sckit launched via Python imports or OpenClaw execution from an affected version. Implementation features identified in public analysis alone do not confirm successful execution in individual victim environments. (Scope: Internal investigation criteria; execution records by organization remain unpublicized.)
Information Theft or Session Compromise Confirmed: Criteria: Validate access to credential files and external transmission using endpoint and network logs. Scanning and exfiltration features identified in public analysis alone do not confirm successful information theft in individual victim environments. (Scope: Internal investigation criteria; individual theft success unconfirmed.)

10. Investigation Playbook

The following outlines recommended investigation and response steps for internal organizations based on public information.

Starting Point: Begin with the use of malicious versions, sckit execution, and traffic to related domains.
Initial Response: Preserve lock files and distribution packages, and determine whether the package was merely installed or if import/OpenClaw execution paths were reached.
Endpoint: Preserve processes, files, services, persistence mechanisms, and EDR telemetry.
Identity / Cloud: Review tokens, keys, logins, and SaaS/cloud audit logs.
Follow-up Verification: Track information theft, lateral movement, additional payloads, and configuration changes.
Containment: Isolate endpoints that executed the affected version to remove payloads, and Revoke and reissue all credentials accessible from affected environments, including package-publishing tokens, source-control credentials, cloud credentials, and SSH keys.
Triage: Categorize and record contacts, initial execution, authentication/malware success, information compromise, and secondary compromises separately.

11. Defense and Detection Ideas

Single Events: Investigate sckit launches originating from Python or OpenClaw, mass reading of credential files, and communications with related domains.
Timeline Analysis: Correlate events from initial entry to execution, credential access, and outbound communication within a short timeframe.
Threat Hunting: Cross-reference impact windows with asset inventories to proactively search for identical IoCs and behaviors.
Logging Gaps: Lack of necessary logs limits the ability to determine success stages. Absence of logs should not be interpreted as lack of execution.
Priority Mitigations: Prioritize replacing affected packages with verified clean versions or removing them, implementing least privilege, controlling outbound traffic, and retaining audit logs.

12. Facts / Inference / Hypothesis

Facts

The malicious npm versions are @memtensor/memos-cloud-openclaw-plugin 0.1.21, 0.1.23, and 0.1.25, and the PyPI version is MemoryOS 2.0.34.
Importing memos triggers logging initialization, which calls memos._stage0.trigger() through the modified configure_logging() function. The npm launcher also passes prompt text to the payload through the SCKIT_EVENT_TEXT environment variable.
Analyzed distributions include sckit binaries for Windows, Linux, and macOS, equipped with functionality to scan home directories and environment variables for credentials related to npm, PyPI, GitHub, GitLab, AWS, Hugging Face, Vault, Slack, Stripe, SendGrid, JWT, and others.
Logic exists to transmit collected data to *.skyleen[.]fr, with the npm version also passing prompt text via SCKIT_EVENT_TEXT in the payload. This represents analysis results of the implementation, not proof that data from individual users was actually transmitted.
While self-propagation templates for GitHub Actions and npm/PyPI publishing were included, Semgrep and Aikido have found no evidence of spread to public workflows or additional packages.

Inference

Because the analyzed MemTensor releases trigger the payload at runtime rather than during installation, installation monitoring alone may miss execution.

Hypothesis

The self-propagation features suggest an intent to spread as a worm, but successful propagation has not been observed.

13. MITRE ATT&CK Mapping

ID	Technique	Confidence	Basis
T1195.002	Supply Chain Compromise: Compromise Software Supply Chain	high	Mapping based on implementation analysis of published packages. Malicious binaries were mixed into legitimate npm and PyPI package releases.
T1552.001	Unsecured Credentials: Credentials In Files	high	Mapping based on implementation analysis of published packages. Numerous tokens and keys are scanned from beneath the HOME directory.
T1041	Exfiltration Over C2 Channel	high	Mapping based on implementation analysis of published packages. Collected information is transmitted to destinations under skyleen.fr.

14. Gaps and Further Investigation

Exact initial entry points and timestamps for maintainer account compromises.
Number of users whose tokens were actually stolen, secondary exploitation, and the presence of self-propagation to private repositories.

15. Impact on SOCs and Organizations

Inspecting installation-time scripts alone will fail to catch logic embedded in normal imports and application startups. Investigate developer workstations and CI runners that executed affected versions under the assumption of compromise. In addition to removing the package, revoke and reissue credentials that were accessible from the execution environment, and verify whether public packages managed by your organization were illicitly modified.

16. Audience-Specific Summary

SOC: Correlate affected package versions, sckit processes, skyleen.fr, credential read operations under HOME, and anomalous publications.
Administrators: Switch to clean versions such as npm 0.1.20 or PyPI 2.0.33 as advised by Semgrep (or remove the package), and revoke/reissue credentials potentially exposed from execution endpoints.
Users: If the affected package was executed, suspend development environment tokens and report to the organizational incident response team.

SalesBleed: Zero-Click DNS Data Exfiltration from Agentforce Through Indirect Prompt Injection

Anoymask — Sat, 26 Sep 2026 01:17:00 +0000

1. Basic Information

Original Title: SalesBleed: Indirect Prompt Injection and 0-Click Data Exfiltration on Agentforce
Source: Zenity Labs
Published Date: 2026-09-24
Updated Date: None
Severity: High
Severity Basis: This is a proof of concept demonstrating how the General CRM sub-agent's inherent read permissions for Leads and Accounts can be abused to exfiltrate data via DNS queries triggered by image rendering or Slack link previews. It does not demonstrate privilege escalation, and active exploitation in the wild remains unconfirmed.
Original Link: SalesBleed: Indirect Prompt Injection and 0-Click Data Exfiltration on Agentforce
Related Link: SecurityWeek: SalesBleed flaws in Salesforce Agentforce
Revision Notes: Clarified the research environment, existing permission abuse, image and Slack exfiltration paths, patch status, and ATT&CK mapping.

2. Executive Summary

In Zenity's research environment, malicious instructions stored in Lead records submitted through public Web-to-Lead forms caused Agentforce to follow malicious prompts, embedding retrieved account data into DNS queries. The attack starts with standard lead inquiries and requires no additional link clicks. The reported chain has been patched by Salesforce.

3. Attack Flow

The following outlines the verification and implementation path shown in public disclosures. For actual observation scope in the wild, refer to Attack Confirmation.

From Public Lead to DNS Data Exfiltration

An attacker persists indirect prompt injection payloads via Web-to-Lead.
An internal user sends a standard lead query to Agentforce.
The General CRM sub-agent follows instructions contained in the lead and retrieves Account values.
A crafted URL exploits the discrepancy between Trusted URLs filtering and browser or Slack link parsing.
Browser or Slack link preview processing resolves the attacker-controlled domain, leaking data encoded within the hostname via DNS.

4. Attacker Position and Execution Location

Attackers submit data through unauthenticated public forms.
Sensitive data retrieval occurs within Salesforce sub-agents, while exfiltration happens via the DNS resolver of the user browser or integration services.

5. Victim and Administrator Perspective

Victims

Responses to standard lead queries may include external images or links. Name resolution occurs without additional clicks during image rendering or Slack automatic previews.

Administrators

Indicators for investigation include lead creation containing external input, unexpected Account lookups outside intended queries, URLs in responses, and external DNS queries. Log availability depends on configuration.

6. Success and Failure Conditions

Success Conditions

In environments where the reported fix has not been applied, input from public forms is incorporated into the Agentforce context.
The General CRM sub-agent has permissions to read Leads and Accounts.
Image rendering or Slack link previews trigger name resolution to an external domain that bypasses Trusted URLs filtering.

Failure Conditions and Risk Mitigation

Verify that Salesforce has addressed the reported Trusted URLs bypasses. The following design and operational measures mitigate residual similar risks:
Treat external input strictly as data rather than instructions, and minimize object and field permissions for sub-agents.
Prevent automatic fetching of external resources from rich text and restrict outbound DNS and HTTP traffic to approved domains.

7. What Happens Upon Success

Salesforce account information and other data are exfiltrated to the attacker as DNS query names.
Because malicious leads persist, subsequent routine queries may re-trigger the attack.

8. Observable Logs

These are investigation perspectives for your organization. They do not imply that all items were observed in actual incidents.

Email: Check Web-to-Lead notifications and user query timestamps.
Proxy / SWG / DNS: Check for unusually long or data-bearing DNS labels under unfamiliar domains, and correlate them with external URLs in agent responses.
Endpoint / EDR: Verify external resource retrieval by user browsers or integration clients.
Identity / IdP: Confirm users invoking Agentforce and sub-agent permissions.
SaaS / Cloud: Review lead creation, Account reads, agent execution traces, and response rendering.
Network: Reconstruct DNS query labels and investigate correlations with CRM field values.

9. Attack Confirmation

Confirmed in Public Information

Data Exfiltration Confirmed in a Controlled PoC: Public Information: Zenity's controlled PoC embedded Account values into DNS query names and retrieved them via a researcher-controlled DNS server. (Scope: Research environment. In-the-wild exploitation unconfirmed)

10. Investigation Playbook

The following outlines investigation and response steps for organizations based on public information:

Starting Point: Begin with suspicious lead content, unexpected Agentforce data lookups, and external DNS queries containing CRM values.
Initial Response: Check public forms, General CRM sub-agent permissions, lead ingestion times, user queries, and patch status.
Endpoint: Preserve user browser response and image retrieval logs. Combine Slack path evidence with preview processing logs, noting that the absence of local endpoint logs does not rule out the activity.
Identity / Cloud: Correlate available Agentforce execution logs, Lead and Account lookups, and object and field permissions.
Follow-up Verification: Correlate the accessed Lead and Account fields with external DNS queries to determine the exfiltration scope and check for recurring processing.
Containment: Preserve malicious leads and related evidence, restrict processing of untrusted input, and limit external resource retrieval. Verify the application of reported patches and identify potentially exfiltrated data.
Triage: Assess malicious lead submission, instruction following, unauthorized data retrieval, URL generation, and DNS exfiltration separately.

11. Defense and Detection Ideas

Single Event: Investigate instructions within external input, record lookups unrelated to business objectives, and unknown external URLs within responses.
Timeline: Correlate lead creation, user queries, Account lookups, generated URLs, and DNS queries within the same processing timeline.
Hunting: Cross-reference impact windows and asset inventories to retroactively search for matching IoCs and behaviors.
Log Gaps: SaaS audit logs may not record all read operations or Slack-side DNS processing. Verify the availability limits of execution and communication logs.
Priority Actions: Prioritize verifying Salesforce’s remediation status, least privilege, outbound traffic control, and audit log retention.

12. Facts, Inference, and Hypothesis

Facts

In the controlled PoC, researchers saved malicious instructions in Lead fields through public Web-to-Lead forms.
When internal users initiated standard lead queries, the General CRM sub-agent read the malicious leads and embedded values retrieved from Accounts into the hostnames of attacker-controlled domains.
Combining a TLD unrecognized by the URL redactor, such as .fun, with trailing braces or brackets allowed crafted URLs to survive filtering.
Data embedded in hostnames was exfiltrated during DNS resolution, even if the subsequent HTTP request was blocked or failed.
Zenity reported the issue on June 1, 2026. Salesforce confirmed the fixes on August 18, and Zenity verified the reported Trusted URLs bypass fix on August 19.
Researchers also demonstrated an exfiltration path where external URLs were resolved via Slack link previews in addition to image rendering.

Inference

Outbound communication defenses for AI agents require monitoring not only HTTP allowlists but also DNS query names, specifically targeting boundaries where model outputs are interpreted as HTML or URLs.

Hypothesis

No additional hypotheses. Unverified items are listed in Open Questions and Further Investigation.

13. MITRE ATT&CK Mapping

ID	Technique	Confidence	Basis
T1048	Exfiltration Over Alternative Protocol	Medium	Zenity's PoC embeds CRM data into DNS query names and retrieves it via an attacker's authoritative DNS server. The encryption method for DNS transport was not specified, mapping to the parent technique.

14. Open Questions and Further Investigation

Whether the reported chain has been exploited in production environments.
Whether other undisclosed paths exist beyond the reported Trusted URLs bypasses. Image rendering and Slack previews represent the two paths demonstrated in this research.

15. Impact on SOCs and Organizations

Organizations operating Agentforce alongside Web-to-Lead integration should verify designs that prevent untrusted inputs from being elevated to trusted instructions, sub-agent object permissions, rich text rendering, and DNS monitoring. Because standard business queries alone can trigger the behavior, controls over data boundaries and outbound traffic take precedence over user awareness training.

16. Summary by Role

SOC: Correlate Agentforce executions, long DNS labels targeting unknown domains, and concurrent Lead/Account lookups.
Administrators: Verify patch status, restrict sub-agent permissions, public form inputs, HTML rendering, and outbound DNS traffic.
Users: Standard inquiries can process malicious leads. Report suspicious external images or abnormal responses to administrators.

Exposed GitLab Incoming Email Tokens Allow Unauthorized Code Modifications and CI Execution

Anoymask — Fri, 25 Sep 2026 10:26:17 +0000

1. Basic Information

Original Title: Send GitLab an email, push to main
Source: Aikido Security
Published Date: 2026-09-23
Updated Date: None
Collected Date: 2026-09-25T08:28:50+09:00
Severity: High
Severity Rationale: Aikido demonstrated in a controlled test that exposed tokens allow code modifications, CI execution, and access to private data. While active exploitation in the wild has not been reported, the severity is rated high because long-lived token exposure impacts development infrastructure.
Original Link: Send GitLab an email, push to main
Related Sources: BleepingComputer: Exposed GitLab project email addresses let attackers push code, GitLab: Group access and permissions
CVE: None
Target Products and Services: GitLab, GitLab incoming email, GitLab CI/CD

2. Executive Summary

When a token included in a GitLab incoming email address is leaked, an unauthorized third party can modify code and run CI pipelines using the permissions of that user. This can affect multiple projects owned by the same user, but it does not provide a mechanism to gain permissions for separate accounts.

3. Attack Flow

This mechanism is described based on public information. Distinctions between researcher verification, implementation analysis, and actual exploitation are detailed in the success criteria section.

From Exposed Incoming Email Addresses to Code Modifications

A third party identifies a valid incoming email address and target project from public documents or other sources.
The attacker sends an email containing a patch to the merge request destination address.
GitLab processes branch creation and modifications under the permissions of the token owner. This is not a privilege escalation to projects or operations unauthorized for the owner.
If CI execution conditions are met, the modified job runs on the runner. Available secrets and external permissions depend on the configuration of the job and runner.

4. Attacker Position and Execution Environment

The attacker knows a valid incoming email token and the target project, and has the ability to send messages to the incoming email feature.
Operations within GitLab run with the permissions of the token owner, while processes inside the job run with the permissions assigned to the runner and the job.

5. Victim and Administrator Perspectives

Victims

Branches, merge requests, and pipelines originating from emails not sent by the user may appear as their own actions.

Administrators

Even without abnormal web logins, email receipt timestamps may correlate with code modifications and CI execution records.

6. Success and Failure Conditions

Success Conditions

The incoming email feature is enabled, and the leaked token has not been revoked.
The token owner has the necessary operational permissions in the target project, and the request meets the email processing criteria.
CI-related impacts require target job execution conditions as well as permissions for secrets and external resources.

Failure Conditions and Risk Mitigation

Reset the exposed incoming email token and disable the old address. Because this changes addresses for other projects owned by the same user, verify legitimate integrations.
Reduce unnecessary project permissions and direct push rights to protected branches, and restrict CI secrets and runner permissions to necessary scopes.
For GitLab Self-Managed, consider disabling the unused incoming email feature. Web or SSH IP restrictions alone cannot block email channels.

7. Impact of Successful Exploitation

Code modifications, CI execution, and access to source code or sensitive information become possible within the scope of the owner's permissions and project settings.
A token exposed in a single project may be leveraged across other projects belonging to the same user.

8. Observable Logs

The following guidance covers investigation and detection perspectives within your organization. It does not imply that all indicators were observed in public incidents.

Email

Preserve the incoming email recipient, sender, attached patches, and processing results. Do not rely solely on the sender display name to determine legitimate operations.

Proxy, SWG, and DNS

Check runners for suspicious outbound network connections. Web access logs alone cannot track email-initiated operations.

Endpoints and EDR

Inspect runner jobs, child processes, artifact generation, and external data transmissions.

Authentication and IdP

Verify token reset timestamps along with changes to owner permissions and group memberships.

SaaS and Cloud

Review change histories for branches, merge requests, CI configurations, and pipelines. Individual reads of secret information are not always logged.

Network

Correlate email receipt timestamps with outbound network traffic originating from jobs.

9. Determining Attack Success

Scope Confirmable via Public Information

Initial Execution Confirmed: Public Information: Code changes and CI execution were confirmed during Aikido's controlled verification (Scope: Researcher test environment; active exploitation in the wild is unconfirmed).
Information Theft or Session Compromise Confirmed: Public Information: Access to private source code and CI variables was demonstrated in the same tests (Scope: Access to data managed by researchers; theft confirmation from victim organizations is absent).

10. Investigation Playbook

The following are proposed investigation and mitigation measures based on public information.

Investigation Starting Point

Start by looking for public exposure of incoming email addresses or unfamiliar email-initiated code modifications.

Initial Verification

Check the token owner, exposure duration, associated projects, and operational permissions for protected branches.

Endpoints and Servers

Preserve incoming emails, patches, job logs, and runner process records.

Authentication and Cloud

Inventory CI variables, job tokens, and deployment credentials that the affected jobs could access.

Subsequent Operations

Check for retrieval of private data, modifications to artifacts or deployment targets, and actions affecting other projects.

Containment

Reset exposed tokens and stop unauthorized jobs. Investigate and revert alterations, and rotate any secrets that may have been accessed.

Decision Categories

Evaluate address exposure, email acceptance, code modification, job execution, and data access separately.

11. Defense and Detection Ideas

The following are proposed investigation and mitigation measures based on public information.

Single Events

Detect email-initiated branch modifications or CI configuration changes that lack standard modification workflows.

Time-Series Correlation

Correlate incoming emails with pipeline triggers and outbound runner communications.

Threat Hunting

Search for incoming email addresses mentioned in public sources and review multi-project operations performed by their owners.

Log Limitations

Without incoming email and runner execution records, web authentication logs alone cannot determine the operational origin or data access.

Priority Mitigations

Prioritize token resets, removal of exposure vectors, and minimization of project and CI permissions.

12. Facts, Inference, and Hypothesis

Facts

Incoming email tokens are issued per user and shared across multiple projects belonging to that user. They do not expire until explicitly reset.
Email senders are not validated; if the address is modified for a merge request and a patch is attached, branch creation and modifications occur under the token owner's permissions.
Tokens do not exceed the existing permissions of the owner. Direct pushes to protected branches require the user to have push rights. Furthermore, GitLab incoming emails are exempt from group IP restrictions.
Aikido demonstrated authorized changes to protected main branches and access to private source code and CI variables under controlled conditions. This report does not confirm actual attack victims.
Aikido discovered approximately 12 valid addresses in public documents and other sources. GitLab reportedly considered this expected behavior and updated warning notices and documentation.

Inference

Incoming email addresses must be managed as long-term credentials, requiring a joint review of exposure scopes across repositories, documents, and email archives, along with user permissions.

Hypothesis

No additional hypotheses. Unconfirmed items are listed in open questions and further investigation.

13. MITRE ATT&CK Mapping

T1552.001 Unsecured Credentials: Credentials In Files (Confidence: High): Mapping to the path demonstrated by researchers where credentials are obtained from public repositories or documents.
T1078 Valid Accounts (Confidence: High): Mapping to the verified technique of leveraging the legitimate permissions of the token owner.

14. Open Questions and Further Investigation

The presence of actual attack victims utilizing exposed tokens.
Total exposure counts, revocation status, and affected project counts across GitLab.com and Self-Managed deployments.

15. Impact on SOCs and Organizations

Audit incoming email addresses across public documents, wikis, ticketing systems, and email archives, and reset any exposed tokens. While glimt- is a useful search clue, older formats and custom prefixes also exist, so do not rely solely on this string to conclude searches. Make email-initiated code modifications and CI executions subject to auditing.

16. Summary by Role

SOC: Correlate incoming emails, branch modifications, pipelines, and outbound runner traffic on a unified timeline.
Administrators: Reset exposed tokens and review user permissions, protected branches, CI secrets, and runner privileges.
Users: Do not make incoming email addresses public. Report any exposures or unfamiliar modifications to administrators.

Roundcube CVE-2026-48842: Active Exploitation Reported for Pre-Authentication SQL Injection in virtuser_query

Anoymask — Fri, 25 Sep 2026 10:24:06 +0000

1. Basic Information

Original Title: Roundcube security advisory (AV26-503) – Update 1
Source: Canadian Centre for Cyber Security
Published: May 25, 2026
Updated: September 21, 2026
Collected: September 25, 2026, 08:28:50 +09:00
Severity: High
Severity Basis: Canadian cybersecurity authorities reported active exploitation based on public information for this pre-authentication SQL injection. The CVE CVSS v3.1 score is 8.1. It depends on the use and configuration of virtuser_query, and public reports do not confirm individual data theft or OS command execution.
Original Link: Roundcube security advisory (AV26-503) – Update 1
Related Sources: Roundcube: Security updates 1.6.16 and 1.7.1, CVE Record: CVE-2026-48842, Critical Roundcube flaw now actively exploited in code injection attacks
CVE: CVE-2026-48842
Target Products and Services: Roundcube Webmail, virtuser_query

2. Quick Summary

Active exploitation has been reported for CVE-2026-48842, a pre-authentication SQL injection vulnerability in Roundcube's virtuser_query plugin. Organizations must verify plugin enablement and configuration, and update to the patched version for their active branch.

3. Attack Flow

This mechanism is described based on public information. Distinctions between researcher verification, implementation analysis, and actual exploitation are detailed in the success determination section.

From Pre-Authentication User Mapping to SQL Injection

An attacker sends a crafted request to an unpatched Roundcube instance.
If the virtuser_query plugin is enabled and input reaches the vulnerable SQL processing path, a pre-authentication SQL injection can occur.
The scope of subsequent data access or modification depends on database contents, privileges, and authentication configuration. SQL injection alone does not confirm the theft of all emails or execution of server-side code.

4. Attacker Position and Execution Location

An unauthenticated attacker capable of sending HTTP requests to Roundcube.
The affected operation is the SQL query executed by virtuser_query. This is not a report directly confirming OS command execution.

5. Victim and Administrator Perspective

Victims

Visible anomalies may not immediately appear on the user interface.

Administrators

Suspicious pre-authentication requests, SQL errors, and unusual data access or modifications serve as investigation leads.

6. Success and Failure Conditions

Success Conditions

The virtuser_query plugin is enabled in an affected, unpatched version.
A vulnerable query configuration is used, allowing attacker input to reach the target process.
Data access and modification depend on the connected database and its assigned privileges.

Failure Conditions and Risk Mitigation

Update to patched versions corresponding to the deployed branch: version 1.6.16 or later for the 1.6.x branch, and version 1.7.1 or later for the 1.7.x branch.
Disable virtuser_query if it is not needed; if required, verify configurations and patch application. Confirm mail authentication impacts before disabling functionality.
Minimize database privileges and add defenses against suspicious input. Do not rely solely on a WAF as a replacement for patching.

7. What Happens Upon Success

SQL injection may lead to information retrieval or modification within the limits permitted by the connected database.
The retrieval of email bodies or credentials, authentication bypass, and OS command execution must be verified via evidence in each specific environment.

8. Observable Logs

The following section includes investigation and detection perspectives for internal operations. It does not imply that all items were observed in public incidents.

Email

No information has been publicly reported indicating that email was used for initial access. Post-compromise email activity must be verified separately.

Proxy, SWG, and DNS

Review suspicious pre-authentication HTTP requests and responses. Note that POST bodies may not always be recorded.

Endpoints and EDR

Preserve logs related to the web server, PHP, Roundcube, and its plugins. Investigate suspicious files and child processes as evidence of secondary compromise.

Authentication and IdP

Check for logins, sessions, and mail authentication following suspicious requests. The absence of a normal login does not rule out SQL operations.

SaaS and Cloud

Check database errors, audit logs, configuration changes, and abnormal query volumes.

Network

Correlate suspicious web requests with database connections and outbound traffic by timestamp and target.

9. Attack Success Determination

Scope Confirmable via Public Information

Canadian cybersecurity authorities have reported active exploitation based on public information. SQL execution results, data theft, and subsequent activities for specific victim environments have not been publicly disclosed.

Criteria for Internal Assessment

Criteria for Data Theft or Session Compromise: Correlate suspicious SQL operations with unauthorized data retrieval, data modification, or session usage. Public information indicates active exploitation reports but does not confirm individual data theft success. (Scope: Internal databases and authentication records.)

10. Investigation Playbook

The following are investigative and remedial suggestions based on public information.

Starting Point for Investigation

Begin with vulnerable versions and plugin configurations, or suspicious pre-authentication requests.

Initial Checks

Verify patch status for 1.6.x and 1.7.x branches, virtuser_query configurations, and database connections and privileges.

Endpoints and Servers

Preserve web, PHP, and Roundcube logs and configurations, and correlate request processing timestamps.

Authentication and Cloud

Examine database operations alongside subsequent login, session, and email activities.

Subsequent Activity

Check for data access, configuration changes, additional files, and credential usage.

Containment

Restrict access to affected features and services while applying updates. Investigate the scope of compromise and update exposed credentials.

Decision Categories

Distinguish between suspicious input, SQL processing anomalies, data operations, successful authentication, and subsequent compromise.

11. Defense and Detection Ideas

The following are investigative and remedial suggestions based on public information.

Single Event

Detect suspicious SQL errors and data modifications occurring around the same time as pre-authentication requests.

Timeline Correlation

Correlate HTTP requests with database operations and subsequent authentication or data access.

Threat Hunting

Target environments with vulnerable plugin configurations to retroactively review pre-patch requests and database records.

Limitations of Logs

Web logs alone cannot confirm SQL execution details or email access. Combine database and authentication evidence.

Priority Mitigations

Prioritize updating to patched versions, verifying plugin configurations, enforcing least privilege, and preserving logs.

12. Facts, Inference, and Hypothesis

Facts

CVE-2026-48842 is a pre-authentication SQL injection vulnerability in the virtuser_query plugin caused by improper handling of backslashes in preg_replace().
The affected scope includes versions 1.6.x prior to 1.6.16 and 1.7.x prior to 1.7.1. Roundcube released versions 1.6.16 and 1.7.1 on May 24, 2026.
In its September 21 update, the Canadian Centre for Cyber Security stated that public information indicates active exploitation. It did not disclose specific attackers, victim environments, or stolen data.
The CVSS v3.1 score is 8.1. Exploitation does not occur merely by deploying the product; it requires virtuser_query to be enabled and vulnerable query configurations to be present.

Inference

Incorporating plugin and query configurations alongside version data into asset inventories helps narrow down priorities for patching and retroactive investigation.

Hypothesis

No additional hypotheses. Unverified items are listed in "Unknowns and Additional Investigation".

13. MITRE ATT&CK Mapping

T1190 Exploit Public-Facing Application (Confidence: High): The vector exploits pre-authentication SQL processing in public webmail. This does not indicate specific subsequent actions.

14. Unknowns and Additional Investigation

Requests used in active exploitation, along with the identities of attackers and victim organizations.
Information accessed or modified in individual environments, as well as subsequent authentication and operations.
The number of unpatched environments with vulnerable plugin configurations.

15. Impact on SOCs and Organizations

Verify Roundcube versions, virtuser_query enablement and configurations, update to patched versions, and investigate past pre-authentication requests. Evaluate SQL injection separately from email or session compromise.

16. Summary by Role

SOC: Correlate web, plugin, database, and authentication records to distinguish requests from actual data operations.
Administrators: Update to the patched version for the deployed branch, and reduce unnecessary plugins and excessive database privileges.
Users: Follow service administrator notifications and report any suspicious email activities or authentication prompts.

SolarWinds Observability Self-Hosted: Two Pre-Authentication RCE Vulnerabilities Fixed with Different Configuration Requirements

Anoymask — Fri, 25 Sep 2026 10:21:59 +0000

1. Basic Information

Original Title: SolarWinds Observability Self-Hosted Remote Code Execution Vulnerability (CVE-2026-28324)
Source: SolarWinds
Published: September 22, 2026
Updated: None
Collected: September 25, 2026, 08:28:50 JST
Severity: Critical
Severity Rationale: These are pre-authentication remote code execution vulnerabilities with CVSS v3.1 scores of 9.8 for CVE-2026-28324 and 8.8 for CVE-2026-28325. While active exploitation has not been confirmed, they can impact the privileges and accessible destinations of monitoring infrastructure, so this report rates the overall severity as critical.
Original Link: SolarWinds Observability Self-Hosted Remote Code Execution Vulnerability (CVE-2026-28324)
Related Sources: SolarWinds: CVE-2026-28325 advisory, SolarWinds patches critical RCE flaws in Observability Self-Hosted
CVEs: CVE-2026-28324, CVE-2026-28325
Affected Products/Services: SolarWinds Observability Self-Hosted 2026.2.2 and earlier, SolarWinds Observability Self-Hosted 2026.2.3

2. Quick Summary

SolarWinds has patched two pre-authentication RCE vulnerabilities in Observability Self-Hosted. CVE-2026-28324 requires an insecure, non-standard configuration, while CVE-2026-28325 requires a specific communication mode and network adjacency. Both flaws are addressed in version 2026.2.3.

3. Attack Flow

This section describes the mechanics explained in public disclosures. The distinction between researcher verification, implementation analysis, and actual exploitation is detailed in "Attack Success Determination."

CVE-2026-28324: Insecure Non-Standard Configuration

An attacker reaches an unpatched system running an affected non-standard configuration.
The flaw, involving improper integrity checks, can be exploited to achieve pre-authentication code execution. Specific request details and attack paths have not been publicly disclosed.

CVE-2026-28325: Deserialization in a Specific Communication Mode

An attacker reaches an unpatched system using an affected communication mode from an adjacent network.
The vulnerability, involving insecure deserialization of untrusted data, can be exploited to achieve pre-authentication code execution. There are no reports of observed active attack procedures.

4. Attacker Position and Execution Location

CVE-2026-28324 assumes an unauthenticated attacker reaching the target process over the network.
CVE-2026-28325 carries the official CVSS Adjacent requirement, meaning it cannot be generalized as directly executable from any source on the internet.
Subsequent actions may execute with the privileges of the affected service, though details regarding specific services and execution paths remain unpublished.

5. Victim and Administrator Perspective

Victims

There are no reports indicating that general user interaction is required.

Administrators

Abnormal service termination, suspicious child processes, configuration modifications, and external communications warrant investigation. These represent investigative viewpoints rather than published IOCs specific to this issue.

6. Success and Failure Conditions

Success Conditions

Reaching the target process on an unpatched environment running version 2026.2.2 or earlier.
For CVE-2026-28324, the presence of an insecure non-standard configuration.
For CVE-2026-28325, the use of a specific communication mode combined with network adjacency access.

Failure Conditions and Risk Mitigation

Update to version 2026.2.3 or a subsequent release designated by the vendor as containing the fix.
Until updating, verify affected configurations and communication modes with the vendor, and restrict communication sources and paths. Blocking administrative interfaces alone may not protect all target processes.
Minimize monitoring service credentials and destination privileges to limit the blast radius in the event of a compromise.

7. Impact Upon Success

Environments meeting the conditions may be exposed to pre-authentication remote code execution.
Inference: Configurations, credentials, and accessible destinations associated with the monitoring infrastructure could be impacted. This does not imply that individual data theft or lateral movement has been observed.

8. Observable Logs

The following outlines investigative and detection perspectives for internal security teams. This does not imply that all indicators were observed in public incidents.

Email

There is no public information indicating that email was used for initial access.

Proxy, SWG, and DNS

Check for requests directed at affected communication paths and suspicious external connections originating from the monitoring server.

Endpoint and EDR

Preserve service anomalies, child processes, newly created files, and persistence configurations.

Authentication and IdP

Check for subsequent use of credentials or administrator accounts assigned to the monitoring service.

SaaS and Cloud

Review monitoring configurations, administrative actions, and the permissions and audit logs of integrated services.

Network

Identify access paths for each CVE and inspect connections to target processes as well as internal and external communications.

9. Attack Success Determination

Scope Confirmed in Public Information

The vendor has published vulnerabilities and patched versions. There are no reports confirming active exploitation or code execution in individual environments.

Internal Determination Criteria

Initial Execution Criteria: Criteria: Correlate suspicious incoming request processing with execution evidence such as service child processes and file creation. Public information contains no reports confirming active exploitation. (Scope: Organization's vulnerable services.)
Subsequent Compromise Criteria: Criteria: Confirm additional evidence of credential usage following code execution, configuration changes, or interactions with secondary systems. (Scope: Investigated environment; not a published attack record.)

10. Investigation Playbook

The following recommendations for investigation and mitigation are based on public information.

Investigation Starting Point

Triggered by the discovery of affected versions/configurations or anomalies in the monitoring service.

Initial Verification

Verify software version, non-standard settings, communication modes, connection sources, and update status.

Endpoints and Servers

Preserve service logs, processes, files, configurations, and network records.

Authentication and Cloud

Review permissions and usage history for monitoring accounts and integrated credentials.

Subsequent Activity

Inspect for configuration tampering, credential access, and abnormal operations targeting monitored systems.

Containment

Restrict target communications while considering potential impacts on necessary monitoring functions, and update to the patched version. If compromise is suspected, proceed with isolation, recovery, and credential rotation.

Determination Categories

Differentiate between vulnerable configurations, requests, code execution, data retrieval, and subsequent compromise.

11. Defense and Detection Ideas

The following recommendations for investigation and mitigation are based on public information.

Single Events

Detect unexpected child processes or executable file creation originating from the monitoring service.

Timeline Correlation

Correlate anomalies in incoming request handling with child processes, configuration changes, and external communications.

Threat Hunting

Identify assets with affected versions and configurations, and inspect pre-update service logs and credential usage.

Log Limitations

Official IOCs and request formats have not been published. General anomalies alone cannot confirm exploitation of these CVEs.

Priority Mitigations

Prioritize patch application, restricting communication paths per CVE, and enforcing the principle of least privilege for monitoring accounts.

12. Facts / Inference / Hypothesis

Facts

CVE-2026-28324 is a pre-authentication RCE caused by improper integrity checks and occurs in insecure non-standard configurations. The CVSS v3.1 score is 9.8 with a Network attack vector.
CVE-2026-28325 involves insecure deserialization of untrusted data in a specific communication mode, leading to pre-authentication RCE. The CVSS v3.1 score is 8.8 with an Adjacent attack vector.
Both vulnerabilities affect versions 2026.2.2 and earlier, with version 2026.2.3 serving as the fix.
The official advisory was published on September 22, 2026. Active exploitation, individual victim environments, and subsequent payloads have not been publicly disclosed.

Inference

Even for pre-authentication RCE vulnerabilities in the same product, configurations and network conditions differ. Prioritization requires combining version, communication mode, and reachability assessments rather than relying solely on asset counts.

Hypothesis

No additional hypotheses. Unverified items are documented in "Unknowns and Further Investigation."

13. MITRE ATT&CK Mapping

Specific exploitation paths and attack behaviors cannot be sufficiently identified from public information; mapping is withheld.

14. Unknowns and Further Investigation

Details of affected non-standard configurations, communication modes, and specific attack requests.
Presence of active exploitation, victim organizations, and subsequent payloads.
Privileges within individual environments and the potential blast radius across monitored targets.

15. Impact on SOCs and Organizations

Verify Observability Self-Hosted versions and configurations, and update to version 2026.2.3 or later. Distinguish between the reachability conditions of the two vulnerabilities, and include credentials and accessible destinations referenced by the monitoring infrastructure in the investigation scope.

16. Summary by Role

SOC: Correlate service request processing, child processes, files, and external communications, and distinguish between attempts and execution.
Administrators: Update to the patched version and review non-standard configurations, communication modes, connection sources, and service privileges.
Users: Report monitoring anomalies or suspicious modifications to administrators.

CARBONATO: A Botnet Built Around an AI Agent via Exposed Docker APIs

Anoymask — Fri, 25 Sep 2026 10:20:22 +0000

1. Basic Information

Original Title: CARBONATO: a botnet built around an AI agent
Source: ThreatDown
Published Date: 2026-09-22
Updated Date: None
Collection Date: 2026-09-25T08:28:50+09:00
Severity: Critical
Basis of Severity: ThreatDown analyzed recovered containers and scripts, identifying host intrusion, persistence, propagation, mining, and AI agent-driven operational capabilities. Although the exact number of victim hosts and the execution status of each feature have not been publicly disclosed, the severity is rated as critical because exposed Docker APIs can impact entire hosts.
Original Link: CARBONATO: a botnet built around an AI agent
Related Sources: BleepingComputer: New Carbonato malware uses AI agents to hijack exposed Docker hosts, Docker: Protect the Docker daemon socket
CVE: None
Target Products and Services: Docker Engine API, Hermes Agent, Telegram, OpenRouter

2. Executive Summary

CARBONATO uses Docker APIs exposed without authentication as an entry point, combining host intrusion and script-based propagation with interactive remote control via the Hermes Agent. The propagation itself is not autonomously decided by an LLM.

3. Attack Flow

This mechanism is described based on publicly available information. Distinctions between researcher verification, implementation analysis, and actual exploitation are detailed in the "Attack Success Determination" section.

Intrusion and Propagation from Docker API to Host

The attacker scans for Docker APIs accessible without authentication.
The attacker uses privileged container creation and access to host resources to execute operations on the host.
Scripts deploy persistence and mining capabilities, periodically scanning surrounding Docker APIs to attempt propagation.

Interactive Control Using an AI Agent

The Hermes Agent and attack instructions are deployed on the host.
Operators issue tasks via Telegram, and the agent uses LLM services to execute commands.
Results are returned through the communication channel. Reverse SSH is a separate connection method, and reports do not indicate that all instructions route through SSH.

4. Attacker Positioning and Execution Location

Attackers reach unauthenticated Docker APIs externally or from a compromised network.
Processing on the host depends on permissions permitted by the Docker configuration. The analyzed mechanism accesses the host using privileged containers or similar methods.

5. Visibility for Victims and Administrators

Victims

Resource consumption due to mining or suspicious persistent processes may be visible, though no screen display is required.

Administrators

Unexpected privileged containers, host mounts, nsenter usage, scheduled jobs, reverse SSH, and communications to Telegram or LLM services serve as investigation clues.

6. Success and Failure Conditions

Success Conditions

The attacker reaches an unauthenticated Docker API and can perform operations such as container creation.
Host intrusion requires a configuration that permits privileged settings, host mounts, or namespace access.
AI control features require communication with an LLM and valid credentials, but initial API exploitation and script-based propagation do not depend on LLM connectivity.

Failure Conditions and Risk Reduction

Stop unnecessary network exposure of Docker APIs. If remote management is required, use SSH, mutual TLS, source IP restrictions, or appropriate authorization controls.
Limit privileged containers, host-side mounts, and namespace sharing to necessary operations only.
During a compromise, do not rely solely on stopping containers; inspect host-side persistence and recover from a trusted state.

7. What Happens Upon Success

The analyzed implementation includes remote host control, mining, persistence, and propagation to surrounding Docker environments.
While some configurations instruct credential collection, the instructions in the materials alone do not prove data theft in individual victim environments.

8. Observable Logs

The following section includes perspectives for internal investigation and detection. This does not mean all items were observed in public incidents.

Email

There are no public reports indicating that email was used for initial access.

Proxy, SWG, and DNS

Correlate suspicious destination IPs, Telegram, and LLM service connections with host-side processing.

Endpoints and EDR

Check for privileged containers, nsenter, /root/.hermes/SOUL.md, /usr/local/bin/.docker-network-monitor, and scheduled jobs.

Authentication and IdP

Verify subsequent usage of SSH keys or cloud credentials that were accessible from the host.

SaaS and Cloud

Review container creation settings, image pull history, and LLM API usage origins.

Network

Inspect TCP/2375 connections, surrounding network scans, and reverse SSH. Prioritize correlating these with unusual processes.

9. Attack Success Determination

Scope Confirmable via Public Information

ThreatDown analyzed recovered materials and operation infrastructure, confirming the implementation of each feature. The execution of all features, successful data theft, and the number of victims on individual compromised hosts have not been publicly disclosed.

Internal Determination Criteria

Initial Execution Criteria: Correlate unauthorized container creation with subsequent host-side processes or file creation. Public documentation reflects implementation analysis of recovered materials and does not indicate execution of all features in a victim environment. (Scope: Internal containers and hosts.)
Data Theft or Session Compromise Criteria: Confirm access to credentials and external transmission using separate evidence. (Scope: Success or failure of individual host theft.)

10. Investigation Playbook

The following are proposals for investigation and countermeasures based on public information.

Starting Point for Investigation

Start with unauthorized Docker operations, privileged containers, or host-side files matching public IoCs.

Initial Verification

Verify Docker API authentication, connection sources, container privileges, host mounts, and creation timestamps.

Endpoints and Servers

Preserve container configurations, images, host processes, scheduled jobs, agent settings, and logs.

Authentication and Cloud

Inspect credentials exposed on hosts and review audit logs for their subsequent use.

Subsequent Operations

Check for connections to other Docker hosts, mining, access to sensitive information, and additional remote control activities.

Containment

Isolate the host, stop API exposure, and investigate persistence. If host compromise is confirmed, recover from a trusted state and rotate exposed credentials.

Decision Categories

Evaluate API access, container creation, host execution, AI control, propagation, and data theft separately.

11. Defense and Detection Ideas

The following are proposals for investigation and countermeasures based on public information.

Single Events

Detect unauthorized privileged container creation or suspicious host-side scheduled jobs.

Time-Series Correlation

Correlate Docker operations with host execution, persistence, network scanning, and outbound communications.

Threat Hunting

Search using public IoCs and SOUL.md files containing GH0ST indicators. The mere presence of Hermes Agent does not inherently indicate maliciousness.

Limitations of Logs

Implementation materials within registries alone do not prove execution in a victim environment. Records from both containers and hosts are required.

Priority Countermeasures

Prioritize stopping public API exposure, securing and restricting management paths, minimizing host privileges, and removing host-side persistence.

12. Facts / Inference / Hypothesis

Facts

ThreatDown analyzed 59 repositories, 234 tags, and 605 verified blobs from public container registry materials obtained in August 2026. This figure does not represent the number of victim hosts.
The entry point is the Docker API exposed without authentication. Mechanisms using privileged containers, host-side mounts, and namespaces to proceed to host execution have been confirmed.
The Hermes Agent code itself is unmodified; SOUL.md instructions impart malicious behaviors associated with GH0ST. The inclusion of credential collection in instructions is distinct from actual successful theft in individual cases.
The architecture uses Telegram to instruct the agent and perform operations via LLMs. A reverse SSH connection path is also implemented separately.
Periodic scanning and propagation to surrounding networks are implemented via scripts and do not require LLM decision-making.
Based on infrastructure clues, ThreatDown assesses that the operators are located in Costa Rica. This is the vendor's attribution assessment.

Inference

Because public exposure of the Docker API and high host privileges create the entry point, while interactive AI control and routine script propagation operate independently, blocking AI communication alone cannot be considered complete containment.

Hypothesis

No additional hypotheses. Unconfirmed items are listed in "Unknowns and Additional Investigation."

13. MITRE ATT&CK Mapping

T1610 Deploy Container (Confidence: High): Implementation creating containers via exposed Docker APIs has been confirmed.
T1611 Escape to Host (Confidence: High): Implementation executing tasks on the host using privileged settings and host resource access has been confirmed.
T1059.004 Command and Scripting Interpreter: Unix Shell (Confidence: High): Shell scripts performing propagation and persistence have been analyzed.

14. Unknowns and Additional Investigation

Number of victim hosts, distribution by country and industry, and execution frequency of each feature.
Information actually retrieved and transmitted by the AI agent, along with individual operator instructions.
Additional operational infrastructure or associates not captured in public data.

15. Impact on SOCs and Organizations

Prioritize checking Docker public exposure settings and host privileges. Do not assume communications with AI services are inherently malicious; investigate by combining unauthorized container creation, host-side persistence, and periodic scanning.

16. Summary by Target Audience

SOC: Correlate Docker APIs, privileged containers, host-side processes, reverse SSH, and AI communications.
Administrators: Stop unauthenticated API exposure, restrict management paths, and limit container host privileges.
Users: Since general users cannot mitigate this, report suspicious resource consumption or processes to Docker administrators.

Arista VeloCloud Orchestrator CVE-2026-93952: Active Exploitation of Authentication Bypass Zero-Day

Anoymask — Thu, 24 Sep 2026 11:37:49 +0000

1. Basic Information

Title: Security Advisory 0183
Published: 2026-09-22
Updated: 2026-09-23
Collected: 2026-09-24T08:09:37+09:00
Source: Arista
Severity: critical
Target Period: 2026-09-23T08:14:06+09:00 - 2026-09-24T08:09:37+09:00 (Asia/Tokyo)
Original: Security Advisory 0183
Related Source: BleepingComputer: Arista patches actively exploited VeloCloud Orchestrator zero-day
Severity Basis: Can be exploited before authentication with a CVSS v3.1 score of 10.0. Arista has confirmed active exploitation and released indicators of compromise including backdoor-related files and systemd services on the VCO.
Update Reason: Verified with primary sources, organized update dates, patch levels by product line, observed indicators of compromise, and unconfirmed downstream impacts.

2. Executive Summary

Arista has confirmed active exploitation of an authentication bypass vulnerability in VeloCloud Orchestrator (VCO) and released indicators of compromise such as backdoor-related files. Exploitation requires the public portion of the Edge authentication certificate and network reachability to the VCO Web UI.

3. Attack Flow

Conditions for Authentication Bypass and Artifacts to Investigate After Compromise

An attacker obtains the public portion of an Edge authentication certificate associated with an unpatched VCO that has certificate-based Edge-to-VCO authentication enabled.
If the VCO Web UI is reachable, the attacker can access privileged internal functions without tenant or operator credentials and impact the VCO host.
Arista has published .vcnode.js, vc-sysmond, vc-sysmon.service, the x-vc-opt header, and source IPs as indicators related to active exploitation. The specific deployment order and header processing details have not been disclosed.
Inference: Investigate potential impact spreading to credentials, configurations, and managed Edges following a compromise. Data theft and lateral movement to Edges are unconfirmed publicly.

4. Attacker Position and Execution Location

External attackers with network reachability to the VCO Web UI from the internet or a management network
Entities capable of acquiring the public portion of the Edge certificate
Operators executing commands on the VCO host after compromise

5. Visibility for Victims and Administrators

Victims

SD-WAN users may not notice direct anomalies

Administrators and SOCs

Potential presence of known JavaScript files, backdoors, and systemd services
The x-vc-opt header in nginx logs
Management plane connections from known IPs
Inference: Configurations, credentials, and managed Edge state changes that do not match administrator actions

6. Success and Failure Conditions

Success Conditions

Certificate-based Edge-to-VCO authentication is enabled
The attacker obtains the public portion of the Edge certificate
Network reachability to the VCO Web UI
Using an unpatched version

Failure Conditions and Mitigations

Update to version 5.2.3.16 or later (5.2.3 branch) or 6.4.2.8 or later (6.4.2 branch). For other branches, consult TAC to confirm patched versions and migration paths.
Restrict the VCO Web UI to trusted management networks or VPNs
Block traffic associated with known malicious IPs and eliminate unnecessary network exposure
If compromise is suspected, preserve evidence, contact Arista TAC, recover from a trusted environment, and determine whether to rotate and revoke exposed credentials.

7. What Happens Upon Success

Authentication bypass to privileged internal functions and compromise of the VCO host
Deployment of backdoors and persistence configurations (related indicators of compromise published by Arista)
Inference: Potential leakage or tampering of SD-WAN configurations, credentials, and Edge information, as well as impacts on managed devices.

8. Observable Logs

Email

No email vectors reported

Proxy / SWG / DNS

Suspicious requests to the VCO Web UI
Incoming connections to the VCO from known malicious source IPs: 142.93.149.77 and 104.248.126.159

Endpoint / EDR

/usr/local/sbin/.vcnode.js
/usr/local/sbin/vc-sysmond (MD5 dc78e206eaeadec59fc5801fe4556bd0)
Creation and startup of /etc/systemd/system/vc-sysmon.service

Identity / IdP

Management operations occurring without normal operator or tenant authentication records

SaaS / Cloud

Hosted VCOs are handled by the vendor. For on-premises, check configuration exports, Edge status, and administrator audit logs

Network

nginx request header x-vc-opt
Communication from the VCO to unknown external hosts
Abnormal connections from the VCO to Edges or management networks

9. Attack Success Determination

Confirmed via Public Information

Subsequent Compromise Confirmed: Public info: Arista has confirmed active exploitation and published indicators of compromise regarding malicious files, systemd services, and traffic on the VCO. Commands executed in individual environments, stolen data, and the scope of managed Edge compromise have not been publicly confirmed. Scope: VCO indicators published by Arista. Does not imply installation in all affected environments.

10. Investigation Playbook

Trigger

Presence of the affected version, known files, services, headers, or IPs

Initial Checks

Check version, deployment format, certificate authentication settings, and Web UI exposure
Preserve web access, backend, system, database logs, and file timestamps before recovery.

Endpoints and Servers

Investigate the three known paths, hashes, processes, process lineage, persistence, and additional files
Check command history and outbound communication during the backdoor execution period

Authentication and Cloud

Check credentials and certificate usage history for VCO administrators, tenants, and Edges
Mark API tokens, backups, and integration secrets for rotation and revocation

Subsequent Operations

Compare changes in Edge settings, routing, firewall and VPN policies, and firmware distribution
Check for lateral movement within the management network

Containment

Isolate the VCO from the management network and rebuild/restore according to vendor procedures
Update to a patched version, and rotate or revoke credentials and certificates
Deploy IoCs to network and EDR tools

Decision Criteria

Do not assume successful compromise based on suspicious requests alone; cross-reference known file contents, hashes, service configurations, and execution logs. If IoCs match, preserve state and contact Arista TAC.

11. Defense and Detection Ideas

Single Event

VCO requests containing the x-vc-opt header
Creation of known backdoor paths or services
Connections to the VCO management plane from known IPs

Timeline Correlation

Correlate Web UI requests without authentication records -> file creation -> systemd service activation -> outbound connections

Threat Hunting

Search across the VCO for hidden files, unknown services, and recent modifications in /usr/local/sbin

Log Gaps

If shell and EDR observability is lacking on the appliance, packet capture and vendor support diagnostic data are required

Priority Mitigations

Emergency update to patched versions corresponding to the deployment branch
Restrict connection sources to the management UI
Immutable backups
Rotate or revoke credentials and certificates based on exposure
File integrity monitoring for the appliance

12. Facts / Inference / Hypothesis

Facts

CVE-2026-93952 is an input validation flaw in VeloCloud Orchestrator, rated 10.0 for CVSS v3.1 and 9.5 for CVSS v4.0.
It can be exploited without operator or tenant credentials if certificate-based Edge-to-VCO authentication is enabled, the public portion of the Edge certificate is obtained, and the VCO Web UI is reachable.
Arista has confirmed active exploitation, hosted VCOs have been patched, and on-premises users are urged to update and investigate compromises.
Affected ranges are 5.2.3.15 and earlier for the 5.2.x branch, 6.1.3.7 and earlier for the 6.1.x branch, 6.4.2.7 and earlier for the 6.4.x branch, and 7.0.0.2 and earlier for the 7.0.x branch.
Patched versions are 5.2.3.16 and later for the 5.2.3 branch, and 6.4.2.8 and later for the 6.4.2 branch. Additional patched versions for other affected branches are scheduled for release, and update paths must be confirmed with Arista TAC.
Malicious files .vcnode.js, vc-sysmond, vc-sysmon.service, nginx header x-vc-opt, and IPs 142.93.149.77 and 104.248.126.159 have been published as IoCs.

Inference

VCO compromise can expand impact to individual Edge settings, credentials, and SD-WAN configurations; remediation should not stop at a single host.
Because public certificate portions are sufficient and private key theft is not required, reducing the exposure surface of Edge certificates and management UI reachability is critical.

Hypothesis

No additional hypotheses. Unconfirmed items are listed under Unknowns and Further Investigation.

13. MITRE ATT&CK Mapping

ID	Technique	Confidence	Basis
T1190	Exploit Public-Facing Application	high	Exploiting authentication bypass in the VCO Web UI.
T1543.002	Create or Modify System Process: Systemd Service	high	Persistence via vc-sysmon.service.

14. Unknowns and Further Investigation

Full pattern of initial intrusion requests
Number of compromised organizations and duration of activity
Commands executed by the backdoor and data stolen
Release schedules for patched versions of the affected 6.1.x and 7.0.x branches
Presence of configuration tampering down to the Edge level
Persistence methods other than public IoCs and specific processing of the x-vc-opt header

15. Impact on SOCs and Organizations

Organizations utilizing on-premises VCOs must verify not only updates but also known IoCs, management audit records, and Edge configuration diffs. Because SD-WAN management planes can span all branch sites, handle matching IoCs as a wide-area network incident.

16. Summary by Persona

SOC

Cross-reference VCO headers, files, systemd, and network IoCs, and investigate potential Edge configuration changes.

Administrators

Restrict reachability to the Web UI, update to patched versions, and if compromise is suspected, preserve evidence before rebuilding and rotating or revoking credentials.

General Users

No direct remediation is required of end users, but report any communication disruptions or VPN changes to the IT support team.

F5 BIG-IP APM CVE-2026-94127: Pre-authentication RCE Zero-Day Targeting OAuth Configurations

Anoymask — Thu, 24 Sep 2026 11:33:28 +0000

1. Basic Information

Original Title: BIG-IP APM OAuth vulnerability
Published Date: 2026-09-22
Updated Date: 2026-09-23
Collection Date: 2026-09-24T08:09:37+09:00
Source: F5 (CVE Record)
Severity: critical
Target Period: 2026-09-23T08:14:06+09:00 to 2026-09-24T08:09:37+09:00 (Asia/Tokyo)
Original Reference: BIG-IP APM OAuth vulnerability
Related Sources: F5 patches BIG-IP APM zero-day flaw exploited in RCE attacks, F5 Security Advisory K000162605, CISA Known Exploited Vulnerabilities Catalog
Basis for Severity: Active exploitation of pre-authentication RCE has been confirmed. The target is APM configured with an OAuth authorization server. The observation count of over 14,700 IPs introduced by BleepingComputer does not represent vulnerable configurations or unpatched counts.
Reason for Update: The CVE record provided by F5 was used as the primary source, and the data plane impact scope and fixed builds were added. The distinction between investigation indicators and successful compromise, as well as the Japanese expressions, were revised.

2. Executive Summary

A pre-authentication remote code execution vulnerability exists in the data plane of BIG-IP APM configured as an OAuth authorization server. CISA has confirmed active exploitation and added it to the KEV catalog.

3. Attack Flow

RCE via Specially Crafted Traffic to OAuth Authorization Server

An attacker reaches a BIG-IP APM virtual server with an access policy and an OAuth profile.
Specially crafted traffic exploits a heap-based buffer overflow without authentication, potentially leading to remote code execution.
According to F5 guidance cited by BleepingComputer, indicators of compromise include a combination of multiple OAuth authentication failures, suspicious commands, and a subsequent TMM SIGABRT. This is not a mandatory step for all attacks, and a crash alone does not prove successful code execution.

4. Attacker Position and Execution Location

Unauthenticated external attacker able to reach the OAuth endpoint of the BIG-IP virtual server
Entity executing commands on the appliance after compromise

5. Victim and Administrator Perspective

Victims

May appear as authentication failures or temporary access disruptions

Administrators and SOCs

Repeated OAuth authentication failures within a short period
Signs of suspicious commands on the appliance
Subsequent crash due to TMM SIGABRT
Unexpected processes, files, or outbound connections

6. Success and Failure Conditions

Success Conditions

BIG-IP APM configured as an OAuth authorization server
Access policy and OAuth profile associated with the target virtual server
Attacker network reachability to the virtual server
Use of an unpatched build

Failure Conditions and Mitigations

The fixed builds indicated in the F5 CVE record are Hotfix-BIGIP-21.1.0.2.0.30.22-ENG for the 21.1 branch, Hotfix-BIGIP-17.5.1.9.0.160.12-ENG for the 17.5 branch, and Hotfix-BIGIP-17.1.3.5.0.41.14-ENG for the 17.1 branch. Check F5 Support for installation instructions for the appropriate fixed build.
If immediate updates are not possible, obtain an iRule from F5 Support and apply it to the affected APM virtual servers.
Temporarily restrict the use or reachability of affected OAuth authorization servers. Restricting management interfaces alone cannot protect vulnerable data plane paths.

7. What Happens Upon Success

Remote code execution on the BIG-IP appliance
Possible disruption of authentication and access gateway services.
Inference: Potential access to configurations, credentials, and session information
Inference: Use as a stepping stone to the internal network

8. Observable Logs

Email

No email vectors reported

Proxy / SWG / DNS

Repeated requests to the OAuth authorization endpoint
Connections from BIG-IP to unknown external domains or IPs

Endpoint / EDR

Suspicious commands, unknown processes, and files on the appliance
TMM SIGABRT and core dump

Identity / IdP

Multiple OAuth authentication failures
Client and request parameters inconsistent with normal user authentication procedures

SaaS / Cloud

Verify virtual server, access policy, and OAuth profile changes via centralized management or SIEM

Network

Surge in OAuth authentication failures from the same source
Timeline sequence: Surge in failures -> command indicators -> TMM reset/crash

9. Attack Success Determination

Confirmed in Public Information

Active exploitation confirmed (individual execution results not publicly disclosed): F5 reported exploitation in the wild, and CISA added the vulnerability to KEV. Public disclosures do not specify the commands executed, the number of affected customers, or subsequent activity.

10. Investigation Playbook

Trigger

Affected configuration, surge in OAuth authentication failures, suspicious commands, TMM SIGABRT

Initial Verification

Check BIG-IP version/build, OAuth role, virtual server, access policy, and profile
Preserve F5 audit, access, and TMM logs along with core dumps
Retrieve network observation data around the time of the initial anomaly

Endpoints and Servers

Check appliance filesystem, processes, scheduled tasks, configuration changes, and support diagnostic data using vendor procedures

Authentication and Cloud

Investigate anomalies in OAuth clients, tokens, sessions, administrator accounts, and device certificates
Rotate and revoke secrets whose compromise cannot be ruled out

Subsequent Operations

Search for internal discovery, credential access, configuration exports, tunnel creation, and outbound C2

Containment

Restrict affected virtual servers and apply patches or iRules
If compromise indicators are present, isolate the appliance and consult F5 Support to determine whether to rebuild

Determination Criteria

Corroborate each stage with separate evidence: exploit requests, attacker code execution, credential/session theft, and internal intrusion.

11. Defense and Detection Ideas

Single Event

Abnormal OAuth parameters and authentication failures
TMM SIGABRT
Unknown commands and processes on the appliance

Timeline Correlation

Correlate repeated OAuth authentication failures, suspicious command indicators, and a subsequent TMM crash. Tune the correlation window to your environment.

Threat Hunting

Inventory all virtual servers operating as OAuth authorization servers and search for correlation patterns dating back prior to September 23

Log Gaps

BIG-IP local logs alone lack the full picture of commands and network activity, requiring remote syslog, flows, and packet captures

Priority Countermeasures

Emergency patch
Reduction of affected configurations
an iRule supplied by F5 Support
Remote log forwarding
Outbound traffic control on the appliance

12. Facts / Inference / Hypothesis

Facts

CVE-2026-94127 is a pre-authentication remote code execution vulnerability in BIG-IP APM, and F5 has confirmed active exploitation.
It affects instances where APM is configured as an OAuth authorization server and has an access policy and OAuth profile associated with a virtual server.
Configurations operating solely as an OAuth Client or Resource Server are stated not to be affected by this vulnerability.
F5 guidance cited by BleepingComputer lists a combination of multiple OAuth authentication failures, suspicious commands, and a subsequent TMM SIGABRT as investigation indicators.
If patches cannot be applied immediately, mitigation guidance was provided to apply an iRule supplied by F5 Support to affected virtual servers.
According to BleepingComputer, Shadowserver has identified over 14,700 BIG-IP APM IPs. This number does not indicate the target configuration, patch status, or honeypot ratio.
According to F5's CVE record, The vulnerability is exposed through the data plane, not through a control-plane interface. This does not establish the limits of post-compromise impact. Appliance mode is also affected. Versions that have reached EoTS are out of scope for evaluation.
The fixed builds are Hotfix-BIGIP-21.1.0.2.0.30.22-ENG for the 21.1 branch, Hotfix-BIGIP-17.5.1.9.0.160.12-ENG for the 17.5 branch, and Hotfix-BIGIP-17.1.3.5.0.41.14-ENG for the 17.1 branch.
CISA's CVE additional info records the KEV addition and active exploitation on September 22, 2026.

Inference

Prioritizing the inventory of internet-reachable OAuth authorization server configurations narrows down the response scope better than relying solely on product ownership counts.
Because a TMM crash alone cannot identify the root cause, decisions should be made by correlating OAuth authentication failures, suspicious commands, and evidence of files or processes.

Hypothesis

No additional hypotheses. Unverified items are listed in "Unknowns and Additional Investigation".

13. MITRE ATT&CK Mapping

ID	Technique	Confidence	Basis
T1190	Exploit Public-Facing Application	high	Pre-authentication exploit request to public OAuth endpoint.

14. Unknowns and Additional Investigation

Number of active exploitations, threat actors, and payloads
Commands executed by attackers and post-compromise activity
Proportion of the over 14,700 observed IPs that have vulnerable configurations and are unpatched
Impact of EoTS versions and application procedures for fixed builds suitable for each environment

15. Impact on SOCs and Organizations

Organizations utilizing BIG-IP APM for remote access or OAuth integration must immediately verify not only their product versions, but also the presence of authorization server configurations. SOCs should correlate OAuth authentication failure, command indicators, and TMM crashes as a single incident and conduct an emergency investigation even without proof of success.

16. Summary by Target Audience

SOC

Correlate surges in OAuth authentication failures, suspicious commands, and TMM crashes, and trace subsequent communications from the appliance to the internal network.

Administrators

Identify affected OAuth configurations and apply patches, or if difficult, apply an iRule supplied by F5 Support and network restrictions.

General Users

As issues cannot be resolved by general user actions, contact your IT administrator or support team if access disruptions or re-authentication requests persist.

Autonomous AI Agents Breach Online Retailers in Chained Attacks to Steal Payment Card Data

Anoymask — Thu, 24 Sep 2026 11:29:59 +0000

1. Basic Information

Original Title: Autonomous AI Agents are breaking into hundreds of Online Retailers for $25 a target in an ongoing campaign
Published Date: 2026-09-22
Updated Date: None
Collected Date: 2026-09-24T08:09:37+09:00
Source: Gambit Security
Severity: critical
Type: Threat Intelligence
Target Period: 2026-09-23T08:14:06+09:00 - 2026-09-24T08:09:37+09:00 (Asia/Tokyo)
Original Link: Autonomous AI Agents are breaking into hundreds of Online Retailers for $25 a target in an ongoing campaign
Related Sources: BleepingComputer: Malicious AI agents steal 600K credit cards, infect 100+ sites with skimmers
Basis for Severity: Gambit reported 105 attack projects and at least 27 compromised companies. Over 600,000 unexpired payment card records were stolen from two companies, and card-skimming scripts along with data deletion were confirmed. Some individual actions are evaluated based on agent reports and execution logs.
Reason for Update: Separated attack cases from skimmer installation paths, clarified Gambit's evidence categories, observation denominators, and human instructions. Updated MITRE ATT&CK mapping for sudo and cloud secrets, and revised Japanese phrasing.

2. Executive Summary

Gambit reported an ongoing campaign where human-directed AI agents named Hermes, Strix, and Cairn automated much of multi-stage retail site breaches and payment skimmer deployments. Gambit confirmed the theft of over 600,000 unexpired payment card records from two companies. Skimmer deployment was confirmed on 19 targets, with more than 100 additional related sites identified.

3. Attack Flow

Case A: From SQL Injection to Database Card Data

A human attacker sets targets and goals, and the agents explore entry paths. In one Gambit case, the agent read a one-time password (OTP) from a pre-authentication SQL injection and accessed the admin panel.
The agent moved from file upload to remote code execution on the host, abusing sudo NOPASSWD settings to gain root privileges.
It retrieved WordPress database credentials from an internal NFS share, added an administrator, uploaded a plugin, and executed code on an adjacent blog host.
Recovered project logs show it retrieved 46 secrets from AWS Secrets Manager, reaching the Magento database hosted on Amazon Aurora and subsequently obtained the Magento encryption key.

Skimmer Deployment and Post-Exploitation Across Multiple Victims

Gambit reported varying installation methods per victim, including JavaScript appending, tag scripts, S3/CDNs, database contents, Kubernetes initContainers, server-side caching, and cron-based re-deployment. These were not executed sequentially on all targets.
Operations such as restoring timestamps of existing files and deleting data after card theft were recorded.
At another bicycle retailer, cleanup of staging tables deleted 180 tables matching ZQ or Backup, destroying victim-side backup tables as well.

4. Attacker Location and Execution Context

External attacker reaching public web applications
Post-compromise Linux/WordPress/Magento administrator or OS shell
Post-compromise access to cloud secrets, Kubernetes, and NFS resources
Operator directing and evaluating multiple AI agents

5. Victim and Administrator Perspective

Victims

Checkout pages display normally while card data is silently exfiltrated in the background
During outages, business impact surfaces through database table deletions

Administrators and SOCs

Vulnerability scans, admin logins, file uploads, sudo usage, NFS mounts, Secrets Manager reads, and skimmer modifications are scattered across logs of different products
File timestamps are restored, which can cause simple mtime monitoring to miss tampering

6. Success and Failure Conditions

Success Conditions

Public web applications contain exploitable vulnerabilities or weak administrative interfaces
Acquired shells provide pathways to the next stage via sudo, NFS, or cloud secrets
Payment assets and distribution infrastructure can be modified
Outbound communication to card data exfiltration destinations is allowed

Failure Conditions and Mitigations

Prompt patching of public assets and use of WAF/virtual patching
Principle of least privilege for admin panels and file uploads, and protection of OTP storage and validation mechanisms
Elimination of NFS no_root_squash and excessive sudo permissions
Isolation of Secrets Manager, database, CDN, and Kubernetes credentials
Integrity monitoring for checkout page assets and implementation of CSP

7. Impact of Successful Attacks

Confirmation of over 600,000 stolen payment card records
Skimmer deployment confirmed on 19 targets, with over 100 related skimmer-infected sites identified
Theft of cloud secrets and database credentials
Lateral movement across multiple systems
Destruction and evidence removal including database table deletion

8. Observable Logs

Email

No email usage was reported in the initial compromise of this case

Proxy / SWG / DNS

Traffic to AI agent working servers, C2 servers, or skimmer collection endpoints
POST requests from checkout pages to new external domains

Endpoint / EDR

Web processes spawning shells, curl, wget, sudo, mount, cloud CLI, kubectl, and similar tools
Modifications and timestamp manipulation on web roots, plugins, and tag scripts

Identity / IdP

Administrator logins following abnormal OTP reads
Rapid authentication spanning multiple administrative panels and cloud roles

SaaS / Cloud

Mass enumeration/reading in Secrets Manager
S3/CDN object updates
Kubernetes deployment modifications
Abnormal queries and table deletions on Aurora/databases

Network

Automated reconnaissance and SQLi against public web servers
NFS connections and lateral movement to internal WordPress/Magento instances
Card data transmission from shoppers’ browsers to collection servers

9. Attack Success Assessment

Confirmed in Public Information

Subsequent Compromise Confirmed: Gambit directly confirmed stolen card data and active skimmers, reporting at least 27 company compromises and data deletions. Some individual actions are evaluated through agent reports and execution logs rather than independent re-verification. Scope: Recovered attack infrastructure and verified victim sites. The numbers 27 companies, 19 instances, and over 100 sites represent different metrics.

10. Investigation Playbook

Triggers

Checkout tampering, unknown exfiltration destinations, abnormal Secrets Manager reads, web process-initiated shells, database table deletions

Initial Verification

Normalize timestamps across web servers, WAFs, authentication, cloud audit logs, and EDRs to UTC
Preserve historical data for checkout assets, CDNs, and S3 objects
Cross-search for IoCs and related operations originating from agent working servers

Endpoints and Servers

Check web process lineage, sudo usage, mounts, plugin/file uploads, and timestamp modifications
Inspect NFS export configurations and the use of no_root_squash

Authentication and Cloud

Trace OTPs, admin logins, role assumptions, secret access, and Kubernetes modifications
Identify secrets accessible from compromised privileges within your organization and revoke/re-issue them. The figure of 46 secrets applies to a specific reported case.

Subsequent Operations

Verify WordPress/Magento lateral movement, S3/CDN tampering, database card data, and skimmer transmission destinations
Audit create and delete operations, including tables matching ZQ or Backup

Containment

Revert checkout distribution to a known good version and block external exfiltration
Isolate compromised hosts, update and revoke secrets, keys, and sessions
Minimize NFS, sudo, and cloud IAM permissions

Severity Classification

Categorize reconnaissance as contact, shell acquisition as initial execution, secret/card data acquisition as data theft, and skimmer deployment or database deletion as subsequent compromise

11. Defense and Detection Ideas

Single Events

Execution of sudo, mount, aws, or kubectl from web processes
Data transmission from checkout JavaScript to unknown domains
High-volume GetSecretValue calls in Secrets Manager within a short timeframe

Timeline Correlation

Correlate SQLi -> OTP read -> admin login -> file upload -> shell -> sudo -> secret access
Correlate checkout asset modification -> timestamp restoration -> external POST request

Threat Hunting

Search for the creation/deletion of tables whose names match the observed ZQ or Backup naming patterns, and check for identical skimmer code snippets across multiple distribution surfaces

Log Gaps

Gaps in CDN/S3 modification history, NFS logs, tag management, or checkout page observation records make identifying installation paths difficult

Priority Countermeasures

Management of external-facing public assets
Breaking the privilege chain
Automation of secret rotation and revocation
Integrity monitoring of checkout pages and application of CSP and SRI based on distribution pathways. Additional verification is required for authorized scripts or same-origin tampering.
Isolation of database backups

12. Facts / Inference / Hypothesis

Facts

Gambit based its findings on stolen data and tools recovered from attacker working servers, real-world site skimmers, agent reports, and execution logs. Some actions could not be independently verified and were evaluated alongside other corroborated records.
Between September 10 and 15, 2026, 105 attack projects were created, of which 48 were analyzable and 57 had been deleted. Gambit reported that at least 27 companies suffered varying degrees of compromise.
Hermes, Strix, and Cairn automated the attacks, but humans provided targets, objectives, and subsequent instructions. This does not imply completely human-free attacks.
Over 600,000 unexpired payment card records were stolen from two companies. Skimmer deployment was instructed for at least 27 named targets and confirmed in 19 instances. Separately, over 100 sites infected with related skimmers were found.
In one project, the recorded path progressed through SQL injection, OTP reading, file upload, sudo, NFS, WordPress, AWS Secrets Manager, Aurora, and Magento encryption keys. This path was not shared by all victims.
Estimated model API costs were $12,000 to $18,000 USD, with an average of $25.46 USD per target across 101 completed scans.
Evidence-removal instructions included payment database deletion, with one agent deleting 180 ZQ or Backup tables.
Gambit noted suspicious script distribution from a Japanese travel booking site as an example of a related skimmer.

Inference

Autonomous execution lowers the unit cost per target, enabling attackers to test long compromise chains and making medium-sized retailers—previously filtered out by human labor—viable targets.
Preserving agent dialogue, execution logs, and tool artifacts can help reconstruct not only individual vulnerabilities but also attacker objectives and automated decision-making processes.

Hypothesis

No additional hypotheses. Unverified items are listed under 'Gaps and Additional Research'.

13. MITRE ATT&CK Mapping

ID	Technique	Confidence	Basis
T1190	Exploit Public-Facing Application	high	Automated discovery and exploitation of pre-authentication SQL injections and other vulnerabilities.
T1548.003	Abuse Elevation Control Mechanism: Sudo and Sudo Caching	high	Privilege escalation abusing Python execution via sudo NOPASSWD. Distinct from vulnerability exploitation.
T1552.001	Unsecured Credentials: Credentials In Files	high	Retrieving credentials from configuration files such as wp-config.php.
T1078	Valid Accounts	high	Logging into administrative panels using OTPs and administrative credentials.
T1056.003	Input Capture: Web Portal Capture	high	Capturing card input via payment skimmers.
T1070.006	Indicator Removal: Timestomp	high	Restoring timestamps after file tampering.
T1485	Data Destruction	high	Destruction via database table deletion.
T1555.006	Credentials from Password Stores: Cloud Secrets Management Stores	high	Retrieving secrets from AWS Secrets Manager.

14. Gaps and Additional Research

Total number of victim organizations, industry sectors, and geographical distribution
Number of stolen cards among the 600,000+ that were actually used fraudulently
Operator attribution and modifications to the agent execution infrastructure
Initial intrusion vulnerabilities per target
Undisclosed skimmer collection endpoints

15. Impact on SOCs and Organizations

The intrusion paths shown by Gambit varied by victim, with multiple agents pursuing reconnaissance based on short human instructions. E-commerce and retail organizations must remove excessive privileges and restrict access between systems spanning web servers, operating systems, NFS shares, cloud environments, and payment assets, while correlating logs across each environment. Because a Japanese travel booking site was also included as an example of a related skimmer, verifying checkout page distribution sources and change histories remains a concrete investigation task.

16. Target Audience Summary

SOC

Integrate public web, host, cloud, and payment logs to detect multi-stage privilege chains and skimmer exfiltration.

Administrators

Segregate sudo, NFS, cloud secrets, and CDN permissions, and monitor payment assets for tampering.

End Users

Since tampering is difficult for users to spot independently, regularly review credit card statements and promptly report suspicious transactions, and follow notifications from merchants.