Security Advisory - Published 2026-06-15 - ShopXO / PHP ecommerce
ShopXO CVE-2026-12204: crontab endpoint self-check
CVE-2026-12204 affects ShopXO up to 6.7.1. The public report points at
app/api/controller/Crontab.php, where scheduled task actions can
be reached without the authorization gate a production store expects around
order and payment maintenance work.
Who should check
| Area | What to verify | Why it matters |
|---|---|---|
| ShopXO version | Public reports list versions up to 6.7.1 as affected. | Old ecommerce installs often stay public after a theme or payment integration is finished. |
| Crontab controller | Check app/api/controller/Crontab.php and the scheduled task service layer. | The reported functions can change order, payment-log, or points-related state. |
| HTTP access | Scheduled task routes should not be callable by arbitrary internet traffic. | Cron tasks are operational endpoints, not public customer actions. |
| Recent orders | Review order completion, unpaid order closure, pay-log closure, and points grants. | The business damage may look like normal automation unless you compare timing and logs. |
10-minute exposure check
- Confirm the running ShopXO version from the admin panel, release notes, or deployment files.
- Find whether
app/api/controller/Crontab.phpexists in the deployed application. - Check whether scheduled task endpoints are limited to the server, a cron token, a trusted source address, or a private network.
- Review web logs for unexpected access to crontab-related paths around June 15, 2026 and after.
- Compare order state changes against normal store automation windows and customer-service activity.
grep -R "crontab" /var/log/nginx /var/log/apache2 /usr/local/apache/logs 2>/dev/null | tail -100Preserve suspicious log lines before changing code or clearing caches. A single request can be a scanner, but repeated requests near order-state changes deserve a cleaner timeline.
Code and configuration checks
- Look for an authorization check before the scheduled task methods call the service layer.
- Make sure cron-only actions require a secret, signed request, internal network access, or another explicit gate.
- Confirm the web server does not expose operational endpoints that should only be run by the server scheduler.
- Check whether a CDN, reverse proxy, or rewrite rule made an internal route public by accident.
- Keep a record of the ShopXO version and patch commit or vendor release you applied.
Business records to review
This can become an operations problem for the store. Scheduled task endpoints can touch money-adjacent records, so check these areas before calling the store clean:
- Orders moved to completed without normal customer or staff activity
- Overdue unpaid orders closed at unusual times
- Payment logs closed without a matching payment processor event
- Points, integrals, coupons, or rewards granted earlier than expected
- Customer messages or order-history entries generated in unusual bursts
Safe fix path
- Restrict access first. Block public access to cron-only routes while you confirm the version and patch state.
- Patch ShopXO. Move to the fixed vendor release or apply the vendor-recommended authorization change when available.
- Add an explicit cron gate. Use a server-side secret, signed request, allowlist, or private scheduler path instead of trusting a public route.
- Reconcile orders and payments. Match store state against payment processor records and fulfillment records.
- Rotate operational secrets if exposed. Do this after preserving evidence and confirming whether the route was abused.
When to request repair help
Use Ping7 CVE Repair if ShopXO was public, you found crontab traffic in web logs, or order/payment state changed without a known business reason. Send the domain, ShopXO version, hosting type, and whether you can export web logs and recent order history.