Topic starter
19/10/2026 5:39 pm
TL;DR: Truffle Security found 453 publicly exposed Jenkins servers without authentication requirements, and 3% of scanned servers contained at least one live secret in build logs, including API keys and passwords. Secret leakage here is not just a discovery problem, because unauthenticated access turns logs into a credential exposure path.
Editorial analysis by NHI Mgmt Group, based on content published by Truffle Security: “Leaked Secrets in Public Jenkins Logs”.
By the numbers:
- 3% of all scanned servers contained at least one live secret.
- Truffle Security found 453 live, publicly exposed Jenkins servers without any authentication requirements.
- TruffleHog identified 26 unique, live secrets from 14 different servers.
Key questions
Q: What breaks when Jenkins build logs are publicly accessible?
A: The boundary between operational telemetry and credential custody breaks.
Q: Why do leaked build secrets often lead to broader compromise?
A: Because the secret is usually trusted outside the system that exposed it.
Q: How do security teams measure whether secret scanning is actually reducing exposure?
A: Security teams should measure the time from secret creation to detection, the percentage of repositories and build artifacts scanned, and the time from detection to rotation or revocation.
Practitioner guidance
- Restrict build-log access to authenticated users only Remove public access to Jenkins logs and verify that every job output path is behind an enforced identity check.
- Inventory every secret that can appear in CI output Map API keys, passwords, tokens, and service credentials to the pipelines and jobs that can print them.
- Revoke exposed credentials immediately after discovery Treat any live secret found in logs as compromised until it is rotated or invalidated and downstream access is confirmed closed.
Bottom line: Public Jenkins logs can become a credential exposure channel when authentication is missing and build output contains live secrets.
What's in the full report
Truffle Security's full post covers the operational detail this post intentionally leaves for the source:
- The Shodan and nuclei workflow used to identify public Jenkins instances
- The exact Jenkins build-log scanning command used to find live secrets
- The breakdown of secret types found across AWS, Alibaba, GitHub, OpenAI, and Slack
- The disclosure approach used after the exposed servers were identified
👉 Read Truffle Security's analysis of leaked secrets in public Jenkins logs →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/10/2026 5:39 pm
Unauthenticated build visibility is a governance failure, not just a misconfiguration: when public access reaches internal job logs, the control boundary around machine credentials has already broken. That means the problem spans IAM, secrets management, and platform administration, not one isolated Jenkins setting. The practitioner implication is that log access must be governed with the same discipline as credential issuance.
A few things that frame the scale:
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: What should teams do when a CI/CD credential is exposed?
A: Revoke the token, validate the affected pipeline and artifact chain, and confirm whether the credential was used for deployment or build access. Then rotate any related secrets, review recent pipeline changes, and verify that protected environments and approvals still block unauthorized release activity.
👉 Read our full editorial: Public Jenkins logs exposed live credentials in 3% of servers