Who should shortlist Shuup in 2026, and who should not
If you’re weighing Shuup for a new marketplace build, start here. The verdict below comes from Shuup’s own GitHub repository (opens in a new tab), its PyPI package (opens in a new tab), and its documentation, all checked as of 2026-07-21 against the versions listed above.
No team should start a new multi-vendor marketplace build on Shuup today. The evidence in this review supports skip, not shortlist, for greenfield work — the release history, the licensing gap, and the open security reports all point the same direction.
The only defensible use case this review found is a team already running an existing Shuup install under a signed Multivendor licence, doing maintenance rather than starting something new. That team has already absorbed the procurement and legal cost; walking away mid-contract carries its own risk.
The last stable release is v3.1.0 (opens in a new tab), published on GitHub and mirrored on PyPI on 2021-08-17. No release has shipped in the roughly five years since. The repository’s LICENSE and README carry a copyright notice spanning 2012-2021 with no later year added, which corroborates the release gap rather than just implying it.
This review separates two things that Shuup’s marketing runs together: what the free OSL-3.0 (opens in a new tab) core actually does, and what the “multi-vendor marketplace” positioning implies it does. Sections below treat those as separate questions with separate answers.
flowchart TD
A["Are you starting a new multi-vendor marketplace build?"] -->|Yes| B["Skip Shuup"]
A -->|"No — maintaining an existing Shuup install"| C{"Do you hold a signed Multivendor licence?"}
C -->|Yes| D["Continue maintenance, budget for an unsupported stack"]
C -->|No| B
You should now see: a one-sentence answer for your own situation — new build (skip) or existing licensed install (maintain, with eyes open) — before you read the pricing and architecture detail below.
What Shuup’s Multivendor addon actually costs, and why the price is undisclosed
The feature Shuup is named for is not in the free product. Shuup’s core ships under OSL-3.0 and is free to self-host, but the Multivendor module (opens in a new tab) sits outside that core. Shuup’s own guide states plainly that the feature “is currently only available through a license” — it is a separate, commercial product wrapped around the open-source base.
Getting that licence means emailing support@shuup.com directly. No list price, tier structure, or per-vendor cost is published anywhere audited for this review. That absence is itself the finding: a platform whose headline feature has no public price is asking you to open a sales conversation before you can scope a build, not after.
Total cost of ownership has three drivers once you account for this. First, the undisclosed commercial licence fee itself. Second, engineering time spent patching an unsupported Python 3.6-3.8 / Django 2.2 stack, since no upstream release will do that for you. Third, the cost of triaging any of the open 2026 security reports covered later in this review yourself, because nothing suggests upstream will do that on a predictable timeline either.
The common failure mode here is scoping mistake, not price shock. A team evaluates Shuup against the free core’s admin screens and tutorials, likes what it sees, and only discovers during build-out that vendor dashboards, per-vendor commission plans, and marketplace onboarding don’t exist without a signed commercial agreement. By then the evaluation budget is spent and the real procurement conversation hasn’t started.
This licensing guidance and the support contact were checked on 2026-07-21. Undisclosed commercial terms can change without a public changelog to track, so re-verify before you rely on anything in this section.
flowchart LR
subgraph Free["OSL-3.0 core — free, self-hosted"]
Catalog["Product catalog"]
Orders["Order management"]
Admin["Admin panel"]
API["REST API"]
end
subgraph Paid["Multivendor addon — undisclosed price"]
VendorDash["Vendor dashboards"]
Commission["Per-vendor commission plans"]
Onboarding["Marketplace onboarding"]
end
Free -. "contact support@shuup.com" .-> Paid
You should now see: the Multivendor module for what it is — an unpriced procurement step requiring a sales conversation, not a checkbox on a feature comparison table.
The architecture risk behind Shuup 3.1.0: Python, Django and a five-year release gap
The version numbers translate directly into operational risk, not just a stale-looking badge. Shuup’s documentation (opens in a new tab) states a minimum of Python 3.6+ and Django 2.2 LTS, and the PyPI package’s trove classifiers cap tested support at Python 3.8 — Shuup was never verified against anything newer.
Both floors are past their support window. Django 2.2’s extended support (opens in a new tab) ended 2022-04-11, and Python 3.8 reached end-of-life (opens in a new tab) on 2024-10-07. Neither receives security patches from its own upstream project as of this 2026 review, which means Shuup’s documented baseline is unsupported software running on top of unsupported software.
Django’s current LTS is 5.2, and its current stable release is 6.0.7. Shuup’s documented floor sits several major LTS cycles behind whatever Django release you’d install today, which is the gap you’d need to close yourself before running Shuup on a currently supported interpreter and framework pairing.
No release since v3.1.0 also means nothing has re-verified Shuup’s dependency pins — packages like django-mirage-field and django-parler-era — against any newer interpreter. Nobody upstream has run that compatibility check since 2021-08-17.
That shows up immediately at install time. pip install shuup only resolves cleanly against the Python versions the package classifiers list, and the native build step commonly fails on a modern OS image with an egg_info error on cairocffi, because current images lack the Cairo, Pango, and GDK-Pixbuf development libraries the package needs (tracked as issue #2615 (opens in a new tab)). Installation and Docker-compose failures recur across the issue tracker (opens in a new tab) from 2020 through 2024 — issues #2238, #2334, #2599, #2615, #2621, #2634, #2646 — without a consolidated fix, including a container startup failure reported as recently as 2024-09-28; treat that last date as medium confidence pending your own re-check.
flowchart LR
A["2021-08-17: Shuup v3.1.0 released"] --> B["2022-04-11: Django 2.2 extended support ends"]
B --> C["2024-10-07: Python 3.8 reaches end-of-life"]
C --> D["2026-07-21: This review — no release since v3.1.0"]
You should now see: which specific runtime and packaging failures to expect before you attempt an install, and why a routine pip install is not guaranteed to succeed on a current OS image.
What the OSL-3.0 licence obligates you to do if you host Shuup as a service
Shuup’s core carries a licence obligation that a permissive-licence habit will miss. It’s licensed under the Open Software License 3.0 (opens in a new tab) (OSL-3.0), an OSI-approved reciprocal licence — not a permissive MIT or BSD grant that lets you modify and redistribute with no strings attached.
Section 5 of OSL-3.0, “External Deployment,” is the clause that matters most for a hosted product. It treats making the software available for a third party to interact with over a network the same as distributing it, which triggers the same source-sharing obligation as Section 1(c). That’s an AGPL-like network-copyleft effect: exposure over a network counts as distribution even when you never ship a binary or a repo to anyone.
The practical consequence: if you run a modified Shuup instance as a SaaS-style service, that use obligates you to share the modified source with the users of that service. A permissive core wouldn’t require this; OSL-3.0 does.
This obligation is separate from and in addition to the Multivendor addon’s own commercial licence terms, which are undisclosed and negotiated directly with Shuup Commerce Inc. Clearing the OSL-3.0 network clause doesn’t touch the commercial licence question from the section above — you have to satisfy both independently.
Get a legal review of OSL-3.0 Section 5 specifically before building any hosted or managed-service business model on top of Shuup. This is not a clause to interpret from a blog post, including this one.
You should now see: whether your planned deployment model — self-hosted internal tool versus hosted multi-tenant service — triggers OSL-3.0’s source-sharing clause, and whether that’s a conversation for your legal team before engineering starts.
Where Shuup’s free core still earns its keep
None of the above erases what the free core is. It’s a genuinely inspectable, public codebase on GitHub (opens in a new tab) — not a source-available demo and not a fully closed product gated behind a login. You can read every line of it today without contacting anyone.
The project’s track record on fixing tracked vulnerabilities, while it was active, is real. Two historical CVEs — CVE-2021-25962 (opens in a new tab) (formula injection via the billing-address name field, exploitable through Excel report export) and CVE-2021-25963 (opens in a new tab) (reflected XSS in error pages) — were fixed in Shuup 2.11.0. Whatever the current maintenance state, the project did resolve disclosed vulnerabilities during its active period.
Shuup exposes a REST API built on Django REST Framework, with a “Provides” plugin-discovery mechanism for registering endpoints. That’s a documented extension surface, not a black box you’d have to reverse-engineer to integrate against.
And for a team already fluent in Python and Django, Shuup is a familiar codebase to read, audit, or fork — a different proposition from adopting a foundation written in a framework or language nobody on the team has touched.
You should now see: the specific, verifiable reasons the free core has value independent of the Multivendor addon and independent of the project’s maintenance gap — inspectable code, a resolved CVE history, a documented API surface, and a familiar stack.
Scoring Shuup’s modernity and AI/agent readiness against the CodeNx rubric
Two scores, worked component by component so you can recompute them from the same evidence rather than take a bare number on faith.
Modernity. Maintained runtime and dependency posture scores near zero: the documented floor of Python 3.6+ and Django 2.2 is years past end-of-life, and no release has shipped since 2021-08-17. Release activity and migration clarity also score near zero given that roughly five-year gap, with no visible roadmap or changelog activity on the releases page (opens in a new tab) to offset it. API-first boundaries score moderately — a genuine DRF-based REST API with a Provides plugin-discovery mechanism exists, but it’s undocumented against any current framework version, so integrators are working from 2021-era assumptions. Automated tests and CI visibility earn partial credit at best: the repository is public, but the recurring unresolved install and Docker failures from 2020 through 2024 suggest CI isn’t catching real-world installation regressions before they reach users.
AI/agent readiness. This scores at or near zero. No official MCP server, agent SDK, or GraphQL API turned up in the project’s documentation or its GitHub organisation during this pass — treat that as medium confidence, since an unofficial or community tool could exist outside what this review checked. A REST API alone doesn’t earn AI/agent-readiness credit on its own. Credit requires first-party tooling on top of it: a documented safe-write pattern, an auditability feature, something that makes the API usable by an autonomous caller rather than just a human developer reading Swagger docs. Shuup has none of that documented.
Put together, both scores land low for the same underlying reason: nothing has moved since 2021. A rubric built around active maintenance signals will read Shuup’s gap the same way regardless of which axis you’re measuring.
You should now see: exactly which rubric component drove each point gained or withheld, so you can push back on any part of this scoring with your own evidence rather than take the total on faith.
Production concern: six open 2026 security reports with no maintainer response
Here’s the thing a feature comparison table will never show you. As of 2026-07-21, the issue tracker (opens in a new tab) lists several open, unresolved security reports: a formal vendor-contact security review request (#2661 (opens in a new tab)), a shop-scoped authorization gap in the order-edit view (#2660), and open-redirect and stored-XSS findings (#2657, #2656, #2655), all filed in June and July 2026.
None of these show a visible maintainer response, label, or assignee as of the review date. That’s not “under investigation, no public update” — it’s no evidence of triage at all.
No CVE record exists for any of the 2026 disclosures. They remain unassigned issue-tracker reports, not tracked and patched vulnerabilities — a different status from the two 2021 CVEs that were fixed in Shuup 2.11.0. A CVE number means someone confirmed and catalogued the issue; these reports haven’t reached that stage.
Put the release gap and the report gap together and the conclusion is straightforward: no staffed security-response process is currently operating on this project. A “actively maintained” claim you read anywhere else about Shuup should be checked against the live tracker, not taken on trust, because a feature table will never surface an authorization gap or a stored-XSS report that’s been sitting open for weeks.
sequenceDiagram
participant R as Security researcher
participant GH as GitHub issue tracker
participant M as Shuup maintainers
R->>GH: Files #2661 (security review request)
R->>GH: Files #2660 (authorization gap)
R->>GH: Files #2657, #2656, #2655 (XSS, open redirect)
GH-->>M: Notification
Note over M: No label, assignee or comment as of 2026-07-21
You should now see: why checking the live issue tracker’s security-report activity yourself, right before you deploy, matters more than any maintenance claim in a README — especially for anything handling real customer or order data.
The five-question proof-of-concept checklist before you commit budget to Shuup
Run these five checks before any budget commitment, not after.
Question 1. Has a new stable release shipped since v3.1.0 (2021-08-17)? Check GitHub releases (opens in a new tab) and PyPI (opens in a new tab) directly, not marketing copy, before you scope anything.
Question 2. What exact price, licence term, and support SLA does Shuup Commerce Inc. quote for the Multivendor module when you email support@shuup.com? Get it in writing before you count on the feature existing in your build.
Question 3. Do the specific 2026 security reports — #2661, #2660, #2657, #2656, #2655 — show a maintainer response or a fix by the time you check, or are they still open with no assignee?
Question 4. Does your legal team accept OSL-3.0 Section 5’s network-copyleft obligation for your specific hosting or managed-service deployment model? Get that answer before, not after, you build.
Question 5. Can you get Shuup installed and running end-to-end in a disposable environment without hitting the recurring cairocffi or Docker install failures documented in the issue tracker (opens in a new tab)? If you can’t clear a clean install, nothing downstream matters.
You should now see: five yes/no checks to run against Shuup’s live repository and a real sales contact, before any of them turn into a line item in a project plan.
Limitations
This review did not run an independent penetration test against any of the 2026-reported issues (#2661, #2660, #2657, #2656, #2655); it reports their tracker status as found, not their exploitability. The Multivendor licence price could not be obtained without direct sales contact, so no number appears anywhere in this article — treat that absence as the finding, not an oversight.
Every issue-tracker status cited here is a dated snapshot from 2026-07-21. GitHub issues, unlike CVE records, can be labelled, closed, or answered at any time with no changelog entry marking the change — re-check the tracker (opens in a new tab) and the pull requests (opens in a new tab) yourself before deciding anything based on this review. This review also did not attempt a live installation on a current OS image; the cairocffi and Docker failures are drawn from the issue tracker, not reproduced first-hand, and results from your own environment may differ.