Summary
A template placeholder handling flaw in Wings allows low-privileged users to read sensitive daemon configuration values through egg configuration-file templates.
Under specific template conditions, users can access tokens and registry configuration that should remain private, significantly increasing the risk of further compromise.
Affected context
The vulnerability appears in Wings deployments that use egg configuration-file templates containing {{config.}} placeholders.
It becomes relevant when untrusted or low-privileged panel users can create or modify egg templates or configurations that are later rendered using server-side configuration data.
In these situations, the templating mechanism may inadvertently expose daemon-level secrets such as config.token, config.token_id, and Docker registry entries to users who should not see them.
Exploit preconditions
- Attack surface: Egg configuration-file templating within Wings.
- Required access: A low-privileged account with the ability to create, edit, or apply egg configuration templates or related configuration files.
- Trigger point: Rendering of a template that includes
{{config.}}placeholders tied to daemon configuration values. - Why exploitation is possible: The template engine allows direct interpolation of internal daemon configuration keys into files visible to non-privileged users, breaching the intended separation between panel-managed config and daemon-only secrets.
Why this happens
The core issue is an overly permissive configuration templating mechanism that does not adequately distinguish between safe and sensitive configuration keys when resolving {{config.}} placeholders.
This maps to CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, as confidential daemon settings become accessible through a user-controllable template channel.
It is also related to CWE-522: Insufficiently Protected Credentials, because security-sensitive tokens and registry information are treated as ordinary configuration data instead of being segregated and shielded from template-based disclosure.
Potential impact
- Low-privileged users may read daemon authentication tokens (
config.token,config.token_id). - Attackers could obtain Docker registry credentials or configuration entries from
config.docker.registries. - Compromised tokens can be used to impersonate the daemon or access protected APIs and infrastructure.
- Exposed registry configuration can aid in supply-chain attacks or unauthorized image pulls and modifications.
- Subsequent privilege escalation or lateral movement within the hosting environment can occur if leaked secrets are reused elsewhere.
General mitigation guidance
Effective mitigation centers on reducing the trust boundary of configuration templating and segregating secrets from user-exposed configuration flows.
Common defensive patterns include:
- Restricting template placeholders so that only a curated set of non-sensitive configuration keys can be referenced from egg templates.
- Separating secret material (tokens, registry credentials, API keys) from general daemon configuration and storing them in dedicated secret stores or environment-level facilities that are never interpolated into user-managed templates.
- Implementing strict validation and linting of egg templates so that any attempt to access sensitive
config.paths is rejected early. - Designing defaults such that configuration rendering runs under least privilege and avoids emitting internal daemon state into files that are returned to or editable by panel users.
How teams detect issues like this
Organizations can detect similar vulnerabilities by:
- Reviewing template rendering code paths for access to global or daemon configuration objects, especially any functionality that allows user-controlled placeholders to resolve against internal config trees.
- Applying static analysis rules or pattern-based checks that flag template expressions referencing sensitive namespaces (e.g.,
config.token,config.docker.registries, or other credential-like fields). - Enforcing code review policies that require explicit whitelisting of configuration keys usable in templates and highlight any new link between user-managed templates and secret-bearing config structures.
- Using security-focused linters or automated review tools that understand templating engines and can warn when secrets or tokens are reachable from untrusted template contexts.
