XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. In affected versions any user with edit right can copy the content of a page it does not have access to by using it as template of a new page. This issue has been patched in XWiki 13.2CR1 and 12.10.6. Users are advised to update. 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. Starting with version 8.3-rc-1 and prior to versions 12.10.3 and 14.0, one can ask for any file located in the classloader using the template API and a path with ".." in it. The issue is patched in versions 14.0 and 13.10.3. There is no easy workaround for this issue.

XWiki Platform is a generic wiki platform. Starting in version 5.0-rc-1 and prior to versions 14.10.19, 15.5.4, and 15.9-rc-1, it is possible to access the hash of a password by using the diff feature of the history whenever the object storing the password is deleted. Using that vulnerability it's possible for an attacker to have access to the hash password of a user if they have rights to edit the users' page. With the default right scheme in XWiki this vulnerability is normally prevented on user profiles, except by users with Admin rights. Note that this vulnerability also impacts any extensions that might use passwords stored in xobjects: for those usecases it depends on the right of those pages. There is currently no way to be 100% sure that this vulnerability has been exploited, as an attacker with enough privilege could have deleted the revision where the xobject was deleted after rolling-back the deletion. But again, this operation requires high privileges on the target page (Admin right). A page with a user password xobject which have in its history a revision where the object has been deleted should be considered at risk and the password should be changed there. a diff, to ensure it's not coming from a password field. As another mitigation, admins should ensure that the user pages are properly protected: the edit right shouldn't be allowed for other users than Admin and owner of the profile (which is the default right). There is not much workaround possible for a privileged user other than upgrading XWiki.

org.xwiki.commons:xwiki-commons-xml is a common module used by other XWiki top level projects. Starting in version 2.7 and prior to versions 12.10.10, 13.4.4, and 13.8-rc-1, it is possible for a script to access any file accessing to the user running XWiki application server with XML External Entity Injection through the XML script service. The problem has been patched in versions 12.10.10, 13.4.4, and 13.8-rc-1. There is no easy workaround for fixing this vulnerability other than upgrading and being careful when giving Script rights.

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. A user without script/programming right can trick a user with elevated rights to edit a content with a malicious payload using a WYSIWYG editor. The user with elevated rights is not warned beforehand that they are going to edit possibly dangerous content. The payload is executed at edit time. This vulnerability has been patched in XWiki 15.10RC1.

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. The application allows anyone with view access to modify any page of the wiki by importing a crafted XAR package. The problem has been patched in XWiki 14.6RC1, 14.6 and 13.10.8. As a workaround, setting the right of the page Filter.WebHome and making sure only the main wiki administrators can view the application installed on main wiki or edit the page and apply the changed described in commit fb49b4f.

org.xwiki.platform:xwiki-platform-user-profile-ui is missing authorization to enable or disable users. Any user (logged in or not) with access to the page XWiki.XWikiUserProfileSheet can enable or disable any user profile. This might allow to a disabled user to re-enable themselves, or to an attacker to disable any user of the wiki. The problem has been patched in XWiki 13.10.7, 14.5RC1 and 14.4.2. Workarounds: The problem can be patched immediately by editing the page `XWiki.XWikiUserProfileSheet` in the wiki and by performing the changes contained in https://github.com/xwiki/xwiki-platform/commit/5be1cc0adf917bf10899c47723fa451e950271fa.

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. When a user has view but not edit right on a page in XWiki, that user can delete the page and replace it by a page with new content without having delete right. The previous version of the page is moved into the recycle bin and can be restored from there by an admin. As the user is recorded as deleter, the user would in theory also be able to view the deleted content, but this is not directly possible as rights of the previous version are transferred to the new page and thus the user still doesn't have view right on the page. It therefore doesn't seem to be possible to exploit this to gain any rights. This has been patched in XWiki 14.10.21, 15.5.5 and 15.10.6 by cancelling save operations by users when a new document shall be saved despite the document's existing already.

XWiki Platform is a generic wiki platform. In multilingual wikis, translations can be edited by any user who has edit right, circumventing the rights that are normally required for authoring translations (script right for user-scope translations, wiki admin for translations on the wiki). Starting in version 4.3-milestone-2 and prior to versions 4.10.20, 15.5.4, and 15.10-rc-1, this can be exploited for remote code execution if the translation value is not properly escaped where it is used. This has been patched in XWiki 14.10.20, 15.5.4 and 15.10RC1. As a workaround, one may restrict edit rights on documents that contain translations.

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 Remote Macros provides XWiki rendering macros that are useful when migrating content from Confluence. Prior to version 1.27.0, a user with no view rights on a page may see the content of an office attachment displayed with the view file macro. This issue has been patched in version 1.27.0.

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. Any user with edit right on any page can perform arbitrary remote code execution by adding instances of `XWiki.SearchSuggestConfig` and `XWiki.SearchSuggestSourceClass` to their user profile or any other page. This compromises the confidentiality, integrity and availability of the whole XWiki installation. This vulnerability has been patched in XWiki 14.10.21, 15.5.5 and 15.10.2.

org.xwiki.platform:xwiki-platform-oldcore is missing authorization in User#setDisabledStatus, which may allow an incorrectly authorized user with only Script rights to enable or disable a user. This operation is meant to only be available for users with admin rights. This problem has been patched in XWiki 13.10.7, 14.4.2 and 14.5RC1.

XWiki Platform is a generic wiki platform. Prior to versions 4.10.19, 15.5.4, and 15.10-rc-1, parameters of UI extensions are always interpreted as Velocity code and executed with programming rights. Any user with edit right on any document like the user's own profile can create UI extensions. This allows remote code execution and thereby impacts the confidentiality, integrity and availability of the whole XWiki installation. This vulnerability has been patched in XWiki 14.10.19, 15.5.4 and 15.9-RC1. No known workarounds are available.

XWiki Platform is a generic wiki platform. Starting in version 3.0.1 and prior to versions 4.10.20, 15.5.4, and 15.10-rc-1, remote code execution is possible via PDF export templates. This vulnerability has been patched in XWiki 14.10.20, 15.5.4 and 15.10-rc-1. If PDF templates are not typically used on the instance, an administrator can create the document `XWiki.PDFClass` and block its edition, after making sure that it does not contain a `style` attribute. Otherwise, there are no known workarounds aside from upgrading.

XWiki Platform is a generic wiki platform. Starting in version 6.4-milestone-1 and prior to versions 4.10.19, 15.5.4, and 15.10-rc-1, any user who can edit any page like their profile can create a custom skin with a template override that is executed with programming right, thus allowing remote code execution. This has been patched in XWiki 14.10.19, 15.5.4 and 15.10RC1. No known workarounds are available except for upgrading.

The XWiki licensor application, which manages and enforce application licenses for paid extensions, includes the document `Licenses.Code.LicenseJSON` that provides information for admins regarding active licenses. This document is public and thus exposes this information publicly. The information includes the instance's id as well as first and last name and email of the license owner. This is a leak of information that isn't supposed to be public. The instance id allows associating data on the active installs data with the concrete XWiki instance. Active installs assures that "there's no way to find who's having a given UUID" (referring to the instance id). Further, the information who the license owner is and information about the obtained licenses can be used for targeted phishing attacks. Also, while user information is normally public, email addresses might only be displayed obfuscated, depending on the configuration. This has been fixed in Application Licensing 1.24.2. There are no known workarounds besides upgrading.

XWiki Platform is a generic wiki platform. The REST API exposes the history of any page in XWiki of which the attacker knows the name. The exposed information includes for each modification of the page the time of the modification, the version number, the author of the modification (both username and displayed name) and the version comment. This information is exposed regardless of the rights setup, and even when the wiki is configured to be fully private. On a private wiki, this can be tested by accessing /xwiki/rest/wikis/xwiki/spaces/Main/pages/WebHome/history, if this shows the history of the main page then the installation is vulnerable. This has been patched in XWiki 15.10.9 and XWiki 16.3.0RC1.

XWiki is a generic wiki platform. In versions starting from 1.8.1 to before 14.10.22, from 15.0-rc-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.7.0, anyone can access the metadata of any attachment in the wiki using the wiki attachment REST endpoint. There is no filtering for the results depending on current user rights, meaning an unauthenticated user could exploit this even in a private wiki. This issue has been patched in versions 14.10.22, 15.10.12, 16.4.3, and 16.7.0.

XWiki is a generic wiki platform. In versions starting from 15.3-rc-1 to before 15.10.14, from 16.0.0-rc-1 to before 16.4.6, and from 16.5.0-rc-1 to before 16.10.0-rc-1, a user who can access pages located in the XWiki space (by default, anyone) can access the page XWiki.Authentication.Administration and (unless an authenticator is set in xwiki.cfg) switch to another installed authenticator. Note that, by default, there is only one authenticator available (Standard XWiki Authenticator). So, if no authenticator extension was installed, it's not really possible to do anything for an attacker. Also, in most cases, if an SSO authenticator is installed and utilized (like OIDC or LDAP for example), the worst an attacker can do is break authentication by switching back to the standard authenticator (that's because it's impossible to login to a user which does not have a stored password, and that's usually what SSO authenticator produce). This issue has been patched in versions 15.10.14, 16.4.6, and 16.10.0-rc-1.

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 Platform is a generic wiki platform offering runtime services for applications built on top of it. It is possible in XWiki to execute Velocity code without having script right by creating an XClass with a property of type "TextArea" and content type "VelocityCode" or "VelocityWiki". For the former, the syntax of the document needs to be set the `xwiki/1.0` (this syntax doesn't need to be installed). In both cases, when adding the property to an object, the Velocity code is executed regardless of the rights of the author of the property (edit right is still required, though). In both cases, the code is executed with the correct context author so no privileged APIs can be accessed. However, Velocity still grants access to otherwise inaccessible data and APIs that could allow further privilege escalation. At least for "VelocityCode", this behavior is most likely very old but only since XWiki 7.2, script right is a separate right, before that version all users were allowed to execute Velocity and thus this was expected and not a security issue. This has been patched in XWiki 14.10.10 and 15.4 RC1. Users are advised to upgrade. There are no known workarounds.

XWiki Platform is a generic wiki platform. Starting in version 2.3 and prior to versions 15.10.9, 16.3.0, any user with script rights can perform arbitrary remote code execution by adding instances of `XWiki.ConfigurableClass` to any page. This compromises the confidentiality, integrity and availability of the whole XWiki installation. This has been patched in XWiki 15.10.9 and 16.3.0. No known workarounds are available except upgrading.

XWiki Platform is a generic wiki platform. Starting in version 1.2-milestone-2 and prior to versions 15.10.9 and 16.3.0, any user with an account on the main wiki could run scheduling operations on subwikis. To reproduce, as a user on the main wiki without any special right, view the document `Scheduler.WebHome` in a subwiki. Then, click on any operation (*e.g.,* Trigger) on any job. If the operation is successful, then the instance is vulnerable. This has been patched in XWiki 15.10.9 and 16.3.0. As a workaround, those who have subwikis where the Job Scheduler is enabled can edit the objects on `Scheduler.WebPreferences` to match the patch.

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 is a generic wiki platform. In versions starting from 15.9-rc-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, when a user with programming rights edits a document in XWiki that was last edited by a user without programming rights and contains an XWiki.ComponentClass, there is no warning that this will grant programming rights to this object. An attacker who created such a malicious object could use this to gain programming rights on the wiki. For this, the attacker needs to have edit rights on at least one page to place this object and then get an admin user to edit that document. 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 offering runtime services for applications built on top of it. NOTE: The Realtime WYSIWYG Editor extension was **experimental**, and thus **not recommended**, in the versions affected by this vulnerability. It has become enabled by default, and thus recommended, starting with XWiki 16.9.0. A user with only **edit right** can join a realtime editing session where others, that where already there or that may join later, have **script** or **programming** access rights. This user can then insert **script rendering macros** that are executed for those users in the realtime session that have script or programming rights. The inserted scripts can be used to gain more access rights. This vulnerability has been patched in XWiki 15.10.2, 16.4.1 and 16.6.0-rc-1. Users are advised to upgrade. Users unable to upgrade may either disable the realtime WYSIWYG editing by disabling the ``xwiki-realtime`` CKEditor plugin from the WYSIWYG editor administration section or uninstall the Realtime WYSIWYG Editorextension (org.xwiki.platform:xwiki-platform-realtime-wysiwyg-ui).

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. Starting with the introduction of attachment move support in version 14.0-rc-1 and prior to versions 14.4.8, 14.10.4, and 15.0-rc-1, an attacker with edit access on any document (can be the user profile which is editable by default) can move any attachment of any other document to this attacker-controlled document. This allows the attacker to access and possibly publish any attachment of which the name is known, regardless if the attacker has view or edit rights on the source document of this attachment. Further, the attachment is deleted from the source document. This vulnerability has been patched in XWiki 14.4.8, 14.10.4, and 15.0 RC1. There is no workaround apart from upgrading to a fixed version.

SAP's HCM Travel Management Fiori Apps V2, version - 608, does not perform proper authorization check, allowing an authenticated but unauthorized attacker to read personnel numbers of employees, resulting in escalation of privileges. However, the attacker can only read some information like last name, first name of the employees, so there is some loss of confidential information, Integrity and Availability are not impacted.

A missing permission check in Jenkins Alauda DevOps Pipeline Plugin 2.3.2 and earlier allows attackers with Overall/Read permission to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins.

The SEUR Oficial WordPress plugin before 1.7.2 creates a PHP file with a random name when installed, even though it is used for support purposes, it allows to download any file from the web server without restriction after knowing the URL and a password than an administrator can see in the plugin settings page.

In the Ninja Forms Contact Form WordPress plugin before 3.4.34.1, low-level users, such as subscribers, were able to trigger the action, wp_ajax_nf_oauth, and retrieve the connection url needed to establish a connection. They could also retrieve the client_id for an already established OAuth connection.

The Insert Pages WordPress plugin before 3.7.0 allows users with a role as low as Contributor to access content and metadata from arbitrary posts/pages regardless of their author and status (ie private), using a shortcode. Password protected posts/pages are not affected by such issue.

A missing permission check in Jenkins Team Concert Plugin 1.3.0 and earlier allows attackers with Overall/Read permission to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins.

The Theme Editor WordPress plugin before 2.6 did not validate the GET file parameter before passing it to the download_file() function, allowing administrators to download arbitrary files on the web server, such as /etc/passwd

Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Gallagher Command Centre Server allows OSDP key material to be exposed to Command Centre Operators. This issue affects: Gallagher Command Centre 8.40 versions prior to 8.40.1888 (MR3); 8.30 versions prior to 8.30.1359 (MR3).

A missing permission check in Jenkins Team Concert Plugin 1.3.0 and earlier in form-related methods allowed users with Overall/Read access to enumerate credentials ID of credentials stored in Jenkins.

The direct_mail (aka Direct Mail) extension through 5.2.2 for TYPO3 has a missing access check in the backend module, allowing a user (with restricted permissions to the fe_users table) to view and export data of frontend users who are subscribed to a newsletter.

A missing permission check in Jenkins Alauda Kubernetes Suport Plugin 2.3.0 and earlier allows attackers with Overall/Read permission to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing the Kubernetes service account token or credentials stored in Jenkins.

An issue was discovered in the Infosysta "In-App & Desktop Notifications" app before 1.6.14_J8 for Jira. It is possible to obtain a list of all Jira projects (with authentication as a Jira user, but without authorization for specific projects) via the plugins/servlet/nfj/NotificationSettings URI.

The Atlassian Troubleshooting and Support Tools plugin prior to version 1.17.2 allows an unprivileged user to initiate periodic log scans and send the results to a user-specified email address due to a missing authorization check. The email message may contain configuration information about the application that the plugin is installed into. A vulnerable version of the plugin is included with Bitbucket Server / Data Center before 6.6.0, Confluence Server / Data Center before 7.0.1, Jira Server / Data Center before 8.3.2, Crowd / Crowd Data Center before 3.6.0, Fisheye before 4.7.2, Crucible before 4.7.2, and Bamboo before 6.10.2.

A CWE-552: Files or Directories Accessible to External Parties vulnerability exists in Easergy T300 with firmware V2.7.1 and older that could expose files or directory content when access from an attacker is not restricted or incorrectly restricted.

SAP Banking Services (Generic Market Data) does not perform necessary authorization checks for an authenticated user, resulting in escalation of privileges. An unauthorized User is allowed to display restricted Business Partner Generic Market Data (GMD), due to improper authorization check.

An information disclosure vulnerability in GitLab EE versions 13.10 and later allowed a user to read project details

Jenkins Cloud Statistics Plugin 0.26 and earlier does not perform a permission check in an HTTP endpoint, allowing attackers with Overall/Read permission and knowledge of random activity IDs to view related provisioning exception error messages.

Jenkins CloudBees AWS Credentials Plugin 1.28 and earlier does not perform a permission check in a helper method for HTTP endpoints, allowing attackers with Overall/Read permission to enumerate credentials IDs of AWS credentials stored in Jenkins in some circumstances.

In Rancher 1 and 2 through 2.2.3, unprivileged users (if allowed to deploy nodes) can gain admin access to the Rancher management plane because node driver options intentionally allow posting certain data to the cloud. The problem is that a user could choose to post a sensitive file such as /root/.kube/config or /var/lib/rancher/management-state/cred/kubeconfig-system.yaml.

A missing permission check in Jenkins Team Foundation Server Plugin 5.157.1 and earlier allows attackers with Overall/Read permission to enumerate credentials ID of credentials stored in Jenkins.

Inteno EG200 EG200-WU7P1U_ADAMO3.16.4-190226_1650 routers have a JUCI ACL misconfiguration that allows the "user" account to extract the 3DES key via JSON commands to ubus. The 3DES key is used to decrypt the provisioning file provided by Adamo Telecom on a public URL via cleartext HTTP.

MediaWiki through 1.32.1 has Incorrect Access Control. Suppressed username or log in Special:EditTags are exposed. Fixed in 1.32.2, 1.31.2, 1.30.2 and 1.27.6.