Source
ghsa
### Impact It is possible for a remote unauthenticated user to escape from the HQL execution context and perform a blind SQL injection to execute arbitrary SQL statements on the database backend, including when "Prevent unregistered users from viewing pages, regardless of the page rights" and "Prevent unregistered users from editing pages, regardless of the page rights" options are enabled. 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. The vulnerability may be tested in a default installation of XWIki Standard Flavor, including using the official Docker containers. An example query, which leads to SQL injection with MySQL/MariaDB backend is shown below: ``` time curl "http://127.0.0.1:8080/rest/wikis/xwiki/query?q=where%20doc.name=length('a')*org.apache.logging.log4j.util.Chars.SPACE%20or%201%3C%3E%271%5C%27%27%20union%20select%20...
### Impact 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. The vulnerability may be tested in a default installation of XWIki Standard Flavor, including using the official Docker containers. For example, with a MySQL or MariaDB database, you can use the following script (which a user having SCRIPT right but not PROGRAMMING right) to get the content of the xwikistrings table (which contain all the short string fields stored in objects, including passwords): ``` {{velocity}} $services.query.hql("where 1<>'1\'' union select concat(XWS_NAME, XWS_VALUE) from xwikistrings #'").execute() {{/velocity}} ``` ### Patches This has been patched in 16.10.1, 16.4.6 and...
The path shortening function is used in pnpm： ``` export function depPathToFilename (depPath: string, maxLengthWithoutHash: number): string { let filename = depPathToFilenameUnescaped(depPath).replace(/[\\/:*?"<>|]/g, '+') if (filename.includes('(')) { filename = filename .replace(/\)$/, '') .replace(/(\)\()|\(|\)/g, '_') } if (filename.length > maxLengthWithoutHash || filename !== filename.toLowerCase() && !filename.startsWith('file+')) { return `${filename.substring(0, maxLengthWithoutHash - 27)}_${createBase32Hash(filename)}` } return filename } ``` However, it uses the md5 function as a path shortening compression function, and if a collision occurs, it will result in the same storage path for two different libraries. Although the real names are under the package name /node_modoules/, there are no version numbers for the libraries they refer to.  In t...
## Description https://github.com/vllm-project/vllm/security/advisories/GHSA-rh4j-5rhw-hr54 reported a vulnerability where loading a malicious model could result in code execution on the vllm host. The fix applied to specify `weights_only=True` to calls to `torch.load()` did not solve the problem prior to PyTorch 2.6.0. PyTorch has issued a new CVE about this problem: https://github.com/advisories/GHSA-53q9-r3pm-6pq6 This means that versions of vLLM using PyTorch before 2.6.0 are vulnerable to this problem. ## Background Knowledge When users install VLLM according to the official manual  But the version of PyTorch is specified in the requirements. txt file  So by default when the user install VLLM, it will install the PyTorch with version 2.5.1  in the tags feature. Any user with the ability of create or modify tags can inject malicious JavaScript code in the name field.
### Impact Versions 4.2.1, 4.2.2, 4.2.3, and 4.2.4 of xrpl.js were compromised and contained malicious code designed to exfiltrate private keys. If you are using one of these versions, stop immediately and rotate any private keys or secrets used with affected systems. Version 2.14.2 is also malicious, though it is less likely to lead to exploitation as it is not compatible with other 2.x versions. ### Patches Upgrade to version 4.2.5 or 2.14.3. ### Required Actions To secure funds, think carefully about whether any keys may have been compromised by this supply chain attack, and mitigate by sending funds to secure wallets, and/or rotating keys: The XRP Ledger supports key rotation: https://xrpl.org/docs/tutorials/how-tos/manage-account-settings/assign-a-regular-key-pair If any account's master key is potentially compromised, you should disable it: https://xrpl.org/docs/tutorials/how-tos/manage-account-settings/disable-master-key-pair ### References https://www.aikido.dev/blog/xrp-...
### Impact The input parameter, which consists of a file path and name, can be manipulated to return the Content-Type header with text/html if the name part ends with .html. This could allow malicious JavaScript code to be executed in the browser. For a successful attack, a malicious file needs to be uploaded beforehand. The severity of the vulnerability is mitigated by the fact that the application UI and the JPA Web API are typically accessible only to authenticated users. ### Patches The problem has been fixed in CUBA JPA Web API add-on 1.1.1. ### Workarounds A workaround for those who are unable to upgrade: [Disable Files Endpoint in CUBA Application](https://docs.jmix.io/jmix/files-vulnerabilities.html#disable-files-endpoint-in-cuba-application). ### References [Files Functionality Vulnerabilities :: Jmix Documentation](https://docs.jmix.io/jmix/files-vulnerabilities.html) Similar vulnerability in Jmix: [XSS in the /files Endpoint of the Generic REST API · Advisory · jmix...
### Impact The input parameter, which consists of a file path and name, can be manipulated to return the Content-Type header with text/html if the name part ends with .html. This could allow malicious JavaScript code to be executed in the browser. For a successful attack, a malicious file needs to be uploaded beforehand. The severity of the vulnerability is mitigated by the fact that the application UI and the generic REST API are typically accessible only to authenticated users. ### Patches The problem has been fixed in CUBA REST API add-on 7.2.7. ### Workarounds A workaround for those who are unable to upgrade: [Disable Files Endpoint in CUBA Application](https://docs.jmix.io/jmix/files-vulnerabilities.html#disable-files-endpoint-in-cuba-application). ### References [Files Functionality Vulnerabilities :: Jmix Documentation](https://docs.jmix.io/jmix/files-vulnerabilities.html) Similar vulnerability in Jmix: [XSS in the /files Endpoint of the Generic REST API · Advisory · jm...
### Impact The local file storage implementation does not restrict the size of uploaded files. An attacker could exploit this by uploading excessively large files, potentially causing the server to run out of space and return HTTP 500 error, resulting in a denial of service. The severity of the vulnerability is mitigated by the fact that the application UI and the generic REST API are typically accessible only to authenticated users. ### Patches The problem has been fixed in CUBA 7.2.23. ### Workarounds A workaround for those who are unable to upgrade: [Disable Files Endpoint in CUBA Application](https://docs.jmix.io/jmix/files-vulnerabilities.html#disable-files-endpoint-in-cuba-application). ### References [Files Functionality Vulnerabilities :: Jmix Documentation](https://docs.jmix.io/jmix/files-vulnerabilities.html) Similar vulnerability in Jmix: [DoS in the Local File Storage · Advisory · jmix-framework/jmix](https://github.com/jmix-framework/jmix/security/advisories/GHSA-...
### Impact The local file storage implementation does not restrict the size of uploaded files. An attacker could exploit this by uploading excessively large files, potentially causing the server to run out of space and return HTTP 500 error, resulting in a denial of service. The severity of the vulnerability is mitigated by the fact that the application UI and the generic REST API are typically accessible only to authenticated users. Additionally, the /files endpoint in Jmix requires specific permissions and is disabled by default. ### Patches The problem has been fixed in Jmix 1.6.2+ and 2.4.0+. ### Workarounds A workaround for those who are unable to upgrade: [Disable Files Endpoint in Jmix Application](https://docs.jmix.io/jmix/files-vulnerabilities.html#disable-files-endpoint-in-jmix-application).