ghsa

The package simple-git before 3.15.0 is vulnerable to Remote Code Execution (RCE) when enabling the `ext` transport protocol, which makes it exploitable via `clone()` method. This vulnerability exists due to an incomplete fix of [CVE-2022-24066](https://security.snyk.io/vuln/SNYK-JS-SIMPLEGIT-2434306).

ConcreteCMS v9.1.3 was discovered to be vulnerable to Xpath injection attacks. This vulnerability allows attackers to access sensitive XML data via a crafted payload injected into the URL path folder "3".

Concrete CMS (formerly concrete5) below 8.5.10 and between 9.0.0 and 9.1.2 is vulnerable to XSS in the text input field since the result dashboard page output is not sanitized. The Concrete CMS security team has ranked this 4.2 with CVSS v3.1 vector AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N Thanks @_akbar_jafarli_ for reporting. Remediate by updating to Concrete CMS 8.5.10 and Concrete CMS 9.1.3.

### Summary Unsafe extracting using `shutil.unpack_archive()` from a remotely retrieved tarball may lead to writing the extracted file to an unintended destination. ### Details Extracting files using `shutil.unpack_archive()` from a potentially malicious tarball without validating that the destination file path is within the intended destination directory can cause files outside the destination directory to be overwritten. The vulnerable code snippet is between [L153..158](https://github.com/DataDog/guarddog/blob/a1d064ceb09d39bb28deb6972bc0a278756ea91f/guarddog/scanners/package_scanner.py#L153..158). ```python response = requests.get(url, stream=True) with open(zippath, "wb") as f: f.write(response.raw.read()) shutil.unpack_archive(zippath, unzippedpath) ``` It seems that a remotely retrieved tarball which could be with the extension `.tar.gz` happens to be unpacked using `shutil.unpack_archive()` with no destination verification/limitation of the extracted files. ###...

Capsule implements a multi-tenant and policy-based environment in a Kubernetes cluster. A ServiceAccount deployed in a Tenant Namespace, when granted with `PATCH` capabilities on its own Namespace, is able to edit it and remove the Owner Reference, breaking the reconciliation of the Capsule Operator and removing all the enforcement like Pod Security annotations, Network Policies, Limit Range and Resource Quota items. With that said, an attacker could detach the Namespace from a Tenant that is forbidding starting privileged Pods using the Pod Security labels by removing the OwnerReference, removing the enforcement labels, and being able to start privileged containers that would be able to start a generic Kubernetes privilege escalation. ### Patches Patches have been released for version 0.1.3 and all users must upgrade to this release. ### Workarounds N.A. ### References N.A. ### For more information If you have any questions or comments about this advisory: * Open an issue in ...

### Impact Due to a plain object with a prototype being used in socket.io message handling a specially crafted payload can be used to impersonate other users and takeover accounts. ### Patches Patched in 2.6.1 ### Workarounds Site maintainers can cherry-pick https://github.com/NodeBB/NodeBB/commit/48d143921753914da45926cca6370a92ed0c46b8 into their codebase to patch the exploit. ### For more information If you have any questions or comments about this advisory: Discuss it on [our community forum](https://github.com/NodeBB/NodeBB/security/advisories/community.nodebb.org/) Email us at [[email protected]](mailto:[email protected])

Path resolution in `hyper-staticfile` didn't correctly validate Windows paths, meaning paths like `/foo/bar/c:/windows/web/screen/img101.png` would be allowed and respond with the contents of `c:/windows/web/screen/img101.png`. Thus users could potentially read files anywhere on the filesystem. This only impacts Windows. Linux and other unix likes are not impacted by this.

### Impact Prometheus can be secured by a web.yml file that specifies usernames and hashed passwords for basic authentication. Passwords are hashed with bcrypt, which means that even if you have access to the hash, it is very hard to find the original password back. However, a flaw in the way this mechanism was implemented in the [exporter toolkit](https://github.com/prometheus/exporter-toolkit) makes it possible with people who know the hashed password to authenticate against Prometheus. A request can be forged by an attacker to poison the internal cache used to cache the computation of hashes and make subsequent requests successful. This cache is used in both happy and unhappy scenarios in order to limit side channel attacks that could tell an attacker if a user is present in the file or not. ### Patches Prometheus 2.37.4 ([LTS](https://prometheus.io/docs/introduction/release-cycle/)) and 2.40.4 have been released to address this issue. ### Workarounds There is no workaround ...

All Craft CMS versions between 3.0.0 and 3.7.32 disclose password hashes of users who authenticate using their E-Mail address or username in Anti-CSRF-Tokens. Craft CMS uses a cookie called CRAFT_CSRF_TOKEN and a HTML hidden field called CRAFT_CSRF_TOKEN to avoid Cross Site Request Forgery attacks. The CRAFT_CSRF_TOKEN cookie discloses the password hash in without encoding it whereas the corresponding HTML hidden field discloses the users' password hash in a masked manner, which can be decoded by using public functions of the YII framework.

The Cap'n Proto library and capnp Rust package are vulnerable to out-of-bounds read due to logic error handling list-of-list. If a message consumer expects data of type "list of pointers", and if the consumer performs certain specific actions on such data, then a message producer can cause the consumer to read out-of-bounds memory. This could trigger a process crash in the consumer, or in some cases could allow exfiltration of private in-memory data. Impact ====== - Remotely segfault a peer by sending it a malicious message, if the victim performs certain actions on a list-of-pointer type. - Possible exfiltration of memory, if the victim performs additional certain actions on a list-of-pointer type. - To be vulnerable, an application must perform a specific sequence of actions, described below. At present, **we are not aware of any vulnerable application**, but we advise updating regardless. Fixed in ======== Unfortunately, the bug is present in inlined code, therefore the fix will...