CVE-2026-48105

Executive Summary

CVE-2026-48105 is a path traversal vulnerability (CWE-22) in Arc Enterprise, an open-source SQL-native time-series database for telemetry. The flaw resides in the Raft consensus FSM's manifest-registration handler, which accepts attacker-chosen file paths without validating them against the configured storage backend, allowing a malicious cluster peer to register arbitrary paths. Successful exploitation can lead to path traversal — reading or writing files outside the intended storage backend, including local filesystem paths or unintended S3 buckets — with potential data exfiltration or manipulation of the time-series database. The vulnerability is patched in version 26.06.1, but details regarding the affected system's patch status indicate that many deployments may remain unpatched.

Technical Analysis

The vulnerability exists in Arc Enterprise's internal clustering subsystem that implements the Raft consensus protocol for distributed state management. Specifically, the Raft-based Filesystem State Machine (FSM) processes proposals from cluster peers to register manifests. The affected code path is located in internal/cluster/raft/fsm.go within the applyRegisterFile function, which handles the application of manifest-registration proposals received via the Raft log.

The core flaw is the absence of path validation on the file path proposed by a cluster peer. The only check performed is that the provided path is non-empty — no other validation exists. Specifically, the code does NOT:

1. Reject parent traversal sequences — There is no rejection of .. sequences, allowing paths like ../../etc/passwd or ../../../var/lib/telemetry to be accepted.
2. Enforce an allowlist of legitimate prefixes — No check ensures the path begins with the configured storage backend root directory.
3. Restrict the URL scheme — No validation of the URI scheme, meaning both local filesystem paths (/var/lib/arc/...) and remote storage URIs (s3://bucket/prefix/...) are accepted without differentiation. An attacker can specify file:///etc/cron.d/... or any arbitrary s3 bucket URI.
4. Enforce a length bound — No maximum path length restriction is imposed, enabling potential length-based overflows (though the more immediate risk is traversal).

In a Raft consensus system, proposals are replicated across all cluster members and each member applies the same state machine transitions deterministically. When a compromised or malicious Raft peer submits a manifest-registration proposal containing a crafted path, all other cluster members will process and "apply" that registration during the FSM's applyRegisterFile execution. This means the impact propagates automatically to every node in the cluster without requiring individual per-node exploitation.

The vulnerability is classified as CWE-22 (Path Traversal), and the attack vector is network-based, requiring low privileges (a valid Raft peer or the ability to inject a proposal into the consensus stream). The scope is changed (S:C in CVSS), meaning a vulnerability in one cluster node can impact resources beyond its intended security scope — e.g., reading files from the host filesystem of other cluster members or accessing S3 buckets not intended for telemetry storage.

Exploitation Scenarios

The following attack chain describes exploitation at the vulnerability-class level. No public PoC exists at the time of writing, and no specific exploit code has been observed in the wild; the attack chain is inferred from the vulnerability class and the NVD description.

Step 1: Reconnaissance / Target Identification An attacker identifies Arc Enterprise clusters exposed on the network. Shodan or similar search engines can index instances of Arc Enterprise, particularly those with cluster mode enabled and unauthenticated or weakly-authenticated Raft peer communication. Restricting cluster network access to known-trusted peers (via firewall rules) is the documented workaround, implying that some deployments may expose their Raft ports to a broader network than intended.

Step 2: Triggering the Flaw The attacker must gain the ability to submit a manifest-registration proposal to the Raft cluster. This could occur through:

• A compromised or malicious Raft peer joining the cluster.
• An unauthenticated Raft endpoint (if the deployment has not properly restricted access).
• SOCKS/proxy-based lateral movement from a compromised host inside the trusted network.

Once achieved, the attacker crafts a manifest-registration proposal with a malicious file path — e.g., ../../../../etc/shadow, ../../var/lib/arc/../../../../tmp/evil.sh, or a path without any traversal but pointing to an unintended storage location such as s3://attacker-bucket/exfil or file:///tmp/attacker_controlled_path.

Step 3: Payload / Execution Method At the vulnerability-class level, path traversal allows the attacker to:

• Read arbitrary files from the filesystem by registering a manifest that references a path outside the configured storage root (e.g., /etc/passwd, /etc/shadow, configuration files containing secrets or credentials).
• Write arbitrary files if the applyRegisterFile operation performs file creation/symlink operations, potentially enabling arbitrary file write to sensitive locations (e.g., crontab files, SSH authorized_keys, or web root directories).

The exact impact of reading vs. writing depends on how the registered manifest path is subsequently used. If the manifest file is later read by other components (e.g., during data retrieval queries), a traversal path could cause the database to serve the contents of arbitrary local files to query results, granting an unauthenticated read primitive. If the manifest triggers file creation, it could write attacker-controlled content to arbitrary paths.

Step 4: Post-Exploitation Impact Successful exploitation results in:

• Data exfiltration: Sensitive host files, OS credentials, database configuration, or telemetry data from unintended S3 buckets.
• Data manipulation: Writing malicious files to the host filesystem.
• Cluster-wide propagation: Since Raft replicates state across all peers, every node in the cluster may attempt to apply the malicious registration, expanding the blast radius to all members.

The documented workaround — auditing the cluster manifest for unexpected paths (any path not matching the configured storage backend root is suspect) — indicates that the impact is observable via cluster manifest inspection and that successful exploitation results in persistent, visible records in the cluster state.

Impact Assessment

Business Impact: The vulnerability enables path traversal with the potential for arbitrary file disclosure and, in some scenarios, file modification. Given that telemetry databases often hold operational data, configuration snapshots, and sometimes embedded credentials for downstream systems, data leakage could expose sensitive infrastructure details. Furthermore, if file-write capability is achieved, an attacker could establish persistence or pivot to surrounding infrastructure.

Affected Systems: Arc Enterprise deployments running cluster mode with Raft-based consensus are affected. Any environment that has not yet upgraded to version 26.06.1 is at risk. Enterprises using Arc for critical infrastructure telemetry (cloud observability, industrial IoT, network monitoring) are the most likely targets.

Blast Radius: High — the Raft replication mechanism amplifies the impact across all cluster nodes. The CVSS scope is "Changed" (S:C), meaning the impact extends beyond the vulnerable component to the underlying host and potentially adjacent systems. The confidentiality impact is High (C:H) due to the potential for arbitrary file disclosure; integrity and availability impacts are not explicitly disclosed in the NVD data and should be considered Unknown (or at CVE discretion).

CVSS Context: The available CVSS data indicates N/A (not formally scored), but the described vulnerability class and the changed scope suggest a Severe to Critical severity (estimated in-scope values: AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N). This rating is a provisional estimate; organizations should treat this as critical until a formal score is available.

The vulnerability is unpatched in production for all versions prior to 26.06.1, with no evidence of exploit-in-the-wild detected to date, but the exploitability and impact profile makes active exploitation highly likely once clusters are exposed.

Detection Guidance

Sigma Rule

title: Arc Enterprise Raft Manifest Path Traversal Attempt
id: 7f3c9e2a-1b5d-4a6e-9c0f-2d4a8b61e0aa
status: experimental
description: Detects suspicious manifest-registration proposals in Arc Enterprise Raft FSM that contain path traversal sequences or unexpected URI schemes
author: Valtersit Threat Intelligence
date: 2026/01/15
references:
    - CVE-2026-48105
logsource:
    category: application
    product: arc_enterprise
detection:
    selection_traversal:
        message|contains:
            - '..'
            - '..%2f'
            - '..%5c'
    selection_scheme:
        message|contains:
            - 'file://'
            - 's3://'
    selection_empty:
        path|contains: 'applyRegisterFile'
    condition: selection_empty and (selection_traversal or selection_scheme)
falsepositives:
    - Legitimate use of s3:// URIs if configured (normalized to match storage backend root)
    - Paths with '..' inside a benign filename (rare)
level: high
tags:
    - attack.t1190
    - cve.2026-48105
    - cwe.22

YARA Rule

rule CVE_2026_48105_Arc_Raft_Path_Traversal
{
    meta:
        author = "Valtersit Threat Intelligence"
        date = "2026/01/15"
        description = "Detects path traversal patterns in Raft FSM manifest proposal logs for Arc Enterprise"
        cve = "CVE-2026-48105"
        cwe = "22"
        reference = "internal/cluster/raft/fsm.go"
    strings:
        $fsm = "applyRegisterFile" ascii wide nocase
        $traversal = "..\\" ascii
        $traversal_forward = "../" ascii
        $traversal_encoded = "%2e%2e" ascii wide
        $scheme_file = "file://" ascii wide nocase
        $scheme_s3 = "s3://" ascii wide nocase
    condition:
        $fsm and any of ($traversal*) and any of ($scheme*)
}

Suricata IDS Rule

alert tcp any any -> $HOME_NET any (msg:"CVE-2026-48105 - Arc Raft Manifest Path Traversal"; flow:established,to_server; content:"applyRegisterFile"; nocase; content:".."; http_uri; pcre:"/(\.\.\/|\.\.\\)/"; sid:2026480105; rev:1; reference:cve,2026-48105; classtype:attempted-admin; metadata:created_at 2026_01_15;)

Note: This rule assumes the Raft proposal is transmitted over HTTP or can be pattern-matched as a text protocol. If the Raft protocol uses a binary or non-HTTP transport, adjust the scope from http_uri to content with depth boundaries after determining the exact wire format.

Elastic Detection

sequence by host.name with maxspan=5m
  [ network where event.action == "connection_attempted" and destination.port in (2379, 2380) and
    network.direction == "inbound" and
    source.ip != "127.0.0.1" and source.ip not in ("10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16") ]
  [ process where event.action == "exec" and process.name == "arc" and
    process.args : ("*..*", "*s3://*", "*file://*") ]

Note: This EQL rule assumes Raft peers communicate on ports 2379/2380 (etcd defaults; adjust to the actual ports used by Arc's Raft implementation). Since the exact port is not disclosed in the NVD description, validate and adjust port numbers based on your deployment's configuration.

Splunk SPL Query

index=arc_enterprise sourcetype=arc_cluster 
| WHERE message LIKE "%applyRegisterFile%" 
| WHERE (message LIKE "%..%" OR message LIKE "%s3://%" OR message LIKE "%file://%") 
| WHERE NOT message LIKE "%backend_root=/var/lib/arc%"
| table _time, host, src_ip, message 
| sort _time desc

Wazuh OSSEC Rule

<group name="arc_enterprise,">
  <rule id="966738" level="12">
    <decoded_as>json</decoded_as>
    <field name="log_type">^rac_raft_proposal$</field>
    <regex>\.\.\/|\.\.\\|\.\.%2f|\.\.%5c|s3:\/\/|file:\/\/</regex>
    <description>CVE-2026-48105 - Path traversal attempt in Arc Enterprise Raft manifest registration</description>
    <group>attack.t1190,cve.2026-48105,</group>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
</group>

Note: Adjust the log_type field name and event format to match your Wazuh log parsing configuration for Arc Enterprise logs.

Mitigation & Patch Guidance

Patch Confidence: 0/4 — UNPATCHED. No patch evidence is available from any tracked source, and the vendor-provided fix (version 26.06.1) is the only remediation path. There is no vendor advisory publicly linked, no CVE-specific patch commit identified, and no OSV package data available.

1) Immediate Mitigations (until patched)

• Restrict cluster network access: Implement strict firewall rules to restrict Raft peer communication to only known-trusted peers. This is the vendor-recommended workaround and directly reduces the attacker's ability to inject malicious proposals into the consensus stream.
• Disable cluster mode: If clustering is not critical to your deployment, disable cluster mode entirely until the fix can be applied. This removes the Raft attack surface altogether.
• Audit cluster manifests: Manually inspect the cluster manifest for unexpected paths. Any path not matching the configured storage backend root should be treated as a possible indicator of compromise. This is the second vendor-recommended workaround.
• Monitor for unusual S3 or local file references: Any manifest entry referencing s3:// URIs outside your storage bucket policy, or local paths with .. sequences, should trigger immediate investigation.
• Limit lateral movement: Since exploitation requires either a compromised peer or network access to the Raft port, ensure that credentials and network segmentation prevent initial access from achieving the privilege needed to join the cluster.

2) Patch / Upgrade Steps

• Immediately plan an upgrade to Arc Enterprise version 26.06.1 as soon as the upgrade package is available from your distribution channel.
• Review your current version; if you are running any version prior to 26.06.1, assume you are vulnerable.
• Contact the Arc vendor support for the official patch advisory — at the time of this writing, no public advisory URL is known, so verify patch availability through your support channel.
• After upgrading, verify the FSM now performs path validation (check internal/cluster/raft/fsm.go or the equivalent in the fixed version for added validation).

3) Long-Term Hardening

• Implement network-level ACLs: Ensure that Raft communication (even between trusted peers) is encapsulated on a dedicated management VLAN or encrypted tunnel (e.g., WireGuard, IPsec) that is inaccessible from production user networks.
• Add mutual TLS (mTLS) to the cluster communication channel to ensure only authenticated Raft peers can submit proposals. Confirm whether Arc supports mTLS for cluster traffic; if so, enable it.
• Establish baseline validation: If possible, deploy a lightweight web application firewall or API gateway in front of the Raft endpoints to enforce path-pattern allowlists and reject traversal sequences at the network layer (defense-in-depth).
• Disable cluster mode in edge/remote sites where telemetry data does not require distributed consensus.
• Implement log aggregation and alerting for cluster manifest changes so all future registration events are visible to the SOC.

References

1. NVD Entry — https://nvd.nist.gov/vuln/detail/CVE-2026-48105 (Official NVD database entry; note: the NVD may not yet reflect a published patch or scoring data.)
2. GitHub / Vendor Source (Implicit) — The affected source file is referenced as internal/cluster/raft/fsm.go in the NVD description; consult the Arc GitHub repository (at the vendor's official location) for the fix commit associated with version 26.06.1, if/when released.
3. CWE-22 – Path Traversal — https://cwe.mitre.org/data/definitions/22.html (Reference for the weakness class to inform detection and testing.)
4. MITRE ATT&CK – T1190 — https://attack.mitre.org/techniques/T1190/ (Exploit Public-Facing Application technique category applicable to this vulnerability.)

Threat Actor Activity / Exploitation Evidence: As of the data provided, there is no public exploit code, no Nuclei template, no evidence of exploitation in the wild, and the candidate is not listed in CISA KEV. The EPSS score has not yet been published by FIRST.org. All exploitation scenarios documented above are inferred from the vulnerability class and the NVD description; no real-world campaigns have been observed at the time of writing.