CWE-295: TLS verification disabled in K8s strategy fallback — verify_none when ca.crt missing, Bearer token exposed
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 78/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Quiet
- Tech stack
- elixir, kubernetes
- Domain
- authentication, backend, security
Research direction
Start in lib/strategy/kubernetes.ex:323-337 at get_ssl_opts/1 and trace how its returned options reach the Kubernetes HTTP request. Ensure the missing-ca.crt path no longer disables certificate verification, then run the relevant project tests to confirm the fallback preserves peer verification.
Written by the indexing model from the issue text.
Description
Summary
The Kubernetes clustering strategy's get_ssl_opts/1 function falls back to verify: :verify_none when the service account's ca.crt file is missing. This means K8s API Bearer tokens are transmitted over TLS connections that accept any certificate.
Vulnerable Code (lib/strategy/kubernetes.ex:323-337)
defp get_ssl_opts(service_account_path) do
path = Path.join(service_account_path, "ca.crt")
case File.exists?(path) do
true -> [verify: :verify_peer, cacertfile: String.to_charlist(path)]
false -> [verify: :verify_none] # ← DANGEROUS FALLBACK
end
end
Credential Flow
verify: :verify_noneis passed as SSL options to:httpc.request()- The K8s service account Bearer token is sent via
Authorization: Bearer {token}header - All K8s API responses (pod lists, ConfigMaps, Secrets) transit over unverified TLS
Impact
MITM attacker can capture the K8s service account token, gaining API access within the cluster — pod enumeration, ConfigMap/Secret access, lateral movement.
Fix
Never fall back to verify_none. Use system CA store instead:
false -> [verify: :verify_peer] # Use system CA, don't disable verification
Severity
CVSS 7.4 (HIGH) — CWE-295: Improper Certificate Validation
- Dominant language
- Elixir
- Stars
- 2.2k
- Forks
- 202
- PR merge metrics
- No merged PRs in 30d
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from bitwalker/libcluster
-
Difficulty 4/5 3-5 days Newbie friendliness 42/100
bitwalker/libcluster#213 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 25/100
bitwalker/libcluster#206 · 4 comments · 1 reaction ·
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
bitwalker/libcluster#200 ·
-
Changelogs and TagsOpen
Difficulty 4/5 3-5 days Newbie friendliness 35/100
bitwalker/libcluster#197 · 1 comment · 3 reactions ·
-
feature
Difficulty 3/5 1-2 days Newbie friendliness 38/100
bitwalker/libcluster#191 · 1 comment ·
All issues in bitwalker/libcluster
Similar issues
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
carverauto/serviceradar#5264 ·
Maintainers usually reply within 1 day
-
Handle short ciphertext in AES-GCM Decrypt instead of panickingPossibly taken @pamod-madubashana claimed this 3 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 92/100
semaphoreio/semaphore#1305 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
QuinnWilton/argus#5 · 1 comment ·
-
help-wanted L: docker L: elm L: github:actions L: helm L: ruby:bundler
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
dependabot/dependabot-core#16425 ·
Maintainers usually reply within 2 days
-
Cainophile EXIT handler crashes on its own password redaction and logs the DB password in clear textOpen
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 2 days