XWiki Commons are technical libraries common to several other top level XWiki projects. Any user with view rights on commonly accessible documents including the legacy notification activity macro can execute arbitrary Groovy, Python or Velocity code in XWiki leading to full access to the XWiki installation. The root cause is improper escaping of the macro parameters of the legacy notification activity macro. This macro is installed by default in XWiki. The vulnerability can be exploited via every wiki page that is editable including the user's profile, but also with just view rights using the HTMLConverter that is part of the CKEditor integration which is bundled with XWiki. The vulnerability has been patched in XWiki 13.10.11, 14.4.7 and 14.10.

XWiki Commons are technical libraries common to several other top level XWiki projects. Any user with view rights on commonly accessible documents including the notification preferences macros can execute arbitrary Groovy, Python or Velocity code in XWiki leading to full access to the XWiki installation. The root cause is improper escaping of the user parameter of the macro that provide the notification filters. These macros are used in the user profiles and thus installed by default in XWiki. The vulnerability has been patched in XWiki 13.10.11, 14.4.7 and 14.10.

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. A registered user can perform remote code execution leading to privilege escalation by injecting the proper code in the "property" field of an attachment selector, as a gadget of their own dashboard. Note that the vulnerability does not impact comments of a wiki. The vulnerability has been patched in XWiki 13.10.11, 14.4.8, 14.10.2, 15.0-rc-1. Users are advised to upgrade. There are no known workarounds for this vulnerability.

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. In affected versions it's possible to display or interact with any page a user cannot access through the combination of the async and display macros. A comment with either macro will be executed when viewed providing a code injection vector in the context of the running server. This vulnerability has been patched in XWiki 15.0-rc-1, 14.10.3, 14.4.8, and 13.10.11. Users are advised to upgrade. There are no known workarounds for this issue.

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. Any user with view rights can execute arbitrary Groovy, Python or Velocity code in XWiki leading to full access to the XWiki installation. The root cause is improper escaping of `Invitation.InvitationCommon`. This page is installed by default. The vulnerability has been patched in XWiki 15.0-rc-1, 14.10.1, 14.4.8, and 13.10.11. Users are advised to upgrade. There are no known workarounds for this issue.

XWiki Commons are technical libraries common to several other top level XWiki projects. Any user with edit rights can execute arbitrary Groovy, Python or Velocity code in XWiki leading to full access to the XWiki installation. The root cause is improper escaping of the included pages in the IncludedDocuments panel. The problem has been patched on XWiki 14.4.7, and 14.10.

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. In XWiki, every user can add translations that are only applied to the current user. This also allows overriding existing translations. Such translations are often included in privileged contexts without any escaping which allows remote code execution for any user who has edit access on at least one document which could be the user's own profile where edit access is enabled by default. A mitigation for this vulnerability is part of XWiki 14.10.2 and XWiki 15.0 RC1: translations with user scope now require script right. This means that regular users cannot exploit this anymore as users don't have script right by default anymore starting with XWiki 14.10. There are no known workarounds apart from upgrading to a patched versions.

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. Any user with edit rights on any document (e.g., their own user profile) can execute code with programming rights, leading to remote code execution. This vulnerability has been patched in XWiki 13.10.11, 14.4.8, 14.10.1 and 15.0 RC1. Users are advised to upgrade. There are no known workarounds for this vulnerability.

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. Affected versions of xwiki are subject to code injection in the `since` parameter of the `/xwiki/bin/view/XWiki/Notifications/Code/LegacyNotificationAdministration` endpoint. This provides an XWiki syntax injection attack via the since-parameter, allowing privilege escalation from view to programming rights and subsequent code execution privilege. The vulnerability has been patched in XWiki 15.0-rc-1, 14.10.3, 14.4.8 and 14.10.3. Users are advised to upgrade. Users unable to upgrade may modify the page `XWiki.Notifications.Code.LegacyNotificationAdministration` to add the missing escaping. For versions < 14.6-rc-1 a workaround is to modify the file `<xwikiwebapp>/templates/distribution/eventmigration.wiki` to add the missing escaping.

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. Any user with view rights can execute arbitrary Groovy, Python or Velocity code in XWiki leading to full access to the XWiki installation. The root cause is improper escaping of `Macro.VFSTreeMacro`. This page is not installed by default.This vulnerability has been patched in XWiki 15.0-rc-1, 14.10.2, 14.4.8, 13.10.11. Users are advised to upgrade. There are no known workarounds for this vulnerability.

XWiki Commons are technical libraries common to several other top level XWiki projects. Any user with view rights `WikiManager.DeleteWiki` can execute arbitrary Groovy, Python or Velocity code in XWiki leading to full access to the XWiki installation. The root cause is improper escaping of the `wikiId` url parameter. The problem has been patched on XWiki 13.10.11, 14.4.7, and 14.10.

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. In affected versions a user without script or programming right may edit a user profile (or any other document) with the wiki editor and add groovy script content. Viewing the document after saving it will execute the groovy script in the server context which provides code execution. This vulnerability has been patched in XWiki 15.0-rc-1 and 14.10.3. Users are advised to upgrade. There are no known workarounds for this issue.

XWiki Platform is a generic wiki platform. Starting in version 13.10, it's possible to use the right of an existing document content author to execute a text area property. This has been patched in XWiki 14.10, 14.4.7, and 13.10.11. 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.

XWiki Platform is a generic wiki platform. Starting in version 11.6-rc-1, comments are supposed to be executed with the right of superadmin but in restricted mode (anything dangerous is disabled), but the async macro does not take into account the restricted mode. This means that any user with comment right can use the async macro to make it execute any wiki content with the right of superadmin. This has been patched in XWiki 14.9, 14.4.6, and 13.10.10. The only known workaround consists of applying a patch and rebuilding and redeploying `org.xwiki.platform:xwiki-platform-rendering-async-macro`.

XWiki Platform is a generic wiki platform. Starting in version 2.3-milestone-1, the annotation displayer does not execute the content in a restricted context. This allows executing anything with the right of the author of any document by annotating the document. This has been patched in XWiki 13.10.11, 14.4.7 and 14.10. There is no easy workaround except to upgrade.

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. In affected versions any user with view rights can execute arbitrary Groovy, Python or Velocity code in XWiki leading to full access to the XWiki installation. The root cause is improper escaping of UIX parameters. A proof of concept exploit is to log in, add an `XWiki.UIExtensionClass` xobject to the user profile page, with an Extension Parameters content containing `label={{/html}} {{async async="true" cached="false" context="doc.reference"}}{{groovy}}println("Hello " + "from groovy!"){{/groovy}}{{/async}}`. Then, navigating to `PanelsCode.ApplicationsPanelConfigurationSheet` (i.e., `<xwiki-host>/xwiki/bin/view/PanelsCode/ApplicationsPanelConfigurationSheet` where `<xwiki-host>` is the URL of your XWiki installation) should not execute the Groovy script. If it does, you will see `Hello from groovy!` displayed on the screen. This vulnerability has been patched in XWiki 13.10.11, 14.4.7 and 14.10-rc-1. Users are advised to upgrade. For users unable to upgrade the issue can be fixed by editing the `PanelsCode.ApplicationsPanelConfigurationSheet` wiki page and making the same modifications as shown in commit `6de5442f3c`.

XWiki Platform is a generic wiki platform. Starting in version 6.2-milestone-1, one can execute any wiki content with the right of IconThemeSheet author by creating an icon theme with certain content. This can be done by creating a new page or even through the user profile for users not having edit right. The issue has been patched in XWiki 14.9, 14.4.6, and 13.10.10. An available workaround is to fix the bug in the page `IconThemesCode.IconThemeSheet` by applying a modification from commit 48caf7491595238af2b531026a614221d5d61f38.

XWiki Commons are technical libraries common to several other top level XWiki projects. Starting in version 3.1-milestone-1, any user can edit their own profile and inject code, which is going to be executed with programming right. The same vulnerability can also be exploited in all other places where short text properties are displayed, e.g., in apps created using Apps Within Minutes that use a short text field. The problem has been patched on versions 13.10.9, 14.4.4, 14.7RC1.

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. The rollback action is missing a right protection, a user can rollback to a previous version of the page to gain rights they don't have anymore. The problem has been patched in XWiki 14.10.17, 15.5.3 and 15.8-rc-1 by ensuring that the rights are checked before performing the rollback.

XWiki through version 17.3.0 is vulnerable to Server-Side Template Injection (SSTI) in the Administration interface, specifically within the HTTP Meta Info field of the Global Preferences Presentation section. An authenticated administrator can inject crafted Apache Velocity template code, which is rendered on the server side without proper validation or sandboxing. This enables the execution of arbitrary template logic, which may expose internal server information or, in specific configurations, lead to further exploitation such as remote code execution or sensitive data leakage. The vulnerability resides in improper handling of dynamic template rendering within user-supplied configuration fields.

XWiki is a generic wiki platform. Any user with edit right on a page (could be the user's profile) can execute code (Groovy, Python, Velocity) with programming right by defining a wiki macro. This allows full access to the whole XWiki installation. The main problem is that if a wiki macro parameter allows wiki syntax, its default value is executed with the rights of the author of the document where it is used. This can be exploited by overriding a macro like the children macro that is used in a page that has programming right like the page XWiki.ChildrenMacro and thus allows arbitrary script macros. This vulnerability has been patched in XWiki 16.4.7, 16.10.3 and 17.0.0 by executing wiki parameters with the rights of the wiki macro's author when the parameter's value is the default value.

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. Any user with view rights on commonly accessible documents including the menu macro can execute arbitrary Groovy, Python or Velocity code in XWiki leading to full access to the XWiki installation due to improper escaping of the macro content and parameters of the menu macro. The problem has been patched in XWiki 14.6RC1, 13.10.8 and 14.4.3. The patch (commit `2fc20891`) for the document `Menu.MenuMacro` can be manually applied or a XAR archive of a patched version can be imported. The menu macro was basically unchanged since XWiki 11.6 so on XWiki 11.6 or later the patch for version of 13.10.8 (commit `59ccca24a`) can most likely be applied, on XWiki version 14.0 and later the versions in XWiki 14.6 and 14.4.3 should be appropriate.

xwiki-platform-icon-ui is vulnerable to Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection'). Any user with view rights on commonly accessible documents including the icon picker macro can execute arbitrary Groovy, Python or Velocity code in XWiki due to improper neutralization of the macro parameters of the icon picker macro. The problem has been patched in XWiki 13.10.7, 14.5 and 14.4.2. Workarounds: The [patch](https://github.com/xwiki/xwiki-platform/commit/47eb8a5fba550f477944eb6da8ca91b87eaf1d01) can be manually applied by editing `IconThemesCode.IconPickerMacro` in the object editor. The whole document can also be replaced by the current version by importing the document from the XAR archive of a fixed version as the only changes to the document have been security fixes and small formatting changes.

XWiki Platform Wiki UI Main Wiki is software for managing subwikis on XWiki Platform, a generic wiki platform. Starting with version 5.3-milestone-2 and prior to versions 13.10.6 and 14.4, it's possible to inject arbitrary wiki syntax including Groovy, Python and Velocity script macros via the request (URL parameter) using the `XWikiServerClassSheet` if the user has view access to this sheet and another page that has been saved with programming rights, a standard condition on a public read-only XWiki installation or a private XWiki installation where the user has an account. This allows arbitrary Groovy/Python/Velocity code execution which allows bypassing all rights checks and thus both modification and disclosure of all content stored in the XWiki installation. Also, this could be used to impact the availability of the wiki. This has been patched in versions 13.10.6 and 14.4. As a workaround, edit the affected document `XWiki.XWikiServerClassSheet` or `WikiManager.XWikiServerClassSheet` and manually perform the changes from the patch fixing the issue. On XWiki versions 12.0 and later, it is also possible to import the document `XWiki.XWikiServerClassSheet` from the xwiki-platform-wiki-ui-mainwiki package version 14.4 using the import feature of the administration application as there have been no other changes to this document since XWiki 12.0.

XWiki Platform Applications Tag and XWiki Platform Tag UI are tag applications for XWiki, a generic wiki platform. Starting with version 1.7 in XWiki Platform Applications Tag and prior to 13.10.6 and 14.4 in XWiki Platform Tag UI, the tags document `Main.Tags` in XWiki didn't sanitize user inputs properly. This allowed users with view rights on the document (default in a public wiki or for authenticated users on private wikis) to execute arbitrary Groovy, Python and Velocity code with programming rights. This also allowed bypassing all rights checks and thus both modification and disclosure of all content stored in the XWiki installation. The vulnerability could be used to impact the availability of the wiki. On XWiki versions before 13.10.4 and 14.2, this can be combined with CVE-2022-36092, meaning that no rights are required to perform the attack. The vulnerability has been patched in versions 13.10.6 and 14.4. As a workaround, the patch that fixes the issue can be manually applied to the document `Main.Tags` or the updated version of that document can be imported from version 14.4 of xwiki-platform-tag-ui using the import feature in the administration UI on XWiki 10.9 and later.

XWiki is a generic wiki platform. In versions starting from 1.6-milestone-1 to before 15.10.16, 16.4.6, and 16.10.1, it is possible for a user with SCRIPT right to escape from the HQL execution context and perform a blind SQL injection to execute arbitrary SQL statements on the database backend. Depending on the used database backend, the attacker may be able to not only obtain confidential information such as password hashes from the database, but also execute UPDATE/INSERT/DELETE queries. This issue has been patched in versions 16.10.1, 16.4.6 and 15.10.16. There is no known workaround, other than upgrading XWiki. The protection added to this REST API is the same as the one used to validate complete select queries, making it more consistent. However, while the script API always had this protection for complete queries, it's important to note that it's a very strict protection and some valid, but complex, queries might suddenly require the author to have programming right.

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. It's possible to execute a Velocity script without script right through the document tree. This has been patched in XWiki 14.10.7 and 15.2RC1.

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. In affected versions any user with SCRIPT right can save a document with the right of the current user which allow accessing API requiring programming right if the current user has programming right. This has been patched in XWiki 13.0. Users are advised to update to resolve this issue. The only known workaround is to limit SCRIPT access.

XWiki Platform is a generic wiki platform. Starting in version 3.0-milestone-1, it's possible to execute a script with the right of another user, provided the target user does not have programming right. The problem has been patched in XWiki 14.8-rc-1, 14.4.5, and 13.10.10. There are no known workarounds for this issue.

XWiki is a generic wiki platform. In versions starting from 4.5.1 to before 15.10.13, from 16.0.0-rc-1 to before 16.4.4, and from 16.5.0-rc-1 to before 16.8.0-rc-1, the Solr script service doesn't take dropped programming rights into account. The Solr script service that is accessible in XWiki's scripting API normally requires programming rights to be called. Due to using the wrong API for checking rights, it doesn't take the fact into account that programming rights might have been dropped by calling `$xcontext.dropPermissions()`. If some code relies on this for the safety of executing Velocity code with the wrong author context, this could allow a user with script rights to either cause a high load by indexing documents or to temporarily remove documents from the search index. This issue has been patched in versions 15.10.13, 16.4.4, and 16.8.0-rc-1.

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.

Incorrect authorization vulnerability in TCMAN's GIM v11. This vulnerability allows an unprivileged attacker to create a user and assign it many privileges by sending a POST request to /PC/frmGestionUser.aspx/updateUser.

IBM Data Risk Manager (iDNA) 2.0.6 could allow an authenticated user to escalate their privileges to administrator due to insufficient authorization checks. IBM X-Force ID: 184981.

M/Monit 3.7.4 contains a privilege escalation vulnerability that allows authenticated users to modify user permissions by manipulating the admin parameter. Attackers can send a POST request to the /api/1/admin/users/update endpoint with a crafted payload to grant administrative access to a standard user account.

OvalEdge 5.2.8.0 and earlier is affected by a Privilege Escalation vulnerability via a POST request to /user/assignuserrole via the userid and role parameters . Authentication is required with OE_ADMIN role privilege.

OvalEdge 5.2.8.0 and earlier is affected by an Account Takeover vulnerability via a POST request to /user/updatePassword via the userId and newPsw parameters. Authentication is required.

iDS6 DSSPro Digital Signage System 6.2 contains an improper access control vulnerability that allows authenticated users to elevate privileges through console JavaScript functions. Attackers can create users, modify roles and permissions, and potentially achieve full application takeover by exploiting insecure direct object references.

Rescue Dispatch Management System 1.0 is vulnerable to Incorrect Access Control via http://localhost/rdms/admin/?page=system_info.

Rubygems is a package registry used to supply software for the Ruby language ecosystem. Due to a bug in the yank action, it was possible for any RubyGems.org user to remove and replace certain gems even if that user was not authorized to do so. To be vulnerable, a gem needed: one or more dashes in its name creation within 30 days OR no updates for over 100 days At present, we believe this vulnerability has not been exploited. RubyGems.org sends an email to all gem owners when a gem version is published or yanked. We have not received any support emails from gem owners indicating that their gem has been yanked without authorization. An audit of gem changes for the last 18 months did not find any examples of this vulnerability being used in a malicious way. A deeper audit for any possible use of this exploit is ongoing, and we will update this advisory once it is complete. Using Bundler in --frozen or --deployment mode in CI and during deploys, as the Bundler team has always recommended, will guarantee that your application does not silently switch to versions created using this exploit. To audit your application history for possible past exploits, review your Gemfile.lock and look for gems whose platform changed when the version number did not change. For example, gemname-3.1.2 updating to gemname-3.1.2-java could indicate a possible abuse of this vulnerability. RubyGems.org has been patched and is no longer vulnerable to this issue as of the 5th of May 2022.

Zoho ManageEngine ServiceDesk Plus before 11134 allows an Authentication Bypass (only during SAML login).

An issue was discovered in the XCloner Backup and Restore plugin before 4.2.13 for WordPress. It gave authenticated attackers the ability to modify arbitrary files, including PHP files. Doing so would allow an attacker to achieve remote code execution. The xcloner_restore.php write_file_action could overwrite wp-config.php, for example. Alternatively, an attacker could create an exploit chain to obtain a database dump.

A vulnerability in the REST API endpoint of Cisco Data Center Network Manager (DCNM) could allow an authenticated, remote attacker with a low-privileged account to bypass authorization on the API of an affected device. The vulnerability is due to insufficient authorization of certain API functions. An attacker could exploit this vulnerability by sending a crafted request to the API using low-privileged credentials. A successful exploit could allow the attacker to perform arbitrary actions through the REST API with administrative privileges.

TOTOLINK A3002RU version 2.0.0-B20190902.1958 has a post-authentication RCE due to incorrect access control, allows attackers to bypass front-end security restrictions and execute arbitrary code.

A vulnerability has been identified in SINEMA Remote Connect Server (All versions < V3.0). The webserver could allow unauthorized actions via special urls for unpriviledged users. The settings of the UMC authorization server could be changed to add a rogue server by an attacker authenticating with unprivilege user rights.

Vulnerability in the Oracle Database component of Oracle Database Server. Supported versions that are affected are 19.27 and 23.4-23.8. Easily exploitable vulnerability allows low privileged attacker having Create Session, Create Procedure privilege with network access via Oracle Net to compromise Oracle Database. Successful attacks of this vulnerability can result in takeover of Oracle Database. CVSS 3.1 Base Score 8.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).

In SapphireIMS 5.0, it is possible to create local administrator on any client with credentials of a non-privileged user by directly accessing RemoteMgmtTaskSave (Automation Tasks) feature.

An issue was discovered in Tildeslash Monit before 5.31.0, allows remote attackers to gain escilated privlidges due to improper PAM-authorization.

Improper authorisation of regular users in ProIntegra Uptime DC software (versions below 2.0.0.33940) allows them to change passwords of all other users including administrators leading to a privilege escalation.

Broken access control in the component /admin/management/users of School Fees Management System v1.0 allows attackers to escalate privileges and perform Administrative actions, including adding and deleting user accounts.