solidus_frontend

Version	Released
`4.6.3` patch	Sep 09, 2026
`4.7.1` patch	Sep 09, 2026
`4.7.0` minor	Aug 28, 2026
`4.6.0` minor	Aug 28, 2026
`4.0.0` major	Oct 06, 2023
`3.4.0` minor	Apr 21, 2023
`4.0.0.dev` pre	Apr 21, 2023
`3.1.9` patch	Feb 07, 2023
`3.4.0.dev` pre	Jan 30, 2023
`3.3.0` minor	Jan 24, 2023
`3.2.5` patch	Dec 23, 2022
`3.2.4` patch	Nov 09, 2022
`3.2.3` patch	Nov 03, 2022
`3.0.8` patch	Sep 22, 2022
`3.1.8` patch	Sep 22, 2022
`3.2.1` patch	Sep 09, 2022
`3.2.2` patch	Sep 09, 2022
`3.2.0` minor	Aug 18, 2022
`3.3.0.alpha` pre	Aug 18, 2022
`3.2.0.alpha` pre	Aug 05, 2022
`3.0.7` patch	Jul 15, 2022
`2.11.17` patch	Jul 15, 2022
`3.1.7` patch	Jul 15, 2022
`3.1.6` patch	Jun 01, 2022
`2.11.16` patch	Jun 01, 2022
`3.0.6` patch	Jun 01, 2022
`2.11.15` patch	Mar 10, 2022
`2.11.14` patch	Dec 20, 2021
`3.1.5` patch	Dec 20, 2021
`3.0.5` patch	Dec 20, 2021
`2.11.13` patch 1 CVE	Dec 07, 2021
`3.1.4` patch 1 CVE	Dec 07, 2021
`3.0.4` patch 1 CVE	Dec 07, 2021
`3.0.3` patch 1 CVE	Nov 17, 2021
`2.11.12` patch 1 CVE	Nov 17, 2021
`3.1.3` patch 1 CVE	Nov 17, 2021
`3.1.2` patch 1 CVE	Sep 29, 2021
`3.1.1` patch 1 CVE	Sep 20, 2021
`3.0.2` patch 1 CVE	Sep 10, 2021
`3.1.0` minor 1 CVE	Sep 10, 2021
`2.11.11` patch 1 CVE	Sep 10, 2021
`3.0.1` patch 1 CVE	May 10, 2021
`2.10.5` patch 1 CVE	May 10, 2021
`2.11.10` patch 1 CVE	May 10, 2021
`2.11.9` patch 1 CVE	Apr 20, 2021
`3.0.0` major 1 CVE	Apr 20, 2021
`2.11.8` patch 1 CVE	Apr 01, 2021
`2.11.6` patch 1 CVE	Mar 18, 2021
`2.11.7` patch 1 CVE	Mar 18, 2021
`3.0.0.rc2` pre	Mar 10, 2021

4.6.3 patch

Sep 09, 2026

4.7.1 patch

Sep 09, 2026

4.7.0 minor

Aug 28, 2026

4.6.0 minor

Aug 28, 2026

4.0.0 major

Oct 06, 2023

3.4.0 minor

Apr 21, 2023

4.0.0.dev pre

Apr 21, 2023

3.1.9 patch

Feb 07, 2023

3.4.0.dev pre

Jan 30, 2023

3.3.0 minor

Jan 24, 2023

3.2.5 patch

Dec 23, 2022

3.2.4 patch

Nov 09, 2022

3.2.3 patch

Nov 03, 2022

3.0.8 patch

Sep 22, 2022

3.1.8 patch

Sep 22, 2022

3.2.1 patch

Sep 09, 2022

3.2.2 patch

Sep 09, 2022

3.2.0 minor

Aug 18, 2022

3.3.0.alpha pre

Aug 18, 2022

3.2.0.alpha pre

Aug 05, 2022

3.0.7 patch

Jul 15, 2022

2.11.17 patch

Jul 15, 2022

3.1.7 patch

Jul 15, 2022

3.1.6 patch

Jun 01, 2022

2.11.16 patch

Jun 01, 2022

3.0.6 patch

Jun 01, 2022

2.11.15 patch

Mar 10, 2022

2.11.14 patch

Dec 20, 2021

3.1.5 patch

Dec 20, 2021

3.0.5 patch

Dec 20, 2021

2.11.13 patch

1 CVE

CVE-2021-43846 GHSA-h3fg-h5v3-vf8m Jan 06, 2022

CSRF forgery protection bypass in solidus_frontend

5.3 / 10

Medium

Network Low None None Unchanged None Low None

Impact

CSRF vulnerability that allows a malicious site to add an item to the user's cart without their knowledge.

All solidus_frontend versions are affected. If you're using your own storefront, please, follow along to make sure you're not affected.

To reproduce the issue:

Pick the id for a variant with available stock. From the rails console:
```
Spree::Variant.in_stock.pluck(:id)
```
Say we pick variant id 2.
Launch your application, for instance, on http://localhost:3000:
```
bin/rails server
```
Open your browser dev tools.
Click on whatever link in your store.
Copy the value of the Cookie request header sent for the previous request from your browser dev tools.

Execute the following, using your previously selected variant id and the value of the Cookie header (notice how it doesn't contain any authentication token):

curl -X POST -d "variant_id=2&quantity=1" -H "Cookie: guest_token=eyJfcmFpbHMiOnsibWVzc2FnZSI6IklrWlRVMWRQWnpKMVZVdFNXRzlPVW1aaWJHTjZZa0VpIiwiZXhwIjpudWxsLCJwdXIiOiJjb29raWUuZ3Vlc3RfdG9rZW4ifX0%3D--5006ba5d346f621c760a29b6a797bf351d17d1b8; _sandbox_session=vhutu5%2FL9NmWrUpGc3DxrFA%2FFsQD1dHn1cNsD7nvE84zcjWf17Af4%2F%2F2Vab3md71b6KTb9NP6WktdXktpwH4eU01jEGIBXG5%2BMzW5nL0nb4W269qk1io4LYljvoOg8%2BZVll7oJCVkJLKKh0sSoS0Kg8j%2FCHHs%2BsShohP%2BGnA%2Bfr9Ub8H6HofpSmloSpsfHHygmX0ho03fEgzHJ4DD5wJctaNKwg7NhVikHh5kgIPPHl84OGCgv3p2oe9jR19HTxOKq7BtyvDd7XZsecWhkcfS8BPnvDDUWZG6qpAEFI5kWo81KkpSJ%2Bp6Q1HOo8%3D--n3G2vgaDG7VS%2B%2FhF--ZTjxBAkfGG3hpr4GRQ2S1Q%3D%3D; __profilin=p%3Dt" http://localhost:3000/orders/populate

Reload your browser and look at how your cart got updated.

Patches

Please, upgrade solidus to versions 3.1.5, 3.0.5 or 2.11.14.

After upgrading, make sure you read the "Upgrade notes" section below.

Upgrade notes

The patch adds CSRF token verification to the "Add to cart" action. Adding forgery protection to a form that missed it can have some side effects.

`InvalidAuthenticityToken` errors

If you're using the :exception strategy, it's likely that after upgrading, you'll see more ActionController::InvalidAuthenticityToken errors popping out in your logs. Due to browser-side cache, a form can be re-rendered and sent without any attached request cookie (for instance, when re-opening a mobile browser). That will cause an authentication error, as the sent token won't match with the one in the session (none in this case). That's a known problem in the Rails community (see https://github.com/rails/rails/issues/21948), and, at this point, there's no perfect solution.

Any attempt to mitigate the issue should be seen at the application level. For an excellent survey of all the available options, take a look at https://github.com/betagouv/demarches-simplifiees.fr/blob/5b4f7f9ae9eaf0ac94008b62f7047e4714626cf9/doc/adr-csrf-forgery.md. The latter is a third-party link. As the information is relevant here, we're going to copy it below, but it should be clear that all the credit goes to @kemenaran:

Broken behavior due to session expiration + template cache

Although pretty unlikely, you should make sure that your current setup for cache/session expiration is compatible. The upgrade can break the addition of products to the cart if both:

The "Add to cart" form is being cached (usually along with the variant information).
A user session is reset at every or every few requests.

The token validation depends on the issuing and consuming sessions being the same. If a product page is cached with the token in it, it can become stale on a subsequent rendering if the session changes.

To check that you're safe, after having upgraded locally, go through the following steps:

Enable cache on dev mode:
```
bin/rails dev:cache
```
Visit the page for a variant with stock.
Reload that page several times.
Click on the "Add to cart" button.
Remember to rerun bin/rails dev:cache to turn off cache again.

No error or session reset should happen.

Otherwise, you can try with:

Revisiting how your session gets expired.
Changing the caching strategy to exclude the token.

Using weaker CSRF protection strategies

It's also important to understand that a complete fix will only be in place when using the :exception forgery protection strategy. The solidus_frontend engine can't do pretty much anything otherwise. Using weaker CSRF strategies should be an informed and limited decision made by the application team. After the upgrade:

An app using :null_session should also be safe, but there will be side effects. That strategy runs with a null object session. As such, no order and no user is found on it. A new cart state order is created in the database, associated with no user. Next time the user visits the site, they won't find any difference in its cart state.
An app using :reset_session is not entirely safe. That strategy resets the session. That means that registered users will be logged out. Next time a user visits, they'll see the cart with the items added during the CSRF attack, although it won't be associated with their account in the case of registered users.

Reversing the update

If you still want to deploy the upgraded version before changing your application code (if the latter is needed), you can add the following workaround to your config/application.rb (however, take into account that you'll keep being vulnerable):

config.after_initialize do
  Spree::OrdersController.skip_before_action :verify_authenticity_token, only: [:populate]
end

Workarounds

If an upgrade is not an option, you can work around the issue by adding the following to config/application.rb:

config.after_initialize do
  Spree::OrdersController.protect_from_forgery with: ApplicationController.forgery_protection_strategy.name.demodulize.underscore.to_sym, only: [:populate]
end

However, go through the same safety check detailed on "Upgrade notes" above.

References

For more information

If you have any questions or comments about this advisory:

Open an issue or a discussion in Solidus.
Email us at security@solidus.io
Contact the core team on Slack

Affected versions


          1.0.0


          1.0.0.pre


          1.0.0.pre2


          1.0.0.pre3


          1.0.0.rc1


          1.0.0.rc2


          1.0.1


          1.0.2


          1.0.3


          1.0.4


          1.0.5


          1.0.6

+ 117 more


            1.0.7


            1.1.0


            1.1.0.beta1


            1.1.0.pre1


            1.1.0.pre2


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.2.0


            1.2.0.beta1


            1.2.0.rc1


            1.2.0.rc2


            1.2.1


            1.2.2


            1.2.3


            1.3.0


            1.3.0.beta1


            1.3.0.rc1


            1.3.0.rc2


            1.3.1


            1.3.2


            1.4.0


            1.4.0.beta1


            1.4.0.rc1


            1.4.1


            1.4.2


            2.0.0


            2.0.0.beta1


            2.0.0.rc1


            2.0.1


            2.0.2


            2.0.3


            2.1.0


            2.1.0.beta1


            2.1.0.rc1


            2.1.1


            2.10.0


            2.10.0.beta1


            2.10.1


            2.10.2


            2.10.3


            2.10.5


            2.11.0


            2.11.1


            2.11.10


            2.11.11


            2.11.12


            2.11.13


            2.11.2


            2.11.3


            2.11.4


            2.11.5


            2.11.6


            2.11.7


            2.11.8


            2.11.9


            2.2.0


            2.2.0.beta1


            2.2.0.rc1


            2.2.1


            2.2.2


            2.3.0


            2.3.0.beta1


            2.3.0.rc1


            2.3.0.rc2


            2.3.0.rc3


            2.3.1


            2.4.0


            2.4.0.beta1


            2.4.0.rc1


            2.4.1


            2.4.2


            2.5.0


            2.5.0.beta1


            2.5.0.beta2


            2.5.0.rc1


            2.5.1


            2.5.2


            2.6.0


            2.6.0.rc1


            2.6.1


            2.6.2


            2.6.3


            2.6.4


            2.6.5


            2.6.6


            2.7.0


            2.7.1


            2.7.2


            2.7.3


            2.7.4


            2.8.0


            2.8.1


            2.8.2


            2.8.3


            2.8.4


            2.8.5


            2.8.6


            2.9.0


            2.9.0.rc.1


            2.9.1


            2.9.2


            2.9.3


            2.9.4


            2.9.5


            2.9.6


            3.0.0


            3.0.1


            3.0.2


            3.0.3


            3.0.4


            3.1.0


            3.1.1


            3.1.2


            3.1.3


            3.1.4

Fixed in


          2.11.14


          3.0.5


          3.1.5

References

Updated Jul 08, 2026 · Source: OSV.dev

Dec 07, 2021

3.1.4 patch

1 CVE

CVE-2021-43846 GHSA-h3fg-h5v3-vf8m Jan 06, 2022

CSRF forgery protection bypass in solidus_frontend

5.3 / 10

Medium

Network Low None None Unchanged None Low None

Impact

CSRF vulnerability that allows a malicious site to add an item to the user's cart without their knowledge.

All solidus_frontend versions are affected. If you're using your own storefront, please, follow along to make sure you're not affected.

To reproduce the issue:

Pick the id for a variant with available stock. From the rails console:
```
Spree::Variant.in_stock.pluck(:id)
```
Say we pick variant id 2.
Launch your application, for instance, on http://localhost:3000:
```
bin/rails server
```
Open your browser dev tools.
Click on whatever link in your store.
Copy the value of the Cookie request header sent for the previous request from your browser dev tools.

Execute the following, using your previously selected variant id and the value of the Cookie header (notice how it doesn't contain any authentication token):

curl -X POST -d "variant_id=2&quantity=1" -H "Cookie: guest_token=eyJfcmFpbHMiOnsibWVzc2FnZSI6IklrWlRVMWRQWnpKMVZVdFNXRzlPVW1aaWJHTjZZa0VpIiwiZXhwIjpudWxsLCJwdXIiOiJjb29raWUuZ3Vlc3RfdG9rZW4ifX0%3D--5006ba5d346f621c760a29b6a797bf351d17d1b8; _sandbox_session=vhutu5%2FL9NmWrUpGc3DxrFA%2FFsQD1dHn1cNsD7nvE84zcjWf17Af4%2F%2F2Vab3md71b6KTb9NP6WktdXktpwH4eU01jEGIBXG5%2BMzW5nL0nb4W269qk1io4LYljvoOg8%2BZVll7oJCVkJLKKh0sSoS0Kg8j%2FCHHs%2BsShohP%2BGnA%2Bfr9Ub8H6HofpSmloSpsfHHygmX0ho03fEgzHJ4DD5wJctaNKwg7NhVikHh5kgIPPHl84OGCgv3p2oe9jR19HTxOKq7BtyvDd7XZsecWhkcfS8BPnvDDUWZG6qpAEFI5kWo81KkpSJ%2Bp6Q1HOo8%3D--n3G2vgaDG7VS%2B%2FhF--ZTjxBAkfGG3hpr4GRQ2S1Q%3D%3D; __profilin=p%3Dt" http://localhost:3000/orders/populate

Reload your browser and look at how your cart got updated.

Patches

Please, upgrade solidus to versions 3.1.5, 3.0.5 or 2.11.14.

After upgrading, make sure you read the "Upgrade notes" section below.

Upgrade notes

The patch adds CSRF token verification to the "Add to cart" action. Adding forgery protection to a form that missed it can have some side effects.

`InvalidAuthenticityToken` errors

If you're using the :exception strategy, it's likely that after upgrading, you'll see more ActionController::InvalidAuthenticityToken errors popping out in your logs. Due to browser-side cache, a form can be re-rendered and sent without any attached request cookie (for instance, when re-opening a mobile browser). That will cause an authentication error, as the sent token won't match with the one in the session (none in this case). That's a known problem in the Rails community (see https://github.com/rails/rails/issues/21948), and, at this point, there's no perfect solution.

Any attempt to mitigate the issue should be seen at the application level. For an excellent survey of all the available options, take a look at https://github.com/betagouv/demarches-simplifiees.fr/blob/5b4f7f9ae9eaf0ac94008b62f7047e4714626cf9/doc/adr-csrf-forgery.md. The latter is a third-party link. As the information is relevant here, we're going to copy it below, but it should be clear that all the credit goes to @kemenaran:

Broken behavior due to session expiration + template cache

Although pretty unlikely, you should make sure that your current setup for cache/session expiration is compatible. The upgrade can break the addition of products to the cart if both:

The "Add to cart" form is being cached (usually along with the variant information).
A user session is reset at every or every few requests.

The token validation depends on the issuing and consuming sessions being the same. If a product page is cached with the token in it, it can become stale on a subsequent rendering if the session changes.

To check that you're safe, after having upgraded locally, go through the following steps:

Enable cache on dev mode:
```
bin/rails dev:cache
```
Visit the page for a variant with stock.
Reload that page several times.
Click on the "Add to cart" button.
Remember to rerun bin/rails dev:cache to turn off cache again.

No error or session reset should happen.

Otherwise, you can try with:

Revisiting how your session gets expired.
Changing the caching strategy to exclude the token.

Using weaker CSRF protection strategies

It's also important to understand that a complete fix will only be in place when using the :exception forgery protection strategy. The solidus_frontend engine can't do pretty much anything otherwise. Using weaker CSRF strategies should be an informed and limited decision made by the application team. After the upgrade:

An app using :null_session should also be safe, but there will be side effects. That strategy runs with a null object session. As such, no order and no user is found on it. A new cart state order is created in the database, associated with no user. Next time the user visits the site, they won't find any difference in its cart state.
An app using :reset_session is not entirely safe. That strategy resets the session. That means that registered users will be logged out. Next time a user visits, they'll see the cart with the items added during the CSRF attack, although it won't be associated with their account in the case of registered users.

Reversing the update

If you still want to deploy the upgraded version before changing your application code (if the latter is needed), you can add the following workaround to your config/application.rb (however, take into account that you'll keep being vulnerable):

config.after_initialize do
  Spree::OrdersController.skip_before_action :verify_authenticity_token, only: [:populate]
end

Workarounds

If an upgrade is not an option, you can work around the issue by adding the following to config/application.rb:

config.after_initialize do
  Spree::OrdersController.protect_from_forgery with: ApplicationController.forgery_protection_strategy.name.demodulize.underscore.to_sym, only: [:populate]
end

However, go through the same safety check detailed on "Upgrade notes" above.

References

For more information

If you have any questions or comments about this advisory:

Open an issue or a discussion in Solidus.
Email us at security@solidus.io
Contact the core team on Slack

Affected versions


          1.0.0


          1.0.0.pre


          1.0.0.pre2


          1.0.0.pre3


          1.0.0.rc1


          1.0.0.rc2


          1.0.1


          1.0.2


          1.0.3


          1.0.4


          1.0.5


          1.0.6

+ 117 more


            1.0.7


            1.1.0


            1.1.0.beta1


            1.1.0.pre1


            1.1.0.pre2


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.2.0


            1.2.0.beta1


            1.2.0.rc1


            1.2.0.rc2


            1.2.1


            1.2.2


            1.2.3


            1.3.0


            1.3.0.beta1


            1.3.0.rc1


            1.3.0.rc2


            1.3.1


            1.3.2


            1.4.0


            1.4.0.beta1


            1.4.0.rc1


            1.4.1


            1.4.2


            2.0.0


            2.0.0.beta1


            2.0.0.rc1


            2.0.1


            2.0.2


            2.0.3


            2.1.0


            2.1.0.beta1


            2.1.0.rc1


            2.1.1


            2.10.0


            2.10.0.beta1


            2.10.1


            2.10.2


            2.10.3


            2.10.5


            2.11.0


            2.11.1


            2.11.10


            2.11.11


            2.11.12


            2.11.13


            2.11.2


            2.11.3


            2.11.4


            2.11.5


            2.11.6


            2.11.7


            2.11.8


            2.11.9


            2.2.0


            2.2.0.beta1


            2.2.0.rc1


            2.2.1


            2.2.2


            2.3.0


            2.3.0.beta1


            2.3.0.rc1


            2.3.0.rc2


            2.3.0.rc3


            2.3.1


            2.4.0


            2.4.0.beta1


            2.4.0.rc1


            2.4.1


            2.4.2


            2.5.0


            2.5.0.beta1


            2.5.0.beta2


            2.5.0.rc1


            2.5.1


            2.5.2


            2.6.0


            2.6.0.rc1


            2.6.1


            2.6.2


            2.6.3


            2.6.4


            2.6.5


            2.6.6


            2.7.0


            2.7.1


            2.7.2


            2.7.3


            2.7.4


            2.8.0


            2.8.1


            2.8.2


            2.8.3


            2.8.4


            2.8.5


            2.8.6


            2.9.0


            2.9.0.rc.1


            2.9.1


            2.9.2


            2.9.3


            2.9.4


            2.9.5


            2.9.6


            3.0.0


            3.0.1


            3.0.2


            3.0.3


            3.0.4


            3.1.0


            3.1.1


            3.1.2


            3.1.3


            3.1.4

Fixed in


          2.11.14


          3.0.5


          3.1.5

References

Updated Jul 08, 2026 · Source: OSV.dev

Dec 07, 2021

3.0.4 patch

1 CVE

CVE-2021-43846 GHSA-h3fg-h5v3-vf8m Jan 06, 2022

CSRF forgery protection bypass in solidus_frontend

5.3 / 10

Medium

Network Low None None Unchanged None Low None

Impact

CSRF vulnerability that allows a malicious site to add an item to the user's cart without their knowledge.

All solidus_frontend versions are affected. If you're using your own storefront, please, follow along to make sure you're not affected.

To reproduce the issue:

Pick the id for a variant with available stock. From the rails console:
```
Spree::Variant.in_stock.pluck(:id)
```
Say we pick variant id 2.
Launch your application, for instance, on http://localhost:3000:
```
bin/rails server
```
Open your browser dev tools.
Click on whatever link in your store.
Copy the value of the Cookie request header sent for the previous request from your browser dev tools.

Execute the following, using your previously selected variant id and the value of the Cookie header (notice how it doesn't contain any authentication token):

curl -X POST -d "variant_id=2&quantity=1" -H "Cookie: guest_token=eyJfcmFpbHMiOnsibWVzc2FnZSI6IklrWlRVMWRQWnpKMVZVdFNXRzlPVW1aaWJHTjZZa0VpIiwiZXhwIjpudWxsLCJwdXIiOiJjb29raWUuZ3Vlc3RfdG9rZW4ifX0%3D--5006ba5d346f621c760a29b6a797bf351d17d1b8; _sandbox_session=vhutu5%2FL9NmWrUpGc3DxrFA%2FFsQD1dHn1cNsD7nvE84zcjWf17Af4%2F%2F2Vab3md71b6KTb9NP6WktdXktpwH4eU01jEGIBXG5%2BMzW5nL0nb4W269qk1io4LYljvoOg8%2BZVll7oJCVkJLKKh0sSoS0Kg8j%2FCHHs%2BsShohP%2BGnA%2Bfr9Ub8H6HofpSmloSpsfHHygmX0ho03fEgzHJ4DD5wJctaNKwg7NhVikHh5kgIPPHl84OGCgv3p2oe9jR19HTxOKq7BtyvDd7XZsecWhkcfS8BPnvDDUWZG6qpAEFI5kWo81KkpSJ%2Bp6Q1HOo8%3D--n3G2vgaDG7VS%2B%2FhF--ZTjxBAkfGG3hpr4GRQ2S1Q%3D%3D; __profilin=p%3Dt" http://localhost:3000/orders/populate

Reload your browser and look at how your cart got updated.

Patches

Please, upgrade solidus to versions 3.1.5, 3.0.5 or 2.11.14.

After upgrading, make sure you read the "Upgrade notes" section below.

Upgrade notes

The patch adds CSRF token verification to the "Add to cart" action. Adding forgery protection to a form that missed it can have some side effects.

`InvalidAuthenticityToken` errors

If you're using the :exception strategy, it's likely that after upgrading, you'll see more ActionController::InvalidAuthenticityToken errors popping out in your logs. Due to browser-side cache, a form can be re-rendered and sent without any attached request cookie (for instance, when re-opening a mobile browser). That will cause an authentication error, as the sent token won't match with the one in the session (none in this case). That's a known problem in the Rails community (see https://github.com/rails/rails/issues/21948), and, at this point, there's no perfect solution.

Any attempt to mitigate the issue should be seen at the application level. For an excellent survey of all the available options, take a look at https://github.com/betagouv/demarches-simplifiees.fr/blob/5b4f7f9ae9eaf0ac94008b62f7047e4714626cf9/doc/adr-csrf-forgery.md. The latter is a third-party link. As the information is relevant here, we're going to copy it below, but it should be clear that all the credit goes to @kemenaran:

Broken behavior due to session expiration + template cache

Although pretty unlikely, you should make sure that your current setup for cache/session expiration is compatible. The upgrade can break the addition of products to the cart if both:

The "Add to cart" form is being cached (usually along with the variant information).
A user session is reset at every or every few requests.

The token validation depends on the issuing and consuming sessions being the same. If a product page is cached with the token in it, it can become stale on a subsequent rendering if the session changes.

To check that you're safe, after having upgraded locally, go through the following steps:

Enable cache on dev mode:
```
bin/rails dev:cache
```
Visit the page for a variant with stock.
Reload that page several times.
Click on the "Add to cart" button.
Remember to rerun bin/rails dev:cache to turn off cache again.

No error or session reset should happen.

Otherwise, you can try with:

Revisiting how your session gets expired.
Changing the caching strategy to exclude the token.

Using weaker CSRF protection strategies

It's also important to understand that a complete fix will only be in place when using the :exception forgery protection strategy. The solidus_frontend engine can't do pretty much anything otherwise. Using weaker CSRF strategies should be an informed and limited decision made by the application team. After the upgrade:

An app using :null_session should also be safe, but there will be side effects. That strategy runs with a null object session. As such, no order and no user is found on it. A new cart state order is created in the database, associated with no user. Next time the user visits the site, they won't find any difference in its cart state.
An app using :reset_session is not entirely safe. That strategy resets the session. That means that registered users will be logged out. Next time a user visits, they'll see the cart with the items added during the CSRF attack, although it won't be associated with their account in the case of registered users.

Reversing the update

If you still want to deploy the upgraded version before changing your application code (if the latter is needed), you can add the following workaround to your config/application.rb (however, take into account that you'll keep being vulnerable):

config.after_initialize do
  Spree::OrdersController.skip_before_action :verify_authenticity_token, only: [:populate]
end

Workarounds

If an upgrade is not an option, you can work around the issue by adding the following to config/application.rb:

config.after_initialize do
  Spree::OrdersController.protect_from_forgery with: ApplicationController.forgery_protection_strategy.name.demodulize.underscore.to_sym, only: [:populate]
end

However, go through the same safety check detailed on "Upgrade notes" above.

References

For more information

If you have any questions or comments about this advisory:

Open an issue or a discussion in Solidus.
Email us at security@solidus.io
Contact the core team on Slack

Affected versions


          1.0.0


          1.0.0.pre


          1.0.0.pre2


          1.0.0.pre3


          1.0.0.rc1


          1.0.0.rc2


          1.0.1


          1.0.2


          1.0.3


          1.0.4


          1.0.5


          1.0.6

+ 117 more


            1.0.7


            1.1.0


            1.1.0.beta1


            1.1.0.pre1


            1.1.0.pre2


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.2.0


            1.2.0.beta1


            1.2.0.rc1


            1.2.0.rc2


            1.2.1


            1.2.2


            1.2.3


            1.3.0


            1.3.0.beta1


            1.3.0.rc1


            1.3.0.rc2


            1.3.1


            1.3.2


            1.4.0


            1.4.0.beta1


            1.4.0.rc1


            1.4.1


            1.4.2


            2.0.0


            2.0.0.beta1


            2.0.0.rc1


            2.0.1


            2.0.2


            2.0.3


            2.1.0


            2.1.0.beta1


            2.1.0.rc1


            2.1.1


            2.10.0


            2.10.0.beta1


            2.10.1


            2.10.2


            2.10.3


            2.10.5


            2.11.0


            2.11.1


            2.11.10


            2.11.11


            2.11.12


            2.11.13


            2.11.2


            2.11.3


            2.11.4


            2.11.5


            2.11.6


            2.11.7


            2.11.8


            2.11.9


            2.2.0


            2.2.0.beta1


            2.2.0.rc1


            2.2.1


            2.2.2


            2.3.0


            2.3.0.beta1


            2.3.0.rc1


            2.3.0.rc2


            2.3.0.rc3


            2.3.1


            2.4.0


            2.4.0.beta1


            2.4.0.rc1


            2.4.1


            2.4.2


            2.5.0


            2.5.0.beta1


            2.5.0.beta2


            2.5.0.rc1


            2.5.1


            2.5.2


            2.6.0


            2.6.0.rc1


            2.6.1


            2.6.2


            2.6.3


            2.6.4


            2.6.5


            2.6.6


            2.7.0


            2.7.1


            2.7.2


            2.7.3


            2.7.4


            2.8.0


            2.8.1


            2.8.2


            2.8.3


            2.8.4


            2.8.5


            2.8.6


            2.9.0


            2.9.0.rc.1


            2.9.1


            2.9.2


            2.9.3


            2.9.4


            2.9.5


            2.9.6


            3.0.0


            3.0.1


            3.0.2


            3.0.3


            3.0.4


            3.1.0


            3.1.1


            3.1.2


            3.1.3


            3.1.4

Fixed in


          2.11.14


          3.0.5


          3.1.5

References

Updated Jul 08, 2026 · Source: OSV.dev

Dec 07, 2021

3.0.3 patch

1 CVE

CVE-2021-43846 GHSA-h3fg-h5v3-vf8m Jan 06, 2022

CSRF forgery protection bypass in solidus_frontend

5.3 / 10

Medium

Network Low None None Unchanged None Low None

Impact

CSRF vulnerability that allows a malicious site to add an item to the user's cart without their knowledge.

All solidus_frontend versions are affected. If you're using your own storefront, please, follow along to make sure you're not affected.

To reproduce the issue:

Pick the id for a variant with available stock. From the rails console:
```
Spree::Variant.in_stock.pluck(:id)
```
Say we pick variant id 2.
Launch your application, for instance, on http://localhost:3000:
```
bin/rails server
```
Open your browser dev tools.
Click on whatever link in your store.
Copy the value of the Cookie request header sent for the previous request from your browser dev tools.

Execute the following, using your previously selected variant id and the value of the Cookie header (notice how it doesn't contain any authentication token):

curl -X POST -d "variant_id=2&quantity=1" -H "Cookie: guest_token=eyJfcmFpbHMiOnsibWVzc2FnZSI6IklrWlRVMWRQWnpKMVZVdFNXRzlPVW1aaWJHTjZZa0VpIiwiZXhwIjpudWxsLCJwdXIiOiJjb29raWUuZ3Vlc3RfdG9rZW4ifX0%3D--5006ba5d346f621c760a29b6a797bf351d17d1b8; _sandbox_session=vhutu5%2FL9NmWrUpGc3DxrFA%2FFsQD1dHn1cNsD7nvE84zcjWf17Af4%2F%2F2Vab3md71b6KTb9NP6WktdXktpwH4eU01jEGIBXG5%2BMzW5nL0nb4W269qk1io4LYljvoOg8%2BZVll7oJCVkJLKKh0sSoS0Kg8j%2FCHHs%2BsShohP%2BGnA%2Bfr9Ub8H6HofpSmloSpsfHHygmX0ho03fEgzHJ4DD5wJctaNKwg7NhVikHh5kgIPPHl84OGCgv3p2oe9jR19HTxOKq7BtyvDd7XZsecWhkcfS8BPnvDDUWZG6qpAEFI5kWo81KkpSJ%2Bp6Q1HOo8%3D--n3G2vgaDG7VS%2B%2FhF--ZTjxBAkfGG3hpr4GRQ2S1Q%3D%3D; __profilin=p%3Dt" http://localhost:3000/orders/populate

Reload your browser and look at how your cart got updated.

Patches

Please, upgrade solidus to versions 3.1.5, 3.0.5 or 2.11.14.

After upgrading, make sure you read the "Upgrade notes" section below.

Upgrade notes

The patch adds CSRF token verification to the "Add to cart" action. Adding forgery protection to a form that missed it can have some side effects.

`InvalidAuthenticityToken` errors

If you're using the :exception strategy, it's likely that after upgrading, you'll see more ActionController::InvalidAuthenticityToken errors popping out in your logs. Due to browser-side cache, a form can be re-rendered and sent without any attached request cookie (for instance, when re-opening a mobile browser). That will cause an authentication error, as the sent token won't match with the one in the session (none in this case). That's a known problem in the Rails community (see https://github.com/rails/rails/issues/21948), and, at this point, there's no perfect solution.

Any attempt to mitigate the issue should be seen at the application level. For an excellent survey of all the available options, take a look at https://github.com/betagouv/demarches-simplifiees.fr/blob/5b4f7f9ae9eaf0ac94008b62f7047e4714626cf9/doc/adr-csrf-forgery.md. The latter is a third-party link. As the information is relevant here, we're going to copy it below, but it should be clear that all the credit goes to @kemenaran:

Broken behavior due to session expiration + template cache

Although pretty unlikely, you should make sure that your current setup for cache/session expiration is compatible. The upgrade can break the addition of products to the cart if both:

The "Add to cart" form is being cached (usually along with the variant information).
A user session is reset at every or every few requests.

The token validation depends on the issuing and consuming sessions being the same. If a product page is cached with the token in it, it can become stale on a subsequent rendering if the session changes.

To check that you're safe, after having upgraded locally, go through the following steps:

Enable cache on dev mode:
```
bin/rails dev:cache
```
Visit the page for a variant with stock.
Reload that page several times.
Click on the "Add to cart" button.
Remember to rerun bin/rails dev:cache to turn off cache again.

No error or session reset should happen.

Otherwise, you can try with:

Revisiting how your session gets expired.
Changing the caching strategy to exclude the token.

Using weaker CSRF protection strategies

It's also important to understand that a complete fix will only be in place when using the :exception forgery protection strategy. The solidus_frontend engine can't do pretty much anything otherwise. Using weaker CSRF strategies should be an informed and limited decision made by the application team. After the upgrade:

An app using :null_session should also be safe, but there will be side effects. That strategy runs with a null object session. As such, no order and no user is found on it. A new cart state order is created in the database, associated with no user. Next time the user visits the site, they won't find any difference in its cart state.
An app using :reset_session is not entirely safe. That strategy resets the session. That means that registered users will be logged out. Next time a user visits, they'll see the cart with the items added during the CSRF attack, although it won't be associated with their account in the case of registered users.

Reversing the update

If you still want to deploy the upgraded version before changing your application code (if the latter is needed), you can add the following workaround to your config/application.rb (however, take into account that you'll keep being vulnerable):

config.after_initialize do
  Spree::OrdersController.skip_before_action :verify_authenticity_token, only: [:populate]
end

Workarounds

If an upgrade is not an option, you can work around the issue by adding the following to config/application.rb:

config.after_initialize do
  Spree::OrdersController.protect_from_forgery with: ApplicationController.forgery_protection_strategy.name.demodulize.underscore.to_sym, only: [:populate]
end

However, go through the same safety check detailed on "Upgrade notes" above.

References

For more information

If you have any questions or comments about this advisory:

Open an issue or a discussion in Solidus.
Email us at security@solidus.io
Contact the core team on Slack

Affected versions


          1.0.0


          1.0.0.pre


          1.0.0.pre2


          1.0.0.pre3


          1.0.0.rc1


          1.0.0.rc2


          1.0.1


          1.0.2


          1.0.3


          1.0.4


          1.0.5


          1.0.6

+ 117 more


            1.0.7


            1.1.0


            1.1.0.beta1


            1.1.0.pre1


            1.1.0.pre2


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.2.0


            1.2.0.beta1


            1.2.0.rc1


            1.2.0.rc2


            1.2.1


            1.2.2


            1.2.3


            1.3.0


            1.3.0.beta1


            1.3.0.rc1


            1.3.0.rc2


            1.3.1


            1.3.2


            1.4.0


            1.4.0.beta1


            1.4.0.rc1


            1.4.1


            1.4.2


            2.0.0


            2.0.0.beta1


            2.0.0.rc1


            2.0.1


            2.0.2


            2.0.3


            2.1.0


            2.1.0.beta1


            2.1.0.rc1


            2.1.1


            2.10.0


            2.10.0.beta1


            2.10.1


            2.10.2


            2.10.3


            2.10.5


            2.11.0


            2.11.1


            2.11.10


            2.11.11


            2.11.12


            2.11.13


            2.11.2


            2.11.3


            2.11.4


            2.11.5


            2.11.6


            2.11.7


            2.11.8


            2.11.9


            2.2.0


            2.2.0.beta1


            2.2.0.rc1


            2.2.1


            2.2.2


            2.3.0


            2.3.0.beta1


            2.3.0.rc1


            2.3.0.rc2


            2.3.0.rc3


            2.3.1


            2.4.0


            2.4.0.beta1


            2.4.0.rc1


            2.4.1


            2.4.2


            2.5.0


            2.5.0.beta1


            2.5.0.beta2


            2.5.0.rc1


            2.5.1


            2.5.2


            2.6.0


            2.6.0.rc1


            2.6.1


            2.6.2


            2.6.3


            2.6.4


            2.6.5


            2.6.6


            2.7.0


            2.7.1


            2.7.2


            2.7.3


            2.7.4


            2.8.0


            2.8.1


            2.8.2


            2.8.3


            2.8.4


            2.8.5


            2.8.6


            2.9.0


            2.9.0.rc.1


            2.9.1


            2.9.2


            2.9.3


            2.9.4


            2.9.5


            2.9.6


            3.0.0


            3.0.1


            3.0.2


            3.0.3


            3.0.4


            3.1.0


            3.1.1


            3.1.2


            3.1.3


            3.1.4

Fixed in


          2.11.14


          3.0.5


          3.1.5

References

Updated Jul 08, 2026 · Source: OSV.dev

Nov 17, 2021

2.11.12 patch

1 CVE

CVE-2021-43846 GHSA-h3fg-h5v3-vf8m Jan 06, 2022

CSRF forgery protection bypass in solidus_frontend

5.3 / 10

Medium

Network Low None None Unchanged None Low None

Impact

CSRF vulnerability that allows a malicious site to add an item to the user's cart without their knowledge.

All solidus_frontend versions are affected. If you're using your own storefront, please, follow along to make sure you're not affected.

To reproduce the issue:

Pick the id for a variant with available stock. From the rails console:
```
Spree::Variant.in_stock.pluck(:id)
```
Say we pick variant id 2.
Launch your application, for instance, on http://localhost:3000:
```
bin/rails server
```
Open your browser dev tools.
Click on whatever link in your store.
Copy the value of the Cookie request header sent for the previous request from your browser dev tools.

Execute the following, using your previously selected variant id and the value of the Cookie header (notice how it doesn't contain any authentication token):

curl -X POST -d "variant_id=2&quantity=1" -H "Cookie: guest_token=eyJfcmFpbHMiOnsibWVzc2FnZSI6IklrWlRVMWRQWnpKMVZVdFNXRzlPVW1aaWJHTjZZa0VpIiwiZXhwIjpudWxsLCJwdXIiOiJjb29raWUuZ3Vlc3RfdG9rZW4ifX0%3D--5006ba5d346f621c760a29b6a797bf351d17d1b8; _sandbox_session=vhutu5%2FL9NmWrUpGc3DxrFA%2FFsQD1dHn1cNsD7nvE84zcjWf17Af4%2F%2F2Vab3md71b6KTb9NP6WktdXktpwH4eU01jEGIBXG5%2BMzW5nL0nb4W269qk1io4LYljvoOg8%2BZVll7oJCVkJLKKh0sSoS0Kg8j%2FCHHs%2BsShohP%2BGnA%2Bfr9Ub8H6HofpSmloSpsfHHygmX0ho03fEgzHJ4DD5wJctaNKwg7NhVikHh5kgIPPHl84OGCgv3p2oe9jR19HTxOKq7BtyvDd7XZsecWhkcfS8BPnvDDUWZG6qpAEFI5kWo81KkpSJ%2Bp6Q1HOo8%3D--n3G2vgaDG7VS%2B%2FhF--ZTjxBAkfGG3hpr4GRQ2S1Q%3D%3D; __profilin=p%3Dt" http://localhost:3000/orders/populate

Reload your browser and look at how your cart got updated.

Patches

Please, upgrade solidus to versions 3.1.5, 3.0.5 or 2.11.14.

After upgrading, make sure you read the "Upgrade notes" section below.

Upgrade notes

The patch adds CSRF token verification to the "Add to cart" action. Adding forgery protection to a form that missed it can have some side effects.

`InvalidAuthenticityToken` errors

If you're using the :exception strategy, it's likely that after upgrading, you'll see more ActionController::InvalidAuthenticityToken errors popping out in your logs. Due to browser-side cache, a form can be re-rendered and sent without any attached request cookie (for instance, when re-opening a mobile browser). That will cause an authentication error, as the sent token won't match with the one in the session (none in this case). That's a known problem in the Rails community (see https://github.com/rails/rails/issues/21948), and, at this point, there's no perfect solution.

Any attempt to mitigate the issue should be seen at the application level. For an excellent survey of all the available options, take a look at https://github.com/betagouv/demarches-simplifiees.fr/blob/5b4f7f9ae9eaf0ac94008b62f7047e4714626cf9/doc/adr-csrf-forgery.md. The latter is a third-party link. As the information is relevant here, we're going to copy it below, but it should be clear that all the credit goes to @kemenaran:

Broken behavior due to session expiration + template cache

Although pretty unlikely, you should make sure that your current setup for cache/session expiration is compatible. The upgrade can break the addition of products to the cart if both:

The "Add to cart" form is being cached (usually along with the variant information).
A user session is reset at every or every few requests.

The token validation depends on the issuing and consuming sessions being the same. If a product page is cached with the token in it, it can become stale on a subsequent rendering if the session changes.

To check that you're safe, after having upgraded locally, go through the following steps:

Enable cache on dev mode:
```
bin/rails dev:cache
```
Visit the page for a variant with stock.
Reload that page several times.
Click on the "Add to cart" button.
Remember to rerun bin/rails dev:cache to turn off cache again.

No error or session reset should happen.

Otherwise, you can try with:

Revisiting how your session gets expired.
Changing the caching strategy to exclude the token.

Using weaker CSRF protection strategies

It's also important to understand that a complete fix will only be in place when using the :exception forgery protection strategy. The solidus_frontend engine can't do pretty much anything otherwise. Using weaker CSRF strategies should be an informed and limited decision made by the application team. After the upgrade:

An app using :null_session should also be safe, but there will be side effects. That strategy runs with a null object session. As such, no order and no user is found on it. A new cart state order is created in the database, associated with no user. Next time the user visits the site, they won't find any difference in its cart state.
An app using :reset_session is not entirely safe. That strategy resets the session. That means that registered users will be logged out. Next time a user visits, they'll see the cart with the items added during the CSRF attack, although it won't be associated with their account in the case of registered users.

Reversing the update

If you still want to deploy the upgraded version before changing your application code (if the latter is needed), you can add the following workaround to your config/application.rb (however, take into account that you'll keep being vulnerable):

config.after_initialize do
  Spree::OrdersController.skip_before_action :verify_authenticity_token, only: [:populate]
end

Workarounds

If an upgrade is not an option, you can work around the issue by adding the following to config/application.rb:

config.after_initialize do
  Spree::OrdersController.protect_from_forgery with: ApplicationController.forgery_protection_strategy.name.demodulize.underscore.to_sym, only: [:populate]
end

However, go through the same safety check detailed on "Upgrade notes" above.

References

For more information

If you have any questions or comments about this advisory:

Open an issue or a discussion in Solidus.
Email us at security@solidus.io
Contact the core team on Slack

Affected versions


          1.0.0


          1.0.0.pre


          1.0.0.pre2


          1.0.0.pre3


          1.0.0.rc1


          1.0.0.rc2


          1.0.1


          1.0.2


          1.0.3


          1.0.4


          1.0.5


          1.0.6

+ 117 more


            1.0.7


            1.1.0


            1.1.0.beta1


            1.1.0.pre1


            1.1.0.pre2


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.2.0


            1.2.0.beta1


            1.2.0.rc1


            1.2.0.rc2


            1.2.1


            1.2.2


            1.2.3


            1.3.0


            1.3.0.beta1


            1.3.0.rc1


            1.3.0.rc2


            1.3.1


            1.3.2


            1.4.0


            1.4.0.beta1


            1.4.0.rc1


            1.4.1


            1.4.2


            2.0.0


            2.0.0.beta1


            2.0.0.rc1


            2.0.1


            2.0.2


            2.0.3


            2.1.0


            2.1.0.beta1


            2.1.0.rc1


            2.1.1


            2.10.0


            2.10.0.beta1


            2.10.1


            2.10.2


            2.10.3


            2.10.5


            2.11.0


            2.11.1


            2.11.10


            2.11.11


            2.11.12


            2.11.13


            2.11.2


            2.11.3


            2.11.4


            2.11.5


            2.11.6


            2.11.7


            2.11.8


            2.11.9


            2.2.0


            2.2.0.beta1


            2.2.0.rc1


            2.2.1


            2.2.2


            2.3.0


            2.3.0.beta1


            2.3.0.rc1


            2.3.0.rc2


            2.3.0.rc3


            2.3.1


            2.4.0


            2.4.0.beta1


            2.4.0.rc1


            2.4.1


            2.4.2


            2.5.0


            2.5.0.beta1


            2.5.0.beta2


            2.5.0.rc1


            2.5.1


            2.5.2


            2.6.0


            2.6.0.rc1


            2.6.1


            2.6.2


            2.6.3


            2.6.4


            2.6.5


            2.6.6


            2.7.0


            2.7.1


            2.7.2


            2.7.3


            2.7.4


            2.8.0


            2.8.1


            2.8.2


            2.8.3


            2.8.4


            2.8.5


            2.8.6


            2.9.0


            2.9.0.rc.1


            2.9.1


            2.9.2


            2.9.3


            2.9.4


            2.9.5


            2.9.6


            3.0.0


            3.0.1


            3.0.2


            3.0.3


            3.0.4


            3.1.0


            3.1.1


            3.1.2


            3.1.3


            3.1.4

Fixed in


          2.11.14


          3.0.5


          3.1.5

References

Updated Jul 08, 2026 · Source: OSV.dev

Nov 17, 2021

3.1.3 patch

1 CVE

CVE-2021-43846 GHSA-h3fg-h5v3-vf8m Jan 06, 2022

CSRF forgery protection bypass in solidus_frontend

5.3 / 10

Medium

Network Low None None Unchanged None Low None

Impact

CSRF vulnerability that allows a malicious site to add an item to the user's cart without their knowledge.

All solidus_frontend versions are affected. If you're using your own storefront, please, follow along to make sure you're not affected.

To reproduce the issue:

Pick the id for a variant with available stock. From the rails console:
```
Spree::Variant.in_stock.pluck(:id)
```
Say we pick variant id 2.
Launch your application, for instance, on http://localhost:3000:
```
bin/rails server
```
Open your browser dev tools.
Click on whatever link in your store.
Copy the value of the Cookie request header sent for the previous request from your browser dev tools.

Execute the following, using your previously selected variant id and the value of the Cookie header (notice how it doesn't contain any authentication token):

curl -X POST -d "variant_id=2&quantity=1" -H "Cookie: guest_token=eyJfcmFpbHMiOnsibWVzc2FnZSI6IklrWlRVMWRQWnpKMVZVdFNXRzlPVW1aaWJHTjZZa0VpIiwiZXhwIjpudWxsLCJwdXIiOiJjb29raWUuZ3Vlc3RfdG9rZW4ifX0%3D--5006ba5d346f621c760a29b6a797bf351d17d1b8; _sandbox_session=vhutu5%2FL9NmWrUpGc3DxrFA%2FFsQD1dHn1cNsD7nvE84zcjWf17Af4%2F%2F2Vab3md71b6KTb9NP6WktdXktpwH4eU01jEGIBXG5%2BMzW5nL0nb4W269qk1io4LYljvoOg8%2BZVll7oJCVkJLKKh0sSoS0Kg8j%2FCHHs%2BsShohP%2BGnA%2Bfr9Ub8H6HofpSmloSpsfHHygmX0ho03fEgzHJ4DD5wJctaNKwg7NhVikHh5kgIPPHl84OGCgv3p2oe9jR19HTxOKq7BtyvDd7XZsecWhkcfS8BPnvDDUWZG6qpAEFI5kWo81KkpSJ%2Bp6Q1HOo8%3D--n3G2vgaDG7VS%2B%2FhF--ZTjxBAkfGG3hpr4GRQ2S1Q%3D%3D; __profilin=p%3Dt" http://localhost:3000/orders/populate

Reload your browser and look at how your cart got updated.

Patches

Please, upgrade solidus to versions 3.1.5, 3.0.5 or 2.11.14.

After upgrading, make sure you read the "Upgrade notes" section below.

Upgrade notes

The patch adds CSRF token verification to the "Add to cart" action. Adding forgery protection to a form that missed it can have some side effects.

`InvalidAuthenticityToken` errors

If you're using the :exception strategy, it's likely that after upgrading, you'll see more ActionController::InvalidAuthenticityToken errors popping out in your logs. Due to browser-side cache, a form can be re-rendered and sent without any attached request cookie (for instance, when re-opening a mobile browser). That will cause an authentication error, as the sent token won't match with the one in the session (none in this case). That's a known problem in the Rails community (see https://github.com/rails/rails/issues/21948), and, at this point, there's no perfect solution.

Any attempt to mitigate the issue should be seen at the application level. For an excellent survey of all the available options, take a look at https://github.com/betagouv/demarches-simplifiees.fr/blob/5b4f7f9ae9eaf0ac94008b62f7047e4714626cf9/doc/adr-csrf-forgery.md. The latter is a third-party link. As the information is relevant here, we're going to copy it below, but it should be clear that all the credit goes to @kemenaran:

Broken behavior due to session expiration + template cache

Although pretty unlikely, you should make sure that your current setup for cache/session expiration is compatible. The upgrade can break the addition of products to the cart if both:

The "Add to cart" form is being cached (usually along with the variant information).
A user session is reset at every or every few requests.

The token validation depends on the issuing and consuming sessions being the same. If a product page is cached with the token in it, it can become stale on a subsequent rendering if the session changes.

To check that you're safe, after having upgraded locally, go through the following steps:

Enable cache on dev mode:
```
bin/rails dev:cache
```
Visit the page for a variant with stock.
Reload that page several times.
Click on the "Add to cart" button.
Remember to rerun bin/rails dev:cache to turn off cache again.

No error or session reset should happen.

Otherwise, you can try with:

Revisiting how your session gets expired.
Changing the caching strategy to exclude the token.

Using weaker CSRF protection strategies

It's also important to understand that a complete fix will only be in place when using the :exception forgery protection strategy. The solidus_frontend engine can't do pretty much anything otherwise. Using weaker CSRF strategies should be an informed and limited decision made by the application team. After the upgrade:

An app using :null_session should also be safe, but there will be side effects. That strategy runs with a null object session. As such, no order and no user is found on it. A new cart state order is created in the database, associated with no user. Next time the user visits the site, they won't find any difference in its cart state.
An app using :reset_session is not entirely safe. That strategy resets the session. That means that registered users will be logged out. Next time a user visits, they'll see the cart with the items added during the CSRF attack, although it won't be associated with their account in the case of registered users.

Reversing the update

If you still want to deploy the upgraded version before changing your application code (if the latter is needed), you can add the following workaround to your config/application.rb (however, take into account that you'll keep being vulnerable):

config.after_initialize do
  Spree::OrdersController.skip_before_action :verify_authenticity_token, only: [:populate]
end

Workarounds

If an upgrade is not an option, you can work around the issue by adding the following to config/application.rb:

config.after_initialize do
  Spree::OrdersController.protect_from_forgery with: ApplicationController.forgery_protection_strategy.name.demodulize.underscore.to_sym, only: [:populate]
end

However, go through the same safety check detailed on "Upgrade notes" above.

References

For more information

If you have any questions or comments about this advisory:

Open an issue or a discussion in Solidus.
Email us at security@solidus.io
Contact the core team on Slack

Affected versions


          1.0.0


          1.0.0.pre


          1.0.0.pre2


          1.0.0.pre3


          1.0.0.rc1


          1.0.0.rc2


          1.0.1


          1.0.2


          1.0.3


          1.0.4


          1.0.5


          1.0.6

+ 117 more


            1.0.7


            1.1.0


            1.1.0.beta1


            1.1.0.pre1


            1.1.0.pre2


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.2.0


            1.2.0.beta1


            1.2.0.rc1


            1.2.0.rc2


            1.2.1


            1.2.2


            1.2.3


            1.3.0


            1.3.0.beta1


            1.3.0.rc1


            1.3.0.rc2


            1.3.1


            1.3.2


            1.4.0


            1.4.0.beta1


            1.4.0.rc1


            1.4.1


            1.4.2


            2.0.0


            2.0.0.beta1


            2.0.0.rc1


            2.0.1


            2.0.2


            2.0.3


            2.1.0


            2.1.0.beta1


            2.1.0.rc1


            2.1.1


            2.10.0


            2.10.0.beta1


            2.10.1


            2.10.2


            2.10.3


            2.10.5


            2.11.0


            2.11.1


            2.11.10


            2.11.11


            2.11.12


            2.11.13


            2.11.2


            2.11.3


            2.11.4


            2.11.5


            2.11.6


            2.11.7


            2.11.8


            2.11.9


            2.2.0


            2.2.0.beta1


            2.2.0.rc1


            2.2.1


            2.2.2


            2.3.0


            2.3.0.beta1


            2.3.0.rc1


            2.3.0.rc2


            2.3.0.rc3


            2.3.1


            2.4.0


            2.4.0.beta1


            2.4.0.rc1


            2.4.1


            2.4.2


            2.5.0


            2.5.0.beta1


            2.5.0.beta2


            2.5.0.rc1


            2.5.1


            2.5.2


            2.6.0


            2.6.0.rc1


            2.6.1


            2.6.2


            2.6.3


            2.6.4


            2.6.5


            2.6.6


            2.7.0


            2.7.1


            2.7.2


            2.7.3


            2.7.4


            2.8.0


            2.8.1


            2.8.2


            2.8.3


            2.8.4


            2.8.5


            2.8.6


            2.9.0


            2.9.0.rc.1


            2.9.1


            2.9.2


            2.9.3


            2.9.4


            2.9.5


            2.9.6


            3.0.0


            3.0.1


            3.0.2


            3.0.3


            3.0.4


            3.1.0


            3.1.1


            3.1.2


            3.1.3


            3.1.4

Fixed in


          2.11.14


          3.0.5


          3.1.5

References

Updated Jul 08, 2026 · Source: OSV.dev

Nov 17, 2021

3.1.2 patch

1 CVE

CVE-2021-43846 GHSA-h3fg-h5v3-vf8m Jan 06, 2022

CSRF forgery protection bypass in solidus_frontend

5.3 / 10

Medium

Network Low None None Unchanged None Low None

Impact

CSRF vulnerability that allows a malicious site to add an item to the user's cart without their knowledge.

All solidus_frontend versions are affected. If you're using your own storefront, please, follow along to make sure you're not affected.

To reproduce the issue:

Pick the id for a variant with available stock. From the rails console:
```
Spree::Variant.in_stock.pluck(:id)
```
Say we pick variant id 2.
Launch your application, for instance, on http://localhost:3000:
```
bin/rails server
```
Open your browser dev tools.
Click on whatever link in your store.
Copy the value of the Cookie request header sent for the previous request from your browser dev tools.

Execute the following, using your previously selected variant id and the value of the Cookie header (notice how it doesn't contain any authentication token):

curl -X POST -d "variant_id=2&quantity=1" -H "Cookie: guest_token=eyJfcmFpbHMiOnsibWVzc2FnZSI6IklrWlRVMWRQWnpKMVZVdFNXRzlPVW1aaWJHTjZZa0VpIiwiZXhwIjpudWxsLCJwdXIiOiJjb29raWUuZ3Vlc3RfdG9rZW4ifX0%3D--5006ba5d346f621c760a29b6a797bf351d17d1b8; _sandbox_session=vhutu5%2FL9NmWrUpGc3DxrFA%2FFsQD1dHn1cNsD7nvE84zcjWf17Af4%2F%2F2Vab3md71b6KTb9NP6WktdXktpwH4eU01jEGIBXG5%2BMzW5nL0nb4W269qk1io4LYljvoOg8%2BZVll7oJCVkJLKKh0sSoS0Kg8j%2FCHHs%2BsShohP%2BGnA%2Bfr9Ub8H6HofpSmloSpsfHHygmX0ho03fEgzHJ4DD5wJctaNKwg7NhVikHh5kgIPPHl84OGCgv3p2oe9jR19HTxOKq7BtyvDd7XZsecWhkcfS8BPnvDDUWZG6qpAEFI5kWo81KkpSJ%2Bp6Q1HOo8%3D--n3G2vgaDG7VS%2B%2FhF--ZTjxBAkfGG3hpr4GRQ2S1Q%3D%3D; __profilin=p%3Dt" http://localhost:3000/orders/populate

Reload your browser and look at how your cart got updated.

Patches

Please, upgrade solidus to versions 3.1.5, 3.0.5 or 2.11.14.

After upgrading, make sure you read the "Upgrade notes" section below.

Upgrade notes

The patch adds CSRF token verification to the "Add to cart" action. Adding forgery protection to a form that missed it can have some side effects.

`InvalidAuthenticityToken` errors

If you're using the :exception strategy, it's likely that after upgrading, you'll see more ActionController::InvalidAuthenticityToken errors popping out in your logs. Due to browser-side cache, a form can be re-rendered and sent without any attached request cookie (for instance, when re-opening a mobile browser). That will cause an authentication error, as the sent token won't match with the one in the session (none in this case). That's a known problem in the Rails community (see https://github.com/rails/rails/issues/21948), and, at this point, there's no perfect solution.

Any attempt to mitigate the issue should be seen at the application level. For an excellent survey of all the available options, take a look at https://github.com/betagouv/demarches-simplifiees.fr/blob/5b4f7f9ae9eaf0ac94008b62f7047e4714626cf9/doc/adr-csrf-forgery.md. The latter is a third-party link. As the information is relevant here, we're going to copy it below, but it should be clear that all the credit goes to @kemenaran:

Broken behavior due to session expiration + template cache

Although pretty unlikely, you should make sure that your current setup for cache/session expiration is compatible. The upgrade can break the addition of products to the cart if both:

The "Add to cart" form is being cached (usually along with the variant information).
A user session is reset at every or every few requests.

The token validation depends on the issuing and consuming sessions being the same. If a product page is cached with the token in it, it can become stale on a subsequent rendering if the session changes.

To check that you're safe, after having upgraded locally, go through the following steps:

Enable cache on dev mode:
```
bin/rails dev:cache
```
Visit the page for a variant with stock.
Reload that page several times.
Click on the "Add to cart" button.
Remember to rerun bin/rails dev:cache to turn off cache again.

No error or session reset should happen.

Otherwise, you can try with:

Revisiting how your session gets expired.
Changing the caching strategy to exclude the token.

Using weaker CSRF protection strategies

It's also important to understand that a complete fix will only be in place when using the :exception forgery protection strategy. The solidus_frontend engine can't do pretty much anything otherwise. Using weaker CSRF strategies should be an informed and limited decision made by the application team. After the upgrade:

An app using :null_session should also be safe, but there will be side effects. That strategy runs with a null object session. As such, no order and no user is found on it. A new cart state order is created in the database, associated with no user. Next time the user visits the site, they won't find any difference in its cart state.
An app using :reset_session is not entirely safe. That strategy resets the session. That means that registered users will be logged out. Next time a user visits, they'll see the cart with the items added during the CSRF attack, although it won't be associated with their account in the case of registered users.

Reversing the update

If you still want to deploy the upgraded version before changing your application code (if the latter is needed), you can add the following workaround to your config/application.rb (however, take into account that you'll keep being vulnerable):

config.after_initialize do
  Spree::OrdersController.skip_before_action :verify_authenticity_token, only: [:populate]
end

Workarounds

If an upgrade is not an option, you can work around the issue by adding the following to config/application.rb:

config.after_initialize do
  Spree::OrdersController.protect_from_forgery with: ApplicationController.forgery_protection_strategy.name.demodulize.underscore.to_sym, only: [:populate]
end

However, go through the same safety check detailed on "Upgrade notes" above.

References

For more information

If you have any questions or comments about this advisory:

Open an issue or a discussion in Solidus.
Email us at security@solidus.io
Contact the core team on Slack

Affected versions


          1.0.0


          1.0.0.pre


          1.0.0.pre2


          1.0.0.pre3


          1.0.0.rc1


          1.0.0.rc2


          1.0.1


          1.0.2


          1.0.3


          1.0.4


          1.0.5


          1.0.6

+ 117 more


            1.0.7


            1.1.0


            1.1.0.beta1


            1.1.0.pre1


            1.1.0.pre2


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.2.0


            1.2.0.beta1


            1.2.0.rc1


            1.2.0.rc2


            1.2.1


            1.2.2


            1.2.3


            1.3.0


            1.3.0.beta1


            1.3.0.rc1


            1.3.0.rc2


            1.3.1


            1.3.2


            1.4.0


            1.4.0.beta1


            1.4.0.rc1


            1.4.1


            1.4.2


            2.0.0


            2.0.0.beta1


            2.0.0.rc1


            2.0.1


            2.0.2


            2.0.3


            2.1.0


            2.1.0.beta1


            2.1.0.rc1


            2.1.1


            2.10.0


            2.10.0.beta1


            2.10.1


            2.10.2


            2.10.3


            2.10.5


            2.11.0


            2.11.1


            2.11.10


            2.11.11


            2.11.12


            2.11.13


            2.11.2


            2.11.3


            2.11.4


            2.11.5


            2.11.6


            2.11.7


            2.11.8


            2.11.9


            2.2.0


            2.2.0.beta1


            2.2.0.rc1


            2.2.1


            2.2.2


            2.3.0


            2.3.0.beta1


            2.3.0.rc1


            2.3.0.rc2


            2.3.0.rc3


            2.3.1


            2.4.0


            2.4.0.beta1


            2.4.0.rc1


            2.4.1


            2.4.2


            2.5.0


            2.5.0.beta1


            2.5.0.beta2


            2.5.0.rc1


            2.5.1


            2.5.2


            2.6.0


            2.6.0.rc1


            2.6.1


            2.6.2


            2.6.3


            2.6.4


            2.6.5


            2.6.6


            2.7.0


            2.7.1


            2.7.2


            2.7.3


            2.7.4


            2.8.0


            2.8.1


            2.8.2


            2.8.3


            2.8.4


            2.8.5


            2.8.6


            2.9.0


            2.9.0.rc.1


            2.9.1


            2.9.2


            2.9.3


            2.9.4


            2.9.5


            2.9.6


            3.0.0


            3.0.1


            3.0.2


            3.0.3


            3.0.4


            3.1.0


            3.1.1


            3.1.2


            3.1.3


            3.1.4

Fixed in


          2.11.14


          3.0.5


          3.1.5

References

Updated Jul 08, 2026 · Source: OSV.dev

Sep 29, 2021

3.1.1 patch

1 CVE

CVE-2021-43846 GHSA-h3fg-h5v3-vf8m Jan 06, 2022

CSRF forgery protection bypass in solidus_frontend

5.3 / 10

Medium

Network Low None None Unchanged None Low None

Impact

CSRF vulnerability that allows a malicious site to add an item to the user's cart without their knowledge.

All solidus_frontend versions are affected. If you're using your own storefront, please, follow along to make sure you're not affected.

To reproduce the issue:

Pick the id for a variant with available stock. From the rails console:
```
Spree::Variant.in_stock.pluck(:id)
```
Say we pick variant id 2.
Launch your application, for instance, on http://localhost:3000:
```
bin/rails server
```
Open your browser dev tools.
Click on whatever link in your store.
Copy the value of the Cookie request header sent for the previous request from your browser dev tools.

Execute the following, using your previously selected variant id and the value of the Cookie header (notice how it doesn't contain any authentication token):

curl -X POST -d "variant_id=2&quantity=1" -H "Cookie: guest_token=eyJfcmFpbHMiOnsibWVzc2FnZSI6IklrWlRVMWRQWnpKMVZVdFNXRzlPVW1aaWJHTjZZa0VpIiwiZXhwIjpudWxsLCJwdXIiOiJjb29raWUuZ3Vlc3RfdG9rZW4ifX0%3D--5006ba5d346f621c760a29b6a797bf351d17d1b8; _sandbox_session=vhutu5%2FL9NmWrUpGc3DxrFA%2FFsQD1dHn1cNsD7nvE84zcjWf17Af4%2F%2F2Vab3md71b6KTb9NP6WktdXktpwH4eU01jEGIBXG5%2BMzW5nL0nb4W269qk1io4LYljvoOg8%2BZVll7oJCVkJLKKh0sSoS0Kg8j%2FCHHs%2BsShohP%2BGnA%2Bfr9Ub8H6HofpSmloSpsfHHygmX0ho03fEgzHJ4DD5wJctaNKwg7NhVikHh5kgIPPHl84OGCgv3p2oe9jR19HTxOKq7BtyvDd7XZsecWhkcfS8BPnvDDUWZG6qpAEFI5kWo81KkpSJ%2Bp6Q1HOo8%3D--n3G2vgaDG7VS%2B%2FhF--ZTjxBAkfGG3hpr4GRQ2S1Q%3D%3D; __profilin=p%3Dt" http://localhost:3000/orders/populate

Reload your browser and look at how your cart got updated.

Patches

Please, upgrade solidus to versions 3.1.5, 3.0.5 or 2.11.14.

After upgrading, make sure you read the "Upgrade notes" section below.

Upgrade notes

The patch adds CSRF token verification to the "Add to cart" action. Adding forgery protection to a form that missed it can have some side effects.

`InvalidAuthenticityToken` errors

If you're using the :exception strategy, it's likely that after upgrading, you'll see more ActionController::InvalidAuthenticityToken errors popping out in your logs. Due to browser-side cache, a form can be re-rendered and sent without any attached request cookie (for instance, when re-opening a mobile browser). That will cause an authentication error, as the sent token won't match with the one in the session (none in this case). That's a known problem in the Rails community (see https://github.com/rails/rails/issues/21948), and, at this point, there's no perfect solution.

Any attempt to mitigate the issue should be seen at the application level. For an excellent survey of all the available options, take a look at https://github.com/betagouv/demarches-simplifiees.fr/blob/5b4f7f9ae9eaf0ac94008b62f7047e4714626cf9/doc/adr-csrf-forgery.md. The latter is a third-party link. As the information is relevant here, we're going to copy it below, but it should be clear that all the credit goes to @kemenaran:

Broken behavior due to session expiration + template cache

Although pretty unlikely, you should make sure that your current setup for cache/session expiration is compatible. The upgrade can break the addition of products to the cart if both:

The "Add to cart" form is being cached (usually along with the variant information).
A user session is reset at every or every few requests.

The token validation depends on the issuing and consuming sessions being the same. If a product page is cached with the token in it, it can become stale on a subsequent rendering if the session changes.

To check that you're safe, after having upgraded locally, go through the following steps:

Enable cache on dev mode:
```
bin/rails dev:cache
```
Visit the page for a variant with stock.
Reload that page several times.
Click on the "Add to cart" button.
Remember to rerun bin/rails dev:cache to turn off cache again.

No error or session reset should happen.

Otherwise, you can try with:

Revisiting how your session gets expired.
Changing the caching strategy to exclude the token.

Using weaker CSRF protection strategies

It's also important to understand that a complete fix will only be in place when using the :exception forgery protection strategy. The solidus_frontend engine can't do pretty much anything otherwise. Using weaker CSRF strategies should be an informed and limited decision made by the application team. After the upgrade:

An app using :null_session should also be safe, but there will be side effects. That strategy runs with a null object session. As such, no order and no user is found on it. A new cart state order is created in the database, associated with no user. Next time the user visits the site, they won't find any difference in its cart state.
An app using :reset_session is not entirely safe. That strategy resets the session. That means that registered users will be logged out. Next time a user visits, they'll see the cart with the items added during the CSRF attack, although it won't be associated with their account in the case of registered users.

Reversing the update

If you still want to deploy the upgraded version before changing your application code (if the latter is needed), you can add the following workaround to your config/application.rb (however, take into account that you'll keep being vulnerable):

config.after_initialize do
  Spree::OrdersController.skip_before_action :verify_authenticity_token, only: [:populate]
end

Workarounds

If an upgrade is not an option, you can work around the issue by adding the following to config/application.rb:

config.after_initialize do
  Spree::OrdersController.protect_from_forgery with: ApplicationController.forgery_protection_strategy.name.demodulize.underscore.to_sym, only: [:populate]
end

However, go through the same safety check detailed on "Upgrade notes" above.

References

For more information

If you have any questions or comments about this advisory:

Open an issue or a discussion in Solidus.
Email us at security@solidus.io
Contact the core team on Slack

Affected versions


          1.0.0


          1.0.0.pre


          1.0.0.pre2


          1.0.0.pre3


          1.0.0.rc1


          1.0.0.rc2


          1.0.1


          1.0.2


          1.0.3


          1.0.4


          1.0.5


          1.0.6

+ 117 more


            1.0.7


            1.1.0


            1.1.0.beta1


            1.1.0.pre1


            1.1.0.pre2


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.2.0


            1.2.0.beta1


            1.2.0.rc1


            1.2.0.rc2


            1.2.1


            1.2.2


            1.2.3


            1.3.0


            1.3.0.beta1


            1.3.0.rc1


            1.3.0.rc2


            1.3.1


            1.3.2


            1.4.0


            1.4.0.beta1


            1.4.0.rc1


            1.4.1


            1.4.2


            2.0.0


            2.0.0.beta1


            2.0.0.rc1


            2.0.1


            2.0.2


            2.0.3


            2.1.0


            2.1.0.beta1


            2.1.0.rc1


            2.1.1


            2.10.0


            2.10.0.beta1


            2.10.1


            2.10.2


            2.10.3


            2.10.5


            2.11.0


            2.11.1


            2.11.10


            2.11.11


            2.11.12


            2.11.13


            2.11.2


            2.11.3


            2.11.4


            2.11.5


            2.11.6


            2.11.7


            2.11.8


            2.11.9


            2.2.0


            2.2.0.beta1


            2.2.0.rc1


            2.2.1


            2.2.2


            2.3.0


            2.3.0.beta1


            2.3.0.rc1


            2.3.0.rc2


            2.3.0.rc3


            2.3.1


            2.4.0


            2.4.0.beta1


            2.4.0.rc1


            2.4.1


            2.4.2


            2.5.0


            2.5.0.beta1


            2.5.0.beta2


            2.5.0.rc1


            2.5.1


            2.5.2


            2.6.0


            2.6.0.rc1


            2.6.1


            2.6.2


            2.6.3


            2.6.4


            2.6.5


            2.6.6


            2.7.0


            2.7.1


            2.7.2


            2.7.3


            2.7.4


            2.8.0


            2.8.1


            2.8.2


            2.8.3


            2.8.4


            2.8.5


            2.8.6


            2.9.0


            2.9.0.rc.1


            2.9.1


            2.9.2


            2.9.3


            2.9.4


            2.9.5


            2.9.6


            3.0.0


            3.0.1


            3.0.2


            3.0.3


            3.0.4


            3.1.0


            3.1.1


            3.1.2


            3.1.3


            3.1.4

Fixed in


          2.11.14


          3.0.5


          3.1.5

References

Updated Jul 08, 2026 · Source: OSV.dev

Sep 20, 2021

3.0.2 patch

1 CVE

CVE-2021-43846 GHSA-h3fg-h5v3-vf8m Jan 06, 2022

CSRF forgery protection bypass in solidus_frontend

5.3 / 10

Medium

Network Low None None Unchanged None Low None

Impact

CSRF vulnerability that allows a malicious site to add an item to the user's cart without their knowledge.

All solidus_frontend versions are affected. If you're using your own storefront, please, follow along to make sure you're not affected.

To reproduce the issue:

Pick the id for a variant with available stock. From the rails console:
```
Spree::Variant.in_stock.pluck(:id)
```
Say we pick variant id 2.
Launch your application, for instance, on http://localhost:3000:
```
bin/rails server
```
Open your browser dev tools.
Click on whatever link in your store.
Copy the value of the Cookie request header sent for the previous request from your browser dev tools.

Execute the following, using your previously selected variant id and the value of the Cookie header (notice how it doesn't contain any authentication token):

curl -X POST -d "variant_id=2&quantity=1" -H "Cookie: guest_token=eyJfcmFpbHMiOnsibWVzc2FnZSI6IklrWlRVMWRQWnpKMVZVdFNXRzlPVW1aaWJHTjZZa0VpIiwiZXhwIjpudWxsLCJwdXIiOiJjb29raWUuZ3Vlc3RfdG9rZW4ifX0%3D--5006ba5d346f621c760a29b6a797bf351d17d1b8; _sandbox_session=vhutu5%2FL9NmWrUpGc3DxrFA%2FFsQD1dHn1cNsD7nvE84zcjWf17Af4%2F%2F2Vab3md71b6KTb9NP6WktdXktpwH4eU01jEGIBXG5%2BMzW5nL0nb4W269qk1io4LYljvoOg8%2BZVll7oJCVkJLKKh0sSoS0Kg8j%2FCHHs%2BsShohP%2BGnA%2Bfr9Ub8H6HofpSmloSpsfHHygmX0ho03fEgzHJ4DD5wJctaNKwg7NhVikHh5kgIPPHl84OGCgv3p2oe9jR19HTxOKq7BtyvDd7XZsecWhkcfS8BPnvDDUWZG6qpAEFI5kWo81KkpSJ%2Bp6Q1HOo8%3D--n3G2vgaDG7VS%2B%2FhF--ZTjxBAkfGG3hpr4GRQ2S1Q%3D%3D; __profilin=p%3Dt" http://localhost:3000/orders/populate

Reload your browser and look at how your cart got updated.

Patches

Please, upgrade solidus to versions 3.1.5, 3.0.5 or 2.11.14.

After upgrading, make sure you read the "Upgrade notes" section below.

Upgrade notes

The patch adds CSRF token verification to the "Add to cart" action. Adding forgery protection to a form that missed it can have some side effects.

`InvalidAuthenticityToken` errors

If you're using the :exception strategy, it's likely that after upgrading, you'll see more ActionController::InvalidAuthenticityToken errors popping out in your logs. Due to browser-side cache, a form can be re-rendered and sent without any attached request cookie (for instance, when re-opening a mobile browser). That will cause an authentication error, as the sent token won't match with the one in the session (none in this case). That's a known problem in the Rails community (see https://github.com/rails/rails/issues/21948), and, at this point, there's no perfect solution.

Any attempt to mitigate the issue should be seen at the application level. For an excellent survey of all the available options, take a look at https://github.com/betagouv/demarches-simplifiees.fr/blob/5b4f7f9ae9eaf0ac94008b62f7047e4714626cf9/doc/adr-csrf-forgery.md. The latter is a third-party link. As the information is relevant here, we're going to copy it below, but it should be clear that all the credit goes to @kemenaran:

Broken behavior due to session expiration + template cache

Although pretty unlikely, you should make sure that your current setup for cache/session expiration is compatible. The upgrade can break the addition of products to the cart if both:

The "Add to cart" form is being cached (usually along with the variant information).
A user session is reset at every or every few requests.

The token validation depends on the issuing and consuming sessions being the same. If a product page is cached with the token in it, it can become stale on a subsequent rendering if the session changes.

To check that you're safe, after having upgraded locally, go through the following steps:

Enable cache on dev mode:
```
bin/rails dev:cache
```
Visit the page for a variant with stock.
Reload that page several times.
Click on the "Add to cart" button.
Remember to rerun bin/rails dev:cache to turn off cache again.

No error or session reset should happen.

Otherwise, you can try with:

Revisiting how your session gets expired.
Changing the caching strategy to exclude the token.

Using weaker CSRF protection strategies

It's also important to understand that a complete fix will only be in place when using the :exception forgery protection strategy. The solidus_frontend engine can't do pretty much anything otherwise. Using weaker CSRF strategies should be an informed and limited decision made by the application team. After the upgrade:

An app using :null_session should also be safe, but there will be side effects. That strategy runs with a null object session. As such, no order and no user is found on it. A new cart state order is created in the database, associated with no user. Next time the user visits the site, they won't find any difference in its cart state.
An app using :reset_session is not entirely safe. That strategy resets the session. That means that registered users will be logged out. Next time a user visits, they'll see the cart with the items added during the CSRF attack, although it won't be associated with their account in the case of registered users.

Reversing the update

If you still want to deploy the upgraded version before changing your application code (if the latter is needed), you can add the following workaround to your config/application.rb (however, take into account that you'll keep being vulnerable):

config.after_initialize do
  Spree::OrdersController.skip_before_action :verify_authenticity_token, only: [:populate]
end

Workarounds

If an upgrade is not an option, you can work around the issue by adding the following to config/application.rb:

config.after_initialize do
  Spree::OrdersController.protect_from_forgery with: ApplicationController.forgery_protection_strategy.name.demodulize.underscore.to_sym, only: [:populate]
end

However, go through the same safety check detailed on "Upgrade notes" above.

References

For more information

If you have any questions or comments about this advisory:

Open an issue or a discussion in Solidus.
Email us at security@solidus.io
Contact the core team on Slack

Affected versions


          1.0.0


          1.0.0.pre


          1.0.0.pre2


          1.0.0.pre3


          1.0.0.rc1


          1.0.0.rc2


          1.0.1


          1.0.2


          1.0.3


          1.0.4


          1.0.5


          1.0.6

+ 117 more


            1.0.7


            1.1.0


            1.1.0.beta1


            1.1.0.pre1


            1.1.0.pre2


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.2.0


            1.2.0.beta1


            1.2.0.rc1


            1.2.0.rc2


            1.2.1


            1.2.2


            1.2.3


            1.3.0


            1.3.0.beta1


            1.3.0.rc1


            1.3.0.rc2


            1.3.1


            1.3.2


            1.4.0


            1.4.0.beta1


            1.4.0.rc1


            1.4.1


            1.4.2


            2.0.0


            2.0.0.beta1


            2.0.0.rc1


            2.0.1


            2.0.2


            2.0.3


            2.1.0


            2.1.0.beta1


            2.1.0.rc1


            2.1.1


            2.10.0


            2.10.0.beta1


            2.10.1


            2.10.2


            2.10.3


            2.10.5


            2.11.0


            2.11.1


            2.11.10


            2.11.11


            2.11.12


            2.11.13


            2.11.2


            2.11.3


            2.11.4


            2.11.5


            2.11.6


            2.11.7


            2.11.8


            2.11.9


            2.2.0


            2.2.0.beta1


            2.2.0.rc1


            2.2.1


            2.2.2


            2.3.0


            2.3.0.beta1


            2.3.0.rc1


            2.3.0.rc2


            2.3.0.rc3


            2.3.1


            2.4.0


            2.4.0.beta1


            2.4.0.rc1


            2.4.1


            2.4.2


            2.5.0


            2.5.0.beta1


            2.5.0.beta2


            2.5.0.rc1


            2.5.1


            2.5.2


            2.6.0


            2.6.0.rc1


            2.6.1


            2.6.2


            2.6.3


            2.6.4


            2.6.5


            2.6.6


            2.7.0


            2.7.1


            2.7.2


            2.7.3


            2.7.4


            2.8.0


            2.8.1


            2.8.2


            2.8.3


            2.8.4


            2.8.5


            2.8.6


            2.9.0


            2.9.0.rc.1


            2.9.1


            2.9.2


            2.9.3


            2.9.4


            2.9.5


            2.9.6


            3.0.0


            3.0.1


            3.0.2


            3.0.3


            3.0.4


            3.1.0


            3.1.1


            3.1.2


            3.1.3


            3.1.4

Fixed in


          2.11.14


          3.0.5


          3.1.5

References

Updated Jul 08, 2026 · Source: OSV.dev

Sep 10, 2021

3.1.0 minor

1 CVE

CVE-2021-43846 GHSA-h3fg-h5v3-vf8m Jan 06, 2022

CSRF forgery protection bypass in solidus_frontend

5.3 / 10

Medium

Network Low None None Unchanged None Low None

Impact

CSRF vulnerability that allows a malicious site to add an item to the user's cart without their knowledge.

All solidus_frontend versions are affected. If you're using your own storefront, please, follow along to make sure you're not affected.

To reproduce the issue:

Pick the id for a variant with available stock. From the rails console:
```
Spree::Variant.in_stock.pluck(:id)
```
Say we pick variant id 2.
Launch your application, for instance, on http://localhost:3000:
```
bin/rails server
```
Open your browser dev tools.
Click on whatever link in your store.
Copy the value of the Cookie request header sent for the previous request from your browser dev tools.

Execute the following, using your previously selected variant id and the value of the Cookie header (notice how it doesn't contain any authentication token):

curl -X POST -d "variant_id=2&quantity=1" -H "Cookie: guest_token=eyJfcmFpbHMiOnsibWVzc2FnZSI6IklrWlRVMWRQWnpKMVZVdFNXRzlPVW1aaWJHTjZZa0VpIiwiZXhwIjpudWxsLCJwdXIiOiJjb29raWUuZ3Vlc3RfdG9rZW4ifX0%3D--5006ba5d346f621c760a29b6a797bf351d17d1b8; _sandbox_session=vhutu5%2FL9NmWrUpGc3DxrFA%2FFsQD1dHn1cNsD7nvE84zcjWf17Af4%2F%2F2Vab3md71b6KTb9NP6WktdXktpwH4eU01jEGIBXG5%2BMzW5nL0nb4W269qk1io4LYljvoOg8%2BZVll7oJCVkJLKKh0sSoS0Kg8j%2FCHHs%2BsShohP%2BGnA%2Bfr9Ub8H6HofpSmloSpsfHHygmX0ho03fEgzHJ4DD5wJctaNKwg7NhVikHh5kgIPPHl84OGCgv3p2oe9jR19HTxOKq7BtyvDd7XZsecWhkcfS8BPnvDDUWZG6qpAEFI5kWo81KkpSJ%2Bp6Q1HOo8%3D--n3G2vgaDG7VS%2B%2FhF--ZTjxBAkfGG3hpr4GRQ2S1Q%3D%3D; __profilin=p%3Dt" http://localhost:3000/orders/populate

Reload your browser and look at how your cart got updated.

Patches

Please, upgrade solidus to versions 3.1.5, 3.0.5 or 2.11.14.

After upgrading, make sure you read the "Upgrade notes" section below.

Upgrade notes

The patch adds CSRF token verification to the "Add to cart" action. Adding forgery protection to a form that missed it can have some side effects.

`InvalidAuthenticityToken` errors

If you're using the :exception strategy, it's likely that after upgrading, you'll see more ActionController::InvalidAuthenticityToken errors popping out in your logs. Due to browser-side cache, a form can be re-rendered and sent without any attached request cookie (for instance, when re-opening a mobile browser). That will cause an authentication error, as the sent token won't match with the one in the session (none in this case). That's a known problem in the Rails community (see https://github.com/rails/rails/issues/21948), and, at this point, there's no perfect solution.

Any attempt to mitigate the issue should be seen at the application level. For an excellent survey of all the available options, take a look at https://github.com/betagouv/demarches-simplifiees.fr/blob/5b4f7f9ae9eaf0ac94008b62f7047e4714626cf9/doc/adr-csrf-forgery.md. The latter is a third-party link. As the information is relevant here, we're going to copy it below, but it should be clear that all the credit goes to @kemenaran:

Broken behavior due to session expiration + template cache

Although pretty unlikely, you should make sure that your current setup for cache/session expiration is compatible. The upgrade can break the addition of products to the cart if both:

The "Add to cart" form is being cached (usually along with the variant information).
A user session is reset at every or every few requests.

The token validation depends on the issuing and consuming sessions being the same. If a product page is cached with the token in it, it can become stale on a subsequent rendering if the session changes.

To check that you're safe, after having upgraded locally, go through the following steps:

Enable cache on dev mode:
```
bin/rails dev:cache
```
Visit the page for a variant with stock.
Reload that page several times.
Click on the "Add to cart" button.
Remember to rerun bin/rails dev:cache to turn off cache again.

No error or session reset should happen.

Otherwise, you can try with:

Revisiting how your session gets expired.
Changing the caching strategy to exclude the token.

Using weaker CSRF protection strategies

It's also important to understand that a complete fix will only be in place when using the :exception forgery protection strategy. The solidus_frontend engine can't do pretty much anything otherwise. Using weaker CSRF strategies should be an informed and limited decision made by the application team. After the upgrade:

An app using :null_session should also be safe, but there will be side effects. That strategy runs with a null object session. As such, no order and no user is found on it. A new cart state order is created in the database, associated with no user. Next time the user visits the site, they won't find any difference in its cart state.
An app using :reset_session is not entirely safe. That strategy resets the session. That means that registered users will be logged out. Next time a user visits, they'll see the cart with the items added during the CSRF attack, although it won't be associated with their account in the case of registered users.

Reversing the update

If you still want to deploy the upgraded version before changing your application code (if the latter is needed), you can add the following workaround to your config/application.rb (however, take into account that you'll keep being vulnerable):

config.after_initialize do
  Spree::OrdersController.skip_before_action :verify_authenticity_token, only: [:populate]
end

Workarounds

If an upgrade is not an option, you can work around the issue by adding the following to config/application.rb:

config.after_initialize do
  Spree::OrdersController.protect_from_forgery with: ApplicationController.forgery_protection_strategy.name.demodulize.underscore.to_sym, only: [:populate]
end

However, go through the same safety check detailed on "Upgrade notes" above.

References

For more information

If you have any questions or comments about this advisory:

Open an issue or a discussion in Solidus.
Email us at security@solidus.io
Contact the core team on Slack

Affected versions


          1.0.0


          1.0.0.pre


          1.0.0.pre2


          1.0.0.pre3


          1.0.0.rc1


          1.0.0.rc2


          1.0.1


          1.0.2


          1.0.3


          1.0.4


          1.0.5


          1.0.6

+ 117 more


            1.0.7


            1.1.0


            1.1.0.beta1


            1.1.0.pre1


            1.1.0.pre2


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.2.0


            1.2.0.beta1


            1.2.0.rc1


            1.2.0.rc2


            1.2.1


            1.2.2


            1.2.3


            1.3.0


            1.3.0.beta1


            1.3.0.rc1


            1.3.0.rc2


            1.3.1


            1.3.2


            1.4.0


            1.4.0.beta1


            1.4.0.rc1


            1.4.1


            1.4.2


            2.0.0


            2.0.0.beta1


            2.0.0.rc1


            2.0.1


            2.0.2


            2.0.3


            2.1.0


            2.1.0.beta1


            2.1.0.rc1


            2.1.1


            2.10.0


            2.10.0.beta1


            2.10.1


            2.10.2


            2.10.3


            2.10.5


            2.11.0


            2.11.1


            2.11.10


            2.11.11


            2.11.12


            2.11.13


            2.11.2


            2.11.3


            2.11.4


            2.11.5


            2.11.6


            2.11.7


            2.11.8


            2.11.9


            2.2.0


            2.2.0.beta1


            2.2.0.rc1


            2.2.1


            2.2.2


            2.3.0


            2.3.0.beta1


            2.3.0.rc1


            2.3.0.rc2


            2.3.0.rc3


            2.3.1


            2.4.0


            2.4.0.beta1


            2.4.0.rc1


            2.4.1


            2.4.2


            2.5.0


            2.5.0.beta1


            2.5.0.beta2


            2.5.0.rc1


            2.5.1


            2.5.2


            2.6.0


            2.6.0.rc1


            2.6.1


            2.6.2


            2.6.3


            2.6.4


            2.6.5


            2.6.6


            2.7.0


            2.7.1


            2.7.2


            2.7.3


            2.7.4


            2.8.0


            2.8.1


            2.8.2


            2.8.3


            2.8.4


            2.8.5


            2.8.6


            2.9.0


            2.9.0.rc.1


            2.9.1


            2.9.2


            2.9.3


            2.9.4


            2.9.5


            2.9.6


            3.0.0


            3.0.1


            3.0.2


            3.0.3


            3.0.4


            3.1.0


            3.1.1


            3.1.2


            3.1.3


            3.1.4

Fixed in


          2.11.14


          3.0.5


          3.1.5

References

Updated Jul 08, 2026 · Source: OSV.dev

Sep 10, 2021

2.11.11 patch

1 CVE

CVE-2021-43846 GHSA-h3fg-h5v3-vf8m Jan 06, 2022

CSRF forgery protection bypass in solidus_frontend

5.3 / 10

Medium

Network Low None None Unchanged None Low None

Impact

CSRF vulnerability that allows a malicious site to add an item to the user's cart without their knowledge.

All solidus_frontend versions are affected. If you're using your own storefront, please, follow along to make sure you're not affected.

To reproduce the issue:

Pick the id for a variant with available stock. From the rails console:
```
Spree::Variant.in_stock.pluck(:id)
```
Say we pick variant id 2.
Launch your application, for instance, on http://localhost:3000:
```
bin/rails server
```
Open your browser dev tools.
Click on whatever link in your store.
Copy the value of the Cookie request header sent for the previous request from your browser dev tools.

Execute the following, using your previously selected variant id and the value of the Cookie header (notice how it doesn't contain any authentication token):

curl -X POST -d "variant_id=2&quantity=1" -H "Cookie: guest_token=eyJfcmFpbHMiOnsibWVzc2FnZSI6IklrWlRVMWRQWnpKMVZVdFNXRzlPVW1aaWJHTjZZa0VpIiwiZXhwIjpudWxsLCJwdXIiOiJjb29raWUuZ3Vlc3RfdG9rZW4ifX0%3D--5006ba5d346f621c760a29b6a797bf351d17d1b8; _sandbox_session=vhutu5%2FL9NmWrUpGc3DxrFA%2FFsQD1dHn1cNsD7nvE84zcjWf17Af4%2F%2F2Vab3md71b6KTb9NP6WktdXktpwH4eU01jEGIBXG5%2BMzW5nL0nb4W269qk1io4LYljvoOg8%2BZVll7oJCVkJLKKh0sSoS0Kg8j%2FCHHs%2BsShohP%2BGnA%2Bfr9Ub8H6HofpSmloSpsfHHygmX0ho03fEgzHJ4DD5wJctaNKwg7NhVikHh5kgIPPHl84OGCgv3p2oe9jR19HTxOKq7BtyvDd7XZsecWhkcfS8BPnvDDUWZG6qpAEFI5kWo81KkpSJ%2Bp6Q1HOo8%3D--n3G2vgaDG7VS%2B%2FhF--ZTjxBAkfGG3hpr4GRQ2S1Q%3D%3D; __profilin=p%3Dt" http://localhost:3000/orders/populate

Reload your browser and look at how your cart got updated.

Patches

Please, upgrade solidus to versions 3.1.5, 3.0.5 or 2.11.14.

After upgrading, make sure you read the "Upgrade notes" section below.

Upgrade notes

The patch adds CSRF token verification to the "Add to cart" action. Adding forgery protection to a form that missed it can have some side effects.

`InvalidAuthenticityToken` errors

If you're using the :exception strategy, it's likely that after upgrading, you'll see more ActionController::InvalidAuthenticityToken errors popping out in your logs. Due to browser-side cache, a form can be re-rendered and sent without any attached request cookie (for instance, when re-opening a mobile browser). That will cause an authentication error, as the sent token won't match with the one in the session (none in this case). That's a known problem in the Rails community (see https://github.com/rails/rails/issues/21948), and, at this point, there's no perfect solution.

Any attempt to mitigate the issue should be seen at the application level. For an excellent survey of all the available options, take a look at https://github.com/betagouv/demarches-simplifiees.fr/blob/5b4f7f9ae9eaf0ac94008b62f7047e4714626cf9/doc/adr-csrf-forgery.md. The latter is a third-party link. As the information is relevant here, we're going to copy it below, but it should be clear that all the credit goes to @kemenaran:

Broken behavior due to session expiration + template cache

Although pretty unlikely, you should make sure that your current setup for cache/session expiration is compatible. The upgrade can break the addition of products to the cart if both:

The "Add to cart" form is being cached (usually along with the variant information).
A user session is reset at every or every few requests.

The token validation depends on the issuing and consuming sessions being the same. If a product page is cached with the token in it, it can become stale on a subsequent rendering if the session changes.

To check that you're safe, after having upgraded locally, go through the following steps:

Enable cache on dev mode:
```
bin/rails dev:cache
```
Visit the page for a variant with stock.
Reload that page several times.
Click on the "Add to cart" button.
Remember to rerun bin/rails dev:cache to turn off cache again.

No error or session reset should happen.

Otherwise, you can try with:

Revisiting how your session gets expired.
Changing the caching strategy to exclude the token.

Using weaker CSRF protection strategies

It's also important to understand that a complete fix will only be in place when using the :exception forgery protection strategy. The solidus_frontend engine can't do pretty much anything otherwise. Using weaker CSRF strategies should be an informed and limited decision made by the application team. After the upgrade:

An app using :null_session should also be safe, but there will be side effects. That strategy runs with a null object session. As such, no order and no user is found on it. A new cart state order is created in the database, associated with no user. Next time the user visits the site, they won't find any difference in its cart state.
An app using :reset_session is not entirely safe. That strategy resets the session. That means that registered users will be logged out. Next time a user visits, they'll see the cart with the items added during the CSRF attack, although it won't be associated with their account in the case of registered users.

Reversing the update

If you still want to deploy the upgraded version before changing your application code (if the latter is needed), you can add the following workaround to your config/application.rb (however, take into account that you'll keep being vulnerable):

config.after_initialize do
  Spree::OrdersController.skip_before_action :verify_authenticity_token, only: [:populate]
end

Workarounds

If an upgrade is not an option, you can work around the issue by adding the following to config/application.rb:

config.after_initialize do
  Spree::OrdersController.protect_from_forgery with: ApplicationController.forgery_protection_strategy.name.demodulize.underscore.to_sym, only: [:populate]
end

However, go through the same safety check detailed on "Upgrade notes" above.

References

For more information

If you have any questions or comments about this advisory:

Open an issue or a discussion in Solidus.
Email us at security@solidus.io
Contact the core team on Slack

Affected versions


          1.0.0


          1.0.0.pre


          1.0.0.pre2


          1.0.0.pre3


          1.0.0.rc1


          1.0.0.rc2


          1.0.1


          1.0.2


          1.0.3


          1.0.4


          1.0.5


          1.0.6

+ 117 more


            1.0.7


            1.1.0


            1.1.0.beta1


            1.1.0.pre1


            1.1.0.pre2


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.2.0


            1.2.0.beta1


            1.2.0.rc1


            1.2.0.rc2


            1.2.1


            1.2.2


            1.2.3


            1.3.0


            1.3.0.beta1


            1.3.0.rc1


            1.3.0.rc2


            1.3.1


            1.3.2


            1.4.0


            1.4.0.beta1


            1.4.0.rc1


            1.4.1


            1.4.2


            2.0.0


            2.0.0.beta1


            2.0.0.rc1


            2.0.1


            2.0.2


            2.0.3


            2.1.0


            2.1.0.beta1


            2.1.0.rc1


            2.1.1


            2.10.0


            2.10.0.beta1


            2.10.1


            2.10.2


            2.10.3


            2.10.5


            2.11.0


            2.11.1


            2.11.10


            2.11.11


            2.11.12


            2.11.13


            2.11.2


            2.11.3


            2.11.4


            2.11.5


            2.11.6


            2.11.7


            2.11.8


            2.11.9


            2.2.0


            2.2.0.beta1


            2.2.0.rc1


            2.2.1


            2.2.2


            2.3.0


            2.3.0.beta1


            2.3.0.rc1


            2.3.0.rc2


            2.3.0.rc3


            2.3.1


            2.4.0


            2.4.0.beta1


            2.4.0.rc1


            2.4.1


            2.4.2


            2.5.0


            2.5.0.beta1


            2.5.0.beta2


            2.5.0.rc1


            2.5.1


            2.5.2


            2.6.0


            2.6.0.rc1


            2.6.1


            2.6.2


            2.6.3


            2.6.4


            2.6.5


            2.6.6


            2.7.0


            2.7.1


            2.7.2


            2.7.3


            2.7.4


            2.8.0


            2.8.1


            2.8.2


            2.8.3


            2.8.4


            2.8.5


            2.8.6


            2.9.0


            2.9.0.rc.1


            2.9.1


            2.9.2


            2.9.3


            2.9.4


            2.9.5


            2.9.6


            3.0.0


            3.0.1


            3.0.2


            3.0.3


            3.0.4


            3.1.0


            3.1.1


            3.1.2


            3.1.3


            3.1.4

Fixed in


          2.11.14


          3.0.5


          3.1.5

References

Updated Jul 08, 2026 · Source: OSV.dev

Sep 10, 2021

3.0.1 patch

1 CVE

CVE-2021-43846 GHSA-h3fg-h5v3-vf8m Jan 06, 2022

CSRF forgery protection bypass in solidus_frontend

5.3 / 10

Medium

Network Low None None Unchanged None Low None

Impact

CSRF vulnerability that allows a malicious site to add an item to the user's cart without their knowledge.

All solidus_frontend versions are affected. If you're using your own storefront, please, follow along to make sure you're not affected.

To reproduce the issue:

Pick the id for a variant with available stock. From the rails console:
```
Spree::Variant.in_stock.pluck(:id)
```
Say we pick variant id 2.
Launch your application, for instance, on http://localhost:3000:
```
bin/rails server
```
Open your browser dev tools.
Click on whatever link in your store.
Copy the value of the Cookie request header sent for the previous request from your browser dev tools.

Execute the following, using your previously selected variant id and the value of the Cookie header (notice how it doesn't contain any authentication token):

curl -X POST -d "variant_id=2&quantity=1" -H "Cookie: guest_token=eyJfcmFpbHMiOnsibWVzc2FnZSI6IklrWlRVMWRQWnpKMVZVdFNXRzlPVW1aaWJHTjZZa0VpIiwiZXhwIjpudWxsLCJwdXIiOiJjb29raWUuZ3Vlc3RfdG9rZW4ifX0%3D--5006ba5d346f621c760a29b6a797bf351d17d1b8; _sandbox_session=vhutu5%2FL9NmWrUpGc3DxrFA%2FFsQD1dHn1cNsD7nvE84zcjWf17Af4%2F%2F2Vab3md71b6KTb9NP6WktdXktpwH4eU01jEGIBXG5%2BMzW5nL0nb4W269qk1io4LYljvoOg8%2BZVll7oJCVkJLKKh0sSoS0Kg8j%2FCHHs%2BsShohP%2BGnA%2Bfr9Ub8H6HofpSmloSpsfHHygmX0ho03fEgzHJ4DD5wJctaNKwg7NhVikHh5kgIPPHl84OGCgv3p2oe9jR19HTxOKq7BtyvDd7XZsecWhkcfS8BPnvDDUWZG6qpAEFI5kWo81KkpSJ%2Bp6Q1HOo8%3D--n3G2vgaDG7VS%2B%2FhF--ZTjxBAkfGG3hpr4GRQ2S1Q%3D%3D; __profilin=p%3Dt" http://localhost:3000/orders/populate

Reload your browser and look at how your cart got updated.

Patches

Please, upgrade solidus to versions 3.1.5, 3.0.5 or 2.11.14.

After upgrading, make sure you read the "Upgrade notes" section below.

Upgrade notes

The patch adds CSRF token verification to the "Add to cart" action. Adding forgery protection to a form that missed it can have some side effects.

`InvalidAuthenticityToken` errors

If you're using the :exception strategy, it's likely that after upgrading, you'll see more ActionController::InvalidAuthenticityToken errors popping out in your logs. Due to browser-side cache, a form can be re-rendered and sent without any attached request cookie (for instance, when re-opening a mobile browser). That will cause an authentication error, as the sent token won't match with the one in the session (none in this case). That's a known problem in the Rails community (see https://github.com/rails/rails/issues/21948), and, at this point, there's no perfect solution.

Any attempt to mitigate the issue should be seen at the application level. For an excellent survey of all the available options, take a look at https://github.com/betagouv/demarches-simplifiees.fr/blob/5b4f7f9ae9eaf0ac94008b62f7047e4714626cf9/doc/adr-csrf-forgery.md. The latter is a third-party link. As the information is relevant here, we're going to copy it below, but it should be clear that all the credit goes to @kemenaran:

Broken behavior due to session expiration + template cache

Although pretty unlikely, you should make sure that your current setup for cache/session expiration is compatible. The upgrade can break the addition of products to the cart if both:

The "Add to cart" form is being cached (usually along with the variant information).
A user session is reset at every or every few requests.

The token validation depends on the issuing and consuming sessions being the same. If a product page is cached with the token in it, it can become stale on a subsequent rendering if the session changes.

To check that you're safe, after having upgraded locally, go through the following steps:

Enable cache on dev mode:
```
bin/rails dev:cache
```
Visit the page for a variant with stock.
Reload that page several times.
Click on the "Add to cart" button.
Remember to rerun bin/rails dev:cache to turn off cache again.

No error or session reset should happen.

Otherwise, you can try with:

Revisiting how your session gets expired.
Changing the caching strategy to exclude the token.

Using weaker CSRF protection strategies

It's also important to understand that a complete fix will only be in place when using the :exception forgery protection strategy. The solidus_frontend engine can't do pretty much anything otherwise. Using weaker CSRF strategies should be an informed and limited decision made by the application team. After the upgrade:

An app using :null_session should also be safe, but there will be side effects. That strategy runs with a null object session. As such, no order and no user is found on it. A new cart state order is created in the database, associated with no user. Next time the user visits the site, they won't find any difference in its cart state.
An app using :reset_session is not entirely safe. That strategy resets the session. That means that registered users will be logged out. Next time a user visits, they'll see the cart with the items added during the CSRF attack, although it won't be associated with their account in the case of registered users.

Reversing the update

If you still want to deploy the upgraded version before changing your application code (if the latter is needed), you can add the following workaround to your config/application.rb (however, take into account that you'll keep being vulnerable):

config.after_initialize do
  Spree::OrdersController.skip_before_action :verify_authenticity_token, only: [:populate]
end

Workarounds

If an upgrade is not an option, you can work around the issue by adding the following to config/application.rb:

config.after_initialize do
  Spree::OrdersController.protect_from_forgery with: ApplicationController.forgery_protection_strategy.name.demodulize.underscore.to_sym, only: [:populate]
end

However, go through the same safety check detailed on "Upgrade notes" above.

References

For more information

If you have any questions or comments about this advisory:

Open an issue or a discussion in Solidus.
Email us at security@solidus.io
Contact the core team on Slack

Affected versions


          1.0.0


          1.0.0.pre


          1.0.0.pre2


          1.0.0.pre3


          1.0.0.rc1


          1.0.0.rc2


          1.0.1


          1.0.2


          1.0.3


          1.0.4


          1.0.5


          1.0.6

+ 117 more


            1.0.7


            1.1.0


            1.1.0.beta1


            1.1.0.pre1


            1.1.0.pre2


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.2.0


            1.2.0.beta1


            1.2.0.rc1


            1.2.0.rc2


            1.2.1


            1.2.2


            1.2.3


            1.3.0


            1.3.0.beta1


            1.3.0.rc1


            1.3.0.rc2


            1.3.1


            1.3.2


            1.4.0


            1.4.0.beta1


            1.4.0.rc1


            1.4.1


            1.4.2


            2.0.0


            2.0.0.beta1


            2.0.0.rc1


            2.0.1


            2.0.2


            2.0.3


            2.1.0


            2.1.0.beta1


            2.1.0.rc1


            2.1.1


            2.10.0


            2.10.0.beta1


            2.10.1


            2.10.2


            2.10.3


            2.10.5


            2.11.0


            2.11.1


            2.11.10


            2.11.11


            2.11.12


            2.11.13


            2.11.2


            2.11.3


            2.11.4


            2.11.5


            2.11.6


            2.11.7


            2.11.8


            2.11.9


            2.2.0


            2.2.0.beta1


            2.2.0.rc1


            2.2.1


            2.2.2


            2.3.0


            2.3.0.beta1


            2.3.0.rc1


            2.3.0.rc2


            2.3.0.rc3


            2.3.1


            2.4.0


            2.4.0.beta1


            2.4.0.rc1


            2.4.1


            2.4.2


            2.5.0


            2.5.0.beta1


            2.5.0.beta2


            2.5.0.rc1


            2.5.1


            2.5.2


            2.6.0


            2.6.0.rc1


            2.6.1


            2.6.2


            2.6.3


            2.6.4


            2.6.5


            2.6.6


            2.7.0


            2.7.1


            2.7.2


            2.7.3


            2.7.4


            2.8.0


            2.8.1


            2.8.2


            2.8.3


            2.8.4


            2.8.5


            2.8.6


            2.9.0


            2.9.0.rc.1


            2.9.1


            2.9.2


            2.9.3


            2.9.4


            2.9.5


            2.9.6


            3.0.0


            3.0.1


            3.0.2


            3.0.3


            3.0.4


            3.1.0


            3.1.1


            3.1.2


            3.1.3


            3.1.4

Fixed in


          2.11.14


          3.0.5


          3.1.5

References

Updated Jul 08, 2026 · Source: OSV.dev

May 10, 2021

2.10.5 patch

1 CVE

CVE-2021-43846 GHSA-h3fg-h5v3-vf8m Jan 06, 2022

CSRF forgery protection bypass in solidus_frontend

5.3 / 10

Medium

Network Low None None Unchanged None Low None

Impact

CSRF vulnerability that allows a malicious site to add an item to the user's cart without their knowledge.

All solidus_frontend versions are affected. If you're using your own storefront, please, follow along to make sure you're not affected.

To reproduce the issue:

Pick the id for a variant with available stock. From the rails console:
```
Spree::Variant.in_stock.pluck(:id)
```
Say we pick variant id 2.
Launch your application, for instance, on http://localhost:3000:
```
bin/rails server
```
Open your browser dev tools.
Click on whatever link in your store.
Copy the value of the Cookie request header sent for the previous request from your browser dev tools.

Execute the following, using your previously selected variant id and the value of the Cookie header (notice how it doesn't contain any authentication token):

curl -X POST -d "variant_id=2&quantity=1" -H "Cookie: guest_token=eyJfcmFpbHMiOnsibWVzc2FnZSI6IklrWlRVMWRQWnpKMVZVdFNXRzlPVW1aaWJHTjZZa0VpIiwiZXhwIjpudWxsLCJwdXIiOiJjb29raWUuZ3Vlc3RfdG9rZW4ifX0%3D--5006ba5d346f621c760a29b6a797bf351d17d1b8; _sandbox_session=vhutu5%2FL9NmWrUpGc3DxrFA%2FFsQD1dHn1cNsD7nvE84zcjWf17Af4%2F%2F2Vab3md71b6KTb9NP6WktdXktpwH4eU01jEGIBXG5%2BMzW5nL0nb4W269qk1io4LYljvoOg8%2BZVll7oJCVkJLKKh0sSoS0Kg8j%2FCHHs%2BsShohP%2BGnA%2Bfr9Ub8H6HofpSmloSpsfHHygmX0ho03fEgzHJ4DD5wJctaNKwg7NhVikHh5kgIPPHl84OGCgv3p2oe9jR19HTxOKq7BtyvDd7XZsecWhkcfS8BPnvDDUWZG6qpAEFI5kWo81KkpSJ%2Bp6Q1HOo8%3D--n3G2vgaDG7VS%2B%2FhF--ZTjxBAkfGG3hpr4GRQ2S1Q%3D%3D; __profilin=p%3Dt" http://localhost:3000/orders/populate

Reload your browser and look at how your cart got updated.

Patches

Please, upgrade solidus to versions 3.1.5, 3.0.5 or 2.11.14.

After upgrading, make sure you read the "Upgrade notes" section below.

Upgrade notes

The patch adds CSRF token verification to the "Add to cart" action. Adding forgery protection to a form that missed it can have some side effects.

`InvalidAuthenticityToken` errors

If you're using the :exception strategy, it's likely that after upgrading, you'll see more ActionController::InvalidAuthenticityToken errors popping out in your logs. Due to browser-side cache, a form can be re-rendered and sent without any attached request cookie (for instance, when re-opening a mobile browser). That will cause an authentication error, as the sent token won't match with the one in the session (none in this case). That's a known problem in the Rails community (see https://github.com/rails/rails/issues/21948), and, at this point, there's no perfect solution.

Any attempt to mitigate the issue should be seen at the application level. For an excellent survey of all the available options, take a look at https://github.com/betagouv/demarches-simplifiees.fr/blob/5b4f7f9ae9eaf0ac94008b62f7047e4714626cf9/doc/adr-csrf-forgery.md. The latter is a third-party link. As the information is relevant here, we're going to copy it below, but it should be clear that all the credit goes to @kemenaran:

Broken behavior due to session expiration + template cache

Although pretty unlikely, you should make sure that your current setup for cache/session expiration is compatible. The upgrade can break the addition of products to the cart if both:

The "Add to cart" form is being cached (usually along with the variant information).
A user session is reset at every or every few requests.

The token validation depends on the issuing and consuming sessions being the same. If a product page is cached with the token in it, it can become stale on a subsequent rendering if the session changes.

To check that you're safe, after having upgraded locally, go through the following steps:

Enable cache on dev mode:
```
bin/rails dev:cache
```
Visit the page for a variant with stock.
Reload that page several times.
Click on the "Add to cart" button.
Remember to rerun bin/rails dev:cache to turn off cache again.

No error or session reset should happen.

Otherwise, you can try with:

Revisiting how your session gets expired.
Changing the caching strategy to exclude the token.

Using weaker CSRF protection strategies

It's also important to understand that a complete fix will only be in place when using the :exception forgery protection strategy. The solidus_frontend engine can't do pretty much anything otherwise. Using weaker CSRF strategies should be an informed and limited decision made by the application team. After the upgrade:

An app using :null_session should also be safe, but there will be side effects. That strategy runs with a null object session. As such, no order and no user is found on it. A new cart state order is created in the database, associated with no user. Next time the user visits the site, they won't find any difference in its cart state.
An app using :reset_session is not entirely safe. That strategy resets the session. That means that registered users will be logged out. Next time a user visits, they'll see the cart with the items added during the CSRF attack, although it won't be associated with their account in the case of registered users.

Reversing the update

If you still want to deploy the upgraded version before changing your application code (if the latter is needed), you can add the following workaround to your config/application.rb (however, take into account that you'll keep being vulnerable):

config.after_initialize do
  Spree::OrdersController.skip_before_action :verify_authenticity_token, only: [:populate]
end

Workarounds

If an upgrade is not an option, you can work around the issue by adding the following to config/application.rb:

config.after_initialize do
  Spree::OrdersController.protect_from_forgery with: ApplicationController.forgery_protection_strategy.name.demodulize.underscore.to_sym, only: [:populate]
end

However, go through the same safety check detailed on "Upgrade notes" above.

References

For more information

If you have any questions or comments about this advisory:

Open an issue or a discussion in Solidus.
Email us at security@solidus.io
Contact the core team on Slack

Affected versions


          1.0.0


          1.0.0.pre


          1.0.0.pre2


          1.0.0.pre3


          1.0.0.rc1


          1.0.0.rc2


          1.0.1


          1.0.2


          1.0.3


          1.0.4


          1.0.5


          1.0.6

+ 117 more


            1.0.7


            1.1.0


            1.1.0.beta1


            1.1.0.pre1


            1.1.0.pre2


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.2.0


            1.2.0.beta1


            1.2.0.rc1


            1.2.0.rc2


            1.2.1


            1.2.2


            1.2.3


            1.3.0


            1.3.0.beta1


            1.3.0.rc1


            1.3.0.rc2


            1.3.1


            1.3.2


            1.4.0


            1.4.0.beta1


            1.4.0.rc1


            1.4.1


            1.4.2


            2.0.0


            2.0.0.beta1


            2.0.0.rc1


            2.0.1


            2.0.2


            2.0.3


            2.1.0


            2.1.0.beta1


            2.1.0.rc1


            2.1.1


            2.10.0


            2.10.0.beta1


            2.10.1


            2.10.2


            2.10.3


            2.10.5


            2.11.0


            2.11.1


            2.11.10


            2.11.11


            2.11.12


            2.11.13


            2.11.2


            2.11.3


            2.11.4


            2.11.5


            2.11.6


            2.11.7


            2.11.8


            2.11.9


            2.2.0


            2.2.0.beta1


            2.2.0.rc1


            2.2.1


            2.2.2


            2.3.0


            2.3.0.beta1


            2.3.0.rc1


            2.3.0.rc2


            2.3.0.rc3


            2.3.1


            2.4.0


            2.4.0.beta1


            2.4.0.rc1


            2.4.1


            2.4.2


            2.5.0


            2.5.0.beta1


            2.5.0.beta2


            2.5.0.rc1


            2.5.1


            2.5.2


            2.6.0


            2.6.0.rc1


            2.6.1


            2.6.2


            2.6.3


            2.6.4


            2.6.5


            2.6.6


            2.7.0


            2.7.1


            2.7.2


            2.7.3


            2.7.4


            2.8.0


            2.8.1


            2.8.2


            2.8.3


            2.8.4


            2.8.5


            2.8.6


            2.9.0


            2.9.0.rc.1


            2.9.1


            2.9.2


            2.9.3


            2.9.4


            2.9.5


            2.9.6


            3.0.0


            3.0.1


            3.0.2


            3.0.3


            3.0.4


            3.1.0


            3.1.1


            3.1.2


            3.1.3


            3.1.4

Fixed in


          2.11.14


          3.0.5


          3.1.5

References

Updated Jul 08, 2026 · Source: OSV.dev

May 10, 2021

2.11.10 patch

1 CVE

CVE-2021-43846 GHSA-h3fg-h5v3-vf8m Jan 06, 2022

CSRF forgery protection bypass in solidus_frontend

5.3 / 10

Medium

Network Low None None Unchanged None Low None

Impact

CSRF vulnerability that allows a malicious site to add an item to the user's cart without their knowledge.

All solidus_frontend versions are affected. If you're using your own storefront, please, follow along to make sure you're not affected.

To reproduce the issue:

Pick the id for a variant with available stock. From the rails console:
```
Spree::Variant.in_stock.pluck(:id)
```
Say we pick variant id 2.
Launch your application, for instance, on http://localhost:3000:
```
bin/rails server
```
Open your browser dev tools.
Click on whatever link in your store.
Copy the value of the Cookie request header sent for the previous request from your browser dev tools.

Execute the following, using your previously selected variant id and the value of the Cookie header (notice how it doesn't contain any authentication token):

curl -X POST -d "variant_id=2&quantity=1" -H "Cookie: guest_token=eyJfcmFpbHMiOnsibWVzc2FnZSI6IklrWlRVMWRQWnpKMVZVdFNXRzlPVW1aaWJHTjZZa0VpIiwiZXhwIjpudWxsLCJwdXIiOiJjb29raWUuZ3Vlc3RfdG9rZW4ifX0%3D--5006ba5d346f621c760a29b6a797bf351d17d1b8; _sandbox_session=vhutu5%2FL9NmWrUpGc3DxrFA%2FFsQD1dHn1cNsD7nvE84zcjWf17Af4%2F%2F2Vab3md71b6KTb9NP6WktdXktpwH4eU01jEGIBXG5%2BMzW5nL0nb4W269qk1io4LYljvoOg8%2BZVll7oJCVkJLKKh0sSoS0Kg8j%2FCHHs%2BsShohP%2BGnA%2Bfr9Ub8H6HofpSmloSpsfHHygmX0ho03fEgzHJ4DD5wJctaNKwg7NhVikHh5kgIPPHl84OGCgv3p2oe9jR19HTxOKq7BtyvDd7XZsecWhkcfS8BPnvDDUWZG6qpAEFI5kWo81KkpSJ%2Bp6Q1HOo8%3D--n3G2vgaDG7VS%2B%2FhF--ZTjxBAkfGG3hpr4GRQ2S1Q%3D%3D; __profilin=p%3Dt" http://localhost:3000/orders/populate

Reload your browser and look at how your cart got updated.

Patches

Please, upgrade solidus to versions 3.1.5, 3.0.5 or 2.11.14.

After upgrading, make sure you read the "Upgrade notes" section below.

Upgrade notes

The patch adds CSRF token verification to the "Add to cart" action. Adding forgery protection to a form that missed it can have some side effects.

`InvalidAuthenticityToken` errors

If you're using the :exception strategy, it's likely that after upgrading, you'll see more ActionController::InvalidAuthenticityToken errors popping out in your logs. Due to browser-side cache, a form can be re-rendered and sent without any attached request cookie (for instance, when re-opening a mobile browser). That will cause an authentication error, as the sent token won't match with the one in the session (none in this case). That's a known problem in the Rails community (see https://github.com/rails/rails/issues/21948), and, at this point, there's no perfect solution.

Any attempt to mitigate the issue should be seen at the application level. For an excellent survey of all the available options, take a look at https://github.com/betagouv/demarches-simplifiees.fr/blob/5b4f7f9ae9eaf0ac94008b62f7047e4714626cf9/doc/adr-csrf-forgery.md. The latter is a third-party link. As the information is relevant here, we're going to copy it below, but it should be clear that all the credit goes to @kemenaran:

Broken behavior due to session expiration + template cache

Although pretty unlikely, you should make sure that your current setup for cache/session expiration is compatible. The upgrade can break the addition of products to the cart if both:

The "Add to cart" form is being cached (usually along with the variant information).
A user session is reset at every or every few requests.

The token validation depends on the issuing and consuming sessions being the same. If a product page is cached with the token in it, it can become stale on a subsequent rendering if the session changes.

To check that you're safe, after having upgraded locally, go through the following steps:

Enable cache on dev mode:
```
bin/rails dev:cache
```
Visit the page for a variant with stock.
Reload that page several times.
Click on the "Add to cart" button.
Remember to rerun bin/rails dev:cache to turn off cache again.

No error or session reset should happen.

Otherwise, you can try with:

Revisiting how your session gets expired.
Changing the caching strategy to exclude the token.

Using weaker CSRF protection strategies

It's also important to understand that a complete fix will only be in place when using the :exception forgery protection strategy. The solidus_frontend engine can't do pretty much anything otherwise. Using weaker CSRF strategies should be an informed and limited decision made by the application team. After the upgrade:

An app using :null_session should also be safe, but there will be side effects. That strategy runs with a null object session. As such, no order and no user is found on it. A new cart state order is created in the database, associated with no user. Next time the user visits the site, they won't find any difference in its cart state.
An app using :reset_session is not entirely safe. That strategy resets the session. That means that registered users will be logged out. Next time a user visits, they'll see the cart with the items added during the CSRF attack, although it won't be associated with their account in the case of registered users.

Reversing the update

If you still want to deploy the upgraded version before changing your application code (if the latter is needed), you can add the following workaround to your config/application.rb (however, take into account that you'll keep being vulnerable):

config.after_initialize do
  Spree::OrdersController.skip_before_action :verify_authenticity_token, only: [:populate]
end

Workarounds

If an upgrade is not an option, you can work around the issue by adding the following to config/application.rb:

config.after_initialize do
  Spree::OrdersController.protect_from_forgery with: ApplicationController.forgery_protection_strategy.name.demodulize.underscore.to_sym, only: [:populate]
end

However, go through the same safety check detailed on "Upgrade notes" above.

References

For more information

If you have any questions or comments about this advisory:

Open an issue or a discussion in Solidus.
Email us at security@solidus.io
Contact the core team on Slack

Affected versions


          1.0.0


          1.0.0.pre


          1.0.0.pre2


          1.0.0.pre3


          1.0.0.rc1


          1.0.0.rc2


          1.0.1


          1.0.2


          1.0.3


          1.0.4


          1.0.5


          1.0.6

+ 117 more


            1.0.7


            1.1.0


            1.1.0.beta1


            1.1.0.pre1


            1.1.0.pre2


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.2.0


            1.2.0.beta1


            1.2.0.rc1


            1.2.0.rc2


            1.2.1


            1.2.2


            1.2.3


            1.3.0


            1.3.0.beta1


            1.3.0.rc1


            1.3.0.rc2


            1.3.1


            1.3.2


            1.4.0


            1.4.0.beta1


            1.4.0.rc1


            1.4.1


            1.4.2


            2.0.0


            2.0.0.beta1


            2.0.0.rc1


            2.0.1


            2.0.2


            2.0.3


            2.1.0


            2.1.0.beta1


            2.1.0.rc1


            2.1.1


            2.10.0


            2.10.0.beta1


            2.10.1


            2.10.2


            2.10.3


            2.10.5


            2.11.0


            2.11.1


            2.11.10


            2.11.11


            2.11.12


            2.11.13


            2.11.2


            2.11.3


            2.11.4


            2.11.5


            2.11.6


            2.11.7


            2.11.8


            2.11.9


            2.2.0


            2.2.0.beta1


            2.2.0.rc1


            2.2.1


            2.2.2


            2.3.0


            2.3.0.beta1


            2.3.0.rc1


            2.3.0.rc2


            2.3.0.rc3


            2.3.1


            2.4.0


            2.4.0.beta1


            2.4.0.rc1


            2.4.1


            2.4.2


            2.5.0


            2.5.0.beta1


            2.5.0.beta2


            2.5.0.rc1


            2.5.1


            2.5.2


            2.6.0


            2.6.0.rc1


            2.6.1


            2.6.2


            2.6.3


            2.6.4


            2.6.5


            2.6.6


            2.7.0


            2.7.1


            2.7.2


            2.7.3


            2.7.4


            2.8.0


            2.8.1


            2.8.2


            2.8.3


            2.8.4


            2.8.5


            2.8.6


            2.9.0


            2.9.0.rc.1


            2.9.1


            2.9.2


            2.9.3


            2.9.4


            2.9.5


            2.9.6


            3.0.0


            3.0.1


            3.0.2


            3.0.3


            3.0.4


            3.1.0


            3.1.1


            3.1.2


            3.1.3


            3.1.4

Fixed in


          2.11.14


          3.0.5


          3.1.5

References

Updated Jul 08, 2026 · Source: OSV.dev

May 10, 2021

2.11.9 patch

1 CVE

CVE-2021-43846 GHSA-h3fg-h5v3-vf8m Jan 06, 2022

CSRF forgery protection bypass in solidus_frontend

5.3 / 10

Medium

Network Low None None Unchanged None Low None

Impact

CSRF vulnerability that allows a malicious site to add an item to the user's cart without their knowledge.

All solidus_frontend versions are affected. If you're using your own storefront, please, follow along to make sure you're not affected.

To reproduce the issue:

Pick the id for a variant with available stock. From the rails console:
```
Spree::Variant.in_stock.pluck(:id)
```
Say we pick variant id 2.
Launch your application, for instance, on http://localhost:3000:
```
bin/rails server
```
Open your browser dev tools.
Click on whatever link in your store.
Copy the value of the Cookie request header sent for the previous request from your browser dev tools.

Execute the following, using your previously selected variant id and the value of the Cookie header (notice how it doesn't contain any authentication token):

curl -X POST -d "variant_id=2&quantity=1" -H "Cookie: guest_token=eyJfcmFpbHMiOnsibWVzc2FnZSI6IklrWlRVMWRQWnpKMVZVdFNXRzlPVW1aaWJHTjZZa0VpIiwiZXhwIjpudWxsLCJwdXIiOiJjb29raWUuZ3Vlc3RfdG9rZW4ifX0%3D--5006ba5d346f621c760a29b6a797bf351d17d1b8; _sandbox_session=vhutu5%2FL9NmWrUpGc3DxrFA%2FFsQD1dHn1cNsD7nvE84zcjWf17Af4%2F%2F2Vab3md71b6KTb9NP6WktdXktpwH4eU01jEGIBXG5%2BMzW5nL0nb4W269qk1io4LYljvoOg8%2BZVll7oJCVkJLKKh0sSoS0Kg8j%2FCHHs%2BsShohP%2BGnA%2Bfr9Ub8H6HofpSmloSpsfHHygmX0ho03fEgzHJ4DD5wJctaNKwg7NhVikHh5kgIPPHl84OGCgv3p2oe9jR19HTxOKq7BtyvDd7XZsecWhkcfS8BPnvDDUWZG6qpAEFI5kWo81KkpSJ%2Bp6Q1HOo8%3D--n3G2vgaDG7VS%2B%2FhF--ZTjxBAkfGG3hpr4GRQ2S1Q%3D%3D; __profilin=p%3Dt" http://localhost:3000/orders/populate

Reload your browser and look at how your cart got updated.

Patches

Please, upgrade solidus to versions 3.1.5, 3.0.5 or 2.11.14.

After upgrading, make sure you read the "Upgrade notes" section below.

Upgrade notes

The patch adds CSRF token verification to the "Add to cart" action. Adding forgery protection to a form that missed it can have some side effects.

`InvalidAuthenticityToken` errors

If you're using the :exception strategy, it's likely that after upgrading, you'll see more ActionController::InvalidAuthenticityToken errors popping out in your logs. Due to browser-side cache, a form can be re-rendered and sent without any attached request cookie (for instance, when re-opening a mobile browser). That will cause an authentication error, as the sent token won't match with the one in the session (none in this case). That's a known problem in the Rails community (see https://github.com/rails/rails/issues/21948), and, at this point, there's no perfect solution.

Any attempt to mitigate the issue should be seen at the application level. For an excellent survey of all the available options, take a look at https://github.com/betagouv/demarches-simplifiees.fr/blob/5b4f7f9ae9eaf0ac94008b62f7047e4714626cf9/doc/adr-csrf-forgery.md. The latter is a third-party link. As the information is relevant here, we're going to copy it below, but it should be clear that all the credit goes to @kemenaran:

Broken behavior due to session expiration + template cache

Although pretty unlikely, you should make sure that your current setup for cache/session expiration is compatible. The upgrade can break the addition of products to the cart if both:

The "Add to cart" form is being cached (usually along with the variant information).
A user session is reset at every or every few requests.

The token validation depends on the issuing and consuming sessions being the same. If a product page is cached with the token in it, it can become stale on a subsequent rendering if the session changes.

To check that you're safe, after having upgraded locally, go through the following steps:

Enable cache on dev mode:
```
bin/rails dev:cache
```
Visit the page for a variant with stock.
Reload that page several times.
Click on the "Add to cart" button.
Remember to rerun bin/rails dev:cache to turn off cache again.

No error or session reset should happen.

Otherwise, you can try with:

Revisiting how your session gets expired.
Changing the caching strategy to exclude the token.

Using weaker CSRF protection strategies

It's also important to understand that a complete fix will only be in place when using the :exception forgery protection strategy. The solidus_frontend engine can't do pretty much anything otherwise. Using weaker CSRF strategies should be an informed and limited decision made by the application team. After the upgrade:

An app using :null_session should also be safe, but there will be side effects. That strategy runs with a null object session. As such, no order and no user is found on it. A new cart state order is created in the database, associated with no user. Next time the user visits the site, they won't find any difference in its cart state.
An app using :reset_session is not entirely safe. That strategy resets the session. That means that registered users will be logged out. Next time a user visits, they'll see the cart with the items added during the CSRF attack, although it won't be associated with their account in the case of registered users.

Reversing the update

If you still want to deploy the upgraded version before changing your application code (if the latter is needed), you can add the following workaround to your config/application.rb (however, take into account that you'll keep being vulnerable):

config.after_initialize do
  Spree::OrdersController.skip_before_action :verify_authenticity_token, only: [:populate]
end

Workarounds

If an upgrade is not an option, you can work around the issue by adding the following to config/application.rb:

config.after_initialize do
  Spree::OrdersController.protect_from_forgery with: ApplicationController.forgery_protection_strategy.name.demodulize.underscore.to_sym, only: [:populate]
end

However, go through the same safety check detailed on "Upgrade notes" above.

References

For more information

If you have any questions or comments about this advisory:

Open an issue or a discussion in Solidus.
Email us at security@solidus.io
Contact the core team on Slack

Affected versions


          1.0.0


          1.0.0.pre


          1.0.0.pre2


          1.0.0.pre3


          1.0.0.rc1


          1.0.0.rc2


          1.0.1


          1.0.2


          1.0.3


          1.0.4


          1.0.5


          1.0.6

+ 117 more


            1.0.7


            1.1.0


            1.1.0.beta1


            1.1.0.pre1


            1.1.0.pre2


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.2.0


            1.2.0.beta1


            1.2.0.rc1


            1.2.0.rc2


            1.2.1


            1.2.2


            1.2.3


            1.3.0


            1.3.0.beta1


            1.3.0.rc1


            1.3.0.rc2


            1.3.1


            1.3.2


            1.4.0


            1.4.0.beta1


            1.4.0.rc1


            1.4.1


            1.4.2


            2.0.0


            2.0.0.beta1


            2.0.0.rc1


            2.0.1


            2.0.2


            2.0.3


            2.1.0


            2.1.0.beta1


            2.1.0.rc1


            2.1.1


            2.10.0


            2.10.0.beta1


            2.10.1


            2.10.2


            2.10.3


            2.10.5


            2.11.0


            2.11.1


            2.11.10


            2.11.11


            2.11.12


            2.11.13


            2.11.2


            2.11.3


            2.11.4


            2.11.5


            2.11.6


            2.11.7


            2.11.8


            2.11.9


            2.2.0


            2.2.0.beta1


            2.2.0.rc1


            2.2.1


            2.2.2


            2.3.0


            2.3.0.beta1


            2.3.0.rc1


            2.3.0.rc2


            2.3.0.rc3


            2.3.1


            2.4.0


            2.4.0.beta1


            2.4.0.rc1


            2.4.1


            2.4.2


            2.5.0


            2.5.0.beta1


            2.5.0.beta2


            2.5.0.rc1


            2.5.1


            2.5.2


            2.6.0


            2.6.0.rc1


            2.6.1


            2.6.2


            2.6.3


            2.6.4


            2.6.5


            2.6.6


            2.7.0


            2.7.1


            2.7.2


            2.7.3


            2.7.4


            2.8.0


            2.8.1


            2.8.2


            2.8.3


            2.8.4


            2.8.5


            2.8.6


            2.9.0


            2.9.0.rc.1


            2.9.1


            2.9.2


            2.9.3


            2.9.4


            2.9.5


            2.9.6


            3.0.0


            3.0.1


            3.0.2


            3.0.3


            3.0.4


            3.1.0


            3.1.1


            3.1.2


            3.1.3


            3.1.4

Fixed in


          2.11.14


          3.0.5


          3.1.5

References

Updated Jul 08, 2026 · Source: OSV.dev

Apr 20, 2021

3.0.0 major

1 CVE

CVE-2021-43846 GHSA-h3fg-h5v3-vf8m Jan 06, 2022

CSRF forgery protection bypass in solidus_frontend

5.3 / 10

Medium

Network Low None None Unchanged None Low None

Impact

CSRF vulnerability that allows a malicious site to add an item to the user's cart without their knowledge.

All solidus_frontend versions are affected. If you're using your own storefront, please, follow along to make sure you're not affected.

To reproduce the issue:

Pick the id for a variant with available stock. From the rails console:
```
Spree::Variant.in_stock.pluck(:id)
```
Say we pick variant id 2.
Launch your application, for instance, on http://localhost:3000:
```
bin/rails server
```
Open your browser dev tools.
Click on whatever link in your store.
Copy the value of the Cookie request header sent for the previous request from your browser dev tools.

Execute the following, using your previously selected variant id and the value of the Cookie header (notice how it doesn't contain any authentication token):

curl -X POST -d "variant_id=2&quantity=1" -H "Cookie: guest_token=eyJfcmFpbHMiOnsibWVzc2FnZSI6IklrWlRVMWRQWnpKMVZVdFNXRzlPVW1aaWJHTjZZa0VpIiwiZXhwIjpudWxsLCJwdXIiOiJjb29raWUuZ3Vlc3RfdG9rZW4ifX0%3D--5006ba5d346f621c760a29b6a797bf351d17d1b8; _sandbox_session=vhutu5%2FL9NmWrUpGc3DxrFA%2FFsQD1dHn1cNsD7nvE84zcjWf17Af4%2F%2F2Vab3md71b6KTb9NP6WktdXktpwH4eU01jEGIBXG5%2BMzW5nL0nb4W269qk1io4LYljvoOg8%2BZVll7oJCVkJLKKh0sSoS0Kg8j%2FCHHs%2BsShohP%2BGnA%2Bfr9Ub8H6HofpSmloSpsfHHygmX0ho03fEgzHJ4DD5wJctaNKwg7NhVikHh5kgIPPHl84OGCgv3p2oe9jR19HTxOKq7BtyvDd7XZsecWhkcfS8BPnvDDUWZG6qpAEFI5kWo81KkpSJ%2Bp6Q1HOo8%3D--n3G2vgaDG7VS%2B%2FhF--ZTjxBAkfGG3hpr4GRQ2S1Q%3D%3D; __profilin=p%3Dt" http://localhost:3000/orders/populate

Reload your browser and look at how your cart got updated.

Patches

Please, upgrade solidus to versions 3.1.5, 3.0.5 or 2.11.14.

After upgrading, make sure you read the "Upgrade notes" section below.

Upgrade notes

The patch adds CSRF token verification to the "Add to cart" action. Adding forgery protection to a form that missed it can have some side effects.

`InvalidAuthenticityToken` errors

If you're using the :exception strategy, it's likely that after upgrading, you'll see more ActionController::InvalidAuthenticityToken errors popping out in your logs. Due to browser-side cache, a form can be re-rendered and sent without any attached request cookie (for instance, when re-opening a mobile browser). That will cause an authentication error, as the sent token won't match with the one in the session (none in this case). That's a known problem in the Rails community (see https://github.com/rails/rails/issues/21948), and, at this point, there's no perfect solution.

Any attempt to mitigate the issue should be seen at the application level. For an excellent survey of all the available options, take a look at https://github.com/betagouv/demarches-simplifiees.fr/blob/5b4f7f9ae9eaf0ac94008b62f7047e4714626cf9/doc/adr-csrf-forgery.md. The latter is a third-party link. As the information is relevant here, we're going to copy it below, but it should be clear that all the credit goes to @kemenaran:

Broken behavior due to session expiration + template cache

Although pretty unlikely, you should make sure that your current setup for cache/session expiration is compatible. The upgrade can break the addition of products to the cart if both:

The "Add to cart" form is being cached (usually along with the variant information).
A user session is reset at every or every few requests.

The token validation depends on the issuing and consuming sessions being the same. If a product page is cached with the token in it, it can become stale on a subsequent rendering if the session changes.

To check that you're safe, after having upgraded locally, go through the following steps:

Enable cache on dev mode:
```
bin/rails dev:cache
```
Visit the page for a variant with stock.
Reload that page several times.
Click on the "Add to cart" button.
Remember to rerun bin/rails dev:cache to turn off cache again.

No error or session reset should happen.

Otherwise, you can try with:

Revisiting how your session gets expired.
Changing the caching strategy to exclude the token.

Using weaker CSRF protection strategies

It's also important to understand that a complete fix will only be in place when using the :exception forgery protection strategy. The solidus_frontend engine can't do pretty much anything otherwise. Using weaker CSRF strategies should be an informed and limited decision made by the application team. After the upgrade:

An app using :null_session should also be safe, but there will be side effects. That strategy runs with a null object session. As such, no order and no user is found on it. A new cart state order is created in the database, associated with no user. Next time the user visits the site, they won't find any difference in its cart state.
An app using :reset_session is not entirely safe. That strategy resets the session. That means that registered users will be logged out. Next time a user visits, they'll see the cart with the items added during the CSRF attack, although it won't be associated with their account in the case of registered users.

Reversing the update

If you still want to deploy the upgraded version before changing your application code (if the latter is needed), you can add the following workaround to your config/application.rb (however, take into account that you'll keep being vulnerable):

config.after_initialize do
  Spree::OrdersController.skip_before_action :verify_authenticity_token, only: [:populate]
end

Workarounds

If an upgrade is not an option, you can work around the issue by adding the following to config/application.rb:

config.after_initialize do
  Spree::OrdersController.protect_from_forgery with: ApplicationController.forgery_protection_strategy.name.demodulize.underscore.to_sym, only: [:populate]
end

However, go through the same safety check detailed on "Upgrade notes" above.

References

For more information

If you have any questions or comments about this advisory:

Open an issue or a discussion in Solidus.
Email us at security@solidus.io
Contact the core team on Slack

Affected versions


          1.0.0


          1.0.0.pre


          1.0.0.pre2


          1.0.0.pre3


          1.0.0.rc1


          1.0.0.rc2


          1.0.1


          1.0.2


          1.0.3


          1.0.4


          1.0.5


          1.0.6

+ 117 more


            1.0.7


            1.1.0


            1.1.0.beta1


            1.1.0.pre1


            1.1.0.pre2


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.2.0


            1.2.0.beta1


            1.2.0.rc1


            1.2.0.rc2


            1.2.1


            1.2.2


            1.2.3


            1.3.0


            1.3.0.beta1


            1.3.0.rc1


            1.3.0.rc2


            1.3.1


            1.3.2


            1.4.0


            1.4.0.beta1


            1.4.0.rc1


            1.4.1


            1.4.2


            2.0.0


            2.0.0.beta1


            2.0.0.rc1


            2.0.1


            2.0.2


            2.0.3


            2.1.0


            2.1.0.beta1


            2.1.0.rc1


            2.1.1


            2.10.0


            2.10.0.beta1


            2.10.1


            2.10.2


            2.10.3


            2.10.5


            2.11.0


            2.11.1


            2.11.10


            2.11.11


            2.11.12


            2.11.13


            2.11.2


            2.11.3


            2.11.4


            2.11.5


            2.11.6


            2.11.7


            2.11.8


            2.11.9


            2.2.0


            2.2.0.beta1


            2.2.0.rc1


            2.2.1


            2.2.2


            2.3.0


            2.3.0.beta1


            2.3.0.rc1


            2.3.0.rc2


            2.3.0.rc3


            2.3.1


            2.4.0


            2.4.0.beta1


            2.4.0.rc1


            2.4.1


            2.4.2


            2.5.0


            2.5.0.beta1


            2.5.0.beta2


            2.5.0.rc1


            2.5.1


            2.5.2


            2.6.0


            2.6.0.rc1


            2.6.1


            2.6.2


            2.6.3


            2.6.4


            2.6.5


            2.6.6


            2.7.0


            2.7.1


            2.7.2


            2.7.3


            2.7.4


            2.8.0


            2.8.1


            2.8.2


            2.8.3


            2.8.4


            2.8.5


            2.8.6


            2.9.0


            2.9.0.rc.1


            2.9.1


            2.9.2


            2.9.3


            2.9.4


            2.9.5


            2.9.6


            3.0.0


            3.0.1


            3.0.2


            3.0.3


            3.0.4


            3.1.0


            3.1.1


            3.1.2


            3.1.3


            3.1.4

Fixed in


          2.11.14


          3.0.5


          3.1.5

References

Updated Jul 08, 2026 · Source: OSV.dev

Apr 20, 2021

2.11.8 patch

1 CVE

CVE-2021-43846 GHSA-h3fg-h5v3-vf8m Jan 06, 2022

CSRF forgery protection bypass in solidus_frontend

5.3 / 10

Medium

Network Low None None Unchanged None Low None

Impact

CSRF vulnerability that allows a malicious site to add an item to the user's cart without their knowledge.

All solidus_frontend versions are affected. If you're using your own storefront, please, follow along to make sure you're not affected.

To reproduce the issue:

Pick the id for a variant with available stock. From the rails console:
```
Spree::Variant.in_stock.pluck(:id)
```
Say we pick variant id 2.
Launch your application, for instance, on http://localhost:3000:
```
bin/rails server
```
Open your browser dev tools.
Click on whatever link in your store.
Copy the value of the Cookie request header sent for the previous request from your browser dev tools.

Execute the following, using your previously selected variant id and the value of the Cookie header (notice how it doesn't contain any authentication token):

curl -X POST -d "variant_id=2&quantity=1" -H "Cookie: guest_token=eyJfcmFpbHMiOnsibWVzc2FnZSI6IklrWlRVMWRQWnpKMVZVdFNXRzlPVW1aaWJHTjZZa0VpIiwiZXhwIjpudWxsLCJwdXIiOiJjb29raWUuZ3Vlc3RfdG9rZW4ifX0%3D--5006ba5d346f621c760a29b6a797bf351d17d1b8; _sandbox_session=vhutu5%2FL9NmWrUpGc3DxrFA%2FFsQD1dHn1cNsD7nvE84zcjWf17Af4%2F%2F2Vab3md71b6KTb9NP6WktdXktpwH4eU01jEGIBXG5%2BMzW5nL0nb4W269qk1io4LYljvoOg8%2BZVll7oJCVkJLKKh0sSoS0Kg8j%2FCHHs%2BsShohP%2BGnA%2Bfr9Ub8H6HofpSmloSpsfHHygmX0ho03fEgzHJ4DD5wJctaNKwg7NhVikHh5kgIPPHl84OGCgv3p2oe9jR19HTxOKq7BtyvDd7XZsecWhkcfS8BPnvDDUWZG6qpAEFI5kWo81KkpSJ%2Bp6Q1HOo8%3D--n3G2vgaDG7VS%2B%2FhF--ZTjxBAkfGG3hpr4GRQ2S1Q%3D%3D; __profilin=p%3Dt" http://localhost:3000/orders/populate

Reload your browser and look at how your cart got updated.

Patches

Please, upgrade solidus to versions 3.1.5, 3.0.5 or 2.11.14.

After upgrading, make sure you read the "Upgrade notes" section below.

Upgrade notes

The patch adds CSRF token verification to the "Add to cart" action. Adding forgery protection to a form that missed it can have some side effects.

`InvalidAuthenticityToken` errors

If you're using the :exception strategy, it's likely that after upgrading, you'll see more ActionController::InvalidAuthenticityToken errors popping out in your logs. Due to browser-side cache, a form can be re-rendered and sent without any attached request cookie (for instance, when re-opening a mobile browser). That will cause an authentication error, as the sent token won't match with the one in the session (none in this case). That's a known problem in the Rails community (see https://github.com/rails/rails/issues/21948), and, at this point, there's no perfect solution.

Any attempt to mitigate the issue should be seen at the application level. For an excellent survey of all the available options, take a look at https://github.com/betagouv/demarches-simplifiees.fr/blob/5b4f7f9ae9eaf0ac94008b62f7047e4714626cf9/doc/adr-csrf-forgery.md. The latter is a third-party link. As the information is relevant here, we're going to copy it below, but it should be clear that all the credit goes to @kemenaran:

Broken behavior due to session expiration + template cache

Although pretty unlikely, you should make sure that your current setup for cache/session expiration is compatible. The upgrade can break the addition of products to the cart if both:

The "Add to cart" form is being cached (usually along with the variant information).
A user session is reset at every or every few requests.

The token validation depends on the issuing and consuming sessions being the same. If a product page is cached with the token in it, it can become stale on a subsequent rendering if the session changes.

To check that you're safe, after having upgraded locally, go through the following steps:

Enable cache on dev mode:
```
bin/rails dev:cache
```
Visit the page for a variant with stock.
Reload that page several times.
Click on the "Add to cart" button.
Remember to rerun bin/rails dev:cache to turn off cache again.

No error or session reset should happen.

Otherwise, you can try with:

Revisiting how your session gets expired.
Changing the caching strategy to exclude the token.

Using weaker CSRF protection strategies

It's also important to understand that a complete fix will only be in place when using the :exception forgery protection strategy. The solidus_frontend engine can't do pretty much anything otherwise. Using weaker CSRF strategies should be an informed and limited decision made by the application team. After the upgrade:

An app using :null_session should also be safe, but there will be side effects. That strategy runs with a null object session. As such, no order and no user is found on it. A new cart state order is created in the database, associated with no user. Next time the user visits the site, they won't find any difference in its cart state.
An app using :reset_session is not entirely safe. That strategy resets the session. That means that registered users will be logged out. Next time a user visits, they'll see the cart with the items added during the CSRF attack, although it won't be associated with their account in the case of registered users.

Reversing the update

If you still want to deploy the upgraded version before changing your application code (if the latter is needed), you can add the following workaround to your config/application.rb (however, take into account that you'll keep being vulnerable):

config.after_initialize do
  Spree::OrdersController.skip_before_action :verify_authenticity_token, only: [:populate]
end

Workarounds

If an upgrade is not an option, you can work around the issue by adding the following to config/application.rb:

config.after_initialize do
  Spree::OrdersController.protect_from_forgery with: ApplicationController.forgery_protection_strategy.name.demodulize.underscore.to_sym, only: [:populate]
end

However, go through the same safety check detailed on "Upgrade notes" above.

References

For more information

If you have any questions or comments about this advisory:

Open an issue or a discussion in Solidus.
Email us at security@solidus.io
Contact the core team on Slack

Affected versions


          1.0.0


          1.0.0.pre


          1.0.0.pre2


          1.0.0.pre3


          1.0.0.rc1


          1.0.0.rc2


          1.0.1


          1.0.2


          1.0.3


          1.0.4


          1.0.5


          1.0.6

+ 117 more


            1.0.7


            1.1.0


            1.1.0.beta1


            1.1.0.pre1


            1.1.0.pre2


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.2.0


            1.2.0.beta1


            1.2.0.rc1


            1.2.0.rc2


            1.2.1


            1.2.2


            1.2.3


            1.3.0


            1.3.0.beta1


            1.3.0.rc1


            1.3.0.rc2


            1.3.1


            1.3.2


            1.4.0


            1.4.0.beta1


            1.4.0.rc1


            1.4.1


            1.4.2


            2.0.0


            2.0.0.beta1


            2.0.0.rc1


            2.0.1


            2.0.2


            2.0.3


            2.1.0


            2.1.0.beta1


            2.1.0.rc1


            2.1.1


            2.10.0


            2.10.0.beta1


            2.10.1


            2.10.2


            2.10.3


            2.10.5


            2.11.0


            2.11.1


            2.11.10


            2.11.11


            2.11.12


            2.11.13


            2.11.2


            2.11.3


            2.11.4


            2.11.5


            2.11.6


            2.11.7


            2.11.8


            2.11.9


            2.2.0


            2.2.0.beta1


            2.2.0.rc1


            2.2.1


            2.2.2


            2.3.0


            2.3.0.beta1


            2.3.0.rc1


            2.3.0.rc2


            2.3.0.rc3


            2.3.1


            2.4.0


            2.4.0.beta1


            2.4.0.rc1


            2.4.1


            2.4.2


            2.5.0


            2.5.0.beta1


            2.5.0.beta2


            2.5.0.rc1


            2.5.1


            2.5.2


            2.6.0


            2.6.0.rc1


            2.6.1


            2.6.2


            2.6.3


            2.6.4


            2.6.5


            2.6.6


            2.7.0


            2.7.1


            2.7.2


            2.7.3


            2.7.4


            2.8.0


            2.8.1


            2.8.2


            2.8.3


            2.8.4


            2.8.5


            2.8.6


            2.9.0


            2.9.0.rc.1


            2.9.1


            2.9.2


            2.9.3


            2.9.4


            2.9.5


            2.9.6


            3.0.0


            3.0.1


            3.0.2


            3.0.3


            3.0.4


            3.1.0


            3.1.1


            3.1.2


            3.1.3


            3.1.4

Fixed in


          2.11.14


          3.0.5


          3.1.5

References

Updated Jul 08, 2026 · Source: OSV.dev

Apr 01, 2021

2.11.6 patch

1 CVE

CVE-2021-43846 GHSA-h3fg-h5v3-vf8m Jan 06, 2022

CSRF forgery protection bypass in solidus_frontend

5.3 / 10

Medium

Network Low None None Unchanged None Low None

Impact

CSRF vulnerability that allows a malicious site to add an item to the user's cart without their knowledge.

All solidus_frontend versions are affected. If you're using your own storefront, please, follow along to make sure you're not affected.

To reproduce the issue:

Pick the id for a variant with available stock. From the rails console:
```
Spree::Variant.in_stock.pluck(:id)
```
Say we pick variant id 2.
Launch your application, for instance, on http://localhost:3000:
```
bin/rails server
```
Open your browser dev tools.
Click on whatever link in your store.
Copy the value of the Cookie request header sent for the previous request from your browser dev tools.

Execute the following, using your previously selected variant id and the value of the Cookie header (notice how it doesn't contain any authentication token):

curl -X POST -d "variant_id=2&quantity=1" -H "Cookie: guest_token=eyJfcmFpbHMiOnsibWVzc2FnZSI6IklrWlRVMWRQWnpKMVZVdFNXRzlPVW1aaWJHTjZZa0VpIiwiZXhwIjpudWxsLCJwdXIiOiJjb29raWUuZ3Vlc3RfdG9rZW4ifX0%3D--5006ba5d346f621c760a29b6a797bf351d17d1b8; _sandbox_session=vhutu5%2FL9NmWrUpGc3DxrFA%2FFsQD1dHn1cNsD7nvE84zcjWf17Af4%2F%2F2Vab3md71b6KTb9NP6WktdXktpwH4eU01jEGIBXG5%2BMzW5nL0nb4W269qk1io4LYljvoOg8%2BZVll7oJCVkJLKKh0sSoS0Kg8j%2FCHHs%2BsShohP%2BGnA%2Bfr9Ub8H6HofpSmloSpsfHHygmX0ho03fEgzHJ4DD5wJctaNKwg7NhVikHh5kgIPPHl84OGCgv3p2oe9jR19HTxOKq7BtyvDd7XZsecWhkcfS8BPnvDDUWZG6qpAEFI5kWo81KkpSJ%2Bp6Q1HOo8%3D--n3G2vgaDG7VS%2B%2FhF--ZTjxBAkfGG3hpr4GRQ2S1Q%3D%3D; __profilin=p%3Dt" http://localhost:3000/orders/populate

Reload your browser and look at how your cart got updated.

Patches

Please, upgrade solidus to versions 3.1.5, 3.0.5 or 2.11.14.

After upgrading, make sure you read the "Upgrade notes" section below.

Upgrade notes

The patch adds CSRF token verification to the "Add to cart" action. Adding forgery protection to a form that missed it can have some side effects.

`InvalidAuthenticityToken` errors

If you're using the :exception strategy, it's likely that after upgrading, you'll see more ActionController::InvalidAuthenticityToken errors popping out in your logs. Due to browser-side cache, a form can be re-rendered and sent without any attached request cookie (for instance, when re-opening a mobile browser). That will cause an authentication error, as the sent token won't match with the one in the session (none in this case). That's a known problem in the Rails community (see https://github.com/rails/rails/issues/21948), and, at this point, there's no perfect solution.

Any attempt to mitigate the issue should be seen at the application level. For an excellent survey of all the available options, take a look at https://github.com/betagouv/demarches-simplifiees.fr/blob/5b4f7f9ae9eaf0ac94008b62f7047e4714626cf9/doc/adr-csrf-forgery.md. The latter is a third-party link. As the information is relevant here, we're going to copy it below, but it should be clear that all the credit goes to @kemenaran:

Broken behavior due to session expiration + template cache

Although pretty unlikely, you should make sure that your current setup for cache/session expiration is compatible. The upgrade can break the addition of products to the cart if both:

The "Add to cart" form is being cached (usually along with the variant information).
A user session is reset at every or every few requests.

The token validation depends on the issuing and consuming sessions being the same. If a product page is cached with the token in it, it can become stale on a subsequent rendering if the session changes.

To check that you're safe, after having upgraded locally, go through the following steps:

Enable cache on dev mode:
```
bin/rails dev:cache
```
Visit the page for a variant with stock.
Reload that page several times.
Click on the "Add to cart" button.
Remember to rerun bin/rails dev:cache to turn off cache again.

No error or session reset should happen.

Otherwise, you can try with:

Revisiting how your session gets expired.
Changing the caching strategy to exclude the token.

Using weaker CSRF protection strategies

It's also important to understand that a complete fix will only be in place when using the :exception forgery protection strategy. The solidus_frontend engine can't do pretty much anything otherwise. Using weaker CSRF strategies should be an informed and limited decision made by the application team. After the upgrade:

An app using :null_session should also be safe, but there will be side effects. That strategy runs with a null object session. As such, no order and no user is found on it. A new cart state order is created in the database, associated with no user. Next time the user visits the site, they won't find any difference in its cart state.
An app using :reset_session is not entirely safe. That strategy resets the session. That means that registered users will be logged out. Next time a user visits, they'll see the cart with the items added during the CSRF attack, although it won't be associated with their account in the case of registered users.

Reversing the update

If you still want to deploy the upgraded version before changing your application code (if the latter is needed), you can add the following workaround to your config/application.rb (however, take into account that you'll keep being vulnerable):

config.after_initialize do
  Spree::OrdersController.skip_before_action :verify_authenticity_token, only: [:populate]
end

Workarounds

If an upgrade is not an option, you can work around the issue by adding the following to config/application.rb:

config.after_initialize do
  Spree::OrdersController.protect_from_forgery with: ApplicationController.forgery_protection_strategy.name.demodulize.underscore.to_sym, only: [:populate]
end

However, go through the same safety check detailed on "Upgrade notes" above.

References

For more information

If you have any questions or comments about this advisory:

Open an issue or a discussion in Solidus.
Email us at security@solidus.io
Contact the core team on Slack

Affected versions


          1.0.0


          1.0.0.pre


          1.0.0.pre2


          1.0.0.pre3


          1.0.0.rc1


          1.0.0.rc2


          1.0.1


          1.0.2


          1.0.3


          1.0.4


          1.0.5


          1.0.6

+ 117 more


            1.0.7


            1.1.0


            1.1.0.beta1


            1.1.0.pre1


            1.1.0.pre2


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.2.0


            1.2.0.beta1


            1.2.0.rc1


            1.2.0.rc2


            1.2.1


            1.2.2


            1.2.3


            1.3.0


            1.3.0.beta1


            1.3.0.rc1


            1.3.0.rc2


            1.3.1


            1.3.2


            1.4.0


            1.4.0.beta1


            1.4.0.rc1


            1.4.1


            1.4.2


            2.0.0


            2.0.0.beta1


            2.0.0.rc1


            2.0.1


            2.0.2


            2.0.3


            2.1.0


            2.1.0.beta1


            2.1.0.rc1


            2.1.1


            2.10.0


            2.10.0.beta1


            2.10.1


            2.10.2


            2.10.3


            2.10.5


            2.11.0


            2.11.1


            2.11.10


            2.11.11


            2.11.12


            2.11.13


            2.11.2


            2.11.3


            2.11.4


            2.11.5


            2.11.6


            2.11.7


            2.11.8


            2.11.9


            2.2.0


            2.2.0.beta1


            2.2.0.rc1


            2.2.1


            2.2.2


            2.3.0


            2.3.0.beta1


            2.3.0.rc1


            2.3.0.rc2


            2.3.0.rc3


            2.3.1


            2.4.0


            2.4.0.beta1


            2.4.0.rc1


            2.4.1


            2.4.2


            2.5.0


            2.5.0.beta1


            2.5.0.beta2


            2.5.0.rc1


            2.5.1


            2.5.2


            2.6.0


            2.6.0.rc1


            2.6.1


            2.6.2


            2.6.3


            2.6.4


            2.6.5


            2.6.6


            2.7.0


            2.7.1


            2.7.2


            2.7.3


            2.7.4


            2.8.0


            2.8.1


            2.8.2


            2.8.3


            2.8.4


            2.8.5


            2.8.6


            2.9.0


            2.9.0.rc.1


            2.9.1


            2.9.2


            2.9.3


            2.9.4


            2.9.5


            2.9.6


            3.0.0


            3.0.1


            3.0.2


            3.0.3


            3.0.4


            3.1.0


            3.1.1


            3.1.2


            3.1.3


            3.1.4

Fixed in


          2.11.14


          3.0.5


          3.1.5

References

Updated Jul 08, 2026 · Source: OSV.dev

Mar 18, 2021

2.11.7 patch

1 CVE

CVE-2021-43846 GHSA-h3fg-h5v3-vf8m Jan 06, 2022

CSRF forgery protection bypass in solidus_frontend

5.3 / 10

Medium

Network Low None None Unchanged None Low None

Impact

CSRF vulnerability that allows a malicious site to add an item to the user's cart without their knowledge.

All solidus_frontend versions are affected. If you're using your own storefront, please, follow along to make sure you're not affected.

To reproduce the issue:

Pick the id for a variant with available stock. From the rails console:
```
Spree::Variant.in_stock.pluck(:id)
```
Say we pick variant id 2.
Launch your application, for instance, on http://localhost:3000:
```
bin/rails server
```
Open your browser dev tools.
Click on whatever link in your store.
Copy the value of the Cookie request header sent for the previous request from your browser dev tools.

Execute the following, using your previously selected variant id and the value of the Cookie header (notice how it doesn't contain any authentication token):

curl -X POST -d "variant_id=2&quantity=1" -H "Cookie: guest_token=eyJfcmFpbHMiOnsibWVzc2FnZSI6IklrWlRVMWRQWnpKMVZVdFNXRzlPVW1aaWJHTjZZa0VpIiwiZXhwIjpudWxsLCJwdXIiOiJjb29raWUuZ3Vlc3RfdG9rZW4ifX0%3D--5006ba5d346f621c760a29b6a797bf351d17d1b8; _sandbox_session=vhutu5%2FL9NmWrUpGc3DxrFA%2FFsQD1dHn1cNsD7nvE84zcjWf17Af4%2F%2F2Vab3md71b6KTb9NP6WktdXktpwH4eU01jEGIBXG5%2BMzW5nL0nb4W269qk1io4LYljvoOg8%2BZVll7oJCVkJLKKh0sSoS0Kg8j%2FCHHs%2BsShohP%2BGnA%2Bfr9Ub8H6HofpSmloSpsfHHygmX0ho03fEgzHJ4DD5wJctaNKwg7NhVikHh5kgIPPHl84OGCgv3p2oe9jR19HTxOKq7BtyvDd7XZsecWhkcfS8BPnvDDUWZG6qpAEFI5kWo81KkpSJ%2Bp6Q1HOo8%3D--n3G2vgaDG7VS%2B%2FhF--ZTjxBAkfGG3hpr4GRQ2S1Q%3D%3D; __profilin=p%3Dt" http://localhost:3000/orders/populate

Reload your browser and look at how your cart got updated.

Patches

Please, upgrade solidus to versions 3.1.5, 3.0.5 or 2.11.14.

After upgrading, make sure you read the "Upgrade notes" section below.

Upgrade notes

The patch adds CSRF token verification to the "Add to cart" action. Adding forgery protection to a form that missed it can have some side effects.

`InvalidAuthenticityToken` errors

If you're using the :exception strategy, it's likely that after upgrading, you'll see more ActionController::InvalidAuthenticityToken errors popping out in your logs. Due to browser-side cache, a form can be re-rendered and sent without any attached request cookie (for instance, when re-opening a mobile browser). That will cause an authentication error, as the sent token won't match with the one in the session (none in this case). That's a known problem in the Rails community (see https://github.com/rails/rails/issues/21948), and, at this point, there's no perfect solution.

Any attempt to mitigate the issue should be seen at the application level. For an excellent survey of all the available options, take a look at https://github.com/betagouv/demarches-simplifiees.fr/blob/5b4f7f9ae9eaf0ac94008b62f7047e4714626cf9/doc/adr-csrf-forgery.md. The latter is a third-party link. As the information is relevant here, we're going to copy it below, but it should be clear that all the credit goes to @kemenaran:

Broken behavior due to session expiration + template cache

Although pretty unlikely, you should make sure that your current setup for cache/session expiration is compatible. The upgrade can break the addition of products to the cart if both:

The "Add to cart" form is being cached (usually along with the variant information).
A user session is reset at every or every few requests.

The token validation depends on the issuing and consuming sessions being the same. If a product page is cached with the token in it, it can become stale on a subsequent rendering if the session changes.

To check that you're safe, after having upgraded locally, go through the following steps:

Enable cache on dev mode:
```
bin/rails dev:cache
```
Visit the page for a variant with stock.
Reload that page several times.
Click on the "Add to cart" button.
Remember to rerun bin/rails dev:cache to turn off cache again.

No error or session reset should happen.

Otherwise, you can try with:

Revisiting how your session gets expired.
Changing the caching strategy to exclude the token.

Using weaker CSRF protection strategies

It's also important to understand that a complete fix will only be in place when using the :exception forgery protection strategy. The solidus_frontend engine can't do pretty much anything otherwise. Using weaker CSRF strategies should be an informed and limited decision made by the application team. After the upgrade:

An app using :null_session should also be safe, but there will be side effects. That strategy runs with a null object session. As such, no order and no user is found on it. A new cart state order is created in the database, associated with no user. Next time the user visits the site, they won't find any difference in its cart state.
An app using :reset_session is not entirely safe. That strategy resets the session. That means that registered users will be logged out. Next time a user visits, they'll see the cart with the items added during the CSRF attack, although it won't be associated with their account in the case of registered users.

Reversing the update

If you still want to deploy the upgraded version before changing your application code (if the latter is needed), you can add the following workaround to your config/application.rb (however, take into account that you'll keep being vulnerable):

config.after_initialize do
  Spree::OrdersController.skip_before_action :verify_authenticity_token, only: [:populate]
end

Workarounds

If an upgrade is not an option, you can work around the issue by adding the following to config/application.rb:

config.after_initialize do
  Spree::OrdersController.protect_from_forgery with: ApplicationController.forgery_protection_strategy.name.demodulize.underscore.to_sym, only: [:populate]
end

However, go through the same safety check detailed on "Upgrade notes" above.

References

For more information

If you have any questions or comments about this advisory:

Open an issue or a discussion in Solidus.
Email us at security@solidus.io
Contact the core team on Slack

Affected versions


          1.0.0


          1.0.0.pre


          1.0.0.pre2


          1.0.0.pre3


          1.0.0.rc1


          1.0.0.rc2


          1.0.1


          1.0.2


          1.0.3


          1.0.4


          1.0.5


          1.0.6

+ 117 more


            1.0.7


            1.1.0


            1.1.0.beta1


            1.1.0.pre1


            1.1.0.pre2


            1.1.1


            1.1.2


            1.1.3


            1.1.4


            1.2.0


            1.2.0.beta1


            1.2.0.rc1


            1.2.0.rc2


            1.2.1


            1.2.2


            1.2.3


            1.3.0


            1.3.0.beta1


            1.3.0.rc1


            1.3.0.rc2


            1.3.1


            1.3.2


            1.4.0


            1.4.0.beta1


            1.4.0.rc1


            1.4.1


            1.4.2


            2.0.0


            2.0.0.beta1


            2.0.0.rc1


            2.0.1


            2.0.2


            2.0.3


            2.1.0


            2.1.0.beta1


            2.1.0.rc1


            2.1.1


            2.10.0


            2.10.0.beta1


            2.10.1


            2.10.2


            2.10.3


            2.10.5


            2.11.0


            2.11.1


            2.11.10


            2.11.11


            2.11.12


            2.11.13


            2.11.2


            2.11.3


            2.11.4


            2.11.5


            2.11.6


            2.11.7


            2.11.8


            2.11.9


            2.2.0


            2.2.0.beta1


            2.2.0.rc1


            2.2.1


            2.2.2


            2.3.0


            2.3.0.beta1


            2.3.0.rc1


            2.3.0.rc2


            2.3.0.rc3


            2.3.1


            2.4.0


            2.4.0.beta1


            2.4.0.rc1


            2.4.1


            2.4.2


            2.5.0


            2.5.0.beta1


            2.5.0.beta2


            2.5.0.rc1


            2.5.1


            2.5.2


            2.6.0


            2.6.0.rc1


            2.6.1


            2.6.2


            2.6.3


            2.6.4


            2.6.5


            2.6.6


            2.7.0


            2.7.1


            2.7.2


            2.7.3


            2.7.4


            2.8.0


            2.8.1


            2.8.2


            2.8.3


            2.8.4


            2.8.5


            2.8.6


            2.9.0


            2.9.0.rc.1


            2.9.1


            2.9.2


            2.9.3


            2.9.4


            2.9.5


            2.9.6


            3.0.0


            3.0.1


            3.0.2


            3.0.3


            3.0.4


            3.1.0


            3.1.1


            3.1.2


            3.1.3


            3.1.4

Fixed in


          2.11.14


          3.0.5


          3.1.5

References

Updated Jul 08, 2026 · Source: OSV.dev

Mar 18, 2021

3.0.0.rc2 pre

Mar 10, 2021

Activity

Reach

Details