CVE-2025-32971 is an authorization vulnerability in the XWiki platform, specifically affecting the Solr script service component. XWiki is a widely used generic wiki platform that supports scripting through its API, including Velocity scripting. The vulnerability exists in versions from 4.5.1 up to but not including 15.10.13, and in certain release candidate versions from 16.0.0-rc-1 to before 16.4.4 and 16.5.0-rc-1 to before 16.8.0-rc-1. The root cause is that the Solr script service fails to properly check if programming rights have been dropped via the $xcontext.dropPermissions() call. Normally, invoking the Solr script service requires programming rights, which restricts access to authorized users. However, due to the incorrect use of the rights-checking API, the service does not recognize when programming rights have been dropped, allowing users with script rights but without programming rights to invoke Solr script service functions improperly. This can lead to two main issues: first, a user with script rights can cause a high load on the system by forcing the indexing of documents, potentially leading to denial of service conditions; second, such a user can temporarily remove documents from the search index, impacting the availability and integrity of search results. The vulnerability does not allow direct access to confidential data or code execution beyond the scripting context, but it does affect the integrity and availability of the search index. The issue has been patched in versions 15.10.13, 16.4.4, and 16.8.0-rc-1. The CVSS v3.1 base score is 3.8, indicating a low severity primarily due to the requirement of privileges (script rights) and the limited impact scope. No known exploits are reported in the wild at this time.

For European organizations using affected versions of XWiki, this vulnerability could lead to disruptions in internal or public-facing wiki search functionality. Organizations relying on XWiki for knowledge management, documentation, or collaboration may experience degraded service availability or inaccurate search results due to temporary removal of documents from the search index. This could hinder operational efficiency, especially in sectors where timely access to information is critical, such as government, healthcare, and finance. While the vulnerability does not expose sensitive data directly, the ability to manipulate search indexing could be leveraged as part of a broader attack chain or insider threat scenario. The potential for high system load caused by forced indexing could also impact system performance, leading to denial of service conditions that affect user productivity. Given that exploitation requires script rights, the threat is more relevant in environments where multiple users have scripting privileges, such as large enterprises or collaborative platforms with delegated scripting capabilities. The impact on confidentiality is negligible, but integrity and availability of search services are affected.

1. Upgrade affected XWiki instances to patched versions: 15.10.13, 16.4.4, or 16.8.0-rc-1 or later. This is the most effective mitigation. 2. Audit and restrict script rights assignments: Ensure that only trusted users have script rights, as exploitation requires these privileges. 3. Review and harden scripting policies: Disable or limit the use of the Solr script service where possible, or implement additional access controls around scripting features. 4. Monitor system performance and search index behavior: Set up alerts for unusual spikes in indexing activity or unexpected removal of documents from the search index to detect potential exploitation attempts. 5. Implement application-layer logging and auditing: Track usage of scripting APIs and Solr service calls to identify anomalous or unauthorized actions. 6. Consider network segmentation and access controls to limit exposure of the XWiki platform to only necessary users and systems. 7. If upgrading immediately is not feasible, consider disabling scripting features temporarily or applying custom patches/workarounds to enforce correct permission checks.