CVE-2026-50196 is a high-severity (CVSS 7.5) Improper Input Validation vulnerability in Steeltoe.Discovery.Eureka. A fix is available for Steeltoe.Discovery.Eureka — see the affected versions and patch details below.
Steeltoe.Discovery.Eureka: Unrecognized DataCenterInfo.Name poisons entire registry fetch
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-50196.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
CVE-2026-50196 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 380,526 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
Steeltoe.Discovery.Eureka.NETSteeltoe.Discovery.EurekaReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects NuGet packages — download data is not available via public APIs for these ecosystems.
Description
Summary
DataCenterInfo.FromJson throws ArgumentException for any name value other than "MyOwn" or "Amazon", despite the Java Eureka specification defining a third valid value: "Netflix". The exception propagates through the entire registry deserialization chain and is swallowed by the periodic cache refresh task, leaving the local service registry permanently empty or stale.
Impact
Any registration with an unrecognized DataCenterInfo.name permanently disables service discovery for every Steeltoe Eureka client connected to the same registry. New clients start with an empty registry and running clients stop refreshing. The outage persists until the triggering registration is removed.
Because "Netflix" is valid in the Java Eureka specification, a Java or Spring service in the same mesh can trigger this unintentionally.
Affected configuration
- Application uses the Steeltoe Eureka client (
EurekaDiscoveryClient). - The registry contains at least one registration with a
DataCenterInfo.namevalue other than"MyOwn"or"Amazon".
Mitigations
If an immediate upgrade is not possible, remove any registrations using unsupported DataCenterInfo.name values from the registry. In mixed Java/Spring and Steeltoe environments, audit for the Netflix data center type before deploying Steeltoe Eureka clients.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| .NETNuGet | Steeltoe.Discovery.Eureka | ≥ 4.0.0&&< 4.2.0 | 4.2.0dotnet add package Steeltoe.Discovery.Eureka --version 4.2.0 |
| .NETNuGet | Steeltoe.Discovery.Eureka | all versions | 3.4.0dotnet add package Steeltoe.Discovery.Eureka --version 3.4.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for Steeltoe.Discovery.Eureka, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update Steeltoe.Discovery.Eureka to 4.2.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-50196 is resolved across your whole dependency graph.
Workarounds
Do not deserialise data from untrusted sources: where the format allows it, restrict deserialisation to an explicit allowlist of expected types, and prefer a data-only format (JSON, Protobuf) over one that can reconstruct arbitrary objects until you can upgrade.
Frequently Asked Questions
Is CVE-2026-50196 in your dependencies?
Find it across NuGet, including transitive dependencies.