Critical · 26,946 sites report using it · SA-CONTRIB-2026-296 · on drupal.org
This module allows a website to securely share access with other applications using digital tokens.
The module does not properly restrict who can configure the access settings. An administrator account could create malicious settings to gain full control over the site as another user. They could view any information or alter any data including the code itself.
- Who could do thisOnly someone with an administrator login.
- Does it apply to youSites are affected if an attacker has the access right to add or update consumer settings.
- 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 Simple OAuth (OAuth2) & OpenID Connect to 5.2.6, 6.0.10 or 6.1.4, whichever branch you are on.
For developers: what the fix changed
The fix introduces a new validation constraint `Oauth2PrivilegedConsumerField` and its validator in `src/Plugin/Validation/Constraint/Oauth2PrivilegedConsumerFieldValidator.php` to restrict modifications to privileged consumer fields. It requires the new `administer consumer access settings` permission to change the `roles`, `user_id` and `third_party` fields, preventing unauthorised privilege escalation.
Also in this release The release also updates GitLab CI templates, reduces logging severity for expired tokens, fixes authorisation for clients with empty string secrets and prevents echoing request headers.
5.2.5 to 5.2.6 6 commits, 18 files including 1 test.
.gitlab-ci.yml +22 −106config/install/simple_oauth.oauth2_token.bundle.access_token.yml +1 −0config/install/simple_oauth.oauth2_token.bundle.auth_code.yml +1 −0config/install/simple_oauth.oauth2_token.bundle.refresh_token.yml +1 −0simple_oauth.module +11 −0 fixsimple_oauth.permissions.yml +5 −0 fixsimple_oauth.services.yml +9 −1src/Authentication/Provider/SimpleOauthAuthenticationProvider.php +29 −11src/Controller/Oauth2AuthorizeController.php +20 −6src/Controller/Oauth2Token.php +19 −3src/Entity/Form/Oauth2GenerateKeyForm.php +14 −3src/EventSubscriber/ExceptionLoggingSubscriber.php +65 −0
Full diff, 5.2.5 to 5.2.6 · Full diff, 6.0.9 to 6.0.10 · Full diff, 6.1.3 to 6.1.4
The comparison is against the release immediately before the fix. If your site is on an older release, more will have changed.
Critical · 2,001 sites report using it · 2 security fixes
This module allows administrators to move content between different websites using uploaded archive files.
2 security fixes in one update. Content Synchronizer fixed 2 separate security bugs at once: 1 remote code execution, 1 cross site scripting. One update covers all of them. The most serious, SA-CONTRIB-2026-293, is explained here and the full list is at the end of the card.
The module unsafely processes the contents of uploaded archive files. An administrator account could upload a malicious file to run harmful code on the server. They could view any information or alter any data including the code itself.
- 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 urgentDrupal rates this critical. Cyber Essentials expects a fix within 14 days. Do it this week.
Tell your developerUpdate Content Synchronizer to 4.1.1.
For developers: what the fix changed
This release carries 2 security fixes. The summary below is for SA-CONTRIB-2026-293, the most serious of them.
The fix prevents PHP Object Injection by unsetting the `block_serialized` key from the plugin configuration in `LayoutBuilderProcessor.php` during import. This ensures untrusted data is not passed to core's `unserialize()` function.
Also in this release Added GitLab CI configuration, fixed download archive URL handling, added empty results text in LaunchExportForm, and merged properties in EntityProcessorBase.
4.1.0 to 4.1.1 8 commits, 9 files including 3 tests.
.gitlab-ci.yml +39 −0content_synchronizer.info.yml +1 −1libraries/javascript/download_archive.js +2 −2src/Form/LaunchExportForm.php +6 −0src/Plugin/content_synchronizer/type_processor/LayoutBuilderProcessor.php +7 −0 fixsrc/Processors/Entity/EntityProcessorBase.php +1 −8
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.
Critical · 1,520 sites report using it · SA-CONTRIB-2026-298 · on drupal.org
This module protects data feeds by requiring a special key to access them.
The module fails to block access when the special key has not been set up. Anyone could bypass the security checks to view hidden information. They could also alter any data on the site including the code itself.
- Who could do thisAnyone visiting the site. No login needed.
- Does it apply to youSites are affected when data feed security is turned on but the special key has not been created.
- 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 REST & JSON API Authentication for Drupal to 3.2.1.
For developers: what the fix changed
The fix adds a check in ApiAuthenticationApiToken::validateUserAndToken() to explicitly reject requests if the expected API token is not a string or is empty, preventing authentication bypass when no key is configured. It also adds validation in MiniOrangeAPIAuth::validateForm() to prevent saving an application without generating an API key.
Also in this release The release also includes minor code cleanups, such as removing unused imports and fixing trailing commas, alongside new automated tests.
3.2.0 to 3.2.1 1 commit, 12 files including 2 tests.
config/schema/rest_api_authentication.schema.yml +6 −0src/ApiAuthenticationApiToken.php +6 −0 fixsrc/Controller/RestApiAuthenticationController.php +3 −3src/Form/MiniOrangeAPIAuth.php +30 −1 fixsrc/Form/UpgradePlansForm.php +2 −3src/MiniorangeApiAuthConstants.php +4 −2src/MiniorangeApiAuthSupport.php +1 −1src/Routing/RouteSubscriber.php +0 −3src/Services/RestApiLogger.php +0 −1src/Utilities.php +1 −1
Full diff, 3.2.0 to 3.2.1
The comparison is against the release immediately before the fix. If your site is on an older release, more will have changed.
Critical · 1,225 sites report using it · SA-CONTRIB-2026-295 · on drupal.org
This module allows users to upload very large files directly to a remote storage service from their browser.
The module does not properly check who is allowed to manage uploaded files. Anyone could delete files they should not have access to. They might uncover hidden details or alter content.
- 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 S3 File System CORS Upload to 8.x-1.3.
For developers: what the fix changed
The fix introduces an `UploadToken` service to sign upload directories and reserve file keys for the current user. It validates these tokens in `AjaxController::getKey()` and `AjaxController::saveFile()` and adds download access checks in `S3fsCorsFile::valueCallback()` to prevent users from overwriting or accessing files they do not own.
Also in this release Added filename validation for disallowed characters, fixed raw HTML in error messages, added human-readable file size units, fixed file input visibility after failed uploads, and fixed duplicated protocol in custom S3FS hostname.
8.x-1.2 to 8.x-1.3 9 commits, 13 files including 2 tests.
.cspell-project-words.txt +1 −1config/schema/s3fs_cors.schema.yml +7 −0s3fs_cors.info.yml +1 −0s3fs_cors.js +130 −80 fixs3fs_cors.module +30 −0s3fs_cors.services.yml +4 −0 fixsrc/Controller/AjaxController.php +71 −32 fixsrc/Element/S3fsCorsFile.php +42 −6 fixsrc/Plugin/Field/FieldWidget/S3fsCorsFileWidget.php +22 −0src/Plugin/Field/FieldWidget/S3fsCorsImageWidget.php +22 −0src/UploadToken.php +79 −0 fix
Full diff, 8.x-1.2 to 8.x-1.3
The comparison is against the release immediately before the fix. If your site is on an older release, more will have changed.
Critical · 228 sites report using it · SA-CONTRIB-2026-299 · on drupal.org
This module allows editors to display computer code with coloured text to make it easier to read.
The module does not properly check text sent to its preview page. Anyone could use this to run unwanted scripts in the browser. This might allow them to view private details or modify existing content.
- 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 Highlight Js syntax highlighter to 1.3.1.
For developers: what the fix changed
The fix decodes the JSON configuration and validates it as an array in HighlightJsPreview.php, and forces the text configuration to a string in LanguageSelect.php to prevent render array injection.
1.3.0 to 1.3.1 1 commit, 2 files.
src/Controller/HighlightJsPreview.php +5 −1 fixsrc/Plugin/HighlightJs/LanguageSelect.php +4 −1 fix
Full diff, 1.3.0 to 1.3.1
The comparison is against the release immediately before the fix. If your site is on an older release, more will have changed.
Critical · 140 sites report using it · SA-CONTRIB-2026-297 · on drupal.org
This module sends an email or text message when a piece of content moves to a new stage in an approval process.
The module does not properly protect its settings page. Anyone could make unauthorised changes to the notification settings. They might uncover hidden details or alter how messages are sent.
- 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 Workflow Notifications to 3.0.3.
For developers: what the fix changed
The fix removes the insecure `WorkflowNotificationControlHandler` which bypassed access checks for update and delete operations. It also adds `admin_permission = "administer workflow"` to the entity annotations in `WorkflowSmsNotify.php` and `WorkflowNotification.php`, and enforces `_permission: 'administer workflow'` in the routing requirements for both modules.
Also in this release Added an option to allow same state transitions, automated Drupal 12 compatibility fixes (moving hooks to classes), and general code cleanup.
3.0.2 to 3.0.3 11 commits, 27 files.
composer.json +1 −2config/schema/workflow_notifications.schema.yml +3 −0modules/workflow_sms_notify/composer.json +1 −3modules/workflow_sms_notify/config/schema/workflow_sms_notify.schema.yml +7 −1modules/workflow_sms_notify/src/Entity/WorkflowSmsNotify.php +8 −6 fixmodules/workflow_sms_notify/src/Form/WorkflowSmsNotificationForm.php +2 −1modules/workflow_sms_notify/src/Hook/WorkflowSmsNotifyHooks.php +70 −0modules/workflow_sms_notify/workflow_sms_notify.info.yml +3 −2modules/workflow_sms_notify/workflow_sms_notify.install +3 −1modules/workflow_sms_notify/workflow_sms_notify.module +8 −35modules/workflow_sms_notify/workflow_sms_notify.routing.yml +9 −6 fixmodules/workflow_sms_notify/workflow_sms_notify.services.yml +5 −0
Full diff, 3.0.2 to 3.0.3
The comparison is against the release immediately before the fix. If your site is on an older release, more will have changed.
Critical · 87 sites report using it · SA-CONTRIB-2026-278 · on drupal.org
This module connects a website to a specific external system for managing group exercise classes.
The module does not properly check information provided by users. An administrator account could exploit this to run harmful code on the server. They could view any information or alter any data including the code itself.
- 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 urgentDrupal rates this critical. Cyber Essentials expects a fix within 14 days. Do it this week.
Tell your developerUpdate GroupEx PRO ( Daxko ) integration to 2.2.1.
For developers: what the fix changed
The fix prevents PHP object injection by restricting the classes that can be unserialised, passing the allowed_classes option to unserialize() in GroupexFormCacheManager.php and GroupexFormCacheWarmer.php.
2.2.0 to 2.2.1 4 commits, 2 files.
modules/openy_group_schedules/modules/groupex_form_cache/src/GroupexFormCacheManager.php +4 −1 fixmodules/openy_group_schedules/modules/groupex_form_cache/src/GroupexFormCacheWarmer.php +2 −2 fix
Full diff, 2.2.0 to 2.2.1
The comparison is against the release immediately before the fix. If your site is on an older release, more will have changed.
Critical · 31 sites report using it · SA-CONTRIB-2026-305 · on drupal.org
This module sends a one time code via email or text message to help users regain access to their accounts.
The module allows password resets for accounts that have been blocked. Anyone could trigger this process to change the password for a blocked user and potentially view hidden information. They could only use the new password if an administrator unblocks the account.
- Who could do thisAnyone visiting the site. No login needed.
- Does it apply to youSites are affected if someone with the right access unblocks the affected user account.
- 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 Reset Password Email/SMS OTP to 1.0.5.
For developers: what the fix changed
The fix ensures that the user account is active during the OTP verification steps by introducing the `loadOtpRecord` method in `src/Form/EmailOTPCheck.php`, which explicitly checks `$account->isActive()` before allowing the password reset to proceed.
Also in this release The release also adds Twilio SMS integration, hashes OTPs in the database, introduces flood control, refactors code into services, and adds Drupal 12 compatibility.
1.0.4 to 1.0.5 11 commits, 31 files including 11 tests.
.cspell-project-words.txt +3 −0.gitlab-ci.yml +5 −0composer.json +19 −0config/install/reset_password_email_otp.settings.yml +16 −4config/schema/reset_password_email_otp.yml +32 −6css/reset-password-email-otp.css +14 −0reset_password_email_otp.api.php +39 −0reset_password_email_otp.info.yml +2 −2reset_password_email_otp.install +38 −1reset_password_email_otp.libraries.yml +4 −0reset_password_email_otp.module +6 −35reset_password_email_otp.post_update.php +13 −0
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.
Critical · 7 sites report using it · SA-CONTRIB-2026-301 · on drupal.org
This module lets shoppers swap an item in their basket for a similar alternative without having to remove and add it again.
The module fails to check who owns a shopping basket when the visitor is not logged in. Anyone could view the names and prices of items in other visitor baskets and swap them for alternatives. They could uncover hidden details and alter basket contents.
- Who could do thisAnyone visiting the site. No login needed.
- Does it apply to youSites are affected only for the shopping baskets of visitors who are not logged in.
- 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 Product Alternative to 1.0.1.
For developers: what the fix changed
Updates `SwitchAccessChecker::access` to verify cart ownership using `CartProviderInterface::getCartIds` instead of comparing customer IDs, ensuring anonymous users can only access carts tied to their own session. It also disables caching for the switch route in `commerce_product_alternative.routing.yml`.
Also in this release Added a kernel test to verify access control for anonymous and authenticated carts.
1.0.0 to 1.0.1 1 commit, 3 files including 1 test.
commerce_product_alternative.routing.yml +2 −0 fixsrc/Access/SwitchAccessChecker.php +8 −4 fix
Full diff, 1.0.0 to 1.0.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 · 125,356 sites report using it · SA-CONTRIB-2026-306 · on drupal.org
This module allows editors to set specific dates and times for content to become public or be hidden.
The module does not properly check if a user is allowed to change scheduled dates. An ordinary account on the site could make content public too early or hide it at the wrong time. They might uncover hidden details or alter content schedules.
- Who could do thisOnly someone with a login on your site.
- Does it apply to youSites are affected if an attacker has the access right to edit the content and the content can be edited through a web services data feed.
- 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 Scheduler to 8.x-1.7, 2.2.3 or 2.3.1, whichever branch you are on.
For developers: what the fix changed
The fix implements `hook_entity_field_access()` in `scheduler.module` to restrict edit access to the `publish_on` and `unpublish_on` fields, ensuring that users must have the 'schedule publishing of nodes' permission and that the content type has scheduling enabled.
Also in this release The release also includes CI pipeline updates, deprecation fixes for Drupal 11.3, and test coverage improvements.
8.x-1.6 to 8.x-1.7 8 commits, 19 files including 6 tests.
.gitlab-ci.yml +24 −35composer.json +1 −0phpcs.xml +0 −5phpstan-baseline-to-fix.neon +1 −1phpstan-baseline.neon +14 −1phpstan.neon +1 −1scheduler.module +37 −1 fixscheduler_rules_integration/composer.json +1 −0scheduler_rules_integration/src/Plugin/RulesAction/RemovePublishingDate.php +1 −1scheduler_rules_integration/src/Plugin/RulesAction/RemoveUnpublishingDate.php +1 −1scheduler_rules_integration/src/Plugin/RulesAction/SetPublishingDate.php +1 −1scheduler_rules_integration/src/Plugin/RulesAction/SetUnpublishingDate.php +1 −1
Full diff, 8.x-1.6 to 8.x-1.7 · Full diff, 2.2.2 to 2.2.3 · 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 · 51,019 sites report using it · SA-CONTRIB-2026-312 · on drupal.org
This module allows a website to send emails containing formatted text and images.
The module might include private uploaded files in outgoing emails. Anyone could potentially see this hidden information if they know the file names in advance. They would not be able to alter any information on the site.
- Who could do thisAnyone visiting the site. No login needed.
- Does it apply to youSites are affected under rare configurations where an attacker can send formatted emails and set the recipient list.
- 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 Mime Mail to 2.0.4.
For developers: what the fix changed
The fix modifies the path validation in MimeMailFormatHelper.php by appending a directory separator to the public path and using str_starts_with to ensure the file is strictly within the public directory.
2.0.3 to 2.0.4 1 commit, 1 file.
src/Utility/MimeMailFormatHelper.php +2 −1 fix
Full diff, 2.0.3 to 2.0.4
The comparison is against the release immediately before the fix. If your site is on an older release, more will have changed.
Moderately critical · 8,572 sites report using it · SA-CONTRIB-2026-304 · on drupal.org
This module provides a specific way to store personal names in separate parts like first name and last name.
The module sometimes treats a stored name as code instead of plain text. An ordinary account on the site could use this to run unwanted scripts. This would allow them to view private details or modify existing content.
- Who could do thisOnly someone with a login on your site.
- Does it apply to youAny site using this module.
- 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 Name Field to 8.x-1.6.
For developers: what the fix changed
Escapes HTML in autocomplete suggestion labels in `AutocompleteController` to prevent cross-site scripting.
Also in this release The release also includes coding standards fixes, complexity reductions, PHPUnit deprecation updates, and documentation improvements.
8.x-1.5 to 8.x-1.6 10 commits, 171 files including 64 tests.
.cspell-project-words.txt +5 −0.cursor/rules/drupal.mdc +2 −0.cursor/rules/no-dependency-bags.mdc +65 −0.cursor/rules/readability-control-flow.mdc +32 −3.cursor/skills/code-review-checklist/SKILL.md +2 −0.gitlab-ci.yml +45 −2composer.json +2 −1docs/api/overview.md +71 −1docs/classes/index.md +90 −1docs/coverage/index.html +1 −0docs/deprecations.md +103 −0docs/examples/extending.md +0 −0
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.
Moderately critical · 2,683 sites report using it · SA-CONTRIB-2026-307 · on drupal.org
This module provides a dedicated page where users must enter their current password before setting a new one.
The module sometimes fails to verify the current password correctly. An ordinary account on the site could use a temporarily unattended browser to take permanent control of another user account. They would not be able to view hidden information but could alter account details.
- Who could do thisOnly someone with a login on your site.
- Does it apply to youSites are affected if an attacker already has access to a logged in session for the victim.
- 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 Password Separate Form to 2.0.3.
For developers: what the fix changed
The fix removes a conditional check on the current password input in validateForm within src/Form/ChangePasswordForm.php that allowed a value of zero to bypass validation.
2.0.2 to 2.0.3 1 commit, 2 files including 1 test.
src/Form/ChangePasswordForm.php +7 −6 fix
Full diff, 2.0.2 to 2.0.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 · 1,997 sites report using it · SA-CONTRIB-2026-303 · on drupal.org
This module allows administrators to create private discussion areas and control who can view or participate in them.
The module fails to prevent users from starting new discussions in areas where they should only be able to read. An ordinary account on the site could add new content to a private area. They would not be able to view any hidden information.
- Who could do thisOnly someone with a login on your site.
- Does it apply to youSites are affected if the discussion area does not use the default selection tool or if content is created through a web services data feed.
- 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 Forum Access to 2.0.3.
For developers: what the fix changed
The fix introduces a new validation constraint, `ForumAccessCreate`, and attaches it to the `taxonomy_forums` field via `forum_access_entity_bundle_field_info_alter()` in `forum_access.module`. The constraint validator in `ForumCreateAccessConstraintValidator.php` enforces the 'create' grant on the forum, ensuring access checks apply to all input methods including autocomplete widgets and APIs.
Also in this release Added a post-update hook to rebuild caches and updated a test group annotation.
2.0.2 to 2.0.3 1 commit, 6 files including 1 test.
forum_access.module +23 −5 fixforum_access.post_update.php +14 −0includes/forum_access.common.inc +4 −2 fixsrc/Plugin/Validation/Constraint/ForumCreateAccessConstraint.php +32 −0 fixsrc/Plugin/Validation/Constraint/ForumCreateAccessConstraintValidator.php +94 −0 fix
Full diff, 2.0.2 to 2.0.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 · 1,714 sites report using it · SA-CONTRIB-2026-309 · on drupal.org
This module allows editors to add custom visual styles to text when writing content.
The module does not properly clean up certain text attributes. An ordinary account on the site could use this to run unwanted scripts. This might allow them to view private details or modify existing content.
- Who could do thisOnly someone with a login on your site.
- Does it apply to youSites are affected if an attacker is able to insert text with specific attributes.
- 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 Extended HTML Filter to 1.0.4.
For developers: what the fix changed
The fix adds checks to skip attributes starting with 'data-hx' or 'hx' in the ExtendedHTMLFilterXss class to prevent XSS via HTMX attributes.
Also in this release The release also updates strpos checks to str_starts_with for better readability and performance.
1.0.3 to 1.0.4 1 commit, 1 file.
src/Utility/ExtendedHTMLFilterXss.php +4 −2 fix
Full diff, 1.0.3 to 1.0.4
The comparison is against the release immediately before the fix. If your site is on an older release, more will have changed.
Moderately critical · 1,564 sites report using it · 2 security fixes
This module filters text input to ensure it meets site standards and is safe to display.
2 security fixes in one update. htmLawed fixed 2 separate security bugs at once: 2 cross site scripting. One update covers all of them. The most serious, SA-CONTRIB-2026-315, is explained here and the full list is at the end of the card.
The module fails to properly filter certain text attributes. An ordinary account on the site could use this to run unwanted scripts in the browser. They might uncover hidden details or alter the appearance of pages.
- Who could do thisOnly someone with a login on your site.
- Does it apply to youSites are affected if they use Drupal core newer than version 11.2 or any version with the HTMX library.
- 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 htmLawed to the latest release.
For developers: what the fix changed
The code change for this release could not be fetched from git.drupalcode.org.
All 2 security bugs this update fixes, worst first. Each link is the drupal.org notice for that one.
Moderately critical · 878 sites report using it · SA-CONTRIB-2026-313 · on drupal.org
This module helps organisations manage and share digital files collaboratively.
The module does not properly check access rights when someone uploads or updates media files. An ordinary account on the site could overwrite private files they are not allowed to modify. They would not be able to view any hidden information.
- Who could do thisOnly someone with a login on your site.
- Does it apply to youSites are affected if a user has the access right to update media or to update a piece of content and create media.
- 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 Islandora to 2.19.1.
For developers: what the fix changed
The fix adds file update access checks in MediaSourceService::validateFileWriteAccess to prevent unauthorised file overwrites. It also updates the Islandora Text Extraction submodule's MediaSourceController::attachToMedia to use the shared MediaSourceService::putToMedia method, ensuring destination URI and file extension validation are applied.
Also in this release The release also includes Drupal 11 compatibility fixes, such as replacing deprecated entity storage calls and updating render methods.
2.19.0 to 2.19.1 3 commits, 30 files including 9 tests.
islandora.module +18 −9islandora.routing.yml +2 −2 fixmodules/islandora_breadcrumbs/src/IslandoraBreadcrumbBuilder.php +12 −10modules/islandora_iiif/src/Plugin/views/style/IIIFManifest.php +6 −5modules/islandora_text_extraction/islandora_text_extraction.routing.yml +1 −1 fixmodules/islandora_text_extraction/src/Controller/MediaSourceController.php +35 −69 fixphpunit.xml +1 −0src/Controller/MediaSourceController.php +3 −3 fixsrc/EventGenerator/EventGenerator.php +1 −0src/EventSubscriber/JwtEventSubscriber.php +13 −14src/Form/AddChildrenWizard/Access.php +2 −2src/Form/IslandoraSettingsForm.php +3 −3
Full diff, 2.19.0 to 2.19.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 · 48 sites report using it · SA-CONTRIB-2026-310 · on drupal.org
This module connects a website to a translation service to help translate content.
The module does not properly check data before sending it to the database. An administrator account could exploit this to view any information on the site including user account details. They would not be able to alter any information.
- Who could do thisOnly someone with an administrator login.
- Does it apply to youSites are affected if an attacker is logged in and has the access right to create translation jobs.
- 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 WordsOnline Connector to the latest release.
For developers: what the fix changed
The code change for this release could not be fetched from git.drupalcode.org.
Moderately critical · 16 sites report using it · SA-CONTRIB-2026-300 · on drupal.org
This module connects an online store to a popular payment service to process customer purchases.
The module does not properly check incoming messages from the payment service. Anyone could send a fake message to mark an order as paid without actually spending any money. They would not be able to view hidden 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 attacksNo sign of it.
- How urgentDrupal rates this moderately critical. Include it in your next routine update, within the month.
Tell your developerUpdate AlternativeCommerce PayPal Checkout to 1.1.1.
For developers: what the fix changed
The fix adds webhook signature verification in `src/PayPal.php` and `src/Controller/Pages.php` to ensure requests originate from PayPal. It also introduces strict validation in `src/Controller/ApiPage.php` and `src/PayPal.php` to ensure the PayPal order details match the local payment record before marking an order as paid.
Also in this release Added webhook ID configuration, improved session handling for checkout snapshots, and added unit tests.
1.1.0 to 1.1.1 1 commit, 11 files including 2 tests.
basket_paypal.libraries.yml +5 −0config/install/basket_paypal.settings.yml +2 −0src/Controller/ApiPage.php +209 −50 fixsrc/Controller/Pages.php +132 −82 fixsrc/Form/PaymentForm.php +61 −12src/Form/SettingsForm.php +22 −5src/PayPal.php +137 −1 fixsrc/Services/PayPalJs.php +14 −3templates/basket-paypal-buttons.html.twig +1 −0
Full diff, 1.1.0 to 1.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 · 9 sites report using it · SA-CONTRIB-2026-311 · on drupal.org
This module connects a website to Adobe analytics software to track visitor activity.
The module lacks proper access controls for some of its advanced features. An ordinary account on the site could use this to run unwanted scripts. This could let them uncover hidden details or alter content on the site.
- Who could do thisOnly someone with a login on your site.
- Does it apply to youSites are affected if a user has the access right to add or edit content that uses the advanced features of the module.
- 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 AdobeAnalytics to 8.x-1.1.
For developers: what the fix changed
The fix implements `hook_entity_field_access()` in `adobe_analytics.module` and `src/Hook/AdobeAnalyticsHooks.php` to restrict edit access for the `adobe_analytics` field type to users with the `administer adobe analytics configuration` permission, preventing unauthorised users from injecting arbitrary JavaScript.
Also in this release The release also adds GitLab CI configuration, updates core version requirements for Drupal 11 and 12, and converts hooks to use the new object-oriented hook attributes.
8.x-1.0 to 8.x-1.1 4 commits, 22 files including 9 tests.
.cspell.json +36 −0.gitignore +1 −0.gitlab-ci.yml +67 −0README.md +5 −5adobe_analytics.info.yml +1 −1adobe_analytics.module +25 −22 fixadobe_analytics.services.yml +6 −2src/Form/AdobeAnalyticsAdminSettings.php +4 −4src/Hook/AdobeAnalyticsHooks.php +95 −0 fixsrc/Plugin/Field/FieldWidget/AdobeAnalyticsWidget.php +4 −4src/TrackingMatcher/TrackingMatcherInterface.php +3 −3src/VariableFormatter.php +3 −4
Full diff, 8.x-1.0 to 8.x-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 · 6 sites report using it · SA-CONTRIB-2026-302 · on drupal.org
This module allows an online store to accept payments through a specific secure third party service.
The module does not properly verify incoming messages from the payment service. Anyone could fake payment updates to mark unpaid orders as paid or cancel ongoing orders. They would not be able to view hidden 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 attacksNo sign of it.
- How urgentDrupal rates this moderately critical. Include it in your next routine update, within the month.
Tell your developerUpdate Commerce Escrow to 1.1.0.
For developers: what the fix changed
The fix secures webhook handling by adding a secret token to the webhook URL and introducing a custom access check in `EscrowController::access`. It also updates `EscrowController::webhook` to validate the payload and confirm events by fetching the transaction directly from the Escrow.com API.
1.0.2 to 1.1.0 1 commit, 9 files.
README.md +15 −1commerce_escrow.post_update.php +28 −0 fixcommerce_escrow.routing.yml +7 −2 fixsrc/Controller/EscrowController.php +163 −20 fixsrc/Event/EscrowWebhookEvent.php +10 −1 fixsrc/Plugin/Commerce/PaymentGateway/EscrowGatewayInterface.php +32 −0 fixsrc/Plugin/Commerce/PaymentGateway/EscrowOffer.php +50 −0 fixsrc/Plugin/Commerce/PaymentGateway/EscrowPay.php +20 −0 fixsrc/Plugin/Commerce/PaymentGateway/EscrowTrait.php +74 −0 fix
Full diff, 1.0.2 to 1.1.0
The comparison is against the release immediately before the fix. If your site is on an older release, more will have changed.
Less critical · 465 sites report using it · SA-CONTRIB-2026-308 · on drupal.org
This module restricts which languages a user can use when editing content.
The module fails to stop someone from using a restricted language when creating new content. An ordinary account on the site could bypass this restriction to publish in the wrong language. They would not be able to view hidden information or alter anything else.
- Who could do thisOnly someone with a login on your site.
- Does it apply to youSites are affected if a user has the access right to create content in at least one language.
- Has it been used in attacksNo sign of it.
- How urgentDrupal rates this less critical. Fix it with the next routine update.
Tell your developerUpdate Allowed Languages to 2.0.3.
For developers: what the fix changed
The release diff is linked below. No summary of the fix has been written for this one.
2.0.2 to 2.0.3 0 commits, 0 files.
Full diff, 2.0.2 to 2.0.3
The comparison is against the release immediately before the fix. If your site is on an older release, more will have changed.
