ghsa

Cross-site scripting (XSS) vulnerability in the Web Content Display widget's article selector in Liferay Liferay Portal 7.4.3.50, and Liferay DXP 7.4 update 50 allows remote attackers to inject arbitrary web script or HTML via a crafted payload injected into a web content article's `Title` field.

Cross-site scripting (XSS) vulnerability in IFrame type Remote Apps in Liferay Portal 7.4.0 through 7.4.3.30, and Liferay DXP 7.4 before update 31 allows remote attackers to inject arbitrary web script or HTML via the Remote App's IFrame URL.

A vulnerability, which was classified as problematic, was found in SiteServer CMS up to 7.2.1. Affected is an unknown function of the file `/api/stl/actions/search`. The manipulation of the argument ajaxDivId leads to cross site scripting. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. VDB-229818 is the identifier assigned to this vulnerability.

## Summary Sqlite-jdbc addresses a remote code execution vulnerability via JDBC URL. ## Impacted versions : 3.6.14.1-3.41.2.1 ## References https://github.com/xerial/sqlite-jdbc/releases/tag/3.41.2.2

### Impact A specially crafted Socket.IO packet can trigger an uncaught exception on the Socket.IO server, thus killing the Node.js process. ``` TypeError: Cannot convert object to primitive value at Socket.emit (node:events:507:25) at .../node_modules/socket.io/lib/socket.js:531:14 ``` ### Patches A fix has been released today (2023/05/22): - https://github.com/socketio/socket.io-parser/commit/3b78117bf6ba7e99d7a5cfc1ba54d0477554a7f3, included in `socket.io-parser@4.2.3` - https://github.com/socketio/socket.io-parser/commit/2dc3c92622dad113b8676be06f23b1ed46b02ced, included in `socket.io-parser@3.4.3` | `socket.io` version | `socket.io-parser` version | Needs minor update? | |---------------------|---------------------------------------------------------------------------------------------------------|--------------------------------------| | `4.5.2...latest` | `~4.2.0`...

An important security issue affects a range of versions of Openfire, the cross-platform real-time collaboration server based on the XMPP protocol that is created by the Ignite Realtime community. ### Impact Openfire's administrative console (the Admin Console), a web-based application, was found to be vulnerable to a path traversal attack via the setup environment. This permitted an unauthenticated user to use the unauthenticated Openfire Setup Environment in an already configured Openfire environment to access restricted pages in the Openfire Admin Console reserved for administrative users. ### Cause Path traversal protections were already in place to protect against exactly this kind of attack, but didn’t defend against certain non-standard URL encoding for UTF-16 characters, that were not supported by the embedded webserver that was in use at the time. A later upgrade of the embedded webserver included support for non-standard URL encoding of UTF-16 characters. The path traversa...

Skyscreamer Open Source Nevado JMS v1.3.2 does not perform security checks when receiving messages. This allows attackers to execute arbitrary commands via supplying crafted data.

### Impact Since Requests v2.3.0, Requests has been vulnerable to potentially leaking `Proxy-Authorization` headers to destination servers, specifically during redirects to an HTTPS origin. This is a product of how `rebuild_proxies` is used to recompute and [reattach the `Proxy-Authorization` header](https://github.com/psf/requests/blob/f2629e9e3c7ce3c3c8c025bcd8db551101cbc773/requests/sessions.py#L319-L328) to requests when redirected. Note this behavior has _only_ been observed to affect proxied requests when credentials are supplied in the URL user information component (e.g. `https://username:password@proxy:8080`). **Current vulnerable behavior(s):** 1. HTTP → HTTPS: **leak** 2. HTTPS → HTTP: **no leak** 3. HTTPS → HTTPS: **leak** 4. HTTP → HTTP: **no leak** For HTTP connections sent through the proxy, the proxy will identify the header in the request itself and remove it prior to forwarding to the destination server. However when sent over HTTPS, the `Proxy-Authorization` head...

### Summary Unrestricted file extension lead to a potential Remote Code Execution (Authenticated, ALLOW_ADMIN_CHANGES=true) ### Details #### Vulnerability Cause : If the name parameter value is not empty string('') in the View.php's doesTemplateExist() -> resolveTemplate() -> _resolveTemplateInternal() -> _resolveTemplate() function, it returns directly without extension verification, so that arbitrary extension files are rendered as twig templates (even if they are not extensions set in defaultTemplateExtensions = ['html', 'twig']) ```php /** * Searches for a template files, and returns the first match if there is one. * * @param string $basePath The base path to be looking in. * @param string $name The name of the template to be looking for. * @param bool $publicOnly Whether to only look for public templates (template paths that don’t start with the private template trigger). * @return string|null The matching file path, or `null`. */ priv...

### Impact in contracts with at least one regular nonpayable function, due to the callvalue check being inside of the selector section, it is possible to send funds to the default function by using less than 4 bytes of calldata, even if the default function is marked `nonpayable`. this applies to contracts compiled with vyper<=0.3.7. ```vyper # @version 0.3.7 # implicitly nonpayable @external def foo() -> uint256: return 1 # implicitly nonpayable @external def __default__(): # could receive ether here pass ``` ### Patches this was fixed by the removal of the global calldatasize check in https://github.com/vyperlang/vyper/commit/02339dfda0f3caabad142060d511d10bfe93c520. ### Workarounds don't use nonpayable default functions ### References _Are there any links users can visit to find out more?_