SA-CONTRIB-2026-270: Critical severity composer/drupal/ai vulnerability
This module provides a framework for integrating Drupal with AI providers. Its AI Search submodule provides a Search API backend that stores content in a vector database for semantic search. The AI Search submodule has always been marked as 'experimental' but more importantly is deprecated. You may wish to use this as an opportunity to move to the standalone AI Search which is a drop-in replacement and target of all new development. It also has the same vulnerability. The AI Search backend checks access to each search result for the current user, but this is not taken into account when Search API caches the results of a view. As a result, cached search results, including titles and other displayed fields of unpublished or access-restricted content, can be shown to users who do not have access to that content in some configurations. This vulnerability is mitigated by the fact that:
The AI Search submodule must be enabled and used with a Search API view. The view must use Search API result caching ("Search API (time-based)", "Search API (tag-based)" or "Search API (time and tag-based)"). The default, "Search API (none)", is not affected. A user with access to the restricted content must have run the same search within the cache lifetime.
Retrieval-augmented generation (RAG) tools, AI Assistant RAG actions and custom code running Search API queries are not affected.
Credit
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
composer/drupal/aito a version that resolves this vulnerability.Fixed in 1.5.2Fixed in 1.4.11Fixed in 1.5.2Fixed in 1.4.11
Event History
Frequently Asked Questions
Is the default Search API caching configuration affected?
No. The default "Search API (none)" caching option is not affected. Exposure requires one of the Search API result caching options: time-based, tag-based, or time-and-tag-based.
Which deployments are exposed?
The AI Search submodule must be enabled and used with a Search API view. That view must use an affected Search API result-cache configuration.
What information could unauthorized users see?
Cached search results can expose titles and other displayed fields from unpublished or access-restricted content to users who do not have access to that content.
Would moving to the standalone AI Search module remove the risk?
No. The standalone AI Search is identified as a drop-in replacement and the target of new development, but it has the same vulnerability.