dotnet eShop CVE-2026-112044

Requires a running, network-reachable deployment of the eShop Catalog API component built from code at or before commit 913acea66708a59595351174cee9b29f37179d29, where the AddApplicationServices function configures the Catalog API's authentication. Per the CVSS vector (PR:N/UI:N/AC:L) no credentials, user interaction, or special attack prerequisites are stated, so exploitation targets the component as configured by that routine. The dominant LIMITING factor is not configuration but deployment reality: eShop is a Microsoft reference/sample application rarely exposed in production, and the impact is bounded to Low confidentiality, integrity, and availability with no scope change, so any successful bypass yields only limited catalog-level effects.

Signals are mixed and point to a MODERATE, not urgent, issue. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) describes a remote, low-complexity, unauthenticated attack, which sounds serious, but the impact metrics are uniformly LOW (VC:L/VI:L/VA:L) and there is no scope change (SC:N/SI:N/SA:N), capping the base score at 6.9 (Medium). The exploit-maturity metric E:P (Proof-of-Concept) is asserted by VulDB, but NO proof-of-concept is present in the references - the only links are the VulDB record and a GitHub issue - so treat E:P as a reporter claim, not a verified public exploit. This CVE is NOT in CISA KEV and no EPSS score was supplied, so there is no evidence of active or widespread exploitation. The single most important risk-reducing factor is the target: dotnet/eShop is Microsoft's .NET microservices REFERENCE SAMPLE application, not a production product, so real-world exposure is minimal regardless of the network-reachable vector. CONFLICT TO VERIFY: VulDB asserts E:P (PoC maturity) yet publishes no exploit artifact - verify whether an actual PoC exists before treating this as PoC-available. Overall this is a high-looking-but-low-real-risk issue driven by low impacts and a sample-code target.

A remote, unauthenticated attacker sends a crafted request to a deployed instance of the eShop Catalog API whose authentication services are misconfigured by the vulnerable AddApplicationServices routine, bypassing intended authentication to reach catalog operations. Because CVSS impacts are all Low, the attacker gains only limited read/write/availability effects on the catalog rather than full compromise. No working public exploit is included in the references despite VulDB's Proof-of-Concept (E:P) maturity claim.