Skip to content

Vendure

Bug bounty on Sorona vendure.io

Accepting reports open-source
Top reward
$1,500
Top severity paid
Critical
Assets in scope
14
Public CVEs
10
Last change
No changes yet

At a glance

What to know before you start testing.

Pays from $1,500
for critical bugs.
Partial safe harbor
Some legal protection; read the terms.
Publish after a fix
Coordinate the timing with the company.

Rewards

What Sorona lists as the payout for each severity.

Severity Reward
Critical $1,500+
High $700+
Medium $300+
Low $100 $100 / 1 month Claude Max
Safe harbor
Partial Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf.

Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original

Scope

14 assets you may test, 6 excluded.

Web 1

  • https://www.vendure.io

Products and areas 13

  • Asset upload and serving, including image transformation on request
  • Authentication and session handling, covering native and external authentication strategies, session tokens, API keys and the customer verification and password reset flows
  • Customer data: addresses, order history and stored payment method references
  • Payment method handlers and the webhook or callback path a gateway uses to report a settled payment
  • Promotions, discounts, surcharges, tax and shipping calculation, and the order total they produce
  • The Admin API and every operation a merchant operator can perform through it
  • The channel and seller model, where one instance serves several storefronts or a marketplace arrangement
  • The job queue and event bus, where an action on one entity schedules server-side work elsewhere
  • The order state machine and the active-order mechanism, including the session or token that ties an anonymous cart to a caller
  • The permission model spanning both APIs: roles, permissions, the customer and administrator boundary and the per-channel restrictions layered over them
  • The plugin architecture, including how a plugin registers GraphQL extensions, receives configuration and reaches the database
  • The published policy asks for private reports on Vendure and names no component carve-out, so the whole server is in scope, both APIs included
  • The Shop API, the anonymous and customer-authenticated GraphQL surface a storefront calls
Out of scope (6)
  • A role or channel permission an administrator granted deliberately
  • Community plugins maintained outside the Vendure repository
  • Deployment configuration, including an instance that exposes the Admin API where the documentation advises against it
  • Payment gateway providers' own systems, which are separate estates
  • Storefront code a merchant writes themselves, which is their application rather than Vendure
  • Upstream Node, NestJS and TypeORM dependency issues, unless Vendure's own use of the dependency is what makes the defect reachable

Rules

What the policy asks of you, and the bug types it won't reward, quoted from Sorona's policy.

While testing

  • Do not test against live merchant storefronts. Stand up your own instance with your own test data
  • Say which of the two APIs you reached the defect through.
  • State the Vendure version and which plugins were installed.
  • Give the channel and the role your session held.
  • Report through GitHub private vulnerability reporting on vendure-ecommerce/vendure, which is enabled, or by the channel named in the project's SECURITY.md

Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original

Changes

Tracked since 11 Nov 2026. Last checked 1 hour ago.

No changes yet. When the rewards or scope move, you will see it here and in the RSS feed.

Public CVEs

Published vulnerabilities in this vendor's products, from the NVD.

Search NVD
CVESeverityPublished
CVE-2026-25050 Low 2.7 30 Jan 2026
CVE-2022-23065 Medium 5.4 2 May 2022

Original policy

Copied from sorona.xyz on 12 Nov 2026. The summaries on this page are made from it; the live page may have changed since.

Skip to content What this pays This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability CVE history 6 Last 12 months 10 Lifetime Access control 38 % Business logic 24 % Info disclosure 22 % Auth/token handling 16 % Latest advisories Loading the feed Overview Vendure is a TypeScript headless-commerce backend, run as the order and inventory engine behind storefronts and apps that a merchant's team builds separately. It exposes two GraphQL APIs from one service, one for the shop and one for the administrator, so the boundary between a customer and a merchant operator is drawn inside a single process. Payment integrations live on the same side of that boundary. Six of its ten published advisories arrived in the last twelve months. The project takes private reports through GitHub and its security policy, offers no reward of any kind, and sorona.xyz pays you directly on qualified, reproduced findings. In scope The published policy asks for private reports on Vendure and names no component carve-out, so the whole server is in scope, both APIs included The Shop API, the anonymous and customer-authenticated GraphQL surface a storefront calls The Admin API and every operation a merchant operator can perform through it The permission model spanning both APIs: roles, permissions, the customer and administrator boundary and the per-channel restrictions layered over them The order state machine and the active-order mechanism, including the session or token that ties an anonymous cart to a caller Promotions, discounts, surcharges, tax and shipping calculation, and the order total they produce Payment method handlers and the webhook or callback path a gateway uses to report a settled payment The plugin architecture, including how a plugin registers GraphQL extensions, receives configuration and reaches the database Authentication and session handling, covering native and external authentication strategies, session tokens, API keys and the customer verification and password reset flows The channel and seller model, where one instance serves several storefronts or a marketplace arrangement Asset upload and serving, including image transformation on request The job queue and event bus, where an action on one entity schedules server-side work elsewhere Customer data: addresses, order history and stored payment method references Out of scope Storefront code a merchant writes themselves, which is their application rather than Vendure Community plugins maintained outside the Vendure repository Payment gateway providers' own systems, which are separate estates Upstream Node, NestJS and TypeORM dependency issues, unless Vendure's own use of the dependency is what makes the defect reachable Deployment configuration, including an instance that exposes the Admin API where the documentation advises against it A role or channel permission an administrator granted deliberately Most-valued findings Anything on the Shop API that reaches Admin API data or operations. Both run in one service and that boundary is the single most valuable thing to break on this product Active-order and session token handling, where a caller reaches another visitor's cart or a completed order they never placed Order total manipulation through promotions, surcharges, shipping or tax, producing a paid order for less than the goods are worth Payment handler and webhook forgery that settles an order without a genuine gateway response Cross-channel access, where a session scoped to one channel or seller reads or writes another's orders, customers or pricing Permission checks applied per resolver rather than uniformly, so one query or mutation returns data the role was never granted Plugin boundary defects, where a plugin's GraphQL extension inherits more access than its declared permissions Authentication defects across the native and external strategies, including customer verification and password reset token handling Asset serving and the image transformation path, both classic sources of path traversal and server-side request forgery in this kind of backend Unauthorised retrieval of customer records, addresses or order history through an unchecked identifier Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. Report through GitHub private vulnerability reporting on vendure-ecommerce/vendure, which is enabled, or by the channel named in the project's SECURITY.md Say which of the two APIs you reached the defect through. A Shop API finding is reachable by an anonymous visitor and is worth considerably more than the same shape on the Admin API State the Vendure version and which plugins were installed. Vendure deployments assemble plugins heavily, so a reproduction that needs a specific plugin is a different finding from one against core Give the channel and the role your session held. Authorisation here is per-permission and per-channel, so a report without both cannot be reproduced Do not test against live merchant storefronts. Stand up your own instance with your own test data There is no reward tier and no payment to negotiate Disclosure Coordinated privately through GitHub and published as a GitHub Security Advisory alongside a patched release. The advisory record is steady rather than heavy, six in the last year, and it shows a maintainer group that publishes rather than fixing silently. No fixed embargo length is stated. Time disclosure to the release carrying the fix, and account for merchants who pin a Vendure version inside their own application and upgrade on their own schedule. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability