Topic starter
20/08/2026 5:59 pm
TL;DR: A malicious NuGet package posing as Sicoob.Sdk 2.0.0 through 2.0.4 exfiltrated client IDs, PFX paths, PFX passwords, and certificate material at constructor time, according to Corgea. The pattern shows how supply-chain trust collapses when packages that handle banking authentication material can leak secrets before any visible API call.
Editorial analysis by NHI Mgmt Group, based on content published by Corgea: “Sicoob.Sdk NuGet impersonator steals mTLS certificates through Sentry telemetry”.
Key questions
Q: What breaks when a malicious SDK receives certificate material at construction time?
A: The trust model breaks because the dependency becomes a privileged observer of secrets before the application can authenticate anything or detect abuse.
Q: Why do malicious package implants create fraud risk as well as data theft?
A: Because stolen certificate material and client credentials can often be reused to impersonate an integration, not just read configuration data.
Q: What are the signs that a dependency is hiding secret exfiltration logic?
A: Watch for unusual outbound telemetry calls, hardcoded ingestion endpoints, secret handling inside constructors, and binary artifacts that do things not present in the visible source.
Practitioner guidance
- Audit dependencies that process certificate material Inventory SDKs and packages that accept client IDs, PFX files, private keys, OAuth tokens, or passwords, then review their compiled behavior and outbound destinations before approval.
- Block registry artifacts with source and binary mismatch Require that the installed package hash, signed metadata, and compiled contents match the expected release before the dependency reaches CI/CD or production deployment.
- Rotate exposed banking integration secrets If the package was used, revoke and reissue affected certificates, reset PFX passwords, disable or replace impacted client IDs where possible, and inspect API logs for abnormal banking activity.
Bottom line: This incident shows that a trusted-looking SDK can turn certificate onboarding into secret theft the moment it is instantiated.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:38 pm
Supply-chain trust must now include secret-handling behavior, not just package provenance. A package that accepts certificate paths and passwords becomes part of the credential control plane the moment it is instantiated. That means dependency review has to ask what the binary does with secrets, not only whether the repository looks legitimate. Practitioners should treat authentication-capable SDKs as governed secret processors, not ordinary libraries.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: How should teams govern third-party SDKs that handle non-human identity secrets?
A: They should require binary artifact review, strict package allowlisting, and explicit approval for any dependency that touches certificates, tokens, or signing material. The question is not whether the package is popular. The question is whether it can observe or transform authentication secrets outside the application’s control boundary.
👉 Read our full editorial: Malicious NuGet supply chain code turned Sicoob SDK trust into theft