CVE-2026-40050 and the CrowdStrike LogScale Cluster API Path Traversal

ABSTRACT

CVE-2026-40050 is a critical unauthenticated path traversal in CrowdStrike LogScale that affects self-hosted deployments where a specific cluster API endpoint is reachable. CrowdStrike rates the issue 9.8 CVSS and describes a path that allows remote attackers to read arbitrary files from the server filesystem without prior authentication.

The technical significance goes beyond generic file disclosure. LogScale sits in a privileged observability position and commonly handles security telemetry, cloud integrations, service credentials, and internal cluster metadata. In practical terms, arbitrary file read against a logging platform can expose secrets that let an attacker move from observability infrastructure into broader control of the environment.

EXECUTIVE SUMMARY

CrowdStrike states that CVE-2026-40050 affects LogScale Self-Hosted GA versions 1.224.0 through 1.234.0 and LogScale Self-Hosted LTS versions 1.228.0 and 1.228.1. Fixed releases are 1.235.1+, 1.234.1+, 1.233.1+, and 1.228.2+ for the LTS branch. CrowdStrike also notes that Next-Gen SIEM customers are not affected and that SaaS customers received network-layer protections on April 7, 2026.

The vulnerability combines two dangerous properties at once: missing authentication for a critical function and insufficient restriction of path elements. NVD maps the issue to CWE-306 and CWE-22. That combination matters because it means an internet-exposed cluster API surface can become an unauthenticated arbitrary file read primitive against a system that often has privileged visibility into the rest of the enterprise.

CrowdStrike says it has no indication of in-the-wild exploitation and that the issue was discovered through internal product testing. Even so, defenders should treat this as urgent because exposed self-hosted LogScale nodes represent attractive targets, and the files accessible through traversal may include credentials, tokens, certificates, configuration, and sensitive log content.

AFFECTED CONDITIONS

• CrowdStrike LogScale Self-Hosted GA 1.224.0 through 1.234.0 inclusive are affected according to the vendor advisory.

• CrowdStrike LogScale Self-Hosted LTS 1.228.0 and 1.228.1 are affected.

• The vulnerable condition requires exposure of a specific cluster API endpoint. Internet-exposed or broadly reachable management surfaces materially increase risk.

• Next-Gen SIEM customers are not affected, and LogScale SaaS customers were mitigated by CrowdStrike at the network layer on April 7, 2026.

ROOT CAUSE AND ATTACK PATH

Public advisory material characterizes the flaw as an unauthenticated path traversal in a cluster API endpoint. In plain language, the server accepts user-controlled path material in a code path that should remain both authenticated and constrained to a safe directory boundary. When those controls fail together, attackers can coerce the application into resolving filesystem paths outside the intended directory scope.

For LogScale operators, the likely blast radius is shaped by deployment context. Self-hosted LogScale commonly runs with access to cluster configuration, identity material for upstream or downstream integrations, cached credentials for storage backends, and telemetry records from across the environment. Arbitrary read against that kind of host is not just a privacy issue; it can become a pivot into cloud accounts, SIEM pipelines, or internal management planes.

The exposure path is also strategically important because logging platforms often sit at a trust intersection. They ingest from many systems, connect outward to multiple services, and are assumed to be defensive infrastructure. That makes a seemingly read-only primitive more dangerous than the same bug in an isolated line-of-business application.

BUSINESS IMPACT

• Credential and secret disclosure: arbitrary file read can expose service-account tokens, TLS private keys, backend credentials, API tokens, or environment secrets present on the LogScale host or pod.

• Security visibility degradation: compromise of a logging tier can reveal alerting logic, retention settings, parser behavior, and investigative data that help an attacker evade detection.

• Cross-environment pivot risk: observability systems often hold trusted access into storage, cloud, and ticketing integrations that can be reused after file disclosure.

• Sensitive data exposure: the platform may contain customer logs, internal telemetry, and authentication artifacts that create both security and compliance consequences.

PUBLIC POC AND VALIDATION REFERENCES

Public weaponized exploit code does not appear to be broadly circulating at the time of this draft. Even so, defenders have several concrete public references that validate the issue, define scope, and help identify exposed systems quickly:

• CrowdStrike vendor advisory with affected and fixed version ranges: https://www.crowdstrike.com/en-us/security-advisories/cve-2026-40050/

• GitHub Advisory GHSA-q4qj-hj7m-7jgx, which tracks the issue publicly and records the 9.8 critical severity: https://github.com/advisories/GHSA-q4qj-hj7m-7jgx

• NVD record for CVE-2026-40050, including CWE-22 and CWE-306 mappings: https://nvd.nist.gov/vuln/detail/CVE-2026-40050

• runZero public guidance for finding potentially impacted LogScale services by their Humio server header: https://www.runzero.com/blog/crowdstrike-logscale/

• Security Affairs public reporting summarizing the disclosure and operational implications for self-hosted users: https://securityaffairs.com/191343/hacking/critical-bug-in-crowdstrike-logscale-let-attackers-access-files.html

The absence of a mainstream public exploit repository should not be read as safety. It mainly means defenders still have a narrow window where patching and attack-surface reduction can outrun broad commoditization.

ORIGINAL 0DAY INC LAB-ONLY POC A: CONTROLLED CANARY READ HARNESS

The first 0day Inc PoC is intentionally conservative. CrowdStrike does not publish the exact vulnerable cluster API path in the public advisory, so this harness is designed for authorized internal labs where the operator already has that endpoint detail from vendor support or private validation. It requests a harmless canary file such as /etc/hostname and captures the response for analysis. Use only on systems you own or are explicitly authorized to assess.

#!/usr/bin/env bash
set -euo pipefail

BASE_URL="${1:?usage: $0 https://logscale.lab}"
CLUSTER_API_PATH="${CLUSTER_API_PATH:?set the authorized lab-only cluster API path}"
QUERY_STRING="${QUERY_STRING:?set the full lab-approved query string for the read request}"
CANARY_FILE="${CANARY_FILE:-/etc/hostname}"
OUT="${OUT:-logscale-canary.out}"

echo "[*] Requesting harmless canary file: $CANARY_FILE"
echo "[*] Endpoint path: $CLUSTER_API_PATH"

curl -skS -D headers.txt \
  "${BASE_URL%/}${CLUSTER_API_PATH}?${QUERY_STRING}" \
  -o "$OUT"

echo "[*] Saved response headers to headers.txt"
echo "[*] Saved response body to $OUT"
file "$OUT" || true
sed -n "1,10p" "$OUT" || true

Interpretation: if an authorized lab reproduction returns the contents of a benign canary file without authentication, that is enough to confirm impact. There is no reason to escalate to sensitive targets once a harmless file read has been demonstrated.

ORIGINAL 0DAY INC LAB-ONLY POC B: SAFE INTERNET-EXPOSURE AND VERSION TRIAGE

The second 0day Inc PoC is a non-invasive exposure check. It fingerprints a LogScale service from the root path, extracts a version from the Humio server header when available, and compares it to the vendor-published affected ranges. This is useful for rapidly scoping external or internal attack surface before deeper validation.

#!/usr/bin/env bash
set -euo pipefail

BASE_URL="${1:?usage: $0 https://logscale.example}"
headers=$(mktemp)
body=$(mktemp)
trap "rm -f $headers $body" EXIT

curl -skS -D "$headers" -o "$body" "${BASE_URL%/}/" || true
server=$(awk -F": " "tolower($1)=="server" {gsub(/
/, "", $2); print $2}" "$headers" | tail -1)
echo "server_header=${server:-unknown}"

python3 - <<'PY' "$server"
import re, sys
server = sys.argv[1]
m = re.search(r"Humio-(\d+)\.(\d+)\.(\d+)", server or "")
if not m:
    print("[INFO] Unable to infer a LogScale version from the HTTP server header.")
    raise SystemExit(0)
version = tuple(map(int, m.groups()))
vuln = ((1,224,0) <= version <= (1,234,0)) or version in {(1,228,0), (1,228,1)}
print(f"detected_version={'.'.join(map(str, version))}")
print("[HIT] Version falls in the vendor-published vulnerable range" if vuln else "[OK] Version is outside the published vulnerable range")
PY

Interpretation: a positive hit means the service appears to be LogScale and falls within the vendor-published vulnerable range. Even if the exact cluster API endpoint is not exposed externally, that result should trigger immediate patch planning and access review.

DETECTION AND HUNTING

• Inspect reverse-proxy, load-balancer, WAF, and application logs for unauthenticated requests to cluster API paths that contain ../, %2e%2e%2f, or other traversal patterns.

• Look for direct exposure of LogScale management or cluster surfaces to untrusted networks. The vendor advisory specifically ties exploitation risk to an exposed cluster endpoint.

• If running on Kubernetes, review whether pods mount service-account tokens, secrets, or certificates that would be high-value if arbitrary file read were achieved.

• Hunt for suspicious requests originating from internet-facing addresses shortly before unusual access to configuration, key, or token files on the LogScale host.

• Use asset-discovery tooling such as the runZero query for Humio-prefixed HTTP server headers to locate forgotten or secondary LogScale deployments.

MITIGATION PRIORITIES

• Upgrade immediately to a fixed build: 1.235.1+, 1.234.1+, 1.233.1+, or 1.228.2+ for the LTS branch, depending on your deployed series.

• Restrict cluster and management endpoints to trusted administration networks only. If the vulnerable endpoint is not exposed, the attack surface drops sharply.

• Place reverse-proxy or WAF controls in front of any unavoidable externally reachable LogScale surface and alert on traversal patterns.

• Review the host or pod for sensitive local files and assume those artifacts are potentially exposed if the instance remained internet reachable while vulnerable.

• Rotate any credentials, tokens, or certificates stored on or reachable from affected nodes when exposure is suspected.

REFERENCES

• CrowdStrike advisory: https://www.crowdstrike.com/en-us/security-advisories/cve-2026-40050/

• GitHub Advisory GHSA-q4qj-hj7m-7jgx: https://github.com/advisories/GHSA-q4qj-hj7m-7jgx

• NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-40050

• CVE.org record: https://www.cve.org/CVERecord?id=CVE-2026-40050

• runZero exposure-management note: https://www.runzero.com/blog/crowdstrike-logscale/

• Security Affairs reporting: https://securityaffairs.com/191343/hacking/critical-bug-in-crowdstrike-logscale-let-attackers-access-files.html

Bottom line: CVE-2026-40050 is a critical reminder that observability infrastructure is security-critical infrastructure. A read-only primitive against a self-hosted LogScale cluster can expose the exact secrets and context an attacker needs to widen an intrusion, so defenders should treat exposed vulnerable builds as emergency patch-and-contain work.