ghsa

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?_

### Impact Potential for cross-site scripting in `posthog-js`. ### Patches The problem has been patched in `posthog-js` version 1.57.2. ### Workarounds - This isn't an issue for sites that have a Content Security Policy in place. - Using the HTML tracking snippet on PostHog Cloud always guarantees the latest version of the library – in that case no action is required to upgrade to the patched version. ### References We will publish details of the vulnerability in 30 days as per our [security policy](https://posthog.com/handbook/company/security#policies).

### Impact This issue only impacts users who: - Have a HTTP policy that applies to multiple `toEndpoints` AND - Have an allow-all rule in place that affects only one of those endpoints In such cases, a wildcard rule will be appended to the set of HTTP rules, which could cause bypass of HTTP policies. ### Patches This issue has been patched in Cilium 1.11.16, 1.12.9, and 1.13.2. ### Workarounds Rewrite HTTP rules for each endpoint separately. For example, if the initial rule looks like: ``` egress: - toEndpoints: - matchLabels: k8s:kind: echo - matchLabels: k8s:kind: example toPorts: - ports: - port: "8080" protocol: TCP rules: http: - method: "GET" ``` It should be rewritten to: ``` egress: - toEndpoints: - matchLabels: k8s:kind: echo toPorts: - ports: - port: "8080" protocol: TCP ...

### Impact The Parse Server Push Adapter can crash Parse Server due to an invalid push notification payload. ### Patches Invalid push notification payload is caught and an logged. ### Workarounds n/a ### References - https://github.com/parse-community/parse-server-push-adapter/security/advisories/GHSA-mxhg-rvwx-x993 - https://github.com/parse-community/parse-server-push-adapter/pull/217

### Impact This vulnerability allows attackers to execute arbitrary code when you use Validation Placeholders. The vulnerability exists in the Validation library, and validation methods in the controller and in-model validation are also vulnerable because they use the Validation library internally. ### Patches Upgrade to v4.3.5 or later. ### Workarounds Setting validation rules with an array. E.g.: ```php $validation->setRules([ 'email' => ['required', 'valid_email, 'is_unique[users.email,id,{id}]'], ]); ``` ### References - https://codeigniter4.github.io/userguide/libraries/validation.html#validation-placeholders - https://codeigniter4.github.io/userguide/incoming/controllers.html#validating-data - https://codeigniter4.github.io/userguide/models/model.html#in-model-validation

[Timing attacks](https://en.wikipedia.org/wiki/Timing_attack) occur when an attacker can guess a secret by observing a difference in processing time for valid and invalid inputs. Sensitive secrets such as passwords, token and API keys should be compared only using a constant-time comparision function. More information on this attack type can be found in [this blog post](https://verboselogging.com/2012/08/20/a-timing-attack-in-action). # Root Cause Analysis In this case, the vulnerability occurs due to the following code. https://github.com/ginuerzh/gost/blob/1c62376e0880e4094bd3731e06bd4f7842638f6a/auth.go#L46-L46 Here, a untrusted input, sourced from a HTTP header, is compared directly with a secret. Since, this comparision is not secure, an attacker can mount a side-channel timing attack to guess the password. # Remediation This can be easily fixed using a constant time comparing function such as `crypto/subtle`'s `ConstantTimeCompare`. An example fix can be found in https:/...