Vulnerability Database

351,760

Total vulnerabilities in the database

CVE-2026-11752 — com.linecorp.armeria / armeria-xds

External Control of File Name or Path

External Control of File Name or Path in xDS SDS DataSource

Summary

DataSourceStream in the :xds module resolves control-plane-supplied filename and environment_variable fields from SDS Secret resources without any allow-list or base-directory confinement. A semi-trusted or compromised xDS control plane (or an attacker who can MITM SDS responses) can read arbitrary local files and environment variables on the xDS client host.

Affected component: xds/src/main/java/com/linecorp/armeria/xds/DataSourceStream.java Introduced in: Armeria 1.38.0 (commit b199560b10, "Add support for SDS", #6597) Affected versions: 1.38.0, 1.39.0

Impact

A semi-trusted or compromised xDS control plane (or an attacker who can inject/MITM SDS responses) can:

  • Read arbitrary files on the xDS client host — TLS private keys, /etc/passwd, mounted Kubernetes service-account tokens, cloud credential files, etc.
  • Read arbitrary environment variablesAWS_SECRET_ACCESS_KEY, CI tokens, database credentials, etc.

The read bytes are consumed as TLS key/cert/CA material. Combined with CWE-295 (silent disabling of upstream TLS peer verification), the exfiltrated secret can be presented to an attacker-chosen upstream, enabling data exfiltration. This is a confused-deputy / information-disclosure primitive driven entirely by control-plane-supplied configuration.

Severity: High — arbitrary host-level file and environment variable read via control-plane-pushed configuration.

Patches

1.40.0

The fix should:

  1. Confine filename resolution to an operator-configured allow-list of base directories. After normalization, reject any path that escapes the allow-listed root.
  2. Gate environment_variable behind an explicit operator allow-list of permitted variable names.
  3. Default to denying both filename and environment_variable DataSources for control-plane-delivered (SDS) secrets unless explicitly enabled by the operator. This is stricter than upstream Envoy but appropriate when the control plane is not fully trusted.
  4. Document the trust model clearly so operators understand that enabling file/env DataSources grants the control plane host-level read capability.

Workarounds

  • Ensure the xDS control plane channel is authenticated and encrypted (mTLS) to prevent MITM injection of malicious SDS responses.
  • Run the xDS client with minimal filesystem permissions and a restricted environment to limit the blast radius of arbitrary reads.
  • If SDS file-based secrets are not needed, consider using inline DataSource bytes only (delivered over the SDS stream itself) and auditing control-plane configurations to ensure no filename or environment_variable DataSources are present.

No technical information available.

CWEs:

Frequently Asked Questions

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.