GHSA-HGW6-8C77-V4GQ

Vulnerability from github – Published: 2026-06-18 17:22 – Updated: 2026-06-18 17:22
VLAI
Summary
Armeria: External Control of File Name or Path in xDS SDS DataSource
Details

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.
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.linecorp.armeria:armeria-xds"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.40.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-11752"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-73"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-18T17:22:17Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## External Control of File Name or Path in xDS SDS DataSource\n\n### Summary\n\n`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.\n\n**Affected component:** `xds/src/main/java/com/linecorp/armeria/xds/DataSourceStream.java`\n**Introduced in:** Armeria 1.38.0 (commit `b199560b10`, \"Add support for SDS\", #6597)\n**Affected versions:** 1.38.0, 1.39.0\n\n### Impact\n\nA semi-trusted or compromised xDS control plane (or an attacker who can inject/MITM SDS responses) can:\n\n- **Read arbitrary files** on the xDS client host \u2014 TLS private keys, `/etc/passwd`, mounted Kubernetes service-account tokens, cloud credential files, etc.\n- **Read arbitrary environment variables** \u2014 `AWS_SECRET_ACCESS_KEY`, CI tokens, database credentials, etc.\n\nThe 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.\n\n**Severity:** High \u2014 arbitrary host-level file and environment variable read via control-plane-pushed configuration.\n\n### Patches\n\n1.40.0\n\nThe fix should:\n\n1. **Confine `filename` resolution** to an operator-configured allow-list of base directories. After normalization, reject any path that escapes the allow-listed root.\n2. **Gate `environment_variable`** behind an explicit operator allow-list of permitted variable names.\n3. **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.\n4. **Document the trust model** clearly so operators understand that enabling file/env DataSources grants the control plane host-level read capability.\n\n### Workarounds\n\n- Ensure the xDS control plane channel is authenticated and encrypted (mTLS) to prevent MITM injection of malicious SDS responses.\n- Run the xDS client with minimal filesystem permissions and a restricted environment to limit the blast radius of arbitrary reads.\n- 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.",
  "id": "GHSA-hgw6-8c77-v4gq",
  "modified": "2026-06-18T17:22:17Z",
  "published": "2026-06-18T17:22:17Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/line/armeria/security/advisories/GHSA-hgw6-8c77-v4gq"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/line/armeria"
    },
    {
      "type": "WEB",
      "url": "https://github.com/line/armeria/security/advisories/xds/src/main/java/com/linecorp/armeria/xds/DataSourceStream.java"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:H/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Armeria: External Control of File Name or Path in xDS SDS DataSource"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…