XWiki is a generic wiki platform. In XWiki Platform versions 10.9 through 16.4.6, 16.5.0-rc-1 through 16.10.2, and 17.0.0-rc-1, the title of every single page whose reference is known can be accessed through the REST API as long as an XClass with a page property is accessible, this is the default for an XWiki installation. This allows an attacker to get titles of pages whose reference is known, one title per request. This doesn't affect fully private wikis as the REST endpoint checks access rights on the XClass definition. The impact on confidentiality depends on the strategy for page names. By default, page names match the title, so the impact should be low but if page names are intentionally obfuscated because the titles are sensitive, the impact could be high. This has been fixed in XWiki 16.4.7, 16.10.3 and 17.0.0 by adding access control checks before getting the title of any page.

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. The office document viewer macro was allowing anyone to see any file content from the hosting server, provided that the office server was connected and depending on the permissions of the user running the servlet engine (e.g. tomcat) running XWiki. The same vulnerability also allowed to perform internal requests to resources from the hosting server. The problem has been patched in XWiki 13.10.11, 14.10.1, 14.4.8, 15.0-rc-1. Users are advised to upgrade. It might be possible to workaround this vulnerability by running XWiki in a sandbox with a user with very low privileges on the machine.

XWiki Commons are technical libraries common to several other top level XWiki projects. Rights added to a document are not taken into account for viewing it once it's deleted. Note that this vulnerability only impact deleted documents that where containing view rights: the view rights provided on a space of a deleted document are properly checked. The problem has been patched in XWiki 14.10 by checking the rights of current user: only admin and deleter of the document are allowed to view it.

XWiki Platform is a generic wiki platform. Prior to 15.10.14, 16.4.6, and 16.10.0-rc-1, it's possible for an user to get access to private information through the REST API - but could also be through another API - when a sub wiki is using "Prevent unregistered users to view pages". The vulnerability only affects subwikis, and it only concerns specific right options such as "Prevent unregistered users to view pages". or "Prevent unregistered users to edit pages". It's possible to detect the vulnerability by enabling "Prevent unregistered users to view pages" and then trying to access a page through the REST API without using any credentials. The vulnerability has been patched in XWiki 15.10.14, 16.4.6 and 16.10.0RC1.

XWiki Confluence Migrator Pro helps admins to import confluence packages into their XWiki instance. The homepage of the application is public which enables a guest to download the package which might contain sensitive information. This vulnerability is fixed in 1.11.7.

XWiki Platform is a generic wiki platform. Starting in version 3.2-m3, users can deduce the content of the password fields by repeated call to `LiveTableResults` and `WikisLiveTableResultsMacros`. The issue can be fixed by upgrading to versions 14.7-rc-1, 13.4.4, or 13.10.9 and higher, or in version >= 3.2M3 by applying the patch manually on `LiveTableResults` and `WikisLiveTableResultsMacros`.

macro-pdfviewer is a PDF Viewer Macro for XWiki using Mozilla pdf.js. Any user with view right on XWiki.PDFViewerService can access any attachment stored in the wiki as the "key" that is passed to prevent this is computed incorrectly, calling skip on the digest stream doesn't update the digest. This is fixed in 2.5.6.

### Impact It's possible to know if a user has or not an account in a wiki related to an email address, and which username(s) is actually tied to that email by forging a request to the Forgot username page. Note that since this page does not have a CSRF check it's quite easy to perform a lot of those requests. ### Patches This issue has been patched in XWiki 12.10.5 and 13.2RC1. Two different patches are provided: - a first one to fix the CSRF problem - a more complex one that now relies on sending an email for the Forgot username process. ### Workarounds It's possible to fix the problem without uprading by editing the ForgotUsername page in version below 13.x, to use the following code: https://github.com/xwiki/xwiki-platform/blob/69548c0320cbd772540cf4668743e69f879812cf/xwiki-platform-core/xwiki-platform-administration/xwiki-platform-administration-ui/src/main/resources/XWiki/ForgotUsername.xml#L39-L123 In version after 13.x it's also possible to edit manually the forgotusername.vm file, but it's really encouraged to upgrade the version here. ### References * https://jira.xwiki.org/browse/XWIKI-18384 * https://jira.xwiki.org/browse/XWIKI-18408 ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira XWiki](https://jira.xwiki.org) * Email us at [security ML](mailto:security@xwiki.org)

XWiki OIDC has various tools to manipulate OpenID Connect protocol in XWiki. Prior to version 1.29.1, even if a wiki has an OpenID provider configured through its xwiki.properties, it is possible to provide a third party provider its details through request parameters. One can then bypass the XWiki authentication altogether by specifying its own provider through the oidc.endpoint.* request parameters (or by using an XWiki-based OpenID provider with oidc.xwikiprovider. With the same approach, one could also provide a specific group mapping through oidc.groups.mapping that would make his user automatically part of the XWikiAdminGroup. This issue has been patched, please upgrade to 1.29.1. There is no workaround, an upgrade of the authenticator is required.

XWiki Platform Old Core is a core package for XWiki Platform, a generic wiki platform. Prior to versions 14.2 and 13.10.4, all rights checks that would normally prevent a user from viewing a document on a wiki can be bypassed using the login action and directly specified templates. This exposes title, content and comments of any document and properties of objects, though class and property name must be known. This is also exploitable on private wikis. This has been patched in versions 14.2 and 13.10.4 by properly checking view rights before loading documents and disallowing non-default templates in the login, registration and skin action. As a workaround, it would be possible to protect all templates individually by adding code to check access rights first.

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. In affected versions it's possible to guess if a user has an account on the wiki by using the "Forgot your password" form, even if the wiki is closed to guest users. This problem has been patched on XWiki 12.10.9, 13.4.1 and 13.6RC1. Users are advised yo update. There are no known workarounds for this issue.

XWiki Platform is a generic wiki platform. Starting in version 7.3-milestone-1 and prior to versions 14.4.8, 14.10.6, and 15.1, ny user can call a REST endpoint and obtain the obfuscated passwords, even when the mail obfuscation is activated. The issue has been patched in XWiki 14.4.8, 14.10.6, and 15.1. There is no known workaround.

XWiki Platform before 12.8 mishandles escaping in the property displayer.

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. In versions from 14.4.2 to before 16.4.8, 16.5.0-rc-1 to before 16.10.7, and 17.0.0-rc-1 to before 17.4.0-rc-1, the PDF export jobs store sensitive cookies unencrypted in job statuses. XWiki shouldn't store passwords in plain text, and it shouldn't be possible to gain access to plain text passwords by gaining access to, e.g., a backup of the data directory. This vulnerability has been patched in XWiki 16.4.8, 16.10.7, and 17.4.0-rc-1.

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. In versions 4.2-milestone-2 through 16.10.6, configuration files are accessible through jsx and sx endpoints. It's possible to access and read configuration files by using URLs such as `http://localhost:8080/bin/ssx/Main/WebHome?resource=../../WEB-INF/xwiki.cfg&minify=false`. This is fixed in version 16.10.7.

XWiki is an open-source wiki software platform. From 16.7.0 to 16.10.11, 17.4.4, or 17.7.0, in an instance which is using the XWiki Jetty package (XJetty), a context is exposed to statically access any file located in the webapp/ folder. It allows accessing files which might contains credentials. Fixed in 16.10.11, 17.4.4, and 17.7.0.

XWiki Platform is a generic wiki platform. Starting in 7.2-milestone-2 and prior to versions 14.10.15, 15.5.2, and 15.7-rc-1, the Solr-based search in XWiki discloses the password hashes of all users to anyone with view right on the respective user profiles. By default, all user profiles are public. This vulnerability also affects any configurations used by extensions that contain passwords like API keys that are viewable for the attacker. Normally, such passwords aren't accessible but this vulnerability would disclose them as plain text. This has been patched in XWiki 14.10.15, 15.5.2 and 15.7RC1. There are no known workarounds for this vulnerability.

macro-pdfviewer is a PDF Viewer Macro for XWiki using Mozilla pdf.js. The PDF Viewer macro allows an attacker to view any attachment using the "Delegate my view right" feature as long as the attacker can view a page whose last author has access to the attachment. For this, the attacker only needs to provide the reference to a PDF file to the macro. To obtain the reference of the desired attachment, the attacker can access the Page Index, Attachments tab. Even if the UI shows N/A, the user can inspect the page and check the HTTP request that fetches the live data entries. The attachment URL is available in the returned JSON for all attachments, including protected ones and allows getting the necessary values. This vulnerability is fixed in version 2.5.6.

XWiki Platform Web Templates are templates for XWiki Platform, a generic wiki platform. Through the suggestion feature, string and list properties of objects the user shouldn't have access to can be accessed in versions prior to 13.10.4 and 14.2. This includes private personal information like email addresses and salted password hashes of registered users but also other information stored in properties of objects. Sensitive configuration fields like passwords for LDAP or SMTP servers could be accessed. By exploiting an additional vulnerability, this issue can even be exploited on private wikis at least for string properties. The issue is patched in version 13.10.4 and 14.2. Password properties are no longer displayed and rights are checked for other properties. A workaround is available. The template file `suggest.vm` can be replaced by a patched version without upgrading or restarting XWiki unless it has been overridden, in which case the overridden template should be patched, too. This might need adjustments for older versions, though.

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. The `modifications` rest endpoint does not filter out entries according to the user's rights. Therefore, information hidden from unauthorized users are exposed though the `modifications` rest endpoint (comments and page names etc). Users should upgrade to XWiki 14.6+, 14.4.3+, or 13.10.8+. Older versions have not been patched. There are no known workarounds.

XWiki Platform is a generic wiki platform. Starting in version 3.5-milestone-1 and prior to versions 14.4.8, 14.10.4, and 15.0-rc-1, the mail obfuscation configuration was not fully taken into account. While the mail displayed to the end user was obfuscated, the rest response was also containing the mail unobfuscated and users were able to filter and sort on the unobfuscated, allowing them to infer the mail content. The consequence was the possibility to retrieve the email addresses of all users even when obfuscated. This has been patched in XWiki 14.4.8, 14.10.4, and 15.0-rc-1.

XWiki is a generic wiki platform. In versions starting from 6.1-milestone-1 to before 15.10.12, from 16.0.0-rc-1 to before 16.4.3, and from 16.5.0-rc-1 to before 16.8.0-rc-1, the script API of the LESS compiler in XWiki is incorrectly checking for rights when calling the cache cleaning API, making it possible to clean the cache without having programming right. The only impact of this is a slowdown in XWiki execution as the caches are re-filled. As this vulnerability requires script right to exploit, and script right already allows unlimited execution of scripts, the additional impact due to this vulnerability is low. This issue has been patched in versions 15.10.12, 16.4.3, and 16.8.0-rc-1.

XWiki Platform is a generic wiki platform. Prior to 15.10.15, 16.4.6, and 16.10.0, any user can exploit the WikiManager REST API to create a new wiki, where the user could become an administrator and so performs other attacks on the farm. Note that this REST API is not bundled in XWiki Standard by default: it needs to be installed manually through the extension manager. The problem has been patched in versions 15.10.15, 16.4.6 and 16.10.0 of the REST module.

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. In versions prior to 11.10.13, 12.6.7, and 12.10.2, a user disabled on a wiki using email verification for registration canouldre-activate themself by using the activation link provided for his registration. The problem has been patched in the following versions of XWiki: 11.10.13, 12.6.7, 12.10.2, 13.0. It is possible to workaround the issue by resetting the `validkey` property of the disabled XWiki users. This can be done by editing the user profile with object editor.

XWiki Platform Old Core is a core package for XWiki Platform, a generic wiki platform. Prior to versions 13.1.0.5 and 14.3-rc-1, some resources are missing a check for inactive (not yet activated or disabled) users in XWiki, including the REST service. This means a disabled user can enable themselves using a REST call. On the same way some resources handler created by extensions are not protected by default, so an inactive user could perform actions for such extensions. This issue has existed since at least version 1.1 of XWiki for instance configured with the email activation required for new users. Now it's more critical for versions 11.3-rc-1 and later since the maintainers provided the capability to disable user without deleting them and encouraged using that feature. XWiki 14.3-rc-1 and XWiki 13.10.5 contain a patch. There is no workaround for this other than upgrading XWiki.

XWiki Platform Security Parent POM contains the security APIs for XWiki Platform, a generic wiki platform. Starting with version 5.0 and prior to 12.10.11, 13.10.1, and 13.4.6, a bug in the security cache stores rules associated to document Page1.Page2 and space Page1.Page2 in the same cache entry. That means that it's possible to overwrite the rights of a space or a document by creating the page of the space with the same name and checking the right of the new one first so that they end up in the security cache and are used for the other too. The problem has been patched in XWiki 12.10.11, 13.10.1, and 13.4.6. There are no known workarounds.

XWiki is a generic wiki platform. In XWiki 16.10.0, required rights were introduced as a way to limit which rights a document can have. Part of the security model of required rights is that a user who doesn't have a right also cannot define that right as required right. That way, users who are editing documents on which required rights are enforced can be sure that they're not giving a right to a script or object that it didn't have before. A bug in the implementation of the enforcement of this rule means that in fact, it was possible for any user with edit right on a document to set programming right as required right. If then a user with programming right edited that document, the content of that document would gain programming right, allowing remote code execution. This thereby defeats most of the security benefits of required rights. As XWiki still performs the required rights analysis when a user edits a page even when required rights are enforced, the user with programming right would still be warned about the dangerous content unless the attacker managed to bypass this check. Note also that none of the affected versions include a UI for enabling the enforcing of required rights so it seems unlikely that anybody relied on them for security in the affected versions. As this vulnerability provides no additional attack surface unless all documents in the wiki enforce required rights, we consider the impact of this attack to be low even though gaining programming right could have a high impact. This vulnerability has been patched in XWiki 16.10.4 and 17.1.0RC1. No known workarounds are available except for upgrading.

Claude Code is an agentic coding tool. Prior to version 2.1.7, Claude Code failed to strictly enforce deny rules configured in settings.json when accessing files through symbolic links. If a user explicitly denied Claude Code access to a file (such as /etc/passwd) and Claude Code had access to a symbolic link pointing to that file, it was possible for Claude Code to read the restricted file through the symlink without triggering deny rule enforcement. This issue has been patched in version 2.1.7.

Permission verification vulnerability in the media library module Impact: Successful exploitation of this vulnerability may affect service confidentiality.

NETSCOUT nGeniusONE before 6.4.0 b2350 has a Broken Authorization Schema for the report module.

Gradio is an open-source Python package that allows quick building of demos and web application for machine learning models, API, or any arbitrary Python function. Gradio's Access Control List (ACL) for file paths can be bypassed by altering the letter case of a blocked file or directory path. This vulnerability arises due to the lack of case normalization in the file path validation logic. On case-insensitive file systems, such as those used by Windows and macOS, this flaw enables attackers to circumvent security restrictions and access sensitive files that should be protected. This issue can lead to unauthorized data access, exposing sensitive information and undermining the integrity of Gradio's security model. Given Gradio's popularity for building web applications, particularly in machine learning and AI, this vulnerability may pose a substantial threat if exploited in production environments. This issue has been addressed in release version 5.6.0. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Next.js is a React framework for building full-stack web applications. In affected versions if a Next.js application is performing authorization in middleware based on pathname, it was possible for this authorization to be bypassed for pages directly under the application's root directory. For example: * [Not affected] `https://example.com/` * [Affected] `https://example.com/foo` * [Not affected] `https://example.com/foo/bar`. This issue is patched in Next.js `14.2.15` and later. If your Next.js application is hosted on Vercel, this vulnerability has been automatically mitigated, regardless of Next.js version. There are no official workarounds for this vulnerability.

Dell EMC Isilon OneFS versions 8.1.2, 8.1.0.4, 8.1.0.3, and 8.0.0.7 contain a vulnerability in some configurations. An attacker may exploit this vulnerability to gain access to restricted files. The non-RAN HTTP and WebDAV file-serving components have a vulnerability wherein when either are enabled, and Basic Authentication is enabled for either or both components, files are accessible without authentication.

Vulnerabilities in the File Download and Get File handler components in CIPPlanner CIPAce before 9.17 allow attackers to download unauthorized files. An authenticated user can easily change the file id parameter or pass the physical file path in the URL query string to retrieve the files. (Retrieval is not intended without correct data access configured for documents.)

The Product Input Fields for WooCommerce plugin for WordPress is vulnerable to authorization bypass due to a missing capability check on the handle_downloads() function in versions up to, and including, 1.2.6. This makes it possible for unauthenticated attackers to download files from the vulnerable service.

A flaw was found in the Network Observability plugin for OpenShift console. Unless the Loki authToken configuration is set to FORWARD mode, authentication is no longer enforced, allowing any user who can connect to the OpenShift Console in an OpenShift cluster to retrieve flows without authentication.

The IP2Location Country Blocker plugin for WordPress is vulnerable to Regular Information Exposure in all versions up to, and including, 2.38.8 due to missing capability checks on the admin_init() function. This makes it possible for unauthenticated attackers to view the plugin's settings.

A flaw was found in APICast, when 3Scale's OIDC module does not properly evaluate the response to a mismatched token from a separate realm. This could allow a separate realm to be accessible to an attacker, permitting access to unauthorized information.

Implicit Intent hijacking vulnerability in Samsung Cloud prior to version 5.2.0 allows attacker to get sensitive information.

Access control vulnerability in the SystemUI module Impact: Successful exploitation of this vulnerability may affect service confidentiality.

Access permission verification vulnerability in the Notepad module Impact: Successful exploitation of this vulnerability may affect service confidentiality.

An issue was discovered on D-Link DCS-1130 devices. The device requires that a user logging to the device to provide a username and password. However, the device does not enforce the same restriction on a specific URL thereby allowing any attacker in possession of that to view the live video feed. The severity of this attack is enlarged by the fact that there more than 100,000 D-Link devices out there.

GLPI is a free asset and IT management software package. Starting in 9.2.0 and prior to 11.0.0, it is possible to download a document from the API without appropriate rights. Upgrade to 10.0.16.

An authenticated user with API access (e.g.: user with default User role), more specifically a user with access to the user.update API endpoint is enough to be able to add themselves to any group (e.g.: Zabbix Administrators), except to groups that are disabled or having restricted GUI access.

Improper authorization in Microsoft Exchange Online allows an unauthorized attacker to disclose information over a network.

free5GC is an open-source implementation of the 5G core network. In versions 4.2.1 and below of the UDR service, the handler for reading Traffic Influence Subscriptions checks whether the influenceId path segment equals subs-to-notify, but does not return after sending the HTTP 404 response when validation fails. Execution continues and the subscription data is returned alongside the 404 response. An unauthenticated attacker with access to the 5G Service Based Interface can read arbitrary Traffic Influence Subscriptions, including SUPIs/IMSIs, DNNs, S-NSSAIs, and callback URIs, by supplying any value for the influenceId path segment. A patched version was not available at the time of publication.

Vulnerability in the Oracle Financial Services Customer Screening product of Oracle Financial Services Applications (component: User Interface). The supported version that is affected is 8.1.2.8.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Financial Services Customer Screening. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Financial Services Customer Screening accessible data. CVSS 3.1 Base Score 7.5 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N).

Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to versions 8.6.71 and 9.7.1-alpha.1, file downloads via HTTP Range requests bypass the afterFind(Parse.File) trigger and its validators on storage adapters that support streaming (e.g. the default GridFS adapter). This allows access to files that should be protected by afterFind trigger authorization logic or built-in validators such as requireUser. This issue has been patched in versions 8.6.71 and 9.7.1-alpha.1.

Due to insufficient server-side validation, a successful exploit of this vulnerability could allow an attacker to gain access to certain URLs that the attacker should not have access to.

Vikunja is an open-source self-hosted task management platform. Prior to version 2.2.2, the `LinkSharing.ReadAll()` method allows link share authenticated users to list all link shares for a project, including their secret hashes. While `LinkSharing.CanRead()` correctly blocks link share users from reading individual shares via `ReadOne`, the `ReadAllWeb` handler bypasses this check by never calling `CanRead()`. An attacker with a read-only link share can retrieve hashes for write or admin link shares on the same project and authenticate with them, escalating to full admin access. Version 2.2.2 patches the issue.