Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessRegister free member account
-
ExploitAuthenticate to client refund API
-
ExecutionEnumerate sequential refundId values
-
ImpactHarvest other members' PII and order data
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Object-level authorization, IDOR prevention
|
| Exploitation Conditions | Requires a valid authenticated member account against the ClientRefundController refund detail endpoint; the description states registration is open, so this authentication barrier is low but still mandatory (PR:L, not unauthenticated). Exploitation depends on refundId values being sequential and guessable and on refund records existing to enumerate. Limiting factors: the attacker must register and authenticate, impact is confined to reading refund/PII data (no write or system impact), and the product must be deployed at or near the vulnerable commit (122c9e6). No user interaction or non-default configuration is required. |
| Impact | This is a credible but moderate-priority data-exposure issue rather than a critical remote-code-execution threat. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) shows network-reachable, low-complexity exploitation requiring only low-privilege authentication, with a single high impact on confidentiality (VC:H) and no integrity or availability impact. The practical risk is amplified by the fact that the required privilege is trivially obtained: the description states attackers can register freely, so PR:L is effectively a near-zero barrier, and the sequential/enumerable refundId makes mass harvesting straightforward. No EPSS score, no CISA KEV listing, and no confirmed public exploit code were provided in the input, so there is no evidence of active exploitation - this is not confirmed in-the-wild activity. However, the referenced VulnCheck advisory and hackmd write-up publicly document the trivial enumeration technique, which lowers the skill barrier. Net assessment: a real authorization/PII-leakage priority for anyone running fuintCatering (especially given exposure of national ID numbers), but its real-world blast radius is constrained by the product's niche footprint rather than by exploitation difficulty. |
| Exploit ScenarioDerived | An attacker self-registers a free member account, authenticates to the client API, and calls the ClientRefundController refund detail endpoint while incrementing the refundId parameter. Because the endpoint performs no ownership check and IDs are sequential, the attacker iterates through all refund records to harvest other members' names, national ID numbers, addresses, WeChat openIds, and order details. The enumeration technique is publicly documented in the VulnCheck advisory and hackmd write-up, though no packaged exploit code was identified in the input. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 13, 2026
Authenticated members of fuintCatering can read other members' refund records and the personal data they contain by iterating sequential refundId values against the ClientRefundController refund detail endpoint. The flaw is an insecure direct object reference (CWE-639) present through commit 122c9e6, and because self-registration is open, an attacker only needs a freely obtainable account to harvest buyers' names, national ID numbers, addresses, WeChat openIds, and order details. No public exploit code or confirmed active exploitation was identified at time of analysis; the impact is confidentiality-only - no writing, no system compromise - and exploitation further depends on refund records actually existing to enumerate.
RemediationAI
No vendor-released patch was identified at time of analysis, and because the vulnerable state is pinned to a source commit rather than a tagged release, remediation is likely to require upstream code changes or a local patch: add a server-side ownership check in ClientRefundController/RefundServiceImpl so a refund is returned only when its owning member matches the authenticated principal, and replace sequential refundId values with unguessable identifiers (UUIDs or a non-sequential token) to eliminate enumeration entirely - the trade-off being that changing the identifier scheme may break existing client integrations and stored references. As compensating controls until a fix is available, restrict access to the client refund detail endpoint at the reverse proxy or WAF so it is reachable only from expected client contexts, apply aggressive per-account rate limiting and enumeration detection on refund detail requests (acknowledging that this raises operational overhead and can produce false positives for legitimate high-volume users), and, if the endpoint is not needed by the member-facing application, disable it outright - which will break refund-detail display for end users. Avoid relying on authentication alone as a barrier, since registration is open and an attacker can obtain a valid member account at no cost. Review the upstream feintCatering repository (https://github.com/fushengqian/fuintCatering) and the VulnCheck advisory (https://www.vulncheck.com/advisories/fuintcatering-through-commit-122c9e6-idor-via-clientapi-refund-detail) for updated guidance, and treat any logs showing sequential refundId access from a single account as evidence of prior data harvesting requiring breach notification review.
Affected VersionsENISA
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The issue is a classic CWE-639 authorization bypass through user-controlled key in the fuintCatering Java/Spring backend. The ClientRefundController refund detail endpoint (fuintBackend/fuint-application/src/main/java/com/fuint/module/clientApi/controller/ClientRefundController.java#L123-L133) accepts a refundId and passes it to RefundServiceImpl (fuintBackend/fuint-application/src/main/java/com/fuint/common/service/impl/RefundServiceImpl.java#L330-L353), which retrieves the refund record without verifying that the refund belongs to the authenticated caller. Because refundId values appear to be sequential rather than opaque, an attacker with any valid member session can walk the identifier space and pull records belonging to other buyers. The data returned is rich PII: buyer names, national ID numbers, physical addresses, WeChat openIds, and order details - a strong identity-theft and social-engineering feedstock. The provided CPE data does not enumerate a tagged release; the vulnerable state is defined by the source commit 122c9e6, and the reported CVSS 4.0 score of 7.1 aligns with the independent CVSS 3.1 assessment of AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, i.e. a remote, low-complexity, authenticated confidentiality breach with no integrity or availability component.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Network-reachable endpoint with trivially obtained low-privilege member auth (PR:L) and no user interaction; sensitive PII disclosure gives C:H with no integrity or availability impact.
Primary rating from Vendor (vulncheck).
CVSS VectorVendor: vulncheck
DescriptionCVE.org
fuintCatering through commit 122c9e6 contains an insecure direct object reference vulnerability in the ClientRefundController refund detail endpoint that lets authenticated members read other members' refund records. Attackers can register freely and enumerate sequential refundId values to obtain buyers' names, national ID numbers, addresses, WeChat openIds, and order details.
Executive ViewAI
The fuintCatering ordering and refund platform exposes customer refund records - names, national ID numbers, home addresses, WeChat openIds, and order details - to anyone who can create a free self-registered account, because refund records are referenced by sequential identifiers that can simply be counted through. The entire buyer population's refund history is therefore harvestable at low cost and with minimal technical skill, and because no vendor fix is available, the exposure persists for as long as the system runs in its current form. Leadership should treat this as a personal-data protection issue rather than a technical defect: the data types involved carry notification, regulatory, and customer-trust consequences that far outweigh the confidentiality-only technical impact.
No vendor-released patch identified at time of analysis. Interim mitigations: disable or gate open self-registration; enforce server-side object-ownership authorization on the refund detail endpoint; replace sequential refundId values with unguessable identifiers; apply rate limiting and enumeration-pattern detection at the WAF or reverse proxy; restrict network access to the refund API; and enable detailed access logging with alerting to detect and quantify traversal attempts.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
EUVD-2026-98894
GHSA-5cgx-vmcr-xxc6
NVD
CVE.org
EPSS
Exploit-DB