The XWiki Admin Tools Application provides tools to help the administration of XWiki. Starting in version 4.4 and prior to version 4.5.1, a cross site request forgery vulnerability in the admin tool for executing shell commands on the server allows an attacker to execute arbitrary shell commands by tricking an admin into loading the URL with the shell command. A very simple possibility for an attack are comments. When the attacker can leave a comment on any page in the wiki it is sufficient to include an image with an URL like `/xwiki/bin/view/Admin/RunShellCommand?command=touch%20/tmp/attacked` in the comment. When an admin views the comment, the file `/tmp/attacked` will be created on the server. The output of the command is also vulnerable to XWiki syntax injection which offers a simple way to execute Groovy in the context of the XWiki installation and thus an even easier way to compromise the integrity and confidentiality of the whole XWiki installation. This has been patched by adding a form token check in version 4.5.1 of the admin tools. Some workarounds are available. The patch can be applied manually to the affected wiki pages. Alternatively, the document `Admin.RunShellCommand` can also be deleted if the possibility to run shell commands isn't needed.

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. In affected versions it's possible to execute a content with the right of any user via a crafted URL. A user must have `programming` privileges in order to exploit this vulnerability. This issue has been patched in XWiki 14.10.7 and 15.2RC1. Users are advised to upgrade. There are no known workarounds for for this vulnerability.

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. In affected versions of `org.xwiki.platform:xwiki-platform-logging-ui` it is possible to trick a user with programming rights into visiting a constructed url where e.g., by embedding an image with this URL in a document that is viewed by a user with programming rights which will evaluate an expression in the constructed url and execute it. This issue has been addressed in versions 13.10.11, 14.4.7, and 14.10. Users are advised to upgrade. There are no known workarounds for this vulnerability.

XWiki Platform is a generic wiki platform. Starting in 2.3 and prior to versions 14.10.15, 15.5.2, and 15.7-rc-1, there is a reflected XSS or also direct remote code execution vulnerability in the code for displaying configurable admin sections. The code that can be passed through a URL parameter is only executed when the user who is visiting the crafted URL has edit right on at least one configuration section. While any user of the wiki could easily create such a section, this vulnerability doesn't require the attacker to have an account or any access on the wiki. It is sufficient to trick any admin user of the XWiki installation to visit the crafted URL. This vulnerability allows full remote code execution with programming rights and thus impacts the confidentiality, integrity and availability of the whole XWiki installation. This has been fixed in XWiki 14.10.15, 15.5.2 and 15.7RC1. The patch can be manually applied to the document `XWiki.ConfigurableClass`.

CKEditor Integration UI adds support for editing wiki pages using CKEditor. Prior to versions 1.64.3,t he `CKEditor.HTMLConverter` document lacked a protection against Cross-Site Request Forgery (CSRF), allowing to execute macros with the rights of the current user. If a privileged user with programming rights was tricked into executing a GET request to this document with certain parameters (e.g., via an image with a corresponding URL embedded in a comment or via a redirect), this would allow arbitrary remote code execution and the attacker could gain rights, access private information or impact the availability of the wiki. The issue has been patched in the CKEditor Integration version 1.64.3. This has also been patched in the version of the CKEditor integration that is bundled starting with XWiki 14.6 RC1. There are no known workarounds for this other than upgrading the CKEditor integration to a fixed version.

XWiki Platform is a generic wiki platform. Starting in version 13.9-rc-1 and prior to versions 4.10.19, 15.5.4, and 15.10-rc-1, when the realtime editor is installed in XWiki, it allows arbitrary remote code execution with the interaction of an admin user with programming right. More precisely, by getting an admin user to either visit a crafted URL or to view an image with this URL that could be in a comment, the attacker can get the admin to execute arbitrary XWiki syntax including scripting macros with Groovy or Python code. This compromises 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. As a workaround, one may update `RTFrontend.ConvertHTML` manually with the patch. This will, however, break some synchronization processes in the realtime editor, so upgrading should be the preferred way on installations where this editor is used.

XWiki Platform is a generic wiki platform. Starting in version 3.1 and prior to versions 4.10.19, 15.5.4, and 15.10-rc-1, by creating a document with a special crafted documented reference and an `XWiki.SchedulerJobClass` XObject, it is possible to execute arbitrary code on the server whenever an admin visits the scheduler page or the scheduler page is referenced, e.g., via an image in a comment on a page in the wiki. The vulnerability has been fixed in XWiki 14.10.19, 15.5.5, and 15.9. As a workaround, apply the patch manually by modifying the `Scheduler.WebHome` page.

XWiki Platform is a generic wiki platform. The rendered diff in XWiki embeds images to be able to compare the contents and not display a difference for an actually unchanged image. For this, XWiki requests all embedded images on the server side. These requests are also sent for images from other domains and include all cookies that were sent in the original request to ensure that images with restricted view right can be compared. Starting in version 11.10.1 and prior to versions 14.10.15, 15.5.1, and 15.6, this allows an attacker to steal login and session cookies that allow impersonating the current user who views the diff. The attack can be triggered with an image that references the rendered diff, thus making it easy to trigger. Apart from stealing login cookies, this also allows server-side request forgery (the result of any successful request is returned in the image's source) and viewing protected content as once a resource is cached, it is returned for all users. As only successful requests are cached, the cache will be filled by the first user who is allowed to access the resource. This has been patched in XWiki 14.10.15, 15.5.1 and 15.6. The rendered diff now only downloads images from trusted domains. Further, cookies are only sent when the image's domain is the same the requested domain. The cache has been changed to be specific for each user. As a workaround, the image embedding feature can be disabled by deleting `xwiki-platform-diff-xml-<version>.jar` in `WEB-INF/lib/`.

XWiki Platform is vulnerable to Cross-Site Request Forgery (CSRF) that may allow attackers to delete or rename tags without needing any confirmation. The problem has been patched in XWiki 13.10.7, 14.4.1 and 14.5RC1. Workarounds: It's possible to patch existing instances directly by editing the page Main.Tags and add this kind of check, in the code for renaming and for deleting: ``` #if (!$services.csrf.isTokenValid($request.get('form_token'))) #set ($discard = $response.sendError(401, "Wrong CSRF token")) #end ```

XWiki Platform is a generic wiki platform. Prior to versions 13.10.5 and 14.3, it is possible to perform a Cross-Site Request Forgery (CSRF) attack for adding or removing tags on XWiki pages. The problem has been patched in XWiki 13.10.5 and 14.3. As a workaround, one may locally modify the `documentTags.vm` template in one's filesystem, to apply the changes exposed there.

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. The create action is vulnerable to a CSRF attack, allowing script and thus remote code execution when targeting a user with script/programming right, thus compromising the confidentiality, integrity and availability of the whole XWiki installation. When a user with script right views this image and a log message `ERROR foo - Script executed!` appears in the log, the XWiki installation is vulnerable. This has been patched in XWiki 14.10.9 and 15.4RC1 by requiring a CSRF token for the actual page creation.

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. The REST API allows executing all actions via POST requests and accepts `text/plain`, `multipart/form-data` or `application/www-form-urlencoded` as content types which can be sent via regular HTML forms, thus allowing cross-site request forgery. With the interaction of a user with programming rights, this allows remote code execution through script macros and thus impacts the integrity, availability and confidentiality of the whole XWiki installation. For regular cookie-based authentication, the vulnerability is mitigated by SameSite cookie restrictions but as of March 2023, these are not enabled by default in Firefox and Safari. The vulnerability has been patched in XWiki 14.10.8 and 15.2 by requiring a CSRF token header for certain request types that are susceptible to CSRF attacks.

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. A cross-site request forgery vulnerability exists in versions prior to 12.10.5, and in versions 13.0 through 13.1. It's possible for forge an URL that, when accessed by an admin, will reset the password of any user in XWiki. The problem has been patched in XWiki 12.10.5 and 13.2RC1. As a workaround, it is possible to apply the patch manually by modifying the `register_macros.vm` template.

### 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 Platform is a generic wiki platform. Starting in version 3.1 and prior to versions 4.10.20, 15.5.4, and 15.10-rc-1, it is possible to schedule/trigger/unschedule existing jobs by having an admin visit the Job Scheduler page through a predictable URL, for example by embedding such an URL in any content as an image. The vulnerability has been fixed in XWiki 14.10.19, 15.5.5, and 15.9. As a workaround, manually apply the patch by modifying the `Scheduler.WebHome` page.

Cross-site request forgery (CSRF) vulnerability in pixelpost 1.7.3 could allow remote attackers to change the admin password.

A vulnerability classified as problematic has been found in OpenACS bug-tracker. Affected is an unknown function of the file lib/nav-bar.adp of the component Search. The manipulation leads to cross-site request forgery. It is possible to launch the attack remotely. The name of the patch is aee43e5714cd8b697355ec3bf83eefee176d3fc3. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-217440.

ClinicCases 7.3.3 is affected by Cross-Site Request Forgery (CSRF). A successful attack would consist of an authenticated user following a malicious link, resulting in arbitrary actions being carried out with the privilege level of the targeted user. This can be exploited to create a secondary administrator account for the attacker.

VMware vRealize Operations (vROps) contains a CSRF bypass vulnerability. A malicious user could execute actions on the vROps platform on behalf of the authenticated victim user.

Yuba u5cms v8.3.5 was discovered to contain a Cross-Site Request Forgery (CSRF) via the component savepage.php. This vulnerability allows attackers to execute arbitrary code.

your_spotify is an open source, self hosted Spotify tracking dashboard. YourSpotify versions < 1.9.0 do not protect the API and login flow against Cross-Site Request Forgery (CSRF). Attackers can use this to execute CSRF attacks on victims, allowing them to retrieve, modify or delete data on the affected YourSpotify instance. Using repeated CSRF attacks, it is also possible to create a new user on the victim instance and promote the new user to instance administrator if a legitimate administrator visits a website prepared by an attacker. Note: Real-world exploitability of this vulnerability depends on the browser version and browser settings in use by the victim. This issue has been addressed in version 1.9.0. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Cross Site Request Forgery vulnerability in FUEL-CMS 1.4.13 allows remote attackers to run arbitrary code via post ID to /users/delete/2.

firefly-iii is vulnerable to Cross-Site Request Forgery (CSRF)

CSRF vulnerability in Smoothwall Express 3.

Cross-Site Request Forgery (CSRF) vulnerability in bytesforall Atahualpa.This issue affects Atahualpa: from n/a through 3.7.24.

Remote Cross-site Request forgery (CSRF) potential has been identified in UCMBD Server version DDM Content Pack V 10.20, 10.21, 10.22, 10.22 CUP7, 10.30, 10.31, 10.32, 10.33, 10.33 CUP2, 11.0 and CMS Server version 2018.05 BACKGROUND which could allow for remote unsafe deserialization and cross-site request forgery (CSRF).

CSRF tokens are generated using math/rand, which is not a cryptographically secure random number generator, allowing an attacker to predict values and bypass CSRF protections with relatively few requests.

An issue was discovered in Western Bridge Cobub Razor 0.7.2. Authentication is not required for /index.php?/manage/channel/modifychannel. For example, with a crafted channel name, stored XSS is triggered during a later /index.php?/manage/channel request by an admin.

A vulnerability in the web-based management interface of Cisco Application Policy Infrastructure Controller (APIC) and Cisco Cloud Network Controller, formerly Cisco Cloud APIC, could allow an unauthenticated, remote attacker to conduct a cross-site request forgery (CSRF) attack on an affected system. This vulnerability is due to insufficient CSRF protections for the web-based management interface on an affected system. An attacker could exploit this vulnerability by persuading a user of the interface to click a malicious link. A successful exploit could allow the attacker to perform arbitrary actions with the privilege level of the affected user. If the affected user has administrative privileges, these actions could include modifying the system configuration and creating new privileged accounts.

A cross-site request forgery (CSRF) vulnerability exists in Western Bridge Cobub Razor 0.7.2 via /index.php?/user/createNewUser/, resulting in account creation.

Apache OFBiz 17.12.01 is vulnerable to some CSRF attacks.

better_errors is an open source replacement for the standard Rails error page with more information rich error pages. It is also usable outside of Rails in any Rack app as Rack middleware. better_errors prior to 2.8.0 did not implement CSRF protection for its internal requests. It also did not enforce the correct "Content-Type" header for these requests, which allowed a cross-origin "simple request" to be made without CORS protection. These together left an application with better_errors enabled open to cross-origin attacks. As a developer tool, better_errors documentation strongly recommends addition only to the `development` bundle group, so this vulnerability should only affect development environments. Please ensure that your project limits better_errors to the `development` group (or the non-Rails equivalent). Starting with release 2.8.x, CSRF protection is enforced. It is recommended that you upgrade to the latest release, or minimally to "~> 2.8.3". There are no known workarounds to mitigate the risk of using older releases of better_errors.

Due to insufficient CSRF protection, SAP BusinessObjects Business Intelligence Platform (Monitoring Application), before versions 4.1, 4.2 and 4.3, may lead to an authenticated user to send unintended request to the web server, leading to Cross Site Request Forgery.

An attacker could send a malicious link to an authenticated operator, which may allow remote attackers to perform actions with the permissions of the user on the Sunny WebBox Firmware Version 1.6 and prior. This device uses IP addresses to maintain communication after a successful login, which would increase the ease of exploitation.

A potential Cross-Site Request Forgery (CSRF) vulnerability has been identified in ArcSight Management Center (ArcMC) in all versions prior to 2.81. This vulnerability could be exploited to allow for Cross-Site Request Forgery (CSRF).

Remote Cross-site Request forgery (CSRF) potential has been identified in UCMBD Browser version 4.10, 4.11, 4.12, 4.13, 4.14, 4.15, 4.15.1 which could allow for remote unsafe deserialization and cross-site request forgery (CSRF).

The kento-post-view-counter plugin through 2.8 for WordPress has wp-admin/admin.php?page=kentopvc_settings CSRF.

The fluid-responsive-slideshow plugin before 2.2.7 for WordPress has frs_save CSRF with resultant stored XSS.

The fossura-tag-miner plugin before 1.1.5 for WordPress has CSRF.

The PageLines theme 1.1.4 for WordPress has wp-admin/admin-post.php?page=pagelines CSRF.

Tiki Wiki CMS Groupware 5.2 has CSRF

Yoga Class Registration System version 1.0 allows an administrator to execute commands on the server. This is possible because the application does not correctly validate the thumbnails of the classes uploaded by the administrators.

Gambio GX before 4.0.1.0 allows admin/admin.php CSRF.

The WP Fastest Cache WordPress plugin before 1.1.5 does not have CSRF check in an AJAX action, and does not validate user input before using it in the wp_remote_get() function, leading to a Blind SSRF issue

Cross-site request forgery (CSRF) vulnerability on NTT EAST Hikari Denwa routers with firmware PR-400MI, RT-400MI, and RV-440MI 07.00.1006 and earlier and NTT WEST Hikari Denwa routers with firmware PR-400MI, RT-400MI, and RV-440MI 07.00.1005 and earlier allows remote attackers to hijack the authentication of arbitrary users.

The tagDiv Cloud Library WordPress plugin before 2.7 does not have authorisation and CSRF in an AJAX action accessible to both unauthenticated and authenticated users, allowing unauthenticated users to change arbitrary user metadata, which could lead to privilege escalation by setting themselves as an admin of the blog.

The leenkme plugin before 2.6.0 for WordPress has wp-admin/admin.php?page=leenkme_facebook CSRF.

The ad-inserter plugin before 1.5.3 for WordPress has CSRF with resultant XSS via wp-admin/options-general.php?page=ad-inserter.php.

Stupid Simple CMS v1.2.4 was discovered to contain a Cross-Site Request Forgery (CSRF) via /update-article.php.

edx-platform before 2016-06-06 allows CSRF.