## 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 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: 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.
## 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 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: 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.
Update com.linecorp.armeria:armeria-xds to 1.40.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanArmeria: External Control of File Name or Path in xDS SDS DataSource affects com.linecorp.armeria:armeria-xds (maven). Severity is medium. ## 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 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: 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.
AI coding agents often install or upgrade packages automatically in maven. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| com.linecorp.armeria:armeria-xdsmaven | <1.40.0 | 1.40.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate com.linecorp.armeria:armeria-xds to 1.40.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanArmeria: External Control of File Name or Path in xDS SDS DataSource affects com.linecorp.armeria:armeria-xds (maven). Severity is medium. ## 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 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: 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.
AI coding agents often install or upgrade packages automatically in maven. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| com.linecorp.armeria:armeria-xdsmaven | <1.40.0 | 1.40.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard