Context secrets exposed when project visibility changes to public

Question

Context secrets exposed when project visibility changes to public

Problem statement

CircleCI contexts allow sharing environment variables across projects, but the documentation does not clearly specify whether secrets stored in contexts remain accessible to users with read-only permissions when a project's visibility changes from private to public. This creates uncertainty about potential unintended exposure of sensitive credentials.

Relevant constraints

When a CircleCI project is made public, the pipeline configuration files are processed in plaintext, and any embedded secrets would be visible. However, contexts themselves have no built-in access control mechanism, meaning any user with project read access could potentially retrieve context variables. The concern is whether making a project public after secrets have been stored in contexts creates a window where those secrets become accessible to unauthorized users.

Specific questions

Does changing a project's visibility to public after storing secrets in contexts make those context secrets accessible to users who only have read permissions?
What is the exact behavior of CircleCI's permission system when project visibility and context usage intersect?
Is there any audit capability to track unauthorized access to context secrets after visibility changes?

Tasadduq Burney · Answer

Secret Exposure and Project Visibility
Changing a CircleCI project's visibility from private to public does not make the plaintext values of secrets stored in Contexts accessible to users with read-only permissions or the general public. Context variables are stored at the Organization level, not within the project repository or the project's specific configuration.

Behavioral Analysis
The risk of exposure is decoupled from project visibility due to how CircleCI handles environment injection:

Storage: Contexts are organizational entities. The values are stored in CircleCI's encrypted backend, separate from your git history and .circleci/config.yml.
  Injection: Secrets are injected into the build environment only at runtime. They are never written to the project configuration file.
  UI Access: Public read-only access to a project does not grant administrative access to the Organization's Context settings. A public user cannot navigate to the Context settings page to view the values of the variables.
  Log Masking: CircleCI automatically masks secrets in the job output. Even if a public project runs a pipeline using a Context, the secrets appear as *** in the logs.

Critical Risks and Mitigation
While the visibility change itself does not leak Context secrets, two specific vectors remain that you must verify before making a project public:

Git History: If secrets were committed to the repository in plaintext before being moved to a Context, those secrets are exposed the moment the project becomes public. Use a tool like trufflehog or git-filter-repo to scrub history.
  Execution-based Exfiltration: If a public project allows untrusted users to trigger builds (e.g., via Pull Request triggers) and those builds have access to a Context, a malicious actor could attempt to exfiltrate secrets by encoding them (e.g., Base64) to bypass masking and sending them to an external URL.

Verification Steps
To confirm your configuration is secure, perform these checks in a staging environment:

UI Check: Log out of your account or use an incognito window to view the public project. Verify that no Context values are visible in the project settings or pipeline logs.
  Log Audit: Run a pipeline and ensure that any command attempting to print the secret results in the masked *** output.

Diagnostic Detail Needed: Are you using Dynamic Config or Parameterization that might conditionally echo variables based on external inputs?

Context secrets exposed when project visibility changes to public