Critical · 43,392 sites report using it · SA-CONTRIB-2026-062 · on drupal.org
This module adds a way to store geographical coordinates and display them on maps.
Anyone without logging in could enter malicious database commands into a map filter. They could view any private information on the website and modify any files including the underlying code.
- Who could do thisAnyone visiting the site. No login needed.
- Does it apply to youA site is affected if it has a list of content that uses the map filter and is set to accept user input.
- 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 Geolocation Field to 8.x-3.15.
For developers: what the fix changed
The fix updates the `ProximityFilter` views filter in `src/Plugin/views/filter/ProximityFilter.php` to use parameterised queries instead of concatenating user input directly into SQL expressions. It also casts boundary and proximity filter inputs to floats in `src/BoundaryTrait.php` and `src/ProximityTrait.php` to ensure they are safe.
Also in this release The release also addresses PHP 8.4 deprecations, adds MySQL 8.0+ SRID 4326 axis order handling, implements Google Places API session tokens, and updates tests.
8.x-3.14 to 8.x-3.15 8 commits, 75 files including 10 tests.
config/schema/geolocation.views.schema.yml +4 −0modules/geolocation_address/geolocation_address.module +1 −1modules/geolocation_address/js/geolocation-address-map-widget.js +11 −5modules/geolocation_demo/config/install/core.base_field_override.node.geolocation_default_article.promote.yml +0 −0modules/geolocation_demo/config/install/core.entity_form_display.node.geolocation_default_article.default.yml +0 −0modules/geolocation_demo/config/install/core.entity_form_display.taxonomy_term.geolocation_demo_taxonomy.default.yml +0 −0modules/geolocation_demo/config/install/core.entity_view_display.node.geolocation_default_article.default.yml +0 −0modules/geolocation_demo/config/install/core.entity_view_display.node.geolocation_default_article.teaser.yml +0 −0modules/geolocation_demo/config/install/core.entity_view_display.taxonomy_term.geolocation_demo_taxonomy.default.yml +0 −0modules/geolocation_demo/config/install/field.field.node.geolocation_default_article.body.yml +0 −0modules/geolocation_demo/config/install/field.field.node.geolocation_default_article.field_geolocation_demo_multiple.yml +0 −0modules/geolocation_demo/config/install/field.field.node.geolocation_default_article.field_geolocation_demo_single.yml +0 −0
Full diff, 8.x-3.14 to 8.x-3.15
The comparison is against the release immediately before the fix. If your site is on an older release, more will have changed.
Critical · 267 sites report using it · SA-CONTRIB-2026-064 · on drupal.org
This module connects the website to a marketing system that lets you manage tracking tags and vendors.
An ordinary account on the site could write malicious data directly to a tracking field. They could view any hidden information on the website and alter any files including the underlying code.
- Who could do thisOnly someone with a login on your site.
- Does it apply to youA site is affected if an attacker has the access right to edit a piece of content with a Tealium field attached and the data feed module is set to accept all changes or the attacker has another way to edit field values directly.
- 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 Tealium iQ Tag Management to 8.x-2.4.
For developers: what the fix changed
The fix adds the `['allowed_classes' => FALSE]` option to `unserialize()` calls in `FieldItemNormalizer.php`, `TealiumiqFieldItem.php`, `TealiumiqWidget.php`, and `Helper.php` to prevent PHP object injection.
8.x-2.3 to 8.x-2.4 2 commits, 4 files.
src/Normalizer/FieldItemNormalizer.php +1 −1 fixsrc/Plugin/Field/FieldType/TealiumiqFieldItem.php +1 −1 fixsrc/Plugin/Field/FieldWidget/TealiumiqWidget.php +1 −1 fixsrc/Service/Helper.php +1 −1 fix
Full diff, 8.x-2.3 to 8.x-2.4
The comparison is against the release immediately before the fix. If your site is on an older release, more will have changed.
Critical · 237 sites report using it · SA-CONTRIB-2026-059 · on drupal.org
This module adds support for an image viewer and allows people to add notes to images.
Anyone without logging in could submit malicious details through a web address to bypass access checks in the image viewer. They could view hidden image annotations and modify certain research records. They could not access or alter every piece of information on the website.
- Who could do thisAnyone visiting the site. No login needed.
- Does it apply to youA site is affected if it uses the Mirador image viewer feature.
- 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 WissKI to 8.x-4.2.
For developers: what the fix changed
The fix restricts session writes in WisskiMiradorApiController to only allow the mirador key, preventing arbitrary data from being stored in the session.
8.x-4.1 to 8.x-4.2 1 commit, 1 file.
wisski_mirador/src/Controller/WisskiMiradorApiController.php +3 −1 fix
Full diff, 8.x-4.1 to 8.x-4.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 · 251,860 sites report using it · 2 security fixes
This module allows you to save sections of content in a library and reuse them in multiple places across the website.
2 security fixes in one update. Paragraphs fixed 2 separate security bugs this week: 2 access bypass. One update covers all of them. The most serious, SA-CONTRIB-2026-061, is explained here and the full list is at the end of the card.
Anyone without logging in could bypass access checks to reach child sections of library items through data feeds. They could alter or create new library sections on the website. They could not view any restricted information.
- Who could do thisAnyone visiting the site. No login needed.
- Does it apply to youA site is affected if the library feature is in use and general write access to these sections is allowed through another 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 Paragraphs to 8.x-1.21.
For developers: what the fix changed
This release carries 2 security fixes. The summary below is for SA-CONTRIB-2026-061, the most serious of them.
The fix updates `ParagraphAccessControlHandler::checkAccess()` to properly enforce access checks on child paragraphs of library items, and modifies `LibraryItemAccessControlHandler::checkAccess()` to forward view access checks to the referenced paragraph. It also adds `paragraphs_library_query_paragraphs_library_item_access_alter()` in `paragraphs_library.module` to restrict query access to unpublished library items.
Also in this release The release also updates the inline_entity_form dependency and improves mobile behaviour for sticky content tabs.
8.x-1.20 to 8.x-1.21 4 commits, 9 files including 3 tests.
composer.json +1 −1css/paragraphs.widget.css +13 −13css/paragraphs.widget.scss +20 −17modules/paragraphs_library/paragraphs_library.module +42 −0 fixmodules/paragraphs_library/src/LibraryItemAccessControlHandler.php +13 −7 fixsrc/ParagraphAccessControlHandler.php +9 −3 fix
Full diff, 8.x-1.20 to 8.x-1.21
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 · 23,475 sites report using it · 2 security fixes
This module provides the technical foundation for integrating language models and automating tasks with artificial intelligence.
2 security fixes in one update. AI (Artificial Intelligence) fixed 2 separate security bugs this week: 1 access bypass, 1 information disclosure / cross site scripting. One update covers all of them. The most serious, SA-CONTRIB-2026-055, is explained here and the full list is at the end of the card.
An administrator account could use an artificial intelligence agent to bypass access checks for certain website actions. They could view restricted system settings and modify specific automated workflows. They could not access or alter every piece of information on the website.
- Who could do thisOnly someone with an administrator login.
- Does it apply to youA site is affected if an attacker has access to communicate with an affected agent and the site is set up to expose the affected tools to users without special access rights.
- 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 AI (Artificial Intelligence) to 1.2.17, 1.3.8 or 1.4.3, 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-055, the most serious of them.
The fix introduces an `access()` method in `ActionPluginBase` to ensure proper access validation before executing core actions exposed as agent tools, mapping specific actions to required permissions and delegating entity actions to entity access checks. It also updates `RagAction` to enforce access control by default and provides an update hook to migrate existing configurations.
Also in this release The release also adds URL filtering hardening, MIME type validation for AI-generated files, and a SECURITY.md file.
1.2.16 to 1.2.17 7 commits, 15 files including 4 tests.
.cspell-project-words.txt +6 −0.gitlab-ci.yml +1 −1SECURITY.md +36 −0docs/contribute/releases/tagging_a_release.md +1 −1docs/security.md +9 −0mkdocs.yml +1 −0modules/ai_search/ai_search.install +35 −0 fixmodules/ai_search/src/Plugin/AiAssistantAction/RagAction.php +20 −5 fixsrc/Base/OpenAiBasedProviderClientBase.php +56 −13src/Plugin/AiFunctionCall/ActionPluginBase.php +108 −4 fixsrc/Service/HostnameFilter.php +93 −4
Full diff, 1.2.16 to 1.2.17 · Full diff, 1.3.7 to 1.3.8 · Full diff, 1.4.2 to 1.4.3
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 · 15,737 sites report using it · SA-CONTRIB-2026-053 · on drupal.org
This module allows the website to use OpenAI models for text generation and image creation.
An administrator account could supply a malicious web address to force the server to make unsafe requests. They could view restricted server responses and alter specific image generation settings. They could not access or modify every piece of information on the website.
- Who could do thisOnly someone with an administrator login.
- Does it apply to youA site is affected if an attacker has the access right to change the host web address and a way to create artificial intelligence images.
- 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 OpenAI Provider to 1.1.1 or 1.2.2, whichever branch you are on.
For developers: what the fix changed
The fix removes the ability to fetch generated images via URL using `file_get_contents()` in `OpenAiProvider::generateImage()`, instead forcing the API to return base64-encoded image data directly. This prevents the server from making arbitrary requests to potentially malicious URLs.
Also in this release The release also deprecates Dall-E 3 in favour of GPT Image models, updates API key validation, adds host configuration support, and updates model capabilities and defaults.
1.1.0 to 1.1.1 9 commits, 8 files.
.cspell-project-words.txt +1 −2ai_provider_openai.install +23 −0ai_provider_openai.services.yml +1 −1definitions/api_defaults.yml +11 −14src/Form/OpenAiConfigForm.php +15 −5src/OpenAiChatMessageIterator.php +2 −1src/OpenAiHelper.php +15 −1src/Plugin/AiProvider/OpenAiProvider.php +110 −75 fix
Full diff, 1.1.0 to 1.1.1 · Full diff, 1.2.1 to 1.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 · 13,186 sites report using it · 2 security fixes
This module provides a framework to create artificial intelligence agents that can follow instructions to manipulate website content.
2 security fixes in one update. AI Agents fixed 2 separate security bugs this week: 1 information disclosure, 1 access bypass. One update covers all of them. The most serious, SA-CONTRIB-2026-057, is explained here and the full list is at the end of the card.
Anyone without logging in could cause an artificial intelligence agent to reveal hidden details when it uses the same tool multiple times in one request. They could view restricted agent configurations and alter certain automated tasks. They could not access or modify every piece of information on the website.
- 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 AI Agents to 1.1.4, 1.2.5 or 1.3.1, 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-057, the most serious of them.
The fix clones the context definition in `AiAgentEntityWrapper::setToolUsageLimits` to prevent mutating the shared cached definition across agent instances, which stops parameters from being inherited. It also adds field-level access checks to `ContentEntitySeeder`, `GetCurrentContentEntityValues`, and `ListContentEntities` to ensure users have the appropriate view or edit permissions.
Also in this release The release also updates regex constraints to use named arguments, changes token replacement to not escape HTML markup, adds a logger channel, and removes some tests.
1.1.3 to 1.1.4 5 commits, 13 files including 3 tests.
ai_agents.services.yml +4 −1composer.json +1 −1src/Plugin/AiFunctionCall/ContentEntitySeeder.php +5 −0 fixsrc/Plugin/AiFunctionCall/CreateContentType.php +1 −1src/Plugin/AiFunctionCall/EditContentType.php +1 −1src/Plugin/AiFunctionCall/GetCurrentContentEntityValues.php +8 −1 fixsrc/Plugin/AiFunctionCall/ListContentEntities.php +12 −3 fixsrc/Plugin/AiFunctionCall/ModifyVocabulary.php +1 −1src/PluginBase/AiAgentEntityWrapper.php +27 −2 fixsrc/PluginManager/AiAgentManager.php +5 −1
Full diff, 1.1.3 to 1.1.4 · Full diff, 1.2.4 to 1.2.5 · 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.
All 2 security bugs this update fixes, worst first. Each link is the drupal.org notice for that one.
Moderately critical · 3,942 sites report using it · SA-CONTRIB-2026-063 · on drupal.org
This module connects the website to Salesforce to share information like users and contacts between the two systems.
An ordinary account on the site could hijack the authorisation token and connect the website to their own Salesforce account. They could view restricted synchronisation details and modify certain contact records. They could not access or alter every piece of information on the website.
- Who could do thisOnly someone with a login on your site.
- Does it apply to youA site is affected if it uses a version older than version six and has the Salesforce OAuth feature enabled with an active authorisation profile.
- 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 Salesforce Suite to 5.1.3.
For developers: what the fix changed
The fix adds a `state` parameter to the OAuth authorization request in `SalesforceOAuthPlugin::submitConfigurationForm` and validates it during the callback in `SalesforceOAuthController::oauthCallback` to prevent CSRF attacks.
Also in this release The release also includes PHP 8.3 compatibility fixes, updates to the JWT authentication plugin, enhancements to mapping and pull/push events, and various bug fixes.
5.1.2 to 5.1.3 34 commits, 78 files including 8 tests.
.gitignore +3 −1.gitlab-ci.yml +2 −1composer.json +1 −1css/salesforce.css +1 −1modules/salesforce_example/src/EventSubscriber/SalesforceExampleSubscriber.php +3 −0modules/salesforce_jwt/composer.json +1 −1modules/salesforce_jwt/src/Consumer/JWTCredentials.php +41 −6modules/salesforce_jwt/src/Plugin/SalesforceAuthProvider/SalesforceJWTGovCloudPlugin.php +4 −22modules/salesforce_jwt/src/Plugin/SalesforceAuthProvider/SalesforceJWTPlugin.php +338 −29modules/salesforce_logger/salesforce_logger.services.yml +2 −0modules/salesforce_logger/src/Form/SettingsForm.php +6 −1modules/salesforce_mapping/config/schema/salesforce_mapping.schema.yml +8 −0
Full diff, 5.1.2 to 5.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 · 337 sites report using it · 2 security fixes
This module allows website visitors to leave feedback on pages and optionally attach a comment to their vote.
2 security fixes in one update. Advanced Content Feedback (aka admin_feedback) fixed 2 separate security bugs this week: 1 access bypass / insecure direct object reference (idor), 1 cross site scripting. One update covers all of them. The most serious, SA-CONTRIB-2026-052, is explained here and the full list is at the end of the card.
An ordinary account on the site could bypass access checks when submitting a comment to alter another feedback record. They could modify other visitor feedback submissions on the website but they could not view any hidden information.
- Who could do thisOnly someone with a login on your site.
- Does it apply to youA site is affected if an attacker has a role with the access right to give feedback.
- 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 Advanced Content Feedback (aka admin_feedback) to 8.x-2.8.
For developers: what the fix changed
This release carries 2 security fixes. The summary below is for SA-CONTRIB-2026-052, the most serious of them.
The fix replaces the base64-encoded feedback ID with an HMAC-signed token in `AdminFeedbackController::insertFeedback()` and verifies this signature in `AdminFeedbackController::updateFeedback()` to prevent users from modifying arbitrary feedback records. It also updates `AdminFeedbackAjaxForm` to handle the validation result and ensures that a comment can only be set once per feedback record.
Also in this release Added flood control for vote submissions, batch processing for CSV exports, a feature to delete all feedback for a specific node, and made JavaScript markup themeable.
8.x-2.7 to 8.x-2.8 30 commits, 19 files including 1 test.
README.md +55 −0admin_feedback.install +25 −0admin_feedback.libraries.yml +1 −1admin_feedback.module +1 −0admin_feedback.permissions.yml +4 −0admin_feedback.routing.yml +17 −0config/install/admin_feedback.settings.yml +7 −3config/schema/admin_feedback.schema.yml +14 −0css/admin_feedback.css +1 −1js/admin_feedback.js +152 −98logo.png +0 −0src/Controller/AdminFeedbackController.php +277 −63 fix
Full diff, 8.x-2.7 to 8.x-2.8
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 · 61 sites report using it · SA-CONTRIB-2026-058 · on drupal.org
This module allows the website to take payments through the Global Payments system.
Anyone without logging in could fake a payment response from the payment provider. They could mark unpaid orders as paid on the website but they could not view any hidden information.
- Who could do thisAnyone visiting the site. No login needed.
- Does it apply to youA site is affected if the payment system is set up to redirect users to a full page rather than using a popup window.
- 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 Realex / Global Payments to 3.0.2.
For developers: what the fix changed
The fix verifies the SHA hash of the payment response by calling parseResponse in RealexHppResponse.php and rejects the response if the hash check fails.
3.0.1 to 3.0.2 1 commit, 1 file.
src/Controller/RealexHppResponse.php +13 −1 fix
Full diff, 3.0.1 to 3.0.2
The comparison is against the release immediately before the fix. If your site is on an older release, more will have changed.
