GHSA-HGW6-8C77-V4GQ
Vulnerability from github – Published: 2026-06-18 17:22 – Updated: 2026-06-18 17:22External 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 variables —
AWS_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:
- Confine
filenameresolution to an operator-configured allow-list of base directories. After normalization, reject any path that escapes the allow-listed root. - Gate
environment_variablebehind an explicit operator allow-list of permitted variable names. - Default to denying both
filenameandenvironment_variableDataSources 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. - 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
DataSourcebytes only (delivered over the SDS stream itself) and auditing control-plane configurations to ensure nofilenameorenvironment_variableDataSources are present.
{
"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"
}
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.