You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The /prpc/Kms.GetPublicKey endpoint in dstack/kms/src/main_service.rs returns the KMS root public key without requiring any authentication, allowing any network client to retrieve it.
Root Cause
The get_app_env_encrypt_pub_key endpoint returns app-specific encryption public keys without requiring any authentication (no mTLS, no admin token, no attestation). While the returned key is a public key (not a secret), the endpoint allows unauthenticated callers to enumerate valid app_id values by observing which requests return keys versus errors.
Attack Path
Attacker discovers the KMS endpoint
Attacker calls get_app_env_encrypt_pub_key with various app_id values
Attacker builds a list of all active applications registered with the KMS
This information can be used to target specific applications in subsequent attacks
Impact
Information disclosure — an attacker can enumerate all registered application IDs. This is low severity because app_ids may not be secret, and the returned public keys are not sensitive. However, the enumeration provides reconnaissance value for targeted attacks against specific applications.
Suggested Fix
Require at minimum mTLS authentication for this endpoint, or return a consistent response (e.g., a dummy public key) for both valid and invalid app_ids to prevent enumeration.
Note: This issue was created automatically. The vulnerability report was generated by Claude and has not been verified by a human.
Thanks for the detailed report and for writing up the attack path.
You are right that GetAppEnvEncryptPubKey (exposed over /prpc/GetAppEnvEncryptPubKey) does not require mTLS or an attested client. This is intentional. As described in kms/README.md, this RPC is called by the control‑plane frontend when a user configures environment variables for an app. At that point the app is not yet running inside a TEE, so there is no attested identity we could authenticate against, and the only thing the RPC returns is an X25519 public key that untrusted tooling can use to encrypt data which only the in‑TEE app will later be able to decrypt.
We also do not treat either the KMS CA public key or the app_id as secrets. The CA public key is meant to be widely distributed as a trust anchor, and app_ids are already visible in on‑chain state and deployment artifacts.
Regarding enumeration: in practice this endpoint cannot realistically be used to "enumerate apps". It requires the caller to already know the exact app_id value (a 32‑byte identifier); there is no list operation or low‑entropy namespace that would make brute‑force probing feasible. Independently of this RPC, deployed apps are inherently enumerable from the blockchain and other deployment metadata, so the mere existence of an app is not something we rely on as confidential.
Given that, we don't see GetAppEnvEncryptPubKey as adding new enumeration surface beyond what is already visible in the rest of the system. The endpoint remains intentionally unauthenticated so that untrusted tooling can obtain a public encryption key for bootstrap, while all sensitive key‑bearing operations (GetAppKey, SignCert, etc.) stay behind attestation and authorization checks.
We agree that hardening measures like making responses for non‑existent app_ids indistinguishable, or allowing deployments to require mTLS for this RPC when KMS is exposed beyond the control plane, could be reasonable options in more restrictive environments and we'll keep them in mind for future revisions of the KMS public surface.
Thanks again for taking the time to look at this and for the helpful write‑up.
Disposition: not a production vulnerability. The RPC returns a public encryption key before an app has an attested identity, and app_id is not treated as secret. No code fix is planned for this report under the documented production threat model.
Activity
kvinwang commentedon Mar 25, 2026
Thanks for the detailed report and for writing up the attack path.
You are right that
GetAppEnvEncryptPubKey(exposed over/prpc/GetAppEnvEncryptPubKey) does not require mTLS or an attested client. This is intentional. As described inkms/README.md, this RPC is called by the control‑plane frontend when a user configures environment variables for an app. At that point the app is not yet running inside a TEE, so there is no attested identity we could authenticate against, and the only thing the RPC returns is an X25519 public key that untrusted tooling can use to encrypt data which only the in‑TEE app will later be able to decrypt.We also do not treat either the KMS CA public key or the
app_idas secrets. The CA public key is meant to be widely distributed as a trust anchor, andapp_ids are already visible in on‑chain state and deployment artifacts.Regarding enumeration: in practice this endpoint cannot realistically be used to "enumerate apps". It requires the caller to already know the exact
app_idvalue (a 32‑byte identifier); there is no list operation or low‑entropy namespace that would make brute‑force probing feasible. Independently of this RPC, deployed apps are inherently enumerable from the blockchain and other deployment metadata, so the mere existence of an app is not something we rely on as confidential.Given that, we don't see
GetAppEnvEncryptPubKeyas adding new enumeration surface beyond what is already visible in the rest of the system. The endpoint remains intentionally unauthenticated so that untrusted tooling can obtain a public encryption key for bootstrap, while all sensitive key‑bearing operations (GetAppKey,SignCert, etc.) stay behind attestation and authorization checks.We agree that hardening measures like making responses for non‑existent
app_ids indistinguishable, or allowing deployments to require mTLS for this RPC when KMS is exposed beyond the control plane, could be reasonable options in more restrictive environments and we'll keep them in mind for future revisions of the KMS public surface.Thanks again for taking the time to look at this and for the helpful write‑up.
h4x3rotab commentedon Jun 30, 2026
Maintainer triage update: this is recorded in the public security report table: https://github.com/Dstack-TEE/dstack/blob/master/docs/security/public-security-reports.md#public-reports-and-findings
Disposition: not a production vulnerability. The RPC returns a public encryption key before an app has an attested identity, and
app_idis not treated as secret. No code fix is planned for this report under the documented production threat model.Closing as not planned.