Supermarket
Monthly
Missing authentication in the Instant Buy component of ZongXR SuperMarket 1.0.0.0 lets remote attackers invoke the startBuy function without proving a valid session, simply by manipulating the Username argument passed to InstantBuyController.java. Impact is limited to integrity and availability at low severity (assessed CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L), with no confidentiality loss, and publicly available exploit code exists though there is no confirmation of active exploitation. The authentication prerequisite is ambiguous - the CWE-306 classification and description imply no credentials are needed, while the vendor's CVSS 4.0 vector encodes low-privilege (PR:L) access - so the true auth requirement should be treated as unconfirmed. Real-world risk is low primarily because this is an obscure hobby/open-source project that is rarely exposed in production.
Unauthenticated remote attackers can delete arbitrary order records in ZongXR SuperMarket 1.0.0.0 because the OrderController.deleteOrder endpoint lacks authentication checks (CWE-306). Publicly available exploit code exists (GitHub issue #31), and the project maintainer has not responded to the report. With a CVSS 4.0 score of 6.9 (medium) and an independent assessment confirming only low integrity and availability impact, the vulnerability poses a low-to-moderate risk, primarily limited by the product's rare deployment in production environments.
Missing authentication in the ZongXR SuperMarket 1.0.0.0 order-save endpoint (OrderController.addOrder) allows unauthenticated remote attackers to submit order actions while passing an arbitrary userId argument, letting them act on behalf of other accounts without any credentials. The root cause is CWE-306: the handler performs no authentication check at all, so the caller-supplied userId is implicitly trusted. Publicly available exploit code exists (documented in the project's own GitHub issue #32), but real-world priority is low because SuperMarket is a niche, non-production Java project with no large-scale enterprise deployment footprint - the practical limit is whether an instance is network-reachable, and no privileges or user interaction are required (CVSS:4.0 PR:N/UI:N; our assessment scores it AV:N/AC:L/PR:N/UI:N with limited integrity impact, C:N/I:L/A:N).
Missing authentication in the Instant Buy component of ZongXR SuperMarket 1.0.0.0 lets remote attackers invoke the startBuy function without proving a valid session, simply by manipulating the Username argument passed to InstantBuyController.java. Impact is limited to integrity and availability at low severity (assessed CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L), with no confidentiality loss, and publicly available exploit code exists though there is no confirmation of active exploitation. The authentication prerequisite is ambiguous - the CWE-306 classification and description imply no credentials are needed, while the vendor's CVSS 4.0 vector encodes low-privilege (PR:L) access - so the true auth requirement should be treated as unconfirmed. Real-world risk is low primarily because this is an obscure hobby/open-source project that is rarely exposed in production.
Unauthenticated remote attackers can delete arbitrary order records in ZongXR SuperMarket 1.0.0.0 because the OrderController.deleteOrder endpoint lacks authentication checks (CWE-306). Publicly available exploit code exists (GitHub issue #31), and the project maintainer has not responded to the report. With a CVSS 4.0 score of 6.9 (medium) and an independent assessment confirming only low integrity and availability impact, the vulnerability poses a low-to-moderate risk, primarily limited by the product's rare deployment in production environments.
Missing authentication in the ZongXR SuperMarket 1.0.0.0 order-save endpoint (OrderController.addOrder) allows unauthenticated remote attackers to submit order actions while passing an arbitrary userId argument, letting them act on behalf of other accounts without any credentials. The root cause is CWE-306: the handler performs no authentication check at all, so the caller-supplied userId is implicitly trusted. Publicly available exploit code exists (documented in the project's own GitHub issue #32), but real-world priority is low because SuperMarket is a niche, non-production Java project with no large-scale enterprise deployment footprint - the practical limit is whether an instance is network-reachable, and no privileges or user interaction are required (CVSS:4.0 PR:N/UI:N; our assessment scores it AV:N/AC:L/PR:N/UI:N with limited integrity impact, C:N/I:L/A:N).