CVE-2026-12204
Description
ShopXO up to 6.7.1 exposes unauthenticated cron endpoints, allowing remote attackers to force order confirmation and tamper with business logic.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
ShopXO up to 6.7.1 exposes unauthenticated cron endpoints, allowing remote attackers to force order confirmation and tamper with business logic.
Vulnerability
ShopXO versions up to 6.7.1 contain a missing authorization vulnerability in the scheduled task endpoint, specifically within the file app/api/controller/Crontab.php. The affected methods (OrderClose, OrderSuccess, PayLogOrderClose, GoodsGiveIntegral) are intended to be invoked by the system cron daemon but are exposed as ordinary HTTP routes (/api.php?s=crontab/) without any authentication checks. The parent controller's __construct method does not enforce a login, and none of the action methods include authorization middleware or manual IsLogin() calls; the downstream app/service/CrontabService.php also lacks caller validation [1].
Exploitation
An unauthenticated remote attacker can trigger any of the four cron actions by sending a simple HTTP GET request to the corresponding route (e.g., /api.php?s=crontab/OrderSuccess). No special network position, user interaction, or prior authentication is required. The attacker can invoke these endpoints at will, abusing the missing authorization to manipulate business logic [1].
Impact
Successful exploitation allows an attacker to force order confirmation (via OrderSuccess) for orders whose delivery time exceeds the auto-confirm window, as well as close orders early, manipulate payment log closure, and modify integral award logic (GoodsGiveIntegral). This business-logic tampering can lead to financial loss, unauthorized order fulfillment, and disruption of normal operations. The impact is considered high due to the lack of authentication and the ability to execute actions remotely [1].
Mitigation
As of the available references, no official patch or updated version has been released. The vendor was contacted but did not respond. The vulnerability is publicly disclosed and may be exploited. Users should restrict access to the cron endpoints via network-level controls (e.g., firewall rules, IP whitelisting) and consider using a reverse proxy to require authentication or signed tokens until a vendor-provided fix is available [1].
AI Insight generated on Jun 15, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"Missing authorization checks on cron-task endpoints allow unauthenticated remote attackers to invoke business-logic operations."
Attack vector
An unauthenticated remote attacker sends a single HTTP GET request to routes such as `/api.php?s=crontab/ordersuccess` without any session cookie, token, or body [ref_id=1]. The server executes the cron task unconditionally because no authorization gate is present on the controller or service layer [CWE-862, CWE-840]. For the `OrderSuccess` endpoint, this forces all shipped-but-unconfirmed orders older than the configured auto-confirm window (default 15 days) to the "completed" status, triggering side effects including integral granting, sales-count increment, and system message dispatch [ref_id=1]. Companion endpoints (`OrderClose`, `PayLogOrderClose`, `GoodsGiveIntegral`) are reachable via the same unauthenticated pattern.
Affected code
The vulnerability resides in `app/api/controller/Crontab.php` (methods `OrderClose`, `OrderSuccess`, `PayLogOrderClose`, `GoodsGiveIntegral`) and its parent `app/api/controller/Common.php`. The parent constructor populates `$this->user` but never enforces login, and the `IsLogin()` helper defined in the parent is never called from `Crontab.php`. The downstream service layer `app/service/CrontabService.php` performs no caller validation either.
What the fix does
The advisory recommends enforcing authentication on the cron controller by adding a dedicated gate in the constructor of `Crontab.php` that verifies either a long random shared secret (via `X-Cron-Token` header or token query parameter, compared with `hash_equals()`) or the source IP against a configurable whitelist [ref_id=1]. It further suggests moving the gate into a framework middleware so it cannot be silently skipped, rate-limiting the cron endpoints, and returning a uniform response instead of leaking aggregate processing counts. The patch does not show a committed fix; the vendor did not respond to the disclosure.
Preconditions
- configThe target must run ShopXO up to v6.7.1 with the api.php entry point exposed
- authNo authentication, session, or token is required
- networkThe attacker must be able to send HTTP requests to the target server
- inputNo special payload or parameters are needed; the request path alone triggers the action
Reproduction
1. Seed a qualifying order (status=3, delivery_time older than 15 days) in the database. 2. Send an unauthenticated HTTP GET request to `/shopxo/api.php?s=crontab/ordersuccess`. 3. Observe the server responds with `sucs:1, fail:0` and the database row transitions from status=3 to status=4 with `collect_time` populated [ref_id=1].
Generated on Jun 15, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
5News mentions
0No linked articles in our index yet.