Armeria: External Control of File Name or Path in xDS SDS DataSourceGHSA-hgw6-8c77-v4gq
GHSA-hgw6-8c77-v4gq is a security vulnerability in com.linecorp.armeria:armeria-xds. A fix is available for com.linecorp.armeria:armeria-xds — see the affected versions and patch details below.
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-hgw6-8c77-v4gq.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
com.linecorp.armeria:armeria-xdsReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
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:
- 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 Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | com.linecorp.armeria:armeria-xds | all versions | 1.40.0com.linecorp.armeria:armeria-xds:1.40.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for com.linecorp.armeria:armeria-xds, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update com.linecorp.armeria:armeria-xds to 1.40.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-hgw6-8c77-v4gq is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
Frequently Asked Questions
Is GHSA-hgw6-8c77-v4gq in your dependencies?
Find it across Maven, including transitive dependencies.