ghsa

Weak Password Requirements in GitHub repository thorsten/phpmyfaq prior to 3.1.12.

Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.1.12.

Cross-site Scripting (XSS) - Generic in GitHub repository thorsten/phpmyfaq prior to 3.1.12.

Code Injection in GitHub repository thorsten/phpmyfaq prior to 3.1.12.

There is a possible Denial of Service (DoS) vulnerability in the unpoly-rails gem that implements the [Unpoly server protocol](https://unpoly.com/up.protocol) for Rails applications. ### Impact This issues affects Rails applications that operate as an upstream of a load balancer's that uses [passive health checks](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-health-check/#passive-health-checks). The [unpoly-rails](https://github.com/unpoly/unpoly-rails/) gem echoes the request URL as an `X-Up-Location` response header. By making a request with exceedingly long URLs (paths or query string), an attacker can cause unpoly-rails to write a exceedingly large response header. If the response header is too large to be parsed by a load balancer downstream of the Rails application, it may cause the load balancer to remove the upstream from a load balancing group. This causes that application instance to become unavailable until a configured timeout is reached or until an activ...

### Summary An unsafe extraction is being performed using `tarfile.extractall()` from a remotely retrieved tarball. Which may lead to the writing of the extracted files to an unintended location. Sometimes, the vulnerability is called a TarSlip or a ZipSlip variant. ### Details I commented the following snippet of code as a vulnerability details. The code is from [file.py#L26..L134](https://github.com/mindsdb/mindsdb/blob/afedd37c16e579b6dc075b0814e42d0505ccdc07/mindsdb/api/http/namespaces/file.py#L26..L134) ```python @ns_conf.route('/<name>') @ns_conf.param('name', "MindsDB's name for file") class File(Resource): @ns_conf.doc('put_file') def put(self, name: str): ''' add new file params in FormData: - file - original_file_name [optional] ''' data = {} ... omitted for brevity url = data['source'] data['file'] = data['name'] ... omitted for brevity ...

### Impact It was found that AppArmor, and potentially SELinux, can be bypassed when `/proc` inside the container is symlinked with a specific mount configuration. ### Patches Fixed in runc v1.1.5, by prohibiting symlinked `/proc`: https://github.com/opencontainers/runc/pull/3785 This PR fixes CVE-2023-27561 as well. ### Workarounds Avoid using an untrusted container image.

### Impact In certain configurations, data sent by remote servers containing special strings in key locations could cause modifications of the `Object.prototype`, disrupting matrix-js-sdk functionality, causing denial of service and potentially affecting program logic. (This is part 2, where [CVE-2022-36059](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-36059) / [GHSA-rfv9-x7hh-xc32](https://github.com/matrix-org/matrix-js-sdk/security/advisories/GHSA-rfv9-x7hh-xc32) is part 1. Part 2 covers remaining vectors not covered by part 1, found in a codebase audit scheduled after part 1.) ### Patches The issue has been patched in matrix-js-sdk 24.0.0. ### Workarounds None. ### References - [Release blog post](https://matrix.org/blog/2023/03/28/security-releases-matrix-js-sdk-24-0-0-and-matrix-react-sdk-3-69-0) - The advisory [GHSA-rfv9-x7hh-xc32](https://github.com/matrix-org/matrix-js-sdk/security/advisories/GHSA-rfv9-x7hh-xc32) ([CVE-2022-36059](https://cve.mitre.org/cgi-bin...

### Impact Kiwi TCMS accepts SVG files uploaded by users which could potentially contain JavaScript code. If SVG images are viewed directly, i.e. not rendered in an HTML page, this JavaScript code could execute. ### Patches This vulnerability has been fixed by configuring Kiwi TCMS to serve with the Content-Security-Policy HTTP header which blocks inline JavaScript in all modern browsers. ### Workarounds Configure Content-Security-Policy header, see [commit 6617cee0](https://github.com/kiwitcms/Kiwi/commit/6617cee0fb70cc394b7be6bbc86ef84e6e9de077). ### References You can visit https://digi.ninja/blog/svg_xss.php for more technical details. Independently disclosed by [Antonio Spataro](https://huntr.dev/bounties/bf99001b-a0a2-4f7d-98cd-983bc7f14a69/) and [@1d8](https://huntr.dev/bounties/f8c73bcc-02f3-4c65-a92b-1caa4d67c2fd/).

### Impact It was found that rootless runc makes `/sys/fs/cgroup` writable in following conditons: 1. when runc is executed inside the user namespace, and the `config.json` does not specify the cgroup namespace to be unshared (e.g.., `(docker|podman|nerdctl) run --cgroupns=host`, with Rootless Docker/Podman/nerdctl) 2. or, when runc is executed outside the user namespace, and `/sys` is mounted with `rbind, ro` (e.g., `runc spec --rootless`; this condition is very rare) A container may gain the write access to user-owned cgroup hierarchy `/sys/fs/cgroup/user.slice/...` on the host . Other users's cgroup hierarchies are not affected. ### Patches v1.1.5 (planned) ### Workarounds - Condition 1: Unshare the cgroup namespace (`(docker|podman|nerdctl) run --cgroupns=private)`. This is the default behavior of Docker/Podman/nerdctl on cgroup v2 hosts. - Condition 2 (very rare): add `/sys/fs/cgroup` to `maskedPaths`