CVE-2026-40050: Unauthenticated file read in self-hosted LogScale clusters

What it is

LogScale nodes talk to each other through a cluster API. On affected self-hosted versions, one endpoint of that API had no authentication and didn’t restrict file paths. Anyone who could reach it could read any file the LogScale process can read.

CrowdStrike scores it 9.8 (critical). It found the bug in internal testing, and no public exploit or exploitation has been reported. No public source names the endpoint either, which slows attackers down but doesn’t make it safe to wait.

Why file read is serious on a log server: LogScale holds the logs you rely on for detection, often including sensitive data. Its configuration and environment files can also contain credentials, for example for Kafka, object storage buckets or your identity provider. One file read can turn into access to much more.

Am I affected?

Only if you run LogScale Self-Hosted on an affected version:

• GA releases 1.224.0 to 1.234.0. The CVE record also lists 1.235.0, so treat it as affected.
• LTS 1.228.0 and 1.228.1.

You’re not affected if you use:

• LogScale SaaS: CrowdStrike blocked the endpoint on all SaaS clusters on 7 April 2026.
• Falcon Next-Gen SIEM: not affected at all.

Real-world risk depends on who can reach your LogScale nodes. A cluster whose nodes are reachable only from a few internal systems is much harder to attack than one with nodes exposed to user networks or the internet.

What to do

1. Upgrade to 1.233.1, 1.234.1, 1.235.1 or later, or 1.228.2 on the LTS line. CrowdStrike expects no performance impact from the fix.

2. Restrict network access to the nodes, whether or not you’ve upgraded yet. CrowdStrike’s advisory gives no workaround for self-hosted clusters, but the SaaS fix was a network-level block, which shows the approach. In practice:

• Allow node-to-node traffic only between cluster members.
• Expose only the user-facing UI and ingest endpoints, through a reverse proxy or load balancer where you can.
• Keep LogScale nodes off the internet.

3. If nodes were reachable from untrusted networks while vulnerable, review access logs (below). Consider rotating the secrets stored in LogScale’s configuration: storage keys, Kafka credentials and identity-provider secrets.

Detection

No indicators of compromise have been published. Look for:

• Path traversal in requests to LogScale nodes: ../, %2e%2e or double-encoded variants in URLs, especially toward API paths, in your reverse proxy, load balancer or WAF logs.
• Unauthenticated API requests from addresses that aren’t cluster members. Node-to-node API traffic should only come from other nodes.
• Reads of sensitive files on LogScale hosts, if you monitor file access with an EDR (the Falcon sensor, for example) or auditd. Configuration files, environment files and /etc/passwd-style reads by the LogScale process are worth alerting on.