TL;DR: Truffle Security found 140 verified secrets in 1,225,736 public DotNetFiddle snippets plus a context-only Zendesk SSO HMAC key that format-based scanning missed, showing how public code shares can outlive remediation and defeat verification-only secret scanning. Static secret detection and post-publication cleanup both leave dangerous gaps in secrets governance.
At a glance
What this is: Truffle Security’s analysis shows that public DotNetFiddle snippets can leak live .NET and enterprise secrets, including a context-only Zendesk SSO signing key that conventional verification missed.
Why it matters: It matters because IAM, AppSec, and platform teams need controls that prevent secrets from being published in the first place, not just tools that try to find them after exposure.
By the numbers:
- The scan also produced 9,702 raw hits from a .NET-tuned regex pass, including 307 ADO.NET connection strings and 24 live Azure credentials.
👉 Read Truffle Security’s analysis of public .NET snippets and live secret exposure
Context
Public code-sharing environments create a governance gap when developers can save credentials into snippets that remain accessible to anyone who discovers the URL. In this case, the exposure problem is not limited to obvious API keys because .NET snippets often contain enterprise authentication material, connection strings, and signing secrets that standard format-based scanners may not recognise.
For IAM and AppSec teams, the key issue is that publication is itself an exposure event. Once a secret is embedded in a public fiddle, later deletion does not eliminate the risk if search engines, scanners, or threat actors already captured it. The presence of a context-only HMAC signing key shows why secrets governance must cover both detection at save time and semantic inspection of surrounding code.
Key questions
Q: What breaks when live secrets are saved in public code snippets?
A: The main failure is that publication becomes disclosure. Once a working credential is embedded in a public snippet, the organisation no longer controls who can copy it, and later deletion does not undo collection. That creates a standing exposure window for authentication, data access, and token forgery, so controls must stop secrets at save time rather than relying on cleanup.
Q: Why do public code snippets turn secrets into authentication risk?
A: Because many secrets are not just data, they are credentials. If a leaked key signs tokens or authenticates services, anyone who obtains it can impersonate users or access protected systems. The risk is highest where the secret is accepted locally by the application, since there may be no provider API or external verification path to catch misuse.
Q: How can security teams detect context-only secrets more reliably?
A: Use detectors that understand code context, not only token format. Search for nearby signing algorithms, function calls, variable usage, and credential-handling patterns so a high-entropy string can be interpreted in relation to the code around it. That approach catches HMAC keys, client-secret pairs, and other values that pattern matching alone often misses.
Q: Should organisations allow production credentials in public developer playgrounds?
A: No. Public playgrounds should be treated as uncontrolled publishing surfaces, not test benches for live credentials. If developers need working authentication material, they should use isolated non-production secrets and protected environments. Once production secrets reach a public snippet, the organisation should assume exposure and rotate them immediately.
Technical breakdown
Why verification-based secret scanning misses contextual secrets
Most secret scanners are strongest when a credential matches a known pattern and can be checked against a provider API. That works for cloud keys, tokens with prefixes, and other recognisable secrets. It fails when the secret is a symmetric signing key, an OAuth client secret pair, or another value that only becomes meaningful when read alongside surrounding code. In those cases, the high-entropy string is not enough. The controlling signal is the execution context, such as an HS256 signing call or token construction flow. Without that context, scanners misclassify the finding or ignore it entirely.
Practical implication: Add context-aware detection rules for code samples and shared snippets, not just pattern matching and provider verification.
Why public .NET snippets produce enterprise secrets, not just generic tokens
DotNetFiddle is a server-side .NET playground, so the credentials developers paste there tend to reflect the services they actually use in production: Azure, SQL Server, SharePoint, Office 365, and related Microsoft enterprise systems. That changes the exposure profile compared with frontend playgrounds, which more often leak SaaS tokens or browser-facing credentials. The risk is less about the language syntax and more about the operational context it encourages. When a developer needs a working token to test code, they often paste a live one into the snippet, and the public URL turns that test artifact into a durable disclosure.
Practical implication: Treat public code playgrounds as sensitive publishing surfaces and block production secrets from reaching them.
How public snippet exposure becomes an authentication and access-control problem
A leaked secret is not just a data exposure. If it signs JWTs, authenticates SSO, or opens storage and database access, it becomes a direct identity and access issue. In the Zendesk SSO case, a shared HMAC key could mint valid tokens for any user because the application trusted the signature locally. That means the security boundary is the secret itself, not the snippet page. Once the key is public, anyone who can read the snippet may inherit the ability to authenticate, impersonate, or query protected systems.
Practical implication: Apply NHI-style lifecycle controls to signing keys, service credentials, and shared secrets wherever code samples can expose them.
Threat narrative
Attacker objective: Use publicly exposed development secrets to authenticate as legitimate users or services and access production systems without permission.
- Entry occurred when developers saved working credentials into public DotNetFiddle snippets that anyone could access by URL.
- Credential harvesting followed because scanners and human reviewers could collect live Azure, SQL, GitHub, AWS, and SSO-related secrets from the corpus.
- Impact would be unauthorised authentication, data access, or token forgery when exposed secrets are reused against enterprise systems.
Breaches seen in the wild
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
- TruffleNet stolen AWS keys campaign 2025: TruffleNet used 800+ attacker hosts to test stolen AWS keys and check SES capacity; one compromised account sent a fake $50,000 invoice.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Public code sharing has become a secrets governance control surface. The article shows that snippet repositories are not neutral collaboration spaces once live credentials are pasted into them. They behave like public distribution channels for identity material, which means the control objective is prevention at save time, not just retrospective discovery. For IAM and AppSec teams, this shifts code-sharing governance into the same risk category as source control leakage and exposed CI artifacts.
Context-aware detection is now mandatory for secret hygiene. Pattern matching alone will continue to miss the kinds of credentials that matter most, especially HMAC signing keys and token construction flows that have no stable format. This is a clear example of detection blindness created by relying on syntactic signatures instead of code semantics. The security lesson is that verification depth must increase when the credential itself is an authentication primitive.
Shared signing keys are a non-human identity risk, not just an application bug. When a symmetric secret can mint trusted tokens for any user, it functions as a machine-held authority boundary. That makes the exposure problem an NHI governance issue as much as an appsec issue, because the secret is effectively a credential with lifecycle, ownership, and offboarding requirements. The operational implication is that machine secrets in public snippets need the same inventory discipline as service accounts and API keys.
Public snippets create a standing exposure window that deletion cannot reliably close. The article’s findings reinforce a named concept we should treat seriously: snippet-born secret leakage. Once a live credential reaches a public fiddle, the organisation has already lost control of its distribution state, and remediation becomes a race against collection rather than a containment action. Practitioners should therefore judge exposure controls by whether they prevent publication, not by how quickly they can clean up after it.
.NET playground exposure is a governance signal, not an isolated curiosity. The shift toward Azure and enterprise service credentials shows that playground risk tracks developer workflow, not platform popularity. That means organisations need policy and tooling that follow language communities into the places they actually test code. The practical conclusion is simple: if the environment can save public code, it can save public secrets, and that should be treated as a design flaw.
From our research library:
- A May 2025 Gartner poll of 147 CIOs and IT leaders found that 24% had already deployed AI agents, 50% were experimenting and 17% planned to deploy by the end of 2026.
- Read next: Agentic AI Security Guide
What this signals
Snippet-born secret leakage: public code-sharing tools create a persistent distribution problem because the secret is exposed at the moment of publication, not only at the moment of compromise. Teams that only monitor repositories and CI systems will miss a growing class of developer-originated exposure events.
The reader-level implication is that prevention must sit inside the developer workflow. If the platform can accept and save public code, it needs policy controls for secrets, service credentials, and signing material before the snippet becomes reachable by outsiders.
New research from the 2026 Infrastructure Identity Survey shows 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, which underlines how quickly machine-held authority can outrun governance.
For practitioners
- Implement save-time secret blocking Prevent live credentials from being committed into public snippets by scanning on save, not only after publication, and reject content that contains tokens, keys, or connection strings.
- Add context-aware secret detection Extend scanning to evaluate nearby signing calls, algorithm references, and token-construction patterns so HMAC keys and other non-prefixed secrets are detected.
- Treat public playgrounds as risky publishing surfaces Set policy that production credentials must never be used in public code-sharing tools, even for short-lived testing or demonstration code.
- Rotate exposed secrets immediately Rotate any key, token, or connection string that appears in a public snippet, even if the snippet is later deleted or the credential has already expired.
Key takeaways
- Public DotNetFiddle snippets can turn working credentials into durable disclosures, and the risk does not disappear when the snippet is deleted later.
- The most dangerous cases are not always obvious API keys, because context-only signing secrets can evade verification-based scanners and still authenticate users or services.
- Preventing publication is more effective than post hoc cleanup, especially when public code-sharing tools can save production secrets into openly accessible artifacts.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Public snippets expose live secrets and make leakage the primary failure mode. |
| NHI-04 — Insecure Authentication | A leaked HMAC signing key can authenticate as any user in the affected SSO flow. | |
| NHI-07 — Long-Lived Secrets | The article shows how secrets can remain publicly accessible long after creation or deletion. | |
| Recommendation — Block secret publication in snippet workflows and revoke anything exposed in public code immediately. Protect token-signing keys with stronger authentication boundaries and assume exposed shared secrets are compromised. Shorten secret lifetime and remove any long-lived credentials from public developer environments. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle control is central when public snippets expose usable secrets. |
| Recommendation — Apply IA-5 to manage issuance, rotation, and revocation of secrets that can appear in public code. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The exposed secrets grant access beyond intended authorisation boundaries. |
| Recommendation — Review entitlements tied to exposed secrets and limit each credential to the minimum required scope. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Leaked secrets support credential access and subsequent movement into enterprise systems. |
| Recommendation — Map exposed snippet secrets to TA0006 and TA0008 hunts across logs, repos, and exposed developer content. | ||
Key terms
- Secrets Leakage: Secrets leakage is the exposure of credentials such as API keys, tokens, or certificates in places where they can be discovered and reused. The risk is not just disclosure, but unauthorized authentication that turns a coding or pipeline mistake into active access.
- Context-aware secret detection: Context-aware secret detection is a scanning approach that looks at how code uses a value, not just what the value looks like. It helps identify high-risk material such as signing keys, OAuth pairs, and embedded credentials that pattern matching alone can miss.
- Private Signing Key: A private signing key is the secret material that creates a trusted software signature. If it is exposed or copied, an attacker can sign malicious code as if it were legitimate, which is why key storage, access control, and hardware-backed protection are central governance requirements.
- Snippet-Born Exposure: Snippet-born exposure is the publication of sensitive material through a code-sharing or playground environment that was meant for testing or demonstration. Unlike a traditional breach, the disclosure begins when the content is saved publicly, which makes containment dependent on prevention rather than cleanup.
What's in the full report
Truffle Security's full analysis covers the operational detail this post intentionally leaves for the source:
- The step-by-step DotNetFiddle scanning approach used to collect and triage more than 1.2 million public snippets
- The manual review method that separated obvious tokens from context-only signing keys and other non-standard secrets
- The breakdown of secret types by platform, including Azure, SQL Server, Office 365, SharePoint, and other enterprise services
- The examples of raw regex hits that were retained, rejected, or reclassified during analysis
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to real-world exposure paths like public code snippets and shared signing secrets.
Published by the NHIMG editorial team on August 1, 2026.
Updated on October 5, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org