41+ secrets in public GitHub repos (AWS key, admin tokens, TLS keys)

• Severity: High (Critical-adjacent — depends on whether leaked secrets are still live)
• CVSS 3.1: AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:L → 9.3 if any leaked secret is still valid; 6.5 if all are rotated
• CWE: CWE-798 (Use of Hard-coded Credentials), CWE-540 (Inclusion of Sensitive Information in Source Code), CWE-200
• Asset: github.com/corezoid/helm (PUBLIC), github.com/corezoid/corezoid_ansible_roles (PUBLIC), github.com/corezoid/terraform (private — lower blast radius)
• Discovered: 2026-04-26
• Status: Open — rotate every secret listed below immediately

Summary

Gitleaks scanning of the full git history across 3 Corezoid repositories surfaced 41+ secret-shaped strings including RSA private keys, AWS access keys, admin bearer tokens, database passwords, and TLS private keys. Two of the repositories (helm, corezoid_ansible_roles) are public on GitHub, meaning the leaked content is permanently indexed, archived, and searchable by any attacker (Wayback Machine, GitHub Archive, HIBP-style services, and automated credential-harvesting bots).

Repository visibility

Leaked secrets inventory (non-exhaustive)

helm (public) — 26 findings

Example: the AWS key ID AKIAYQAMCNBUQ3PY5FO3 is visible at corezoid/values.yaml:761 in the current tree (not just history), adjacent to secretAccessKey: "" — meaning the secret is expected to be populated at deploy time. If the key ID is real, an attacker with a leaked secretAccessKey (from any channel) can use this pair directly.

corezoid_ansible_roles (public) — 15 findings

Live-key validation

Performed:

• Compared SHA-256 fingerprint of committed ingress-tls.key public key against live *.corezoid.com cert: NO MATCH (b0ea83a9... vs live 021605b2...). The leaked key is not currently deployed. Good.

NOT performed (requires customer action):

• AWS IAM audit — confirm whether AKIAYQAMCNBUQ3PY5FO3 is still active or has been deactivated
• Postgres credential rotation audit
• RabbitMQ credential rotation audit
• Historical log analysis for any successful auth using leaked creds

Impact

If any leaked credential is still live:

• AWS: account takeover (depending on IAM permissions of that user)
• Admin bearer token: unauth admin access to whatever service accepts it
• Postgres admin: full database compromise (customer data, user passwords, workflow secrets)
• TLS keys: if re-issued from the same key, full TLS impersonation

Even if all are rotated:

• Attackers know your internal naming conventions, infrastructure topology, tooling choices
• Future leaks (even of obfuscated secrets) become easier to correlate back to real credentials
• Public visibility damages security reputation and invites continued automated scanning

Remediation

Priority 1 — immediate (within 24h):

1. Rotate every listed secret. Treat all 41+ as compromised.
2. Revoke AKIAYQAMCNBUQ3PY5FO3 in AWS IAM. Audit CloudTrail for any usage of that key over the last 365 days.
3. Rotate all database passwords referenced in add_admin.sql, reset_password.sh, and any seed SQL files.
4. Revoke and re-issue any TLS certificates whose private keys appear in git history — even if currently unused. Ensure certificate transparency logs have no active certificates matching the compromised public keys.
5. Rotate the admin_bearer_token_secret in values.yaml:781.

Priority 2 — within 1 week:

1. Scrub git history using git filter-repo or BFG Repo-Cleaner, then force-push. (Note: old history remains in forks, GitHub's reflog for ~90 days, and external archives forever — rotation is primary defense, history-rewrite is secondary.)
2. Install pre-commit secret-scanning hooks (gitleaks, detect-secrets) for every Corezoid repo.
3. Enable GitHub secret scanning alerts + push protection (Settings → Code security).
4. Enforce AWS key-rotation policy (90 days max, automated via IAM).
5. Audit corezoid_ansible_roles corezoid-demo.pem.j2 — confirm whether "demo" keys are used in any customer-facing demo environment. If yes, rotate; if never-deployed, delete the template.

Priority 3 — systemic:

1. Migrate helm and corezoid_ansible_roles to private if any real customer deployment ever uses them. Public Helm charts are a legitimate pattern (e.g., bitnami/charts), but only when they contain zero secrets and zero internal references.
2. Separate secrets into a vault (Vault, AWS Secrets Manager, Sealed Secrets). Helm values should reference secrets by name, never contain them.
3. Org-wide secret-scan baseline — run trufflehog --only-verified against every repo, including archived ones.
4. Developer training — the README.md pastes of private keys suggest no one realized they shouldn't document config that way.

References

• CWE-798, CWE-540, CWE-200
• GitHub secret scanning
• Gitleaks — detecting secrets
• BFG Repo-Cleaner
• AWS IAM key rotation best practices