ghsa

### Summary In the AES GCM implementation of decrypt_in_place_detached, the decrypted ciphertext (i.e. the correct plaintext) is exposed even if tag verification fails. ### Impact If a program using the `aes-gcm` crate's `decrypt_in_place*` APIs accesses the buffer after decryption failure, it will contain a decryption of an unauthenticated input. Depending on the specific nature of the program this may enable Chosen Ciphertext Attacks (CCAs) which can cause a catastrophic breakage of the cipher including full plaintext recovery. ### Details As seen in the implementation of [decrypt_in_place_detached](https://docs.rs/aes-gcm/latest/src/aes_gcm/lib.rs.html#309) for AES GCM, if the tag verification fails, an error is returned. Because the decryption of the ciphertext is done in place, the plaintext contents are now exposed via `buffer`. This should ideally not be the case - as noted in page 17 of[ NIST's publication _Recommendation for Block Cipher Modes of Operation: Galois/Counter...

A command injection flaw was found in foreman. This flaw allows an authenticated user with admin privileges on the foreman instance to transpile commands through CoreOS and Fedora CoreOS configurations in templates, possibly resulting in arbitrary command execution on the underlying operating system.

A flaw was found in pgAdmin. This issue occurs when the pgAdmin server HTTP API validates the path a user selects to external PostgreSQL utilities such as pg_dump and pg_restore. Versions of pgAdmin prior to 7.7 failed to properly control the server code executed on this API, allowing an authenticated user to run arbitrary commands on the server.

FUXA <= 1.1.12 has a Local File Inclusion vulnerability via file=fuxa.log

A SQL Injection attack in FUXA <= 1.1.12 allows exfiltration of confidential information from the database.

FUXA <= 1.1.12 is vulnerable to SQL Injection via `/api/signin`.

FUXA <= 1.1.12 is vulnerable to Local File Inclusion via `/api/download`.

### Impact Receiving unknown QUIC frames in a QUIC packet could result in a panic. ### Patches The problem has been fixed in 0.9.5 and 0.10.5 maintenance releases. ### References Fixed in https://github.com/quinn-rs/quinn/pull/1667, backported in https://github.com/quinn-rs/quinn/pull/1668 and https://github.com/quinn-rs/quinn/pull/1669.

### Impact There is a stored cross site scripting vulnerability for SVG images uploaded in user portraits. Note that a page that uses an image tag with an SVG image as source is never vulnerable, even when the SVG image contains malicious code. To exploit the vulnerability, an attacker would first need to upload an SVG image as user portrait, and then trick a user into following a link to this portrait. ### Patches A patch will be released in `plone.restapi` 8.43.3. This version is good for Plone 6.0, and for Plone 5.2 on Python 3. In `plone.restapi` 7 or earlier there was no `@portrait` endpoint yet, so there is nothing to fix in that version. It is still vulnerable to this attack, and needs a [fix in Zope 4](https://github.com/zopefoundation/Zope/security/advisories/GHSA-wm8q-9975-xh5v). These two vulnerabilities share the same CVE: CVE-2023-42458. ### Workarounds You could remove the portrait field from the member data schema, and possibly remove all portraits that are already i...

### Impact SSID Command Injection Vulnerability ### Patches Problem was fixed with a parameter check. Please upgrade to version >= 5.21.7, Version 4 was not affected ### Workarounds If you cannot upgrade, be sure to check or sanitize parameter strings that are passed to wifiConnections(), wifiNetworks() (string only) ### References See also https://systeminformation.io/security.html