Highly critical · 42,002 sites report using it · 6 security fixes
This module enables a website to sell goods and services to customers through a shopping basket and checkout form.
6 security fixes in one update. Commerce Core fixed 6 separate security bugs at once: 3 access bypass, 2 information disclosure, 1 cross site request forgery. One update covers all of them. The most serious, SA-CONTRIB-2026-254, is explained here and the full list is at the end of the card.
Anyone could bypass security checks to view and change shop data. They could alter shop records and see private information.
- Who could do thisAnyone visiting the site. No login needed.
- Does it apply to youAny site using this module.
- Has it been used in attacksYes. It has been used in real attacks.
- How urgentDrupal rates this highly critical. Cyber Essentials expects a fix within 14 days. Do it this week.
Tell your developerUpdate Commerce Core to 3.3.13 or 8.x-2.41, whichever branch you are on.
For developers: what the fix changed
This release carries 6 security fixes. The summary below is for SA-CONTRIB-2026-254, the most serious of them.
The fix introduces a `restricted_fields` property to multiple entity types (such as orders, order items, payment methods, and promotions) and enforces access control on these fields in their respective access control handlers to prevent unauthorised modifications. It also restricts access to order administration routes by adding an `OrderAdminRouteSubscriber` and adds CSRF token protection to inbox message routes.
Also in this release The release also adds a `ProductVariationsConstraint` to ensure products only reference their own variations and updates test coverage.
3.3.12 to 3.3.13 1 commit, 84 files including 42 tests.
.cspell-project-words.txt +1 −0commerce.routing.yml +2 −0 fixjs/commerce.inbox.js +1 −3 fixmodules/cart/src/EventSubscriber/QueryAccessSubscriber.php +6 −0 fixmodules/cart/src/Hook/CommerceCartHooks.php +44 −2 fixmodules/checkout/commerce_checkout.module +8 −0 fixmodules/checkout/src/Controller/CheckoutController.php +4 −0 fixmodules/checkout/src/Hook/CommerceCheckoutHooks.php +10 −0 fixmodules/order/commerce_order.routing.yml +1 −0 fixmodules/order/commerce_order.services.yml +5 −0 fixmodules/order/src/Entity/Order.php +5 −0 fixmodules/order/src/Entity/OrderItem.php +5 −0 fix
Full diff, 3.3.12 to 3.3.13 · Full diff, 8.x-2.40 to 8.x-2.41
The comparison is against the release immediately before the fix. If your site is on an older release, more will have changed.
All 6 security bugs this update fixes, worst first. Each link is the drupal.org notice for that one.
Critical · 27,334 sites report using it · SA-CONTRIB-2026-286 · on drupal.org
This module copies files from a live website to a development website when they are needed.
The module does not properly check file web addresses for malicious content. Someone could use this to run malicious scripts and change or add data. They could not do this unless they can upload a malicious file to the live website.
- Who could do thisAnyone visiting the site. No login needed.
- Does it apply to youThis development module is turned on and an attacker can upload a malicious file to the live server.
- Has it been used in attacksNo sign of it.
- How urgentDrupal rates this critical. Cyber Essentials expects a fix within 14 days. Do it this week.
Tell your developerUpdate Stage File Proxy to 4.0.1 or 3.1.7, whichever branch you are on.
For developers: what the fix changed
The fix updates `DownloadManager::fetch()` to ensure that fallback retrieval on a 404 error only processes paths starting with `styles/`, preventing malicious content in file URLs from triggering a cross-site scripting vulnerability.
Also in this release Added WebP support, an interval option for Drush downloads, and fixed hotlink redirects for filenames with multiple dots.
4.0.0 to 4.0.1 8 commits, 12 files including 3 tests.
.cspell-project-words.txt +2 −0.gitlab-ci.yml +8 −57composer.json +5 −1src/Controller/ImageStyleDownloadController.php +10 −12src/DownloadManager.php +30 −1 fixsrc/DownloadManagerInterface.php +11 −0src/Drush/Commands/StageFileProxyCommands.php +6 −0src/EventSubscriber/StageFileProxySubscriber.php +8 −2src/Hook/FileHooks.php +29 −0
Full diff, 4.0.0 to 4.0.1 · Full diff, 3.1.6 to 3.1.7
The comparison is against the release immediately before the fix. If your site is on an older release, more will have changed.
Critical · 24,412 sites report using it · 8 security fixes
This module provides tools to use artificial intelligence services on the website.
8 security fixes in one update. AI (Artificial Intelligence) fixed 8 separate security bugs at once: 5 cross site scripting, 2 information disclosure, 1 access bypass. One update covers all of them. The most serious, SA-CONTRIB-2026-269, is explained here and the full list is at the end of the card.
The module does not properly check links formatted in a specific way. Someone could use this to run malicious scripts and change or add data. They could not do this without interacting with the artificial intelligence features.
- Who could do thisAnyone visiting the site. No login needed.
- Does it apply to youAny site using this module.
- Has it been used in attacksNo sign of it.
- How urgentDrupal rates this critical. Cyber Essentials expects a fix within 14 days. Do it this week.
Tell your developerUpdate AI (Artificial Intelligence) to 1.4.11 or 1.5.2, whichever branch you are on.
For developers: what the fix changed
This release carries 8 security fixes. The summary below is for SA-CONTRIB-2026-269, the most serious of them.
The update changes innerHTML to textContent in assets/js/ai_global.js when rendering tooltips. This prevents cross site scripting payloads in data attributes from being executed as HTML.
Also in this release The release also adds access checks for API explorer output files and enforces text format access restrictions for automators.
1.4.10 to 1.4.11 13 commits, 70 files including 11 tests.
assets/js/ai_global.js +3 −1 fixdocs/modules/ai_automators/automator_types/llm_text.md +2 −2docs/modules/ai_automators/automator_types/llm_text_long.md +1 −1docs/modules/ai_automators/automator_types/llm_text_with_summary.md +2 −2docs/modules/ai_automators/automator_types/llm_video_to_text_long.md +1 −1docs/modules/ai_automators/index.md +29 −1modules/ai_api_explorer/ai_api_explorer.info.yml +1 −0modules/ai_api_explorer/ai_api_explorer.module +5 −17modules/ai_api_explorer/ai_api_explorer.services.yml +3 −0modules/ai_api_explorer/src/ExplorerOutputFiles.php +85 −0modules/ai_api_explorer/src/Plugin/AiApiExplorer/AudioToAudioGenerator.php +7 −13modules/ai_api_explorer/src/Plugin/AiApiExplorer/ImageAndAudioToVideoGenerator.php +7 −13
Full diff, 1.4.10 to 1.4.11 · Full diff, 1.5.1 to 1.5.2
The comparison is against the release immediately before the fix. If your site is on an older release, more will have changed.
All 8 security bugs this update fixes, worst first. Each link is the drupal.org notice for that one.
Critical · 19,748 sites report using it · 2 security fixes
This module lets administrators export and import content between different websites.
2 security fixes in one update. Single Content Sync fixed 2 separate security bugs at once: 1 remote code execution, 1 external control of file name or path. One update covers all of them. The most serious, SA-CONTRIB-2026-275, is explained here and the full list is at the end of the card.
The module does not properly handle data from imported files. Someone could use a malicious import file to run harmful code and change or read any data on the site. They could not do this without the right to import content.
- Who could do thisOnly someone with an administrator login.
- Does it apply to youAn attacker has an account with the access right to import single content.
- Has it been used in attacksNo sign of it.
- How urgentDrupal rates this critical. Cyber Essentials expects a fix within 14 days. Do it this week.
Tell your developerUpdate Single Content Sync to 1.4.19.
For developers: what the fix changed
This release carries 2 security fixes. The summary below is for SA-CONTRIB-2026-275, the most serious of them.
The fix prevents untrusted data deserialization by unsetting the `block_serialized` configuration key for inline blocks in `src/Plugin/SingleContentSyncFieldProcessor/LayoutSection.php`.
Also in this release The release also introduces extensive validation for imported files, restricts remote downloads to trusted hosts, and adds an ImportFileManager service.
1.4.18 to 1.4.19 2 commits, 19 files including 5 tests.
.cspell.json +4 −1README.md +26 −0composer.json +1 −0config/install/single_content_sync.settings.yml +2 −0config/schema/single_content_sync.schema.yml +8 −0single_content_sync.permissions.yml +1 −0single_content_sync.post_update.php +16 −0single_content_sync.services.yml +9 −0src/ContentBatchImporter.php +1 −1src/ContentImporter.php +23 −14src/Form/ContentSyncConfigForm.php +38 −0src/ImportFileManager.php +264 −0
Full diff, 1.4.18 to 1.4.19
The comparison is against the release immediately before the fix. If your site is on an older release, more will have changed.
All 2 security bugs this update fixes, worst first. Each link is the drupal.org notice for that one.
Critical · 5,159 sites report using it · 3 security fixes
This module connects an online shop to a payment processing service.
3 security fixes in one update. Commerce Stripe fixed 3 separate security bugs at once: 1 cross site request forgery, 1 cross site scripting, 1 improper verification of cryptographic signature. One update covers all of them. The most serious, SA-CONTRIB-2026-263, is explained here and the full list is at the end of the card.
The module does not include a security token when returning from the payment service. Someone could trick an administrator into clicking a link that marks an order as paid without any money changing hands. They could read or change data they should not have access to.
- Who could do thisAnyone visiting the site. No login needed.
- Does it apply to youAny site using this module.
- Has it been used in attacksNo sign of it.
- How urgentDrupal rates this critical. Cyber Essentials expects a fix within 14 days. Do it this week.
Tell your developerUpdate Commerce Stripe to 2.2.3.
For developers: what the fix changed
This release carries 3 security fixes. The summary below is for SA-CONTRIB-2026-263, the most serious of them.
The fix generates a random state token in `StripeConnectConfirmationForm::buildForm` and stores it in the session, appending it to the OAuth return URI. It then validates this token against the session in `StripeConnectController` to prevent CSRF attacks.
Also in this release The release also masks the access token in the UI, enforces webhook signing secret validation, adds cacheability metadata to entity operations, sets a field as internal, and renames a test class.
2.2.2 to 2.2.3 1 commit, 6 files including 1 test.
commerce_stripe.module +8 −3src/Controller/StripeConnectController.php +32 −4 fixsrc/Form/StripeConnectConfirmationForm.php +23 −2 fixsrc/Plugin/Commerce/PaymentGateway/StripePaymentElement.php +6 −7src/Plugin/Commerce/PaymentMethodType/StripeDefault.php +2 −1
Full diff, 2.2.2 to 2.2.3
The comparison is against the release immediately before the fix. If your site is on an older release, more will have changed.
All 3 security bugs this update fixes, worst first. Each link is the drupal.org notice for that one.
Critical · 1,824 sites report using it · SA-CONTRIB-2026-276 · on drupal.org
This module lets administrators clear the website memory cache easily.
This project has been withdrawn because of a security problem its maintainer did not fix. The details are not published. It should be treated as unsafe to keep.
- Who could do thisOnly someone with an administrator login.
- Does it apply to youAny site using this module.
- Has it been used in attacksNo sign of it.
- How urgentThe Drupal security team has withdrawn this module because its maintainer did not fix a known problem. The only remedy is to remove or replace it.
Tell your developerRemove or replace CacheFlush. There is no fixed version.
For developers: what the fix changed
The module has been withdrawn, so there is no fixed release to compare.
Critical · 474 sites report using it · SA-CONTRIB-2026-284 · on drupal.org
This module lets users log in to the website using external identity providers.
The module does not properly check access on a setup page or verify email addresses from the identity provider. Someone could log in as any existing user if they know their email address and change or add data. They could not do this without an account on the external identity provider.
- Who could do thisAnyone visiting the site. No login needed.
- Does it apply to youAn attacker has an account with an identity provider the site uses and can change a value like their username on that provider.
- Has it been used in attacksNo sign of it.
- How urgentDrupal rates this critical. Cyber Essentials expects a fix within 14 days. Do it this week.
Tell your developerUpdate OAuth Login - OAuth OIDC SSO to 3.1.1.
For developers: what the fix changed
The fix updates `oauth_login_oauth2.routing.yml` to require the `administer site configuration` permission and a CSRF token for the `oauth_login_oauth2.post_testconfig` route. It also updates `miniorange_oauth_client_mo_login` in `src/Controller/miniorange_oauth_clientController.php` to check the `email_verified` claim from the identity provider, blocking login if the email is unverified unless explicitly configured to trust it.
Also in this release Code style improvements, formatting fixes, and minor refactoring.
3.1.0 to 3.1.1 3 commits, 25 files.
README.md +9 −3config/install/oauth_login_oauth2.settings.yml +1 −0 fixconfig/schema/oauth_login_oauth2.schema.yml +2 −0 fixcss/oauth_login_oauth2.style_settings.css +0 −2oauth_login_oauth2.install +15 −5oauth_login_oauth2.links.task.yml +1 −1oauth_login_oauth2.module +11 −11oauth_login_oauth2.routing.yml +3 −1 fixsrc/AccessToken.php +9 −5src/AuthorizationEndpoint.php +19 −20src/Controller/miniorange_oauth_clientController.php +81 −55 fixsrc/Form/ConfirmDeleteForm.php +20 −9
Full diff, 3.1.0 to 3.1.1
The comparison is against the release immediately before the fix. If your site is on an older release, more will have changed.
Critical · 215 sites report using it · SA-CONTRIB-2026-285 · on drupal.org
This module lets users create and save electronic signatures as images.
The module does not properly clean user submitted content before saving it. Someone could upload a malicious file to run unsafe scripts and change or add data. They could not do this without the ability to submit a signature.
- Who could do thisAnyone visiting the site. No login needed.
- Does it apply to youAny site using this module.
- Has it been used in attacksNo sign of it.
- How urgentDrupal rates this critical. Cyber Essentials expects a fix within 14 days. Do it this week.
Tell your developerUpdate Signature pad widget to 8.x-1.15.
For developers: what the fix changed
The fix introduces SVG sanitisation using the `enshrined/svg-sanitize` library in `SignWidgetController::save` and adds image validation to ensure uploaded files are valid PNGs in `SendSignForm::saveSign` and `SignWidget::massageFormValues`.
Also in this release The release also adds a new permission, implements CSRF token protection for AJAX requests, and refactors hook implementations to use attributes.
8.x-1.12 to 8.x-1.15 9 commits, 18 files including 5 tests.
README.md +1 −1composer.json +3 −0 fixjs/build/signature.js +1 −1js/ckeditor5_plugins/signature/src/InsertSignatureCommand.js +10 −5js/sign_widget.js +17 −11sign_widget.module +6 −28sign_widget.permissions.yml +3 −0sign_widget.routing.yml +5 −2sign_widget.services.yml +5 −0src/Controller/SignWidgetController.php +70 −3 fixsrc/Form/SendSignForm.php +46 −7 fixsrc/Hook/SignWidgetHooks.php +56 −0
Full diff, 8.x-1.12 to 8.x-1.15
The comparison is against the release immediately before the fix. If your site is on an older release, more will have changed.
Critical · 99 sites report using it · SA-CONTRIB-2026-278 · on drupal.org
This module connects the website to an external group exercise system.
This project has been withdrawn because of a security problem its maintainer did not fix. The details are not published. It should be treated as unsafe to keep.
- Who could do thisOnly someone with an administrator login.
- Does it apply to youAny site using this module.
- Has it been used in attacksNo sign of it.
- How urgentThe Drupal security team has withdrawn this module because its maintainer did not fix a known problem. The only remedy is to remove or replace it.
Tell your developerRemove or replace GroupEx PRO ( Daxko ) integration. There is no fixed version.
For developers: what the fix changed
The module has been withdrawn, so there is no fixed release to compare.
Critical · 27 sites report using it · SA-CONTRIB-2026-277 · on drupal.org
This module connects the website to a specific payment gateway for online shops.
This project has been withdrawn because of a security problem its maintainer did not fix. The details are not published. It should be treated as unsafe to keep.
- Who could do thisOnly someone with an administrator login.
- Does it apply to youAny site using this module.
- Has it been used in attacksNo sign of it.
- How urgentThe Drupal security team has withdrawn this module because its maintainer did not fix a known problem. The only remedy is to remove or replace it.
Tell your developerRemove or replace PayUmoney for Drupal Commerce. There is no fixed version.
For developers: what the fix changed
The module has been withdrawn, so there is no fixed release to compare.
Critical · no install count published · SA-CONTRIB-2026-290 · on drupal.org
This module manages system wide access tokens for connecting the website to external services.
The module does not restrict access to its connection pages. A visitor could connect the site to an account they control and change or add data. They could not do this without finding a specific code from a previous connection attempt in the server logs.
- Who could do thisAnyone visiting the site. No login needed.
- Does it apply to youAn attacker can find the state value from a previous system token setup in the server logs.
- Has it been used in attacksNo sign of it.
- How urgentDrupal rates this critical. Cyber Essentials expects a fix within 14 days. Do it this week.
Tell your developerUpdate OAuth2 Token Manager to 8.x-1.2.
For developers: what the fix changed
The fix restricts access to the OAuth2 validation routes by replacing `_access: 'TRUE'` with specific administer permissions in the routing files for Box, Quip, and Slack. It also updates `ValidationControllerBase::validate` to clear the initialisation state after use and ensures it is not empty before comparing it to the request state.
Also in this release The release also fixed a lock contention bug in `refreshSystemAccessToken()` and added automated tests.
8.x-1.1 to 8.x-1.2 2 commits, 13 files including 2 tests.
modules/box/box_token_manager.install +15 −0 fixmodules/box/box_token_manager.permissions.yml +4 −0 fixmodules/box/box_token_manager.routing.yml +1 −1 fixmodules/quip/quip_token_manager.install +15 −0 fixmodules/quip/quip_token_manager.permissions.yml +4 −0 fixmodules/quip/quip_token_manager.routing.yml +1 −1 fixmodules/slack/slack_token_manager.install +15 −0 fixmodules/slack/slack_token_manager.permissions.yml +4 −0 fixmodules/slack/slack_token_manager.routing.yml +1 −1 fixsrc/Controller/ValidationControllerBase.php +4 −3 fixsrc/TokenManager.php +10 −3 fix
Full diff, 8.x-1.1 to 8.x-1.2
The comparison is against the release immediately before the fix. If your site is on an older release, more will have changed.
Moderately critical · 275,902 sites report using it · SA-CONTRIB-2026-281 · on drupal.org
This module adds a test to forms to block automated spam submissions.
The module remembers when a test has been passed but does not properly clear that memory. Someone could submit a protected form multiple times without passing a new test. They could not read or change any existing data.
- Who could do thisAnyone visiting the site. No login needed.
- Does it apply to youAny site using this module.
- Has it been used in attacksYes. It has been used in real attacks.
- How urgentDrupal rates this moderately critical. Include it in your next routine update, within the month.
Tell your developerUpdate CAPTCHA to 2.0.11 or 8.x-1.18, whichever branch you are on.
For developers: what the fix changed
The fix updates _captcha_update_captcha_session in captcha.inc to set the session status to unsolved and modifies _captcha_get_posted_captcha_info in captcha.module to only query unsolved sessions, preventing session reuse.
Also in this release The release also integrates with CrowdSec, removes deprecated imagedestroy calls for PHP 8.5 compatibility, and updates Tugboat preview settings.
2.0.10 to 2.0.11 6 commits, 9 files.
.gitlab-ci.yml +0 −1.tugboat/config.yml +1 −1captcha.inc +1 −0 fixcaptcha.module +33 −15 fixcomposer.json +3 −0modules/image_captcha/image_captcha.admin.inc +0 −1modules/image_captcha/src/Controller/CaptchaFontPreviewController.php +1 −2modules/image_captcha/src/Controller/CaptchaImageGeneratorController.php +1 −2src/Plugin/CrowdsecScenario/FailedCaptchaScenario.php +20 −0
Full diff, 2.0.10 to 2.0.11 · Full diff, 8.x-1.17 to 8.x-1.18
The comparison is against the release immediately before the fix. If your site is on an older release, more will have changed.
Moderately critical · 78,346 sites report using it · 2 security fixes
This module lets site administrators set access rights for viewing and editing individual fields.
2 security fixes in one update. Field Permissions fixed 2 separate security bugs at once: 2 access bypass. One update covers all of them. The most serious, SA-CONTRIB-2026-289, is explained here and the full list is at the end of the card.
The module does not properly hide private fields on items that do not have an author. Anyone could see these private fields. They could not change any data.
- Who could do thisAnyone visiting the site. No login needed.
- Does it apply to youAn administrator has set a field to private on an item type that has no author and the attacker can already view that item.
- Has it been used in attacksNo sign of it.
- How urgentDrupal rates this moderately critical. Include it in your next routine update, within the month.
Tell your developerUpdate Field Permissions to 8.x-1.6.
For developers: what the fix changed
This release carries 2 security fixes. The summary below is for SA-CONTRIB-2026-289, the most serious of them.
The fix updates the PrivateAccess plugin to return FALSE instead of TRUE when an entity lacks an owner. This ensures private fields on these entities are denied access by default.
Also in this release The release also updates the administrator role check to use the isAdmin flag and updates the README.
8.x-1.5 to 8.x-1.6 2 commits, 3 files.
README.md +3 −1src/FieldPermissionsService.php +22 −2src/Plugin/FieldPermissionType/PrivateAccess.php +5 −1 fix
Full diff, 8.x-1.5 to 8.x-1.6
The comparison is against the release immediately before the fix. If your site is on an older release, more will have changed.
All 2 security bugs this update fixes, worst first. Each link is the drupal.org notice for that one.
Moderately critical · 17,818 sites report using it · SA-CONTRIB-2026-279 · on drupal.org
This module stores website files in Amazon cloud storage instead of on the web server.
The module mixes up the context of different file uploads happening at the same time. Files could be uploaded with the wrong access rights or become corrupted. Someone could read or change data they should not have access to.
- Who could do thisAnyone visiting the site. No login needed.
- Does it apply to youAn attacker can trigger multiple file operations at the same time and the site uses specific private file settings or custom code modifications.
- Has it been used in attacksNo sign of it.
- How urgentDrupal rates this moderately critical. Include it in your next routine update, within the month.
Tell your developerUpdate S3 File System to 8.x-3.12.
For developers: what the fix changed
The fix adds a resetContextOptions method to src/StreamWrapper/S3fsStream.php and calls it after file operations like stream_open, stream_flush, and rename to reset the stream context options.
Also in this release The release also updates the README file with bucket configuration recommendations.
8.x-3.11 to 8.x-3.12 1 commit, 2 files.
README.txt +62 −0src/StreamWrapper/S3fsStream.php +30 −3 fix
Full diff, 8.x-3.11 to 8.x-3.12
The comparison is against the release immediately before the fix. If your site is on an older release, more will have changed.
Moderately critical · 17,347 sites report using it · 2 security fixes
This module enables a website to sell physical products that are organised into shipments for delivery.
2 security fixes in one update. Commerce Shipping fixed 2 separate security bugs at once: 2 access bypass. One update covers all of them. The most serious, SA-CONTRIB-2026-261, is explained here and the full list is at the end of the card.
Anyone could change the status of a delivery or delete it entirely. They could not read any private data.
- Who could do thisAnyone visiting the site. No login needed.
- Does it apply to youAny site using this module where a visitor has a shopping basket with data feed access to manage its shipments.
- Has it been used in attacksNo sign of it.
- How urgentDrupal rates this moderately critical. Include it in your next routine update, within the month.
Tell your developerUpdate Commerce Shipping to 8.x-2.16 or 3.0.6, whichever branch you are on.
For developers: what the fix changed
This release carries 2 security fixes. The summary below is for SA-CONTRIB-2026-261, the most serious of them.
The fix implements field-level access control for shipments by defining restricted fields in `src/Entity/Shipment.php` and enforcing access checks in `ShipmentAccessControlHandler::checkFieldAccess()`. It also restricts editing the order's shipments field in `commerce_shipping_entity_field_access()` within `commerce_shipping.module` to users with specific order update permissions.
Also in this release The release also fixes test failures against Commerce 3.x while maintaining compatibility with Commerce 2.x.
8.x-2.15 to 8.x-2.16 3 commits, 12 files including 8 tests.
commerce_shipping.module +17 −0 fixsrc/Entity/Shipment.php +5 −0 fixsrc/ShipmentAccessControlHandler.php +41 −0 fixsrc/ShipmentRouteProvider.php +1 −1 fix
Full diff, 8.x-2.15 to 8.x-2.16 · Full diff, 3.0.5 to 3.0.6
The comparison is against the release immediately before the fix. If your site is on an older release, more will have changed.
All 2 security bugs this update fixes, worst first. Each link is the drupal.org notice for that one.
Moderately critical · 5,210 sites report using it · SA-CONTRIB-2026-292 · on drupal.org
This module lets visitors view a file directly using a friendly web address.
The module might tell web browsers to store files that should be kept private. Someone could see a private file if another person with the right access has already looked at it. They could not change any files or settings.
- Who could do thisAnyone visiting the site. No login needed.
- Does it apply to youThe site is set up to handle private files using an extra module and a private file is still stored in the cache after being viewed by someone with higher access rights.
- Has it been used in attacksA working example has been published, so assume someone will try.
- How urgentDrupal rates this moderately critical. Include it in your next routine update, within the month.
Tell your developerUpdate Media Alias Display to 3.0.3 or 2.1.3, whichever branch you are on.
For developers: what the fix changed
The fix updates src/Controller/DisplayController.php to correctly determine if a file scheme is public and sets the response cache control accordingly.
3.0.2 to 3.0.3 1 commit, 1 file.
src/Controller/DisplayController.php +6 −4 fix
Full diff, 3.0.2 to 3.0.3 · Full diff, 2.1.2 to 2.1.3
The comparison is against the release immediately before the fix. If your site is on an older release, more will have changed.
Moderately critical · 3,330 sites report using it · SA-CONTRIB-2026-260 · on drupal.org
This module enables a website to sell access to restricted resources like files or protected content.
An ordinary account on the site could change the access rights granted by their purchase to give themselves administrator privileges. They could also see data they should not have access to.
- Who could do thisOnly someone with a login on your site.
- Does it apply to youAny site using this module where a user owns a purchase and has the access right to update it.
- Has it been used in attacksNo sign of it.
- How urgentDrupal rates this moderately critical. Include it in your next routine update, within the month.
Tell your developerUpdate Commerce License to 3.1.1.
For developers: what the fix changed
The fix implements access control at the field level by introducing LicenseAccessControlHandler and defining restricted_fields in the License entity annotation to prevent users from modifying critical fields on their licences. It also adds LicenseAdminRouteSubscriber to restrict admin routes and updates LicensePermissionProvider to restrict create and update permissions.
3.1.0 to 3.1.1 1 commit, 11 files including 6 tests.
commerce_license.services.yml +5 −0 fixsrc/Entity/License.php +6 −1 fixsrc/EventSubscriber/LicenseAdminRouteSubscriber.php +48 −0 fixsrc/LicenseAccessControlHandler.php +46 −0 fixsrc/LicensePermissionProvider.php +4 −0 fix
Full diff, 3.1.0 to 3.1.1
The comparison is against the release immediately before the fix. If your site is on an older release, more will have changed.
Moderately critical · 2,387 sites report using it · SA-CONTRIB-2026-291 · on drupal.org
This module lets you share and reuse content across different websites.
The module does not properly scramble the password of the system user that synchronises content. Someone with access to the database could see this password and use it to change or add data. They could not do this without already having access to the database.
- Who could do thisOnly someone with an administrator login.
- Does it apply to youAn attacker has a copy of the database or can read the user data table directly.
- Has it been used in attacksNo sign of it.
- How urgentDrupal rates this moderately critical. Include it in your next routine update, within the month.
Tell your developerUpdate Content Sync (content-sync.io) to 3.2.2.
For developers: what the fix changed
The fix replaces a hardcoded default encryption key with a site-specific key generated using `random_bytes()` and stored in the site's state storage. This is implemented by introducing a new `StateKeyProvider` in `src/Plugin/KeyProvider/StateKeyProvider.php` and updating the installation and update hooks in `cms_content_sync.install` to generate and use this new key.
Also in this release The release also updates the changelog.
3.2.1 to 3.2.2 1 commit, 7 files.
CHANGELOG.md +3 −0cms_content_sync.info.yml +1 −0 fixcms_content_sync.install +192 −2 fixcms_content_sync.module +25 −0 fixconfig/install/key.key.cms_content_sync.yml +5 −8 fixconfig/schema/cms_content_sync.schema.yml +5 −0 fixsrc/Plugin/KeyProvider/StateKeyProvider.php +98 −0 fix
Full diff, 3.2.1 to 3.2.2
The comparison is against the release immediately before the fix. If your site is on an older release, more will have changed.
Moderately critical · 502 sites report using it · 2 security fixes
This module lets administrators quickly publish or unpublish content using links on the page.
2 security fixes in one update. Fasttoggle fixed 2 separate security bugs at once: 1 cross site request forgery, 1 access bypass. One update covers all of them. The most serious, SA-CONTRIB-2026-283, is explained here and the full list is at the end of the card.
The module does not properly protect its toggle links from forged requests. Someone could trick an administrator into visiting a malicious page and change the publication status of content. They could not read any hidden data.
- Who could do thisAnyone visiting the site. No login needed.
- Does it apply to youAn attacker tricks a user with the access right to use this module into visiting a page they control.
- Has it been used in attacksNo sign of it.
- How urgentDrupal rates this moderately critical. Include it in your next routine update, within the month.
Tell your developerUpdate Fasttoggle to 4.1.1.
For developers: what the fix changed
This release carries 2 security fixes. The summary below is for SA-CONTRIB-2026-283, the most serious of them.
The fix adds the _csrf_token requirement to the fasttoggle.toggle route in fasttoggle.routing.yml and updates link generation in src/Controller/FasttoggleController.php and src/Hook/FasttoggleHooks.php to use Url::fromRoute to ensure CSRF tokens are included and validated.
Also in this release The release also refactors the controller to improve access checks and logging and updates PHPStan ignore rules.
4.1.0 to 4.1.1 2 commits, 7 files including 1 test.
fasttoggle.module +0 −10fasttoggle.permissions.yml +1 −0fasttoggle.routing.yml +4 −0 fixphpstan.neon +11 −0src/Controller/FasttoggleController.php +217 −131 fixsrc/Hook/FasttoggleHooks.php +13 −15 fix
Full diff, 4.1.0 to 4.1.1
The comparison is against the release immediately before the fix. If your site is on an older release, more will have changed.
All 2 security bugs this update fixes, worst first. Each link is the drupal.org notice for that one.
Moderately critical · 329 sites report using it · SA-CONTRIB-2026-287 · on drupal.org
This module lets users log in using external authentication services.
The module tries to link a new external login to an existing account with the same email address. Someone could take over an existing account and change or add data. They could not take over the main administrator account.
- Who could do thisAnyone visiting the site. No login needed.
- Does it apply to youThe site is set up to use an external login service that does not verify the email address of the user.
- Has it been used in attacksNo sign of it.
- How urgentDrupal rates this moderately critical. Include it in your next routine update, within the month.
Tell your developerUpdate OpenID Connect Client to 2.3.1.
For developers: what the fix changed
The fix adds a `link_existing_account` setting (defaulting to false) checked in `OpenidConnectController::authenticate()` and introduces an `isEmailVerified()` check in `LinkExistingAccountSubscriber::linkAccountByEmail()` and `UpdateUserSubscriber::onUserUpdate()` to prevent unverified emails from taking over existing accounts.
Also in this release The release also fixes login redirects not preserving query parameters, fixes unwanted redirects on non-HTML requests, adds typehints, updates development dependencies, and modifies DDEV configurations.
2.3.0 to 2.3.1 16 commits, 25 files.
.ddev/config.yaml +1 −1.ddev/docker-compose.keycloak.yaml +5 −7.ddev/docker-compose.web.yaml +4 −4.ddev/githooks/commit-msg +8 −12.ddev/githooks/pre-commit +21 −9.ddev/keycloak/clients/drupal.json +61 −0.ddev/keycloak/realms/oidc.json +0 −0.gitattributes +5 −0.gitignore +0 −1CHANGELOG.md +13 −0composer.json +16 −13config/install/oidc.settings.yml +1 −0 fix
Full diff, 2.3.0 to 2.3.1
The comparison is against the release immediately before the fix. If your site is on an older release, more will have changed.
Moderately critical · 6 sites report using it · SA-CONTRIB-2026-280 · on drupal.org
This module lets site administrators add or remove roles for many users at the same time.
The bulk update form does not stop users who lack the right to assign roles from using it. Someone with the right to manage users could assign roles they should not be able to and change or add data. They could not do this without the right to manage users.
- Who could do thisOnly someone with an administrator login.
- Does it apply to youAn attacker has an account with the access right to administer users.
- Has it been used in attacksNo sign of it.
- How urgentDrupal rates this moderately critical. Include it in your next routine update, within the month.
Tell your developerUpdate Bulk Update User Roles to 1.0.5.
For developers: what the fix changed
The fix updates the routing requirement in bulk_update_user_roles.routing.yml to require the 'administer permissions' permission instead of 'administer users'. It also updates BulkUpdateUserForm.php to filter the assignable roles based on the current user's permissions in getAssignableRoles() and validates the selected roles during form submission in submitForm().
1.0.4 to 1.0.5 2 commits, 2 files.
bulk_update_user_roles.routing.yml +1 −1 fixsrc/Form/BulkUpdateUserForm.php +56 −15 fix
Full diff, 1.0.4 to 1.0.5
The comparison is against the release immediately before the fix. If your site is on an older release, more will have changed.
