Loading vulnerability…
Saleor (e-commerce platform) contains an Insecure Direct Object Reference (IDOR) in its order information retrieval via the GraphQL order() query, affecting versions 3.2.0 through 3.20.109, 3.21.0-a.0 through 3.21.44, and 3.22.0-a.0 through 3.22.28. The flaw allows unauthenticated actors to access and extract sensitive order information in plaintext by directly referencing order objects without proper authorization checks. Orders created before Saleor 3.2.0 are specifically noted as potentially exposing PII via this issue.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos.
This repository is a self-contained lab and proof-of-concept exploit for CVE-2026-24136, an unauthenticated IDOR/BOLA issue in Saleor's GraphQL `order(id: $id)` query. The repo contains 8 files: a README with vulnerability details and usage, Docker Compose lab infrastructure, two setup scripts for Windows/Linux, a container startup wrapper, a Python seed script to create demo victims/orders, and the main Python PoC exploit. The primary exploit logic is in `scripts/poc_cve_2026_24136.py`. It targets the Saleor GraphQL endpoint via HTTP POST to `/graphql/`, sending a crafted GraphQL query that requests order metadata plus sensitive customer fields such as `userEmail`, billing/shipping addresses, phone numbers, and user account details (`email`, `firstName`, `lastName`, `dateJoined`, `lastLogin`, `isActive`). The script supports three practical attack modes: querying a single supplied order ID, enumerating a numeric range of order IDs by converting them into Saleor Relay-style global IDs, and bulk exploitation from a JSON file of known order IDs. It also includes helper functions to encode/decode Saleor global IDs and can export exfiltrated data to a JSON file. `scripts/seed_data.py` is not the exploit itself but supports the lab by authenticating as admin, creating victim customer accounts, creating draft orders populated with PII, and writing valid global order IDs to `order_ids.json`. This makes the PoC immediately usable against the local lab. `docker-compose.yml` provisions PostgreSQL, Redis, a vulnerable Saleor API container (`ghcr.io/saleor/saleor:3.20`), and an optional dashboard. `scripts/start_api.sh` applies migrations, collects static files, patches a WSGI compatibility issue, and launches gunicorn on port 8000. `setup_lab.ps1` and `setup_lab.sh` automate environment startup, readiness checks, admin creation, sample data population, and seed execution. Overall purpose: provide a reproducible vulnerable Saleor environment and an operational PoC demonstrating unauthenticated PII exfiltration from order records through the GraphQL API. This is a real exploit repository, not merely a detector, and its main capability is unauthorized data extraction rather than code execution.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
2 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.