ghsa

### Impact A CSRF vulnerability in the query on XWiki tool allows executing arbitrary database queries on the database of the XWiki installation. Among other things, this allows modifying and deleting all data of the wiki. This could be both used to damage the wiki and to create an account with elevated privileges for the attacker, thus impacting the confidentiality, integrity and availability of the whole XWiki instance. A possible attack vector are comments on the wiki, by embedding an image with wiki syntax like `[[image:path:/xwiki/bin/view/Admin/QueryOnXWiki?query=DELETE%20FROM%20xwikidoc]]`, all documents would be deleted from the database when an admin user views this comment. ### Patches This has been patched in Admin Tools Application 4.5.1 by adding form token checks. ### Workarounds The [patch](https://github.com/xwiki-contrib/application-admintools/commit/45298b4fbcafba6914537dcdd798a1e1385f9e46) can also be applied manually to the affected pages. Alternatively, if the qu...

### Impact 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. ### Patches This has been patched by adding a form token check in version 4.5.1 of the admin tools. ### Workarounds The [patch](https://github.com/xwik...

### Impact The Solr-based search suggestion provider that also duplicates as generic JavaScript API for search results in XWiki exposes the content of all documents of all wikis to anybody who has access to it, by default it is public. This exposes all information stored in the wiki (but not some protected information like password hashes). While there is a right check normally, the right check can be circumvented by explicitly requesting fields from Solr that don't include the data for the right check. This can be reproduced by opening `<xwiki-server>/xwiki/bin/get/XWiki/SuggestSolrService?outputSyntax=plain&media=json&nb=1000&query=q%3D*%3A*%0Aq.op%3DAND%0Afq%3Dtype%3ADOCUMENT%0Afl%3Dtitle_%2C+reference%2C+links%2C+doccontentraw_%2C+objcontent__&input=+` where `<xwiki-server>` is the URL of the XWiki installation. If this displays any results, the wiki is vulnerable. ### Patches This has been fixed in XWiki 15.6RC1, 15.5.1 and 14.10.15 by not listing documents whose rights cannot be...

### Impact 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. 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. More concretely, to reproduce, add 101 different images with references to the attacker's server. In any place add an image with a reference to `/xwiki/bin/view/Image%20Cookie%20Test/?xpage=changes&rev1=1.1&rev2=2.1&include=renderedChanges` where `Image%20Cookie%20Test` needs to be replaced by the path to the document with the images and the two revisions should ma...

### Summary The fast-jwt library does not properly prevent JWT algorithm confusion for all public key types. ### Details The 'publicKeyPemMatcher' in 'fast-jwt/src/crypto.js' does not properly match all common PEM formats for public keys. To exploit this vulnerability, an attacker needs to craft a malicious JWT token containing the HS256 algorithm, signed with the public RSA key of the victim application. This attack will only work if the victim application utilizes a public key containing the `BEGIN RSA PUBLIC KEY` header. ### PoC Take a server running the following code: ```javascript const express = require('express'); const { createSigner, createVerifier } = require('fast-jwt') const fs = require('fs'); const path = require('path'); const app = express(); const port = 3000; // Load the keys from the file const publicKeyPath = path.join(__dirname, 'public_key.pem'); const publicKey = fs.readFileSync(publicKeyPath, 'utf8'); const privateKeyPath = path.join(__dirname, 'key'); cons...

Apache Software Foundation Apache Submarine has a bug when serializing against yaml. The bug is caused by snakeyaml https://nvd.nist.gov/vuln/detail/CVE-2022-1471 . Apache Submarine uses JAXRS to define REST endpoints. In order to handle YAML requests (using application/yaml content-type), it defines a YamlEntityProvider entity provider that will process all incoming YAML requests. In order to unmarshal the request, the readFrom method is invoked, passing the entityStream containing the user-supplied data in `submarine-server/server-core/src/main/java/org/apache/submarine/server/utils/YamlUtils.java`. We have now fixed this issue in the new version by replacing to `jackson-dataformat-yaml`. This issue affects Apache Submarine: from 0.7.0 before 0.8.0. Users are recommended to upgrade to version 0.8.0, which fixes this issue. If using the version smaller than 0.8.0 and not want to upgrade, you can try cherry-pick PR https://github.com/apache/submarine/pull/1054 and rebuild the ...

A cleverly devised username might bypass LDAP authentication checks. In LDAP-authenticated Derby installations, this could let an attacker fill up the disk by creating junk Derby databases. In LDAP-authenticated Derby installations, this could also allow the attacker to execute malware which was visible to and executable by the account which booted the Derby server. In LDAP-protected databases which weren't also protected by SQL GRANT/REVOKE authorization, this vulnerability could also let an attacker view and corrupt sensitive data and run sensitive database functions and procedures. Mitigation: Users should upgrade to Java 21 and Derby 10.17.1.0. Alternatively, users who wish to remain on older Java versions should build their own Derby distribution from one of the release families to which the fix was backported: 10.16, 10.15, and 10.14. Those are the releases which correspond, respectively, with Java LTS versions 17, 11, and 8.

OpenCRX version 5.2.0 is vulnerable to HTML injection via Activity Saved Search Creation.

OpenCRX version 5.2.0 is vulnerable to HTML injection via the Category Creation Name Field.

OpenCRX version 5.2.0 is vulnerable to HTML injection via the Product Configuration Name Field.