CVE-2026-111657: BeikeShop RMA markAsShipped IDOR Lets Authenticated Customers Tamper With Other Customers’ Returns

Summary

BeikeShop, an e-commerce platform with its source code published on GitHub, contains an insecure direct object reference vulnerability — classified as CWE-639, Authorization Bypass Through User-Controlled Key — in all versions through 2.0.0.31. The flaw is located in the markAsShipped handler of the RmaController, the controller that powers return merchandise authorization (RMA) actions in the customer account area. Because the handler processes the user-supplied RMA identifier without confirming that the corresponding return belongs to the requesting customer, any authenticated customer can modify other customers' returns. In practice, an attacker submits sequential RMA ids to the account/rmas/{id}/mark_as_shipped endpoint to overwrite courier names and tracking numbers and to mark approved returns as shipped. The vulnerability carries a CVSS 3.1 base score of 4.3 (MEDIUM severity). It was discovered by hieuPenguinnn, and the CVE identifier was assigned by VulnCheck.

Technical Analysis

CWE-639, Authorization Bypass Through User-Controlled Key, describes a precise failure pattern: an application accepts an identifier from the user, uses it to select an object, and then performs an action on that object without verifying that the authenticated user is authorized to act on that specific object. Authentication succeeds, but object-level authorization never happens. The practical result is that a legitimate account can reach records it should never touch simply by changing the identifier in the request.

That is exactly the shape of CVE-2026-111657. The user-controlled key is the {id} segment of the account/rmas/{id}/mark_as_shipped route, and the protected object is another customer's return record. According to the vulnerability description, the markAsShipped handler in RmaController allows authenticated customers to modify returns owned by other customers — the handler never ties the supplied RMA id back to the requesting session's customer before executing the shipment update.

The advisory references point to the exact code locations in the v2.0.0.31 source snapshot: the handler sits in beike/Shop/Http/Controllers/Account/RmaController.php at lines 67-93, and the route exposing the endpoint is registered in beike/Shop/Routes/shop.php at lines 98-111. Both are PHP files under the shop-facing portion of the application — the account area where customers manage their own returns — which is consistent with an endpoint that should only ever operate on the caller's own RMA records.

The functional consequences described are concrete. A request carrying a victim's RMA id overwrites the courier name and the tracking number stored on that return, and it transitions an approved return into a shipped state. The attacker therefore controls data that feeds the store's reverse-logistics records for a return they do not own, and can flip a status that storefront logic and staff workflows treat as meaningful.

Two properties make the flaw easy to weaponize. First, RMA identifiers are sequential, so an attacker holding any valid customer account can walk the id space numerically instead of guessing random values. Second, exploitation requires only low privileges — a normal customer login — plus no user interaction and no unusual conditions, which is reflected in the CVSS metrics AV:N, AC:L, PR:L, and UI:N. The exact request body parameter names used to supply the new courier and tracking values, and any additional validation performed inside the handler, are not fully disclosed in the provided sources.

Affected Software and Versions

The vulnerability affects BeikeShop, an e-commerce platform whose source code is published on GitHub at the beikeshop/beikeshop repository. Per the advisory data, affected versions are BeikeShop through 2.0.0.31 — every release up to and including 2.0.0.31. The source references are pinned to the v2.0.0.31 tag, the snapshot in which the vulnerable handler and route can be observed.

Product: BeikeShop
Affected versions: through 2.0.0.31 (no earlier bound is stated in the provided data)
Vulnerable component: markAsShipped handler in RmaController — beike/Shop/Http/Controllers/Account/RmaController.php, lines 67-93 in the v2.0.0.31 snapshot
Vulnerable endpoint: account/rmas/{id}/mark_as_shipped, routed via beike/Shop/Routes/shop.php, lines 98-111
Weakness class: CWE-639, Authorization Bypass Through User-Controlled Key

No fixed or patched version is identified in the provided sources. Operators running BeikeShop 2.0.0.31 or earlier should treat customer-facing RMA functionality as exposed to cross-account modification until a vendor fix is confirmed, and should track the associated GitHub advisory (GHSA-cqc2-r3p8-vc5x) and the VulnCheck advisory page for updates.

Impact

The CVSS 3.1 base score is 4.3, rated MEDIUM, with the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N. Each metric maps to something concrete in the description:

AV:N (Network): the endpoint is reachable over the network through the normal storefront account area; no local or adjacent access is required.
AC:L (Low complexity): exploitation is straightforward — submit a different RMA id. Sequential identifiers remove even the guessing burden.
PR:L (Low privileges): the attacker needs an authenticated customer account, the lowest privilege tier available to a storefront user.
UI:N (No user interaction): nothing on the victim's side is clicked, opened, or tricked; the attacker acts entirely from their own session.
S:U (Scope unchanged): the impact stays within the security scope of the affected application's resources; the vulnerability does not cross a boundary into other components.
C:N (No confidentiality impact): the described capability is modification of return records, not disclosure of their contents, so the scoring reflects integrity loss only.
I:L (Low integrity impact): attacker-controlled values — courier names, tracking numbers, shipped status — land in other customers' return records, a limited but real modification of data the store relies on.
A:N (No availability impact): the described attack does not take return records, the endpoint, or the store offline.

Even at low integrity impact, the effect on a live store is tangible: return records that staff and customers rely on can silently display the wrong carrier and the wrong parcel number, and approved returns can be marked as shipped by someone other than the owning customer. How far tampered records propagate into refunds, disputes, or carrier integrations depends on how each individual store processes returns; those downstream behaviors are not fully disclosed in the provided sources.

Exploitation Scenario

The following scenario is illustrative. It is reconstructed step by step from the vulnerability description — the endpoint, the sequential-id behavior, the affected fields, and the authentication requirement — and is intended to show how the flaw translates into an attack path, not to document a captured incident.

Obtain a foothold account. The attacker registers an ordinary customer account on a BeikeShop storefront, or already holds one. This satisfies the low-privilege requirement; no staff or administrative role is involved.
Establish the id space. RMA ids are sequential. The attacker can create a return on their own account to observe the identifier format, then treat neighboring numbers as other customers' returns — for illustration, if the attacker's own return carries id 1001, ids 1002 and 1003 plausibly belong to other shoppers.
Submit cross-account requests. From their own authenticated session, the attacker sends requests to account/rmas/{id}/mark_as_shipped, substituting victim ids one after another. Because the handler lacks the ownership check, it does not reject ids that belong to someone else.
Overwrite the return. For each matching id, the handler overwrites the courier name and tracking number on the victim's return with attacker-supplied values and marks the approved return as shipped.
Observe the result. The victim's return record now carries attacker-chosen carrier data and a shipped status. The attacker's own account shows nothing unusual, and no action from the victim was required at any point.

The exact HTTP method and request body format are not disclosed in the provided sources, so this scenario describes the logical attack flow rather than a verbatim request.

Detection and Mitigation

Detection

Defenders can look for the signature of object-key abuse in three places:

Access logs: requests to paths containing /account/rmas/ and mark_as_shipped where the requested RMA id does not correspond to a return owned by the authenticated session's customer. Correlating the session or customer identifier with RMA ownership makes these mismatches visible.
Enumeration patterns: a single customer account touching many sequential RMA ids in a short window is exactly the behavior the description attributes to attackers. Rate and sequence analysis on the rmas endpoint surfaces this quickly.
Data audits: return records whose courier name or tracking number changed unexpectedly, or approved returns that transitioned to shipped without a matching action from the owning customer, warrant a review of the associated access logs.

Mitigation

Upgrade. Move to a BeikeShop release newer than 2.0.0.31 as soon as a fix is published. No fixed version is identified in the provided sources, so verify vendor releases and the GHSA-cqc2-r3p8-vc5x advisory before declaring the issue remediated.
Enforce object-level authorization. The class-level fix for CWE-639 is to load the RMA by the supplied id and verify it belongs to the authenticated customer before performing any field write or state change; requests for foreign ids should fail with an authorization error.
Constrain state transitions. Only the owning customer, or authorized staff, should be able to move an approved return into the shipped state, and only from legitimate prior states.
Sweep the account area. IDOR flaws frequently cluster: once one handler in an account-area controller skips the ownership check, sibling handlers deserve a review. This is general guidance for the weakness class, not a claim about additional BeikeShop vulnerabilities.

Bug Bounty Angle

This CVE is a textbook low-privilege IDOR on a self-service endpoint, and it maps cleanly onto a repeatable testing routine:

Two-account testing. Register accounts A and B on an authorized BeikeShop target. Create a return on A and note its RMA id, then, from B's session, send requests to account/rmas/{id}/mark_as_shipped using A's id. Any change to A's courier name, tracking number, or shipped status is a direct hit.
Sequential enumeration. The description highlights that attackers submit sequential RMA ids. When an account-area route accepts a numeric {id}, probe neighboring identifiers from the second account; ownership boundaries that hold for one id often fail across the whole range.
Watch the state machine. The described impact includes marking approved returns as shipped, which tells you the handler operates on a specific return state. Mapping which states an endpoint accepts — and which it skips validation for — often separates a reportable IDOR from a dead end.
Score impact honestly. This flaw lands at 4.3 with no confidentiality and no availability impact: record tampering only. Framing a report around the concrete fields an attacker can overwrite — courier name, tracking number, shipped status — helps triage reproduce and rate it correctly.
Read the primary writeup. The HackMD disclosure by hieuPenguinnn is referenced in the advisory data and is the natural starting point for understanding how this handler was analyzed.

As always: test only systems you are authorized to test, and report through the program's designated channels.

Frequently Asked Questions

What is CVE-2026-111657?

An insecure direct object reference (CWE-639) in BeikeShop through 2.0.0.31. The markAsShipped handler of RmaController lets authenticated customers modify other customers' returns via account/rmas/{id}/mark_as_shipped, overwriting courier names and tracking numbers and marking approved returns as shipped.

Which BeikeShop versions are affected?

All versions through 2.0.0.31. The advisory's source references are pinned to the v2.0.0.31 tag, and no fixed version is identified in the provided sources.

How severe is CVE-2026-111657?

CVSS 3.1 base score 4.3 (MEDIUM), vector AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N — network exploitable, low privileges, no user interaction, low integrity impact, and no confidentiality or availability impact.

Who discovered CVE-2026-111657, and is it in CISA's KEV catalog?

Discovered by hieuPenguinnn, who published a technical writeup on HackMD; the CVE was assigned by VulnCheck. Per the provided data, it is not listed in CISA's Known Exploited Vulnerabilities catalog.

Discovery and Credits: Discovered by hieuPenguinnn; CVE assigned by VulnCheck.