Skip to main content

Likeshop CVE-2026-111348

| EUVDEUVD-2026-102492 MEDIUM
Authorization Bypass Through User-Controlled Key (CWE-639)
2026-10-15 VulnCheck GHSA-5vm9-2pq9-4q7r
5.3
CVSS 4.0 · Vendor: VulnCheck
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Self-register and authenticate account
  2. Delivery
    Enumerate victim after-sale record ids
  3. Exploit
    Call after-sale API with foreign id
  4. Execution
    Read refund/order data or alter refund state
  5. Impact
    Customer data disclosure and refund tampering

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 session on the Likeshop instance (PR:L), which is readily obtainable because the platform supports customer self-registration - the only practical prerequisite. The attacker must reach the API after-sale endpoints (detail, goodsInfo, cancel, express, again in AfterSale.php) and supply another user's after-sale record id; no victim user interaction, no special non-default configuration, and no elevated privileges are needed. Limiting factors: exploitation is confined to after-sale/refund records, impact is read-and-modify of order/refund data rather than full account takeover, and the attacker must know or enumerate valid record ids belonging to other customers.

Impact

This is a genuine but moderate-severity authorization flaw, not a drop-everything emergency. The CVSS 4.0 base vector (AV:N/AC:L/AT:N/PR:L/UI:N) shows a remotely reachable, low-complexity issue, but PR:L is the decisive limiter: exploitation requires an authenticated account. Since Likeshop allows self-registration, this authentication barrier is weak in practice - any attacker can obtain a valid low-privilege account and then abuse IDOR to cross customer boundaries. Impact is capped at VC:L/VI:L/VA:N: an attacker reads other customers' refund/order data and can tamper with after-sale workflows (cancel refunds, overwrite return shipment details, re-open refused refunds), but there is no confidentiality compromise of credentials, no code execution, and no availability impact. No EPSS score was provided in the input, so exploitation probability cannot be quantified. The CVE is NOT in CISA KEV and no exploit-code flag is set, though a public technical write-up (hackmd) and exact vulnerable source lines on GitHub exist, which meaningfully lowers the research barrier for an attacker. Net: a legitimate access-control priority for Likeshop operators handling customer PII and refunds, but the limited technical impact and the open-source/niche footprint keep real-world systemic risk modest rather than critical.

Exploit ScenarioDerived

An attacker self-registers a normal customer account on a Likeshop storefront, authenticates, and calls the after-sale API (detail, goodsInfo, cancel, express, again) while substituting another customer's after-sale record id. Because the endpoints in AfterSale.php/AfterSaleLogic.php do not verify record ownership, the attacker reads victims' refund and order data and tampers with their refund state. No exploit code is flagged in the input, but a public technical write-up documenting the flaw and the exact vulnerable source lines is referenced, so weaponization is low-effort.

This Month Plan within 30 days. Why: MEDIUM severity (CVSS 4.0-6.9).
No patch listed yet 0.2% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Oct 15, 2026

Broken object-level authorization (IDOR) in Likeshop through 3.5.1 lets any user who self-registers on the storefront read and modify other customers' after-sale and refund records through the AfterSale API. Supplying another customer's after-sale record id to the detail, goodsInfo, cancel, express, and again actions in server/application/api/controller/AfterSale.php allows an attacker to view refund and order data, cancel pending refunds, overwrite return shipment details, or re-open refused refunds. The only prerequisite is a valid low-privileged authenticated session (PR:L), which the platform effectively hands out via open customer self-registration; no public exploit code has been identified at time of analysis, so this is a genuine but moderate-severity authorization defect rather than a drop-everything emergency.

RemediationAI

No vendor-released patch has been identified at time of analysis: every supplied code reference points at the vulnerable 3.5.1 sources (controller and logic files) rather than a fix commit or tagged release, so there is no confirmed patched version to upgrade to. The correct code-level fix is to add an object-level ownership check in AfterSale.php/AfterSaleLogic.php - resolve the after-sale record, compare its user_id against the authenticated session's user id, and return 403/404 on mismatch - applied to all five actions (detail, goodsInfo, cancel, express, again), since the IDOR is possible in each. Until an upstream fix is tagged, actionable compensating controls are: (1) temporarily disable or WAF-block the AfterSale API routes (the /api/after_sale/* paths and specifically the cancel, express and again actions), which removes the entire reachable attack surface but also removes legitimate self-service refund tracking and forces customers onto support channels; (2) if the business does not require open registration, disable self-registration or require manual account approval, which eliminates the practical PR:L prerequisite at the cost of changing the onboarding flow; (3) add rate limiting and alerting on sequential or cross-account after_sale_id enumeration, plus monitoring on refund-cancellation and return-shipment-change events, so abusive writes are at least detected and attributable; (4) front the API with middleware that maps the requested after_sale_id to the caller and rejects mismatches before the request reaches the controller, accepting the added per-request database lookup latency. Monitor https://github.com/likeadmin-likeshop/likeshop and the VulnCheck advisory for a patched release and upgrade as soon as one is published.

Affected VersionsENISA

Likeshop 0 ≤3.5.1

Affected Packages

euvd likeshop no fix

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

Likeshop is an open-source PHP e-commerce/mall system (the likeadmin-likeshop project) whose after-sale functionality is split between an API controller (server/application/api/controller/AfterSale.php, lines 52-102 at tag 3.5.1) and a business-logic class (server/application/api/logic/AfterSaleLogic.php, lines 251-377). The detail, goodsInfo, cancel, express, and again actions all accept a client-supplied after-sale record id and load or update the corresponding database row by primary key without verifying that the row's owning customer matches the identity in the authenticated session. This is CWE-639 (Authorization Bypass Through User-Controlled Key) - the classic insecure direct object reference pattern in which the object key is predictable and enumerable and object-level authorization is never evaluated in either the controller or the logic layer. The CPE cpe:2.3:a:likeshop:likeshop:*:*:*:*:*:*:*:* and the CVSS:4.0 vector CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N are consistent with a network-reachable, low-privilege, low-impact read/write flaw with no availability impact and unchanged scope. Note that the supplied 'Authentication Bypass' tag is a slight mischaracterization: authentication is required, and it is trivially obtained through self-registration - what is actually missing is per-object authorization.

Know when Likeshop gets its next vulnerability

  • 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

Vendor (VulnCheck) PRIMARY 5.3 MEDIUM
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N
vuln.today AI 5.4 MEDIUM

Self-registerable account gives PR:L over a network API (AV:N/AC:L); IDOR exposes other users' data (C:L) and permits refund-state tampering (I:L) with no availability impact and unchanged scope.

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (VulnCheck).

CVSS VectorVendor: VulnCheck

Attack Vector
Network
Attack Complexity
Low
Attack Requirements
None
Privileges Required
Low
User Interaction
None
Vulnerable system: Confidentiality
Low
Vulnerable system: Integrity
Low
Vulnerable system: Availability
None
Subsequent system: Confidentiality
None
Subsequent system: Integrity
None
Subsequent system: Availability
None

DescriptionCVE.org

Likeshop through 3.5.1 contains an insecure direct object reference vulnerability in AfterSale.php and AfterSaleLogic.php that lets authenticated users access other customers' after-sale records by supplying their ids. Attackers with self-registered accounts can call the detail, goodsInfo, cancel, express, and again actions to read refund and order data, cancel refunds, overwrite return shipment details, or re-open refused refunds.

Threat Intelligence Overview

EPSS Score
0.2%
Top 88% exploitable
Prevalence
Low
niche open-source PHP e-commerce mall, limited enterprise deployment
Social Media
1
Sightings
Data Quality
5 sources
Confidence: Medium

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.

SignalValue
Severity MEDIUM
CISA KEV No
Public POC No
EPSS 0.2%
Patch available No
Active threat No
Deciding rule
MEDIUM severity (CVSS 4.0-6.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation· derived
None
System Exposure· derived
Open
Automatable· derived
No
Human Impact· derived
Medium

Priority Score

26
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +26
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy