oms-erp EUVD-2026-98945

Exploitation requires only network reachability to the skyer-goods service's public es-test maintenance endpoints (specifically /v1/goods/sku/es-test, with a parallel path in SpuController); these endpoints lack any authentication check (CWE-306), so no credentials, tokens, or user interaction are needed against a default deployment that exposes the skyer-goods API. The practical prerequisite - and limiting factor - is that the skyer-goods microservice and its Elasticsearch-backed search (goods_sku_index_01) must be deployed and the endpoint network-reachable to the attacker; impact is confined to search index availability and integrity (no confidentiality exposure, no source-data destruction), and the index is recoverable via reload, which bounds the realistic damage to service degradation.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) describes a remotely reachable, low-complexity, unauthenticated flaw requiring no user interaction, which normally signals easy exploitation. However, the impact metrics deliberately cap the severity: confidentiality is None (VC:N), and both integrity and availability are only Low (VI:L/VA:L) with no scope change, producing a medium 6.9 score rather than a critical one. This is consistent with the description - the issue wipes and forces rebuilds of the shared Elasticsearch goods_sku_index_01, degrading search but not exposing or corrupting source-of-truth data. No EPSS score was provided in the input, so exploitation-probability cannot be quantified and should be verified externally. The vulnerability is NOT listed in CISA KEV and no exploit code is identified in the references (a HackMD technical write-up and a VulnCheck advisory document the issue but are not exploit artifacts). SSVC framing: exploitation is plausible and the action is automatable (a simple repeatable GET to /v1/goods/sku/es-test), but technical impact is partial (availability/integrity degradation of a search subsystem, recoverable via reload). Net assessment: this is a genuine denial-of-service/availability concern for multi-tenant deployments because one unauthenticated request affects ALL tenants, but it is a medium-priority issue, not a high-real-risk code-execution or data-breach flaw. Prioritize based on whether the affected skyer-goods endpoints are internet-exposed.

An unauthenticated attacker who can reach the skyer-goods service sends repeated HTTP requests to the public /v1/goods/sku/es-test maintenance endpoint, each of which empties the shared goods_sku_index_01 Elasticsearch index and forces an expensive full-table reload. Because the index is shared across all tenants, a single external actor degrades product-search availability for every tenant simultaneously. No public exploit code is identified at time of analysis, though a technical write-up describing the behavior is referenced.