sylius/mollie-plugin
Mollie payment plugin for Sylius applications.
Activity
- Latest release
- 1w ago
- Total releases
- 38
- Cadence
- ~6 days
- Last 12 months
- 24
Reach
- Stars
- 9
Details
- License
- MIT
- First release
- Mar 24, 2025
| Version | Released | |
|---|---|---|
v3.3.4
patch
| ||
v3.3.3
patch
| ||
v3.2.6
patch
| ||
v2.2.9
patch
|
v2.2.9
patch
Dependencies (9)
+ 1 more
Changelog
Compare changes
|
|
v3.3.2
patch
| ||
v3.2.5
patch
| ||
v3.3.1
patch
| ||
v3.2.4
patch
| ||
v2.2.8
patch
| ||
v3.3.0
minor
2 CVEs
CVE-2026-68501
GHSA-x83g-979r-f5fh
Jul 31, 2026
Sylius Mollie Plugin has unauthenticated IDOR that leaks order token and customer PII
6.5
/ 10
Medium
Network
Low
None
None
Unchanged
Low
None
Low
ImpactTwo unauthenticated Mollie shop endpoints look up orders by a sequential integer
That None of the plugin endpoints require a login, session or CSRF token. PatchesFixed in 2.2.8, 3.2.4 and 3.3.1. WorkaroundsIf you cannot upgrade immediately, patch both endpoints at the project level by decorating
the plugin controllers. The decorators enforce ownership before delegating to the original
controller, so no plugin behaviour is lost. They keep the original Step 1. Decorate the QR code controllerCreate
Step 2. Decorate the thank-you controllerCreate
Step 3. Register the decoratorsAppend to your project's
Step 4. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev
CVE-2026-68500
GHSA-rc52-c4hv-w89p
Jul 31, 2026
Sylius Mollie Plugin vulnerable to payment status forgery via the payment webhook
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
High
None
ImpactThe shop payment webhook An unauthenticated attacker who holds any valid paid Mollie payment ID, for example
from a EUR 1 order they placed themselves, can submit it together with any victim
PatchesFixed in versions 2.2.8, 3.2.4 and 3.3.1. The webhook now binds the payment to
the order: it reads the Mollie payment ID stored server-side for that order when the payment
was created and compares it to the incoming Mollie payment ID. On mismatch the request is
acknowledged with The stored ID lives in one of two places depending on the checkout flow, and the fix reads
both of them (mirroring
Reading only the payment details would reject legitimate QR-code payments, because their
payment details carry no WorkaroundsIf you cannot upgrade immediately, patch the vulnerability at the project level by decorating the plugin's webhook controller. The decorator checks that the incoming Mollie id matches the id stored for that order before handing over to the original controller, so no plugin behaviour (state machine, logging) is lost and no extra Mollie API call is made. Works on both 2.2 and 3.x. Step 1. Create the decoratorCreate
Step 2. Register the decoratorAppend to your project's
Step 3. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev | ||
v3.2.3
patch
2 CVEs
CVE-2026-68501
GHSA-x83g-979r-f5fh
Jul 31, 2026
Sylius Mollie Plugin has unauthenticated IDOR that leaks order token and customer PII
6.5
/ 10
Medium
Network
Low
None
None
Unchanged
Low
None
Low
ImpactTwo unauthenticated Mollie shop endpoints look up orders by a sequential integer
That None of the plugin endpoints require a login, session or CSRF token. PatchesFixed in 2.2.8, 3.2.4 and 3.3.1. WorkaroundsIf you cannot upgrade immediately, patch both endpoints at the project level by decorating
the plugin controllers. The decorators enforce ownership before delegating to the original
controller, so no plugin behaviour is lost. They keep the original Step 1. Decorate the QR code controllerCreate
Step 2. Decorate the thank-you controllerCreate
Step 3. Register the decoratorsAppend to your project's
Step 4. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev
CVE-2026-68500
GHSA-rc52-c4hv-w89p
Jul 31, 2026
Sylius Mollie Plugin vulnerable to payment status forgery via the payment webhook
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
High
None
ImpactThe shop payment webhook An unauthenticated attacker who holds any valid paid Mollie payment ID, for example
from a EUR 1 order they placed themselves, can submit it together with any victim
PatchesFixed in versions 2.2.8, 3.2.4 and 3.3.1. The webhook now binds the payment to
the order: it reads the Mollie payment ID stored server-side for that order when the payment
was created and compares it to the incoming Mollie payment ID. On mismatch the request is
acknowledged with The stored ID lives in one of two places depending on the checkout flow, and the fix reads
both of them (mirroring
Reading only the payment details would reject legitimate QR-code payments, because their
payment details carry no WorkaroundsIf you cannot upgrade immediately, patch the vulnerability at the project level by decorating the plugin's webhook controller. The decorator checks that the incoming Mollie id matches the id stored for that order before handing over to the original controller, so no plugin behaviour (state machine, logging) is lost and no extra Mollie API call is made. Works on both 2.2 and 3.x. Step 1. Create the decoratorCreate
Step 2. Register the decoratorAppend to your project's
Step 3. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev | ||
v3.2.2
patch
2 CVEs
CVE-2026-68501
GHSA-x83g-979r-f5fh
Jul 31, 2026
Sylius Mollie Plugin has unauthenticated IDOR that leaks order token and customer PII
6.5
/ 10
Medium
Network
Low
None
None
Unchanged
Low
None
Low
ImpactTwo unauthenticated Mollie shop endpoints look up orders by a sequential integer
That None of the plugin endpoints require a login, session or CSRF token. PatchesFixed in 2.2.8, 3.2.4 and 3.3.1. WorkaroundsIf you cannot upgrade immediately, patch both endpoints at the project level by decorating
the plugin controllers. The decorators enforce ownership before delegating to the original
controller, so no plugin behaviour is lost. They keep the original Step 1. Decorate the QR code controllerCreate
Step 2. Decorate the thank-you controllerCreate
Step 3. Register the decoratorsAppend to your project's
Step 4. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev
CVE-2026-68500
GHSA-rc52-c4hv-w89p
Jul 31, 2026
Sylius Mollie Plugin vulnerable to payment status forgery via the payment webhook
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
High
None
ImpactThe shop payment webhook An unauthenticated attacker who holds any valid paid Mollie payment ID, for example
from a EUR 1 order they placed themselves, can submit it together with any victim
PatchesFixed in versions 2.2.8, 3.2.4 and 3.3.1. The webhook now binds the payment to
the order: it reads the Mollie payment ID stored server-side for that order when the payment
was created and compares it to the incoming Mollie payment ID. On mismatch the request is
acknowledged with The stored ID lives in one of two places depending on the checkout flow, and the fix reads
both of them (mirroring
Reading only the payment details would reject legitimate QR-code payments, because their
payment details carry no WorkaroundsIf you cannot upgrade immediately, patch the vulnerability at the project level by decorating the plugin's webhook controller. The decorator checks that the incoming Mollie id matches the id stored for that order before handing over to the original controller, so no plugin behaviour (state machine, logging) is lost and no extra Mollie API call is made. Works on both 2.2 and 3.x. Step 1. Create the decoratorCreate
Step 2. Register the decoratorAppend to your project's
Step 3. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev | ||
v2.2.7
patch
2 CVEs
CVE-2026-68501
GHSA-x83g-979r-f5fh
Jul 31, 2026
Sylius Mollie Plugin has unauthenticated IDOR that leaks order token and customer PII
6.5
/ 10
Medium
Network
Low
None
None
Unchanged
Low
None
Low
ImpactTwo unauthenticated Mollie shop endpoints look up orders by a sequential integer
That None of the plugin endpoints require a login, session or CSRF token. PatchesFixed in 2.2.8, 3.2.4 and 3.3.1. WorkaroundsIf you cannot upgrade immediately, patch both endpoints at the project level by decorating
the plugin controllers. The decorators enforce ownership before delegating to the original
controller, so no plugin behaviour is lost. They keep the original Step 1. Decorate the QR code controllerCreate
Step 2. Decorate the thank-you controllerCreate
Step 3. Register the decoratorsAppend to your project's
Step 4. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev
CVE-2026-68500
GHSA-rc52-c4hv-w89p
Jul 31, 2026
Sylius Mollie Plugin vulnerable to payment status forgery via the payment webhook
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
High
None
ImpactThe shop payment webhook An unauthenticated attacker who holds any valid paid Mollie payment ID, for example
from a EUR 1 order they placed themselves, can submit it together with any victim
PatchesFixed in versions 2.2.8, 3.2.4 and 3.3.1. The webhook now binds the payment to
the order: it reads the Mollie payment ID stored server-side for that order when the payment
was created and compares it to the incoming Mollie payment ID. On mismatch the request is
acknowledged with The stored ID lives in one of two places depending on the checkout flow, and the fix reads
both of them (mirroring
Reading only the payment details would reject legitimate QR-code payments, because their
payment details carry no WorkaroundsIf you cannot upgrade immediately, patch the vulnerability at the project level by decorating the plugin's webhook controller. The decorator checks that the incoming Mollie id matches the id stored for that order before handing over to the original controller, so no plugin behaviour (state machine, logging) is lost and no extra Mollie API call is made. Works on both 2.2 and 3.x. Step 1. Create the decoratorCreate
Step 2. Register the decoratorAppend to your project's
Step 3. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev | ||
v3.2.1
patch
2 CVEs
CVE-2026-68501
GHSA-x83g-979r-f5fh
Jul 31, 2026
Sylius Mollie Plugin has unauthenticated IDOR that leaks order token and customer PII
6.5
/ 10
Medium
Network
Low
None
None
Unchanged
Low
None
Low
ImpactTwo unauthenticated Mollie shop endpoints look up orders by a sequential integer
That None of the plugin endpoints require a login, session or CSRF token. PatchesFixed in 2.2.8, 3.2.4 and 3.3.1. WorkaroundsIf you cannot upgrade immediately, patch both endpoints at the project level by decorating
the plugin controllers. The decorators enforce ownership before delegating to the original
controller, so no plugin behaviour is lost. They keep the original Step 1. Decorate the QR code controllerCreate
Step 2. Decorate the thank-you controllerCreate
Step 3. Register the decoratorsAppend to your project's
Step 4. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev
CVE-2026-68500
GHSA-rc52-c4hv-w89p
Jul 31, 2026
Sylius Mollie Plugin vulnerable to payment status forgery via the payment webhook
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
High
None
ImpactThe shop payment webhook An unauthenticated attacker who holds any valid paid Mollie payment ID, for example
from a EUR 1 order they placed themselves, can submit it together with any victim
PatchesFixed in versions 2.2.8, 3.2.4 and 3.3.1. The webhook now binds the payment to
the order: it reads the Mollie payment ID stored server-side for that order when the payment
was created and compares it to the incoming Mollie payment ID. On mismatch the request is
acknowledged with The stored ID lives in one of two places depending on the checkout flow, and the fix reads
both of them (mirroring
Reading only the payment details would reject legitimate QR-code payments, because their
payment details carry no WorkaroundsIf you cannot upgrade immediately, patch the vulnerability at the project level by decorating the plugin's webhook controller. The decorator checks that the incoming Mollie id matches the id stored for that order before handing over to the original controller, so no plugin behaviour (state machine, logging) is lost and no extra Mollie API call is made. Works on both 2.2 and 3.x. Step 1. Create the decoratorCreate
Step 2. Register the decoratorAppend to your project's
Step 3. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev | ||
v3.1.2
patch
2 CVEs
CVE-2026-68501
GHSA-x83g-979r-f5fh
Jul 31, 2026
Sylius Mollie Plugin has unauthenticated IDOR that leaks order token and customer PII
6.5
/ 10
Medium
Network
Low
None
None
Unchanged
Low
None
Low
ImpactTwo unauthenticated Mollie shop endpoints look up orders by a sequential integer
That None of the plugin endpoints require a login, session or CSRF token. PatchesFixed in 2.2.8, 3.2.4 and 3.3.1. WorkaroundsIf you cannot upgrade immediately, patch both endpoints at the project level by decorating
the plugin controllers. The decorators enforce ownership before delegating to the original
controller, so no plugin behaviour is lost. They keep the original Step 1. Decorate the QR code controllerCreate
Step 2. Decorate the thank-you controllerCreate
Step 3. Register the decoratorsAppend to your project's
Step 4. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev
CVE-2026-68500
GHSA-rc52-c4hv-w89p
Jul 31, 2026
Sylius Mollie Plugin vulnerable to payment status forgery via the payment webhook
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
High
None
ImpactThe shop payment webhook An unauthenticated attacker who holds any valid paid Mollie payment ID, for example
from a EUR 1 order they placed themselves, can submit it together with any victim
PatchesFixed in versions 2.2.8, 3.2.4 and 3.3.1. The webhook now binds the payment to
the order: it reads the Mollie payment ID stored server-side for that order when the payment
was created and compares it to the incoming Mollie payment ID. On mismatch the request is
acknowledged with The stored ID lives in one of two places depending on the checkout flow, and the fix reads
both of them (mirroring
Reading only the payment details would reject legitimate QR-code payments, because their
payment details carry no WorkaroundsIf you cannot upgrade immediately, patch the vulnerability at the project level by decorating the plugin's webhook controller. The decorator checks that the incoming Mollie id matches the id stored for that order before handing over to the original controller, so no plugin behaviour (state machine, logging) is lost and no extra Mollie API call is made. Works on both 2.2 and 3.x. Step 1. Create the decoratorCreate
Step 2. Register the decoratorAppend to your project's
Step 3. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev | ||
v3.0.3
patch
2 CVEs
CVE-2026-68501
GHSA-x83g-979r-f5fh
Jul 31, 2026
Sylius Mollie Plugin has unauthenticated IDOR that leaks order token and customer PII
6.5
/ 10
Medium
Network
Low
None
None
Unchanged
Low
None
Low
ImpactTwo unauthenticated Mollie shop endpoints look up orders by a sequential integer
That None of the plugin endpoints require a login, session or CSRF token. PatchesFixed in 2.2.8, 3.2.4 and 3.3.1. WorkaroundsIf you cannot upgrade immediately, patch both endpoints at the project level by decorating
the plugin controllers. The decorators enforce ownership before delegating to the original
controller, so no plugin behaviour is lost. They keep the original Step 1. Decorate the QR code controllerCreate
Step 2. Decorate the thank-you controllerCreate
Step 3. Register the decoratorsAppend to your project's
Step 4. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev
CVE-2026-68500
GHSA-rc52-c4hv-w89p
Jul 31, 2026
Sylius Mollie Plugin vulnerable to payment status forgery via the payment webhook
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
High
None
ImpactThe shop payment webhook An unauthenticated attacker who holds any valid paid Mollie payment ID, for example
from a EUR 1 order they placed themselves, can submit it together with any victim
PatchesFixed in versions 2.2.8, 3.2.4 and 3.3.1. The webhook now binds the payment to
the order: it reads the Mollie payment ID stored server-side for that order when the payment
was created and compares it to the incoming Mollie payment ID. On mismatch the request is
acknowledged with The stored ID lives in one of two places depending on the checkout flow, and the fix reads
both of them (mirroring
Reading only the payment details would reject legitimate QR-code payments, because their
payment details carry no WorkaroundsIf you cannot upgrade immediately, patch the vulnerability at the project level by decorating the plugin's webhook controller. The decorator checks that the incoming Mollie id matches the id stored for that order before handing over to the original controller, so no plugin behaviour (state machine, logging) is lost and no extra Mollie API call is made. Works on both 2.2 and 3.x. Step 1. Create the decoratorCreate
Step 2. Register the decoratorAppend to your project's
Step 3. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev | ||
v2.2.6
patch
2 CVEs
CVE-2026-68501
GHSA-x83g-979r-f5fh
Jul 31, 2026
Sylius Mollie Plugin has unauthenticated IDOR that leaks order token and customer PII
6.5
/ 10
Medium
Network
Low
None
None
Unchanged
Low
None
Low
ImpactTwo unauthenticated Mollie shop endpoints look up orders by a sequential integer
That None of the plugin endpoints require a login, session or CSRF token. PatchesFixed in 2.2.8, 3.2.4 and 3.3.1. WorkaroundsIf you cannot upgrade immediately, patch both endpoints at the project level by decorating
the plugin controllers. The decorators enforce ownership before delegating to the original
controller, so no plugin behaviour is lost. They keep the original Step 1. Decorate the QR code controllerCreate
Step 2. Decorate the thank-you controllerCreate
Step 3. Register the decoratorsAppend to your project's
Step 4. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev
CVE-2026-68500
GHSA-rc52-c4hv-w89p
Jul 31, 2026
Sylius Mollie Plugin vulnerable to payment status forgery via the payment webhook
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
High
None
ImpactThe shop payment webhook An unauthenticated attacker who holds any valid paid Mollie payment ID, for example
from a EUR 1 order they placed themselves, can submit it together with any victim
PatchesFixed in versions 2.2.8, 3.2.4 and 3.3.1. The webhook now binds the payment to
the order: it reads the Mollie payment ID stored server-side for that order when the payment
was created and compares it to the incoming Mollie payment ID. On mismatch the request is
acknowledged with The stored ID lives in one of two places depending on the checkout flow, and the fix reads
both of them (mirroring
Reading only the payment details would reject legitimate QR-code payments, because their
payment details carry no WorkaroundsIf you cannot upgrade immediately, patch the vulnerability at the project level by decorating the plugin's webhook controller. The decorator checks that the incoming Mollie id matches the id stored for that order before handing over to the original controller, so no plugin behaviour (state machine, logging) is lost and no extra Mollie API call is made. Works on both 2.2 and 3.x. Step 1. Create the decoratorCreate
Step 2. Register the decoratorAppend to your project's
Step 3. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev | ||
v2.1.1
patch
2 CVEs
CVE-2026-68501
GHSA-x83g-979r-f5fh
Jul 31, 2026
Sylius Mollie Plugin has unauthenticated IDOR that leaks order token and customer PII
6.5
/ 10
Medium
Network
Low
None
None
Unchanged
Low
None
Low
ImpactTwo unauthenticated Mollie shop endpoints look up orders by a sequential integer
That None of the plugin endpoints require a login, session or CSRF token. PatchesFixed in 2.2.8, 3.2.4 and 3.3.1. WorkaroundsIf you cannot upgrade immediately, patch both endpoints at the project level by decorating
the plugin controllers. The decorators enforce ownership before delegating to the original
controller, so no plugin behaviour is lost. They keep the original Step 1. Decorate the QR code controllerCreate
Step 2. Decorate the thank-you controllerCreate
Step 3. Register the decoratorsAppend to your project's
Step 4. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev
CVE-2026-68500
GHSA-rc52-c4hv-w89p
Jul 31, 2026
Sylius Mollie Plugin vulnerable to payment status forgery via the payment webhook
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
High
None
ImpactThe shop payment webhook An unauthenticated attacker who holds any valid paid Mollie payment ID, for example
from a EUR 1 order they placed themselves, can submit it together with any victim
PatchesFixed in versions 2.2.8, 3.2.4 and 3.3.1. The webhook now binds the payment to
the order: it reads the Mollie payment ID stored server-side for that order when the payment
was created and compares it to the incoming Mollie payment ID. On mismatch the request is
acknowledged with The stored ID lives in one of two places depending on the checkout flow, and the fix reads
both of them (mirroring
Reading only the payment details would reject legitimate QR-code payments, because their
payment details carry no WorkaroundsIf you cannot upgrade immediately, patch the vulnerability at the project level by decorating the plugin's webhook controller. The decorator checks that the incoming Mollie id matches the id stored for that order before handing over to the original controller, so no plugin behaviour (state machine, logging) is lost and no extra Mollie API call is made. Works on both 2.2 and 3.x. Step 1. Create the decoratorCreate
Step 2. Register the decoratorAppend to your project's
Step 3. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev |
v2.1.1
patch
Dependencies (9)
+ 1 more
Changelog
Compare changes
|
|
v2.0.2
patch
2 CVEs
CVE-2026-68501
GHSA-x83g-979r-f5fh
Jul 31, 2026
Sylius Mollie Plugin has unauthenticated IDOR that leaks order token and customer PII
6.5
/ 10
Medium
Network
Low
None
None
Unchanged
Low
None
Low
ImpactTwo unauthenticated Mollie shop endpoints look up orders by a sequential integer
That None of the plugin endpoints require a login, session or CSRF token. PatchesFixed in 2.2.8, 3.2.4 and 3.3.1. WorkaroundsIf you cannot upgrade immediately, patch both endpoints at the project level by decorating
the plugin controllers. The decorators enforce ownership before delegating to the original
controller, so no plugin behaviour is lost. They keep the original Step 1. Decorate the QR code controllerCreate
Step 2. Decorate the thank-you controllerCreate
Step 3. Register the decoratorsAppend to your project's
Step 4. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev
CVE-2026-68500
GHSA-rc52-c4hv-w89p
Jul 31, 2026
Sylius Mollie Plugin vulnerable to payment status forgery via the payment webhook
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
High
None
ImpactThe shop payment webhook An unauthenticated attacker who holds any valid paid Mollie payment ID, for example
from a EUR 1 order they placed themselves, can submit it together with any victim
PatchesFixed in versions 2.2.8, 3.2.4 and 3.3.1. The webhook now binds the payment to
the order: it reads the Mollie payment ID stored server-side for that order when the payment
was created and compares it to the incoming Mollie payment ID. On mismatch the request is
acknowledged with The stored ID lives in one of two places depending on the checkout flow, and the fix reads
both of them (mirroring
Reading only the payment details would reject legitimate QR-code payments, because their
payment details carry no WorkaroundsIf you cannot upgrade immediately, patch the vulnerability at the project level by decorating the plugin's webhook controller. The decorator checks that the incoming Mollie id matches the id stored for that order before handing over to the original controller, so no plugin behaviour (state machine, logging) is lost and no extra Mollie API call is made. Works on both 2.2 and 3.x. Step 1. Create the decoratorCreate
Step 2. Register the decoratorAppend to your project's
Step 3. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev |
v2.0.2
patch
Dependencies (9)
+ 1 more
Changelog
Compare changes
|
|
v1.0.2
patch
2 CVEs
CVE-2026-68501
GHSA-x83g-979r-f5fh
Jul 31, 2026
Sylius Mollie Plugin has unauthenticated IDOR that leaks order token and customer PII
6.5
/ 10
Medium
Network
Low
None
None
Unchanged
Low
None
Low
ImpactTwo unauthenticated Mollie shop endpoints look up orders by a sequential integer
That None of the plugin endpoints require a login, session or CSRF token. PatchesFixed in 2.2.8, 3.2.4 and 3.3.1. WorkaroundsIf you cannot upgrade immediately, patch both endpoints at the project level by decorating
the plugin controllers. The decorators enforce ownership before delegating to the original
controller, so no plugin behaviour is lost. They keep the original Step 1. Decorate the QR code controllerCreate
Step 2. Decorate the thank-you controllerCreate
Step 3. Register the decoratorsAppend to your project's
Step 4. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev
CVE-2026-68500
GHSA-rc52-c4hv-w89p
Jul 31, 2026
Sylius Mollie Plugin vulnerable to payment status forgery via the payment webhook
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
High
None
ImpactThe shop payment webhook An unauthenticated attacker who holds any valid paid Mollie payment ID, for example
from a EUR 1 order they placed themselves, can submit it together with any victim
PatchesFixed in versions 2.2.8, 3.2.4 and 3.3.1. The webhook now binds the payment to
the order: it reads the Mollie payment ID stored server-side for that order when the payment
was created and compares it to the incoming Mollie payment ID. On mismatch the request is
acknowledged with The stored ID lives in one of two places depending on the checkout flow, and the fix reads
both of them (mirroring
Reading only the payment details would reject legitimate QR-code payments, because their
payment details carry no WorkaroundsIf you cannot upgrade immediately, patch the vulnerability at the project level by decorating the plugin's webhook controller. The decorator checks that the incoming Mollie id matches the id stored for that order before handing over to the original controller, so no plugin behaviour (state machine, logging) is lost and no extra Mollie API call is made. Works on both 2.2 and 3.x. Step 1. Create the decoratorCreate
Step 2. Register the decoratorAppend to your project's
Step 3. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev |
v1.0.2
patch
Dependencies (10)
+ 2 more
Changelog
Compare changes
|
|
v2.2.5
patch
2 CVEs
CVE-2026-68501
GHSA-x83g-979r-f5fh
Jul 31, 2026
Sylius Mollie Plugin has unauthenticated IDOR that leaks order token and customer PII
6.5
/ 10
Medium
Network
Low
None
None
Unchanged
Low
None
Low
ImpactTwo unauthenticated Mollie shop endpoints look up orders by a sequential integer
That None of the plugin endpoints require a login, session or CSRF token. PatchesFixed in 2.2.8, 3.2.4 and 3.3.1. WorkaroundsIf you cannot upgrade immediately, patch both endpoints at the project level by decorating
the plugin controllers. The decorators enforce ownership before delegating to the original
controller, so no plugin behaviour is lost. They keep the original Step 1. Decorate the QR code controllerCreate
Step 2. Decorate the thank-you controllerCreate
Step 3. Register the decoratorsAppend to your project's
Step 4. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev
CVE-2026-68500
GHSA-rc52-c4hv-w89p
Jul 31, 2026
Sylius Mollie Plugin vulnerable to payment status forgery via the payment webhook
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
High
None
ImpactThe shop payment webhook An unauthenticated attacker who holds any valid paid Mollie payment ID, for example
from a EUR 1 order they placed themselves, can submit it together with any victim
PatchesFixed in versions 2.2.8, 3.2.4 and 3.3.1. The webhook now binds the payment to
the order: it reads the Mollie payment ID stored server-side for that order when the payment
was created and compares it to the incoming Mollie payment ID. On mismatch the request is
acknowledged with The stored ID lives in one of two places depending on the checkout flow, and the fix reads
both of them (mirroring
Reading only the payment details would reject legitimate QR-code payments, because their
payment details carry no WorkaroundsIf you cannot upgrade immediately, patch the vulnerability at the project level by decorating the plugin's webhook controller. The decorator checks that the incoming Mollie id matches the id stored for that order before handing over to the original controller, so no plugin behaviour (state machine, logging) is lost and no extra Mollie API call is made. Works on both 2.2 and 3.x. Step 1. Create the decoratorCreate
Step 2. Register the decoratorAppend to your project's
Step 3. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev |
v2.2.5
patch
Dependencies (8)
Changelog
Compare changes
|
|
v2.2.4
patch
2 CVEs
CVE-2026-68501
GHSA-x83g-979r-f5fh
Jul 31, 2026
Sylius Mollie Plugin has unauthenticated IDOR that leaks order token and customer PII
6.5
/ 10
Medium
Network
Low
None
None
Unchanged
Low
None
Low
ImpactTwo unauthenticated Mollie shop endpoints look up orders by a sequential integer
That None of the plugin endpoints require a login, session or CSRF token. PatchesFixed in 2.2.8, 3.2.4 and 3.3.1. WorkaroundsIf you cannot upgrade immediately, patch both endpoints at the project level by decorating
the plugin controllers. The decorators enforce ownership before delegating to the original
controller, so no plugin behaviour is lost. They keep the original Step 1. Decorate the QR code controllerCreate
Step 2. Decorate the thank-you controllerCreate
Step 3. Register the decoratorsAppend to your project's
Step 4. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev
CVE-2026-68500
GHSA-rc52-c4hv-w89p
Jul 31, 2026
Sylius Mollie Plugin vulnerable to payment status forgery via the payment webhook
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
High
None
ImpactThe shop payment webhook An unauthenticated attacker who holds any valid paid Mollie payment ID, for example
from a EUR 1 order they placed themselves, can submit it together with any victim
PatchesFixed in versions 2.2.8, 3.2.4 and 3.3.1. The webhook now binds the payment to
the order: it reads the Mollie payment ID stored server-side for that order when the payment
was created and compares it to the incoming Mollie payment ID. On mismatch the request is
acknowledged with The stored ID lives in one of two places depending on the checkout flow, and the fix reads
both of them (mirroring
Reading only the payment details would reject legitimate QR-code payments, because their
payment details carry no WorkaroundsIf you cannot upgrade immediately, patch the vulnerability at the project level by decorating the plugin's webhook controller. The decorator checks that the incoming Mollie id matches the id stored for that order before handing over to the original controller, so no plugin behaviour (state machine, logging) is lost and no extra Mollie API call is made. Works on both 2.2 and 3.x. Step 1. Create the decoratorCreate
Step 2. Register the decoratorAppend to your project's
Step 3. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev | ||
v3.2.0
minor
2 CVEs
CVE-2026-68501
GHSA-x83g-979r-f5fh
Jul 31, 2026
Sylius Mollie Plugin has unauthenticated IDOR that leaks order token and customer PII
6.5
/ 10
Medium
Network
Low
None
None
Unchanged
Low
None
Low
ImpactTwo unauthenticated Mollie shop endpoints look up orders by a sequential integer
That None of the plugin endpoints require a login, session or CSRF token. PatchesFixed in 2.2.8, 3.2.4 and 3.3.1. WorkaroundsIf you cannot upgrade immediately, patch both endpoints at the project level by decorating
the plugin controllers. The decorators enforce ownership before delegating to the original
controller, so no plugin behaviour is lost. They keep the original Step 1. Decorate the QR code controllerCreate
Step 2. Decorate the thank-you controllerCreate
Step 3. Register the decoratorsAppend to your project's
Step 4. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev
CVE-2026-68500
GHSA-rc52-c4hv-w89p
Jul 31, 2026
Sylius Mollie Plugin vulnerable to payment status forgery via the payment webhook
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
High
None
ImpactThe shop payment webhook An unauthenticated attacker who holds any valid paid Mollie payment ID, for example
from a EUR 1 order they placed themselves, can submit it together with any victim
PatchesFixed in versions 2.2.8, 3.2.4 and 3.3.1. The webhook now binds the payment to
the order: it reads the Mollie payment ID stored server-side for that order when the payment
was created and compares it to the incoming Mollie payment ID. On mismatch the request is
acknowledged with The stored ID lives in one of two places depending on the checkout flow, and the fix reads
both of them (mirroring
Reading only the payment details would reject legitimate QR-code payments, because their
payment details carry no WorkaroundsIf you cannot upgrade immediately, patch the vulnerability at the project level by decorating the plugin's webhook controller. The decorator checks that the incoming Mollie id matches the id stored for that order before handing over to the original controller, so no plugin behaviour (state machine, logging) is lost and no extra Mollie API call is made. Works on both 2.2 and 3.x. Step 1. Create the decoratorCreate
Step 2. Register the decoratorAppend to your project's
Step 3. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev | ||
v2.2.3
patch
2 CVEs
CVE-2026-68501
GHSA-x83g-979r-f5fh
Jul 31, 2026
Sylius Mollie Plugin has unauthenticated IDOR that leaks order token and customer PII
6.5
/ 10
Medium
Network
Low
None
None
Unchanged
Low
None
Low
ImpactTwo unauthenticated Mollie shop endpoints look up orders by a sequential integer
That None of the plugin endpoints require a login, session or CSRF token. PatchesFixed in 2.2.8, 3.2.4 and 3.3.1. WorkaroundsIf you cannot upgrade immediately, patch both endpoints at the project level by decorating
the plugin controllers. The decorators enforce ownership before delegating to the original
controller, so no plugin behaviour is lost. They keep the original Step 1. Decorate the QR code controllerCreate
Step 2. Decorate the thank-you controllerCreate
Step 3. Register the decoratorsAppend to your project's
Step 4. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev
CVE-2026-68500
GHSA-rc52-c4hv-w89p
Jul 31, 2026
Sylius Mollie Plugin vulnerable to payment status forgery via the payment webhook
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
High
None
ImpactThe shop payment webhook An unauthenticated attacker who holds any valid paid Mollie payment ID, for example
from a EUR 1 order they placed themselves, can submit it together with any victim
PatchesFixed in versions 2.2.8, 3.2.4 and 3.3.1. The webhook now binds the payment to
the order: it reads the Mollie payment ID stored server-side for that order when the payment
was created and compares it to the incoming Mollie payment ID. On mismatch the request is
acknowledged with The stored ID lives in one of two places depending on the checkout flow, and the fix reads
both of them (mirroring
Reading only the payment details would reject legitimate QR-code payments, because their
payment details carry no WorkaroundsIf you cannot upgrade immediately, patch the vulnerability at the project level by decorating the plugin's webhook controller. The decorator checks that the incoming Mollie id matches the id stored for that order before handing over to the original controller, so no plugin behaviour (state machine, logging) is lost and no extra Mollie API call is made. Works on both 2.2 and 3.x. Step 1. Create the decoratorCreate
Step 2. Register the decoratorAppend to your project's
Step 3. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev | ||
v2.2.2
patch
2 CVEs
CVE-2026-68501
GHSA-x83g-979r-f5fh
Jul 31, 2026
Sylius Mollie Plugin has unauthenticated IDOR that leaks order token and customer PII
6.5
/ 10
Medium
Network
Low
None
None
Unchanged
Low
None
Low
ImpactTwo unauthenticated Mollie shop endpoints look up orders by a sequential integer
That None of the plugin endpoints require a login, session or CSRF token. PatchesFixed in 2.2.8, 3.2.4 and 3.3.1. WorkaroundsIf you cannot upgrade immediately, patch both endpoints at the project level by decorating
the plugin controllers. The decorators enforce ownership before delegating to the original
controller, so no plugin behaviour is lost. They keep the original Step 1. Decorate the QR code controllerCreate
Step 2. Decorate the thank-you controllerCreate
Step 3. Register the decoratorsAppend to your project's
Step 4. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev
CVE-2026-68500
GHSA-rc52-c4hv-w89p
Jul 31, 2026
Sylius Mollie Plugin vulnerable to payment status forgery via the payment webhook
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
High
None
ImpactThe shop payment webhook An unauthenticated attacker who holds any valid paid Mollie payment ID, for example
from a EUR 1 order they placed themselves, can submit it together with any victim
PatchesFixed in versions 2.2.8, 3.2.4 and 3.3.1. The webhook now binds the payment to
the order: it reads the Mollie payment ID stored server-side for that order when the payment
was created and compares it to the incoming Mollie payment ID. On mismatch the request is
acknowledged with The stored ID lives in one of two places depending on the checkout flow, and the fix reads
both of them (mirroring
Reading only the payment details would reject legitimate QR-code payments, because their
payment details carry no WorkaroundsIf you cannot upgrade immediately, patch the vulnerability at the project level by decorating the plugin's webhook controller. The decorator checks that the incoming Mollie id matches the id stored for that order before handing over to the original controller, so no plugin behaviour (state machine, logging) is lost and no extra Mollie API call is made. Works on both 2.2 and 3.x. Step 1. Create the decoratorCreate
Step 2. Register the decoratorAppend to your project's
Step 3. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev | ||
v3.1.1
patch
2 CVEs
CVE-2026-68501
GHSA-x83g-979r-f5fh
Jul 31, 2026
Sylius Mollie Plugin has unauthenticated IDOR that leaks order token and customer PII
6.5
/ 10
Medium
Network
Low
None
None
Unchanged
Low
None
Low
ImpactTwo unauthenticated Mollie shop endpoints look up orders by a sequential integer
That None of the plugin endpoints require a login, session or CSRF token. PatchesFixed in 2.2.8, 3.2.4 and 3.3.1. WorkaroundsIf you cannot upgrade immediately, patch both endpoints at the project level by decorating
the plugin controllers. The decorators enforce ownership before delegating to the original
controller, so no plugin behaviour is lost. They keep the original Step 1. Decorate the QR code controllerCreate
Step 2. Decorate the thank-you controllerCreate
Step 3. Register the decoratorsAppend to your project's
Step 4. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev
CVE-2026-68500
GHSA-rc52-c4hv-w89p
Jul 31, 2026
Sylius Mollie Plugin vulnerable to payment status forgery via the payment webhook
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
High
None
ImpactThe shop payment webhook An unauthenticated attacker who holds any valid paid Mollie payment ID, for example
from a EUR 1 order they placed themselves, can submit it together with any victim
PatchesFixed in versions 2.2.8, 3.2.4 and 3.3.1. The webhook now binds the payment to
the order: it reads the Mollie payment ID stored server-side for that order when the payment
was created and compares it to the incoming Mollie payment ID. On mismatch the request is
acknowledged with The stored ID lives in one of two places depending on the checkout flow, and the fix reads
both of them (mirroring
Reading only the payment details would reject legitimate QR-code payments, because their
payment details carry no WorkaroundsIf you cannot upgrade immediately, patch the vulnerability at the project level by decorating the plugin's webhook controller. The decorator checks that the incoming Mollie id matches the id stored for that order before handing over to the original controller, so no plugin behaviour (state machine, logging) is lost and no extra Mollie API call is made. Works on both 2.2 and 3.x. Step 1. Create the decoratorCreate
Step 2. Register the decoratorAppend to your project's
Step 3. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev | ||
v3.0.2
patch
2 CVEs
CVE-2026-68501
GHSA-x83g-979r-f5fh
Jul 31, 2026
Sylius Mollie Plugin has unauthenticated IDOR that leaks order token and customer PII
6.5
/ 10
Medium
Network
Low
None
None
Unchanged
Low
None
Low
ImpactTwo unauthenticated Mollie shop endpoints look up orders by a sequential integer
That None of the plugin endpoints require a login, session or CSRF token. PatchesFixed in 2.2.8, 3.2.4 and 3.3.1. WorkaroundsIf you cannot upgrade immediately, patch both endpoints at the project level by decorating
the plugin controllers. The decorators enforce ownership before delegating to the original
controller, so no plugin behaviour is lost. They keep the original Step 1. Decorate the QR code controllerCreate
Step 2. Decorate the thank-you controllerCreate
Step 3. Register the decoratorsAppend to your project's
Step 4. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev
CVE-2026-68500
GHSA-rc52-c4hv-w89p
Jul 31, 2026
Sylius Mollie Plugin vulnerable to payment status forgery via the payment webhook
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
High
None
ImpactThe shop payment webhook An unauthenticated attacker who holds any valid paid Mollie payment ID, for example
from a EUR 1 order they placed themselves, can submit it together with any victim
PatchesFixed in versions 2.2.8, 3.2.4 and 3.3.1. The webhook now binds the payment to
the order: it reads the Mollie payment ID stored server-side for that order when the payment
was created and compares it to the incoming Mollie payment ID. On mismatch the request is
acknowledged with The stored ID lives in one of two places depending on the checkout flow, and the fix reads
both of them (mirroring
Reading only the payment details would reject legitimate QR-code payments, because their
payment details carry no WorkaroundsIf you cannot upgrade immediately, patch the vulnerability at the project level by decorating the plugin's webhook controller. The decorator checks that the incoming Mollie id matches the id stored for that order before handing over to the original controller, so no plugin behaviour (state machine, logging) is lost and no extra Mollie API call is made. Works on both 2.2 and 3.x. Step 1. Create the decoratorCreate
Step 2. Register the decoratorAppend to your project's
Step 3. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev | ||
v3.1.0
minor
2 CVEs
CVE-2026-68501
GHSA-x83g-979r-f5fh
Jul 31, 2026
Sylius Mollie Plugin has unauthenticated IDOR that leaks order token and customer PII
6.5
/ 10
Medium
Network
Low
None
None
Unchanged
Low
None
Low
ImpactTwo unauthenticated Mollie shop endpoints look up orders by a sequential integer
That None of the plugin endpoints require a login, session or CSRF token. PatchesFixed in 2.2.8, 3.2.4 and 3.3.1. WorkaroundsIf you cannot upgrade immediately, patch both endpoints at the project level by decorating
the plugin controllers. The decorators enforce ownership before delegating to the original
controller, so no plugin behaviour is lost. They keep the original Step 1. Decorate the QR code controllerCreate
Step 2. Decorate the thank-you controllerCreate
Step 3. Register the decoratorsAppend to your project's
Step 4. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev
CVE-2026-68500
GHSA-rc52-c4hv-w89p
Jul 31, 2026
Sylius Mollie Plugin vulnerable to payment status forgery via the payment webhook
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
High
None
ImpactThe shop payment webhook An unauthenticated attacker who holds any valid paid Mollie payment ID, for example
from a EUR 1 order they placed themselves, can submit it together with any victim
PatchesFixed in versions 2.2.8, 3.2.4 and 3.3.1. The webhook now binds the payment to
the order: it reads the Mollie payment ID stored server-side for that order when the payment
was created and compares it to the incoming Mollie payment ID. On mismatch the request is
acknowledged with The stored ID lives in one of two places depending on the checkout flow, and the fix reads
both of them (mirroring
Reading only the payment details would reject legitimate QR-code payments, because their
payment details carry no WorkaroundsIf you cannot upgrade immediately, patch the vulnerability at the project level by decorating the plugin's webhook controller. The decorator checks that the incoming Mollie id matches the id stored for that order before handing over to the original controller, so no plugin behaviour (state machine, logging) is lost and no extra Mollie API call is made. Works on both 2.2 and 3.x. Step 1. Create the decoratorCreate
Step 2. Register the decoratorAppend to your project's
Step 3. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev | ||
v3.0.1
patch
2 CVEs
CVE-2026-68501
GHSA-x83g-979r-f5fh
Jul 31, 2026
Sylius Mollie Plugin has unauthenticated IDOR that leaks order token and customer PII
6.5
/ 10
Medium
Network
Low
None
None
Unchanged
Low
None
Low
ImpactTwo unauthenticated Mollie shop endpoints look up orders by a sequential integer
That None of the plugin endpoints require a login, session or CSRF token. PatchesFixed in 2.2.8, 3.2.4 and 3.3.1. WorkaroundsIf you cannot upgrade immediately, patch both endpoints at the project level by decorating
the plugin controllers. The decorators enforce ownership before delegating to the original
controller, so no plugin behaviour is lost. They keep the original Step 1. Decorate the QR code controllerCreate
Step 2. Decorate the thank-you controllerCreate
Step 3. Register the decoratorsAppend to your project's
Step 4. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev
CVE-2026-68500
GHSA-rc52-c4hv-w89p
Jul 31, 2026
Sylius Mollie Plugin vulnerable to payment status forgery via the payment webhook
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
High
None
ImpactThe shop payment webhook An unauthenticated attacker who holds any valid paid Mollie payment ID, for example
from a EUR 1 order they placed themselves, can submit it together with any victim
PatchesFixed in versions 2.2.8, 3.2.4 and 3.3.1. The webhook now binds the payment to
the order: it reads the Mollie payment ID stored server-side for that order when the payment
was created and compares it to the incoming Mollie payment ID. On mismatch the request is
acknowledged with The stored ID lives in one of two places depending on the checkout flow, and the fix reads
both of them (mirroring
Reading only the payment details would reject legitimate QR-code payments, because their
payment details carry no WorkaroundsIf you cannot upgrade immediately, patch the vulnerability at the project level by decorating the plugin's webhook controller. The decorator checks that the incoming Mollie id matches the id stored for that order before handing over to the original controller, so no plugin behaviour (state machine, logging) is lost and no extra Mollie API call is made. Works on both 2.2 and 3.x. Step 1. Create the decoratorCreate
Step 2. Register the decoratorAppend to your project's
Step 3. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev | ||
v2.2.1
patch
2 CVEs
CVE-2026-68501
GHSA-x83g-979r-f5fh
Jul 31, 2026
Sylius Mollie Plugin has unauthenticated IDOR that leaks order token and customer PII
6.5
/ 10
Medium
Network
Low
None
None
Unchanged
Low
None
Low
ImpactTwo unauthenticated Mollie shop endpoints look up orders by a sequential integer
That None of the plugin endpoints require a login, session or CSRF token. PatchesFixed in 2.2.8, 3.2.4 and 3.3.1. WorkaroundsIf you cannot upgrade immediately, patch both endpoints at the project level by decorating
the plugin controllers. The decorators enforce ownership before delegating to the original
controller, so no plugin behaviour is lost. They keep the original Step 1. Decorate the QR code controllerCreate
Step 2. Decorate the thank-you controllerCreate
Step 3. Register the decoratorsAppend to your project's
Step 4. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev
CVE-2026-68500
GHSA-rc52-c4hv-w89p
Jul 31, 2026
Sylius Mollie Plugin vulnerable to payment status forgery via the payment webhook
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
High
None
ImpactThe shop payment webhook An unauthenticated attacker who holds any valid paid Mollie payment ID, for example
from a EUR 1 order they placed themselves, can submit it together with any victim
PatchesFixed in versions 2.2.8, 3.2.4 and 3.3.1. The webhook now binds the payment to
the order: it reads the Mollie payment ID stored server-side for that order when the payment
was created and compares it to the incoming Mollie payment ID. On mismatch the request is
acknowledged with The stored ID lives in one of two places depending on the checkout flow, and the fix reads
both of them (mirroring
Reading only the payment details would reject legitimate QR-code payments, because their
payment details carry no WorkaroundsIf you cannot upgrade immediately, patch the vulnerability at the project level by decorating the plugin's webhook controller. The decorator checks that the incoming Mollie id matches the id stored for that order before handing over to the original controller, so no plugin behaviour (state machine, logging) is lost and no extra Mollie API call is made. Works on both 2.2 and 3.x. Step 1. Create the decoratorCreate
Step 2. Register the decoratorAppend to your project's
Step 3. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev | ||
v3.0.0
major
2 CVEs
CVE-2026-68501
GHSA-x83g-979r-f5fh
Jul 31, 2026
Sylius Mollie Plugin has unauthenticated IDOR that leaks order token and customer PII
6.5
/ 10
Medium
Network
Low
None
None
Unchanged
Low
None
Low
ImpactTwo unauthenticated Mollie shop endpoints look up orders by a sequential integer
That None of the plugin endpoints require a login, session or CSRF token. PatchesFixed in 2.2.8, 3.2.4 and 3.3.1. WorkaroundsIf you cannot upgrade immediately, patch both endpoints at the project level by decorating
the plugin controllers. The decorators enforce ownership before delegating to the original
controller, so no plugin behaviour is lost. They keep the original Step 1. Decorate the QR code controllerCreate
Step 2. Decorate the thank-you controllerCreate
Step 3. Register the decoratorsAppend to your project's
Step 4. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev
CVE-2026-68500
GHSA-rc52-c4hv-w89p
Jul 31, 2026
Sylius Mollie Plugin vulnerable to payment status forgery via the payment webhook
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
High
None
ImpactThe shop payment webhook An unauthenticated attacker who holds any valid paid Mollie payment ID, for example
from a EUR 1 order they placed themselves, can submit it together with any victim
PatchesFixed in versions 2.2.8, 3.2.4 and 3.3.1. The webhook now binds the payment to
the order: it reads the Mollie payment ID stored server-side for that order when the payment
was created and compares it to the incoming Mollie payment ID. On mismatch the request is
acknowledged with The stored ID lives in one of two places depending on the checkout flow, and the fix reads
both of them (mirroring
Reading only the payment details would reject legitimate QR-code payments, because their
payment details carry no WorkaroundsIf you cannot upgrade immediately, patch the vulnerability at the project level by decorating the plugin's webhook controller. The decorator checks that the incoming Mollie id matches the id stored for that order before handing over to the original controller, so no plugin behaviour (state machine, logging) is lost and no extra Mollie API call is made. Works on both 2.2 and 3.x. Step 1. Create the decoratorCreate
Step 2. Register the decoratorAppend to your project's
Step 3. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev | ||
v2.2.0
minor
2 CVEs
CVE-2026-68501
GHSA-x83g-979r-f5fh
Jul 31, 2026
Sylius Mollie Plugin has unauthenticated IDOR that leaks order token and customer PII
6.5
/ 10
Medium
Network
Low
None
None
Unchanged
Low
None
Low
ImpactTwo unauthenticated Mollie shop endpoints look up orders by a sequential integer
That None of the plugin endpoints require a login, session or CSRF token. PatchesFixed in 2.2.8, 3.2.4 and 3.3.1. WorkaroundsIf you cannot upgrade immediately, patch both endpoints at the project level by decorating
the plugin controllers. The decorators enforce ownership before delegating to the original
controller, so no plugin behaviour is lost. They keep the original Step 1. Decorate the QR code controllerCreate
Step 2. Decorate the thank-you controllerCreate
Step 3. Register the decoratorsAppend to your project's
Step 4. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev
CVE-2026-68500
GHSA-rc52-c4hv-w89p
Jul 31, 2026
Sylius Mollie Plugin vulnerable to payment status forgery via the payment webhook
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
High
None
ImpactThe shop payment webhook An unauthenticated attacker who holds any valid paid Mollie payment ID, for example
from a EUR 1 order they placed themselves, can submit it together with any victim
PatchesFixed in versions 2.2.8, 3.2.4 and 3.3.1. The webhook now binds the payment to
the order: it reads the Mollie payment ID stored server-side for that order when the payment
was created and compares it to the incoming Mollie payment ID. On mismatch the request is
acknowledged with The stored ID lives in one of two places depending on the checkout flow, and the fix reads
both of them (mirroring
Reading only the payment details would reject legitimate QR-code payments, because their
payment details carry no WorkaroundsIf you cannot upgrade immediately, patch the vulnerability at the project level by decorating the plugin's webhook controller. The decorator checks that the incoming Mollie id matches the id stored for that order before handing over to the original controller, so no plugin behaviour (state machine, logging) is lost and no extra Mollie API call is made. Works on both 2.2 and 3.x. Step 1. Create the decoratorCreate
Step 2. Register the decoratorAppend to your project's
Step 3. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev | ||
v2.1.0
minor
2 CVEs
CVE-2026-68501
GHSA-x83g-979r-f5fh
Jul 31, 2026
Sylius Mollie Plugin has unauthenticated IDOR that leaks order token and customer PII
6.5
/ 10
Medium
Network
Low
None
None
Unchanged
Low
None
Low
ImpactTwo unauthenticated Mollie shop endpoints look up orders by a sequential integer
That None of the plugin endpoints require a login, session or CSRF token. PatchesFixed in 2.2.8, 3.2.4 and 3.3.1. WorkaroundsIf you cannot upgrade immediately, patch both endpoints at the project level by decorating
the plugin controllers. The decorators enforce ownership before delegating to the original
controller, so no plugin behaviour is lost. They keep the original Step 1. Decorate the QR code controllerCreate
Step 2. Decorate the thank-you controllerCreate
Step 3. Register the decoratorsAppend to your project's
Step 4. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev
CVE-2026-68500
GHSA-rc52-c4hv-w89p
Jul 31, 2026
Sylius Mollie Plugin vulnerable to payment status forgery via the payment webhook
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
High
None
ImpactThe shop payment webhook An unauthenticated attacker who holds any valid paid Mollie payment ID, for example
from a EUR 1 order they placed themselves, can submit it together with any victim
PatchesFixed in versions 2.2.8, 3.2.4 and 3.3.1. The webhook now binds the payment to
the order: it reads the Mollie payment ID stored server-side for that order when the payment
was created and compares it to the incoming Mollie payment ID. On mismatch the request is
acknowledged with The stored ID lives in one of two places depending on the checkout flow, and the fix reads
both of them (mirroring
Reading only the payment details would reject legitimate QR-code payments, because their
payment details carry no WorkaroundsIf you cannot upgrade immediately, patch the vulnerability at the project level by decorating the plugin's webhook controller. The decorator checks that the incoming Mollie id matches the id stored for that order before handing over to the original controller, so no plugin behaviour (state machine, logging) is lost and no extra Mollie API call is made. Works on both 2.2 and 3.x. Step 1. Create the decoratorCreate
Step 2. Register the decoratorAppend to your project's
Step 3. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev |
v2.1.0
minor
Dependencies (8)
Changelog
Compare changes
|
|
v2.0.1
patch
2 CVEs
CVE-2026-68501
GHSA-x83g-979r-f5fh
Jul 31, 2026
Sylius Mollie Plugin has unauthenticated IDOR that leaks order token and customer PII
6.5
/ 10
Medium
Network
Low
None
None
Unchanged
Low
None
Low
ImpactTwo unauthenticated Mollie shop endpoints look up orders by a sequential integer
That None of the plugin endpoints require a login, session or CSRF token. PatchesFixed in 2.2.8, 3.2.4 and 3.3.1. WorkaroundsIf you cannot upgrade immediately, patch both endpoints at the project level by decorating
the plugin controllers. The decorators enforce ownership before delegating to the original
controller, so no plugin behaviour is lost. They keep the original Step 1. Decorate the QR code controllerCreate
Step 2. Decorate the thank-you controllerCreate
Step 3. Register the decoratorsAppend to your project's
Step 4. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev
CVE-2026-68500
GHSA-rc52-c4hv-w89p
Jul 31, 2026
Sylius Mollie Plugin vulnerable to payment status forgery via the payment webhook
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
High
None
ImpactThe shop payment webhook An unauthenticated attacker who holds any valid paid Mollie payment ID, for example
from a EUR 1 order they placed themselves, can submit it together with any victim
PatchesFixed in versions 2.2.8, 3.2.4 and 3.3.1. The webhook now binds the payment to
the order: it reads the Mollie payment ID stored server-side for that order when the payment
was created and compares it to the incoming Mollie payment ID. On mismatch the request is
acknowledged with The stored ID lives in one of two places depending on the checkout flow, and the fix reads
both of them (mirroring
Reading only the payment details would reject legitimate QR-code payments, because their
payment details carry no WorkaroundsIf you cannot upgrade immediately, patch the vulnerability at the project level by decorating the plugin's webhook controller. The decorator checks that the incoming Mollie id matches the id stored for that order before handing over to the original controller, so no plugin behaviour (state machine, logging) is lost and no extra Mollie API call is made. Works on both 2.2 and 3.x. Step 1. Create the decoratorCreate
Step 2. Register the decoratorAppend to your project's
Step 3. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev |
v2.0.1
patch
Dependencies (8)
Changelog
Compare changes
|
|
v1.0.1
patch
2 CVEs
CVE-2026-68501
GHSA-x83g-979r-f5fh
Jul 31, 2026
Sylius Mollie Plugin has unauthenticated IDOR that leaks order token and customer PII
6.5
/ 10
Medium
Network
Low
None
None
Unchanged
Low
None
Low
ImpactTwo unauthenticated Mollie shop endpoints look up orders by a sequential integer
That None of the plugin endpoints require a login, session or CSRF token. PatchesFixed in 2.2.8, 3.2.4 and 3.3.1. WorkaroundsIf you cannot upgrade immediately, patch both endpoints at the project level by decorating
the plugin controllers. The decorators enforce ownership before delegating to the original
controller, so no plugin behaviour is lost. They keep the original Step 1. Decorate the QR code controllerCreate
Step 2. Decorate the thank-you controllerCreate
Step 3. Register the decoratorsAppend to your project's
Step 4. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev
CVE-2026-68500
GHSA-rc52-c4hv-w89p
Jul 31, 2026
Sylius Mollie Plugin vulnerable to payment status forgery via the payment webhook
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
High
None
ImpactThe shop payment webhook An unauthenticated attacker who holds any valid paid Mollie payment ID, for example
from a EUR 1 order they placed themselves, can submit it together with any victim
PatchesFixed in versions 2.2.8, 3.2.4 and 3.3.1. The webhook now binds the payment to
the order: it reads the Mollie payment ID stored server-side for that order when the payment
was created and compares it to the incoming Mollie payment ID. On mismatch the request is
acknowledged with The stored ID lives in one of two places depending on the checkout flow, and the fix reads
both of them (mirroring
Reading only the payment details would reject legitimate QR-code payments, because their
payment details carry no WorkaroundsIf you cannot upgrade immediately, patch the vulnerability at the project level by decorating the plugin's webhook controller. The decorator checks that the incoming Mollie id matches the id stored for that order before handing over to the original controller, so no plugin behaviour (state machine, logging) is lost and no extra Mollie API call is made. Works on both 2.2 and 3.x. Step 1. Create the decoratorCreate
Step 2. Register the decoratorAppend to your project's
Step 3. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev |
v1.0.1
patch
Dependencies (9)
+ 1 more
Changelog
Compare changes
|
|
v2.0.0
major
2 CVEs
CVE-2026-68501
GHSA-x83g-979r-f5fh
Jul 31, 2026
Sylius Mollie Plugin has unauthenticated IDOR that leaks order token and customer PII
6.5
/ 10
Medium
Network
Low
None
None
Unchanged
Low
None
Low
ImpactTwo unauthenticated Mollie shop endpoints look up orders by a sequential integer
That None of the plugin endpoints require a login, session or CSRF token. PatchesFixed in 2.2.8, 3.2.4 and 3.3.1. WorkaroundsIf you cannot upgrade immediately, patch both endpoints at the project level by decorating
the plugin controllers. The decorators enforce ownership before delegating to the original
controller, so no plugin behaviour is lost. They keep the original Step 1. Decorate the QR code controllerCreate
Step 2. Decorate the thank-you controllerCreate
Step 3. Register the decoratorsAppend to your project's
Step 4. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev
CVE-2026-68500
GHSA-rc52-c4hv-w89p
Jul 31, 2026
Sylius Mollie Plugin vulnerable to payment status forgery via the payment webhook
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
High
None
ImpactThe shop payment webhook An unauthenticated attacker who holds any valid paid Mollie payment ID, for example
from a EUR 1 order they placed themselves, can submit it together with any victim
PatchesFixed in versions 2.2.8, 3.2.4 and 3.3.1. The webhook now binds the payment to
the order: it reads the Mollie payment ID stored server-side for that order when the payment
was created and compares it to the incoming Mollie payment ID. On mismatch the request is
acknowledged with The stored ID lives in one of two places depending on the checkout flow, and the fix reads
both of them (mirroring
Reading only the payment details would reject legitimate QR-code payments, because their
payment details carry no WorkaroundsIf you cannot upgrade immediately, patch the vulnerability at the project level by decorating the plugin's webhook controller. The decorator checks that the incoming Mollie id matches the id stored for that order before handing over to the original controller, so no plugin behaviour (state machine, logging) is lost and no extra Mollie API call is made. Works on both 2.2 and 3.x. Step 1. Create the decoratorCreate
Step 2. Register the decoratorAppend to your project's
Step 3. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev | ||
v1.0.0
major
2 CVEs
CVE-2026-68501
GHSA-x83g-979r-f5fh
Jul 31, 2026
Sylius Mollie Plugin has unauthenticated IDOR that leaks order token and customer PII
6.5
/ 10
Medium
Network
Low
None
None
Unchanged
Low
None
Low
ImpactTwo unauthenticated Mollie shop endpoints look up orders by a sequential integer
That None of the plugin endpoints require a login, session or CSRF token. PatchesFixed in 2.2.8, 3.2.4 and 3.3.1. WorkaroundsIf you cannot upgrade immediately, patch both endpoints at the project level by decorating
the plugin controllers. The decorators enforce ownership before delegating to the original
controller, so no plugin behaviour is lost. They keep the original Step 1. Decorate the QR code controllerCreate
Step 2. Decorate the thank-you controllerCreate
Step 3. Register the decoratorsAppend to your project's
Step 4. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev
CVE-2026-68500
GHSA-rc52-c4hv-w89p
Jul 31, 2026
Sylius Mollie Plugin vulnerable to payment status forgery via the payment webhook
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
High
None
ImpactThe shop payment webhook An unauthenticated attacker who holds any valid paid Mollie payment ID, for example
from a EUR 1 order they placed themselves, can submit it together with any victim
PatchesFixed in versions 2.2.8, 3.2.4 and 3.3.1. The webhook now binds the payment to
the order: it reads the Mollie payment ID stored server-side for that order when the payment
was created and compares it to the incoming Mollie payment ID. On mismatch the request is
acknowledged with The stored ID lives in one of two places depending on the checkout flow, and the fix reads
both of them (mirroring
Reading only the payment details would reject legitimate QR-code payments, because their
payment details carry no WorkaroundsIf you cannot upgrade immediately, patch the vulnerability at the project level by decorating the plugin's webhook controller. The decorator checks that the incoming Mollie id matches the id stored for that order before handing over to the original controller, so no plugin behaviour (state machine, logging) is lost and no extra Mollie API call is made. Works on both 2.2 and 3.x. Step 1. Create the decoratorCreate
Step 2. Register the decoratorAppend to your project's
Step 3. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev | ||
v0.1.0
initial
2 CVEs
CVE-2026-68501
GHSA-x83g-979r-f5fh
Jul 31, 2026
Sylius Mollie Plugin has unauthenticated IDOR that leaks order token and customer PII
6.5
/ 10
Medium
Network
Low
None
None
Unchanged
Low
None
Low
ImpactTwo unauthenticated Mollie shop endpoints look up orders by a sequential integer
That None of the plugin endpoints require a login, session or CSRF token. PatchesFixed in 2.2.8, 3.2.4 and 3.3.1. WorkaroundsIf you cannot upgrade immediately, patch both endpoints at the project level by decorating
the plugin controllers. The decorators enforce ownership before delegating to the original
controller, so no plugin behaviour is lost. They keep the original Step 1. Decorate the QR code controllerCreate
Step 2. Decorate the thank-you controllerCreate
Step 3. Register the decoratorsAppend to your project's
Step 4. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev
CVE-2026-68500
GHSA-rc52-c4hv-w89p
Jul 31, 2026
Sylius Mollie Plugin vulnerable to payment status forgery via the payment webhook
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
High
None
ImpactThe shop payment webhook An unauthenticated attacker who holds any valid paid Mollie payment ID, for example
from a EUR 1 order they placed themselves, can submit it together with any victim
PatchesFixed in versions 2.2.8, 3.2.4 and 3.3.1. The webhook now binds the payment to
the order: it reads the Mollie payment ID stored server-side for that order when the payment
was created and compares it to the incoming Mollie payment ID. On mismatch the request is
acknowledged with The stored ID lives in one of two places depending on the checkout flow, and the fix reads
both of them (mirroring
Reading only the payment details would reject legitimate QR-code payments, because their
payment details carry no WorkaroundsIf you cannot upgrade immediately, patch the vulnerability at the project level by decorating the plugin's webhook controller. The decorator checks that the incoming Mollie id matches the id stored for that order before handing over to the original controller, so no plugin behaviour (state machine, logging) is lost and no extra Mollie API call is made. Works on both 2.2 and 3.x. Step 1. Create the decoratorCreate
Step 2. Register the decoratorAppend to your project's
Step 3. Clear the cache
Affected versions
v0.1.0
v1.0.0
v1.0.1
v1.0.2
v2.0.0
v2.0.1
v2.0.2
v2.1.0
v2.1.1
v2.2.0
v2.2.1
v2.2.2
+ 17 more Show less
v2.2.3
v2.2.4
v2.2.5
v2.2.6
v2.2.7
v3.0.0
v3.0.1
v3.0.2
v3.0.3
v3.1.0
v3.1.1
v3.1.2
v3.2.0
v3.2.1
v3.2.2
v3.2.3
v3.3.0
Fixed in
2.2.8
3.2.4
3.3.1
References
Updated Jul 31, 2026 · Source: OSV.dev |
v0.1.0
initial
Dependencies (6)
Changelog
|