ghsa

### Impact The podman machine init command fails to verify the TLS certificate when downloading the VM images from an OCI registry (which it does by default since 5.0.0) allowing a possible Man In The Middle attack. ### Patches https://github.com/containers/podman/commit/726b506acc8a00d99f1a3a1357ecf619a1f798c3 Fixed in v5.5.2 ### Workarounds Download the disk image manually via some other tool that verifies the TLS connection. Then pass the local image as file path (podman machine init --image ./somepath)

### Impact Prior to 2.1.1 and 2.2.0, the `Steel.validateCommitment` Solidity library function will return `true` for a crafted commitment with a digest value of zero. This violates the semantics of `validateCommitment`, as this does not commitment to a block that is in the current chain. Because the digest is zero, it does not correspond to any block and there exist no known openings. As a result, this commitment will never be produced by a correct zkVM guest using Steel. Leveraging this bug to compromise the soundness of an application using Steel would require a separate bug or misuse of the Steel library, which is expected to be used to validate the root of state opening proofs (e.g. having the guest commit to a digest of zero, or failing to check the zkVM proof). Because this bug does not risk application integrity, correctly written applications are not at risk. ### Fix Please see [#605] for a full description of the bug, and the fix. This fix has been released as part of `ri...

### Summary A critical XML External Entity (XXE) vulnerability exists in the xunit-xml-plugin used by Allure 2. The plugin fails to securely configure the XML parser (`DocumentBuilderFactory`) and allows external entity expansion when processing test result .xml files. This allows attackers to read arbitrary files from the file system and potentially trigger server-side request forgery (SSRF). ### Details In `\allure2-main\plugins\xunit-xml-plugin\src\main\java\io\qameta\allure\xunitxml\XunitXmlPlugin.java` the application uses `DocumentBuilderFactory` without disabling DTDs or external entities. By generating a report with a malicious xml file within it, an attacker can perform XXE to leverage SSRF, or to read system files. ### PoC To recreate this vulnerability, you need to install allure for command-line (In my POC I used a Windows 11 Machine). 1. Create a folder called `allure`, and within it, create a malicious XML file. I will attach my SSRF and file reading payloads, however...

### Impact Via a request to an anonymously authenticated endpoint it's possible to retrieve information about the configured password requirements. The information available is limited but would perhaps give some additional detail useful for someone attempting to brute force derive a user's password. The vulnerability can be found in the supported Umbraco versions 10 and 13. It was not exposed in Umbraco 7 or 8, nor in 14 or higher versions. ### Patches Patched in 10.8.11 and 13.9.2

### Summary Due to the insufficient patch for the CVE-2024-39931, it's still possible to delete files under the `.git` directory and achieve remote command execution. ### Details In the patch for CVE-2024-39931, the following check is added: https://github.com/gogs/gogs/commit/77a4a945ae9a87f77e392e9066b560edb71b5de9 ```diff + // 🚨 SECURITY: Prevent uploading files into the ".git" directory + if isRepositoryGitPath(opts.TreePath) { + return errors.Errorf("bad tree path %q", opts.TreePath) + } ``` While the above code snippet checks if the specified path is a `.git` directory, there are no checks for symbolic links in the later steps. So, by creating a symbolic link that points to the `.git` directory, an attacker can still delete arbitrary files in the `.git` directory and achieve remote command execution. ### Impact Unprivileged user accounts can execute arbitrary commands on the Gogs instance with the privileges of the account specified by `RUN_USER` in the configuration. It a...

### Summary On historic but declared as supported Node.js versions (0.12-2.x), pbkdf2 silently disregards Uint8Array input This only affects Node.js <3.0.0, but `pbkdf2` claims to: * Support Node.js [>= 0.12](https://github.com/browserify/pbkdf2/blob/v3.1.2/package.json#L62) (and there seems to be ongoing effort in this repo to maintain that) * Support `Uint8Array` input (input is typechecked against Uint8Array, and the error message includes e.g. "Password must be a string, a Buffer, a typed array or a DataView" ### Details The error is in `toBuffer` method This vulnerability somehow even made it to tests: https://github.com/browserify/pbkdf2/commit/eb9f97a66ed83836bebc4ff563a1588248708501 There, `resultsOld` (where mismatch `results`) are just invalid output generated from empty password/salt instead of the supplied one ### PoC On Node.js/io.js < 3.0.0 ```console > require('pbkdf2').pbkdf2Sync(new Uint8Array([1,2,3]), new Uint8Array([1,3,4]), 1024, 32, 'sha256') <Buffer 21 ...

### Summary This affects both: 1. Unsupported algos (e.g. `sha3-256` / `sha3-512` / `sha512-256`) 2. Supported but non-normalized algos (e.g. `Sha256` / `Sha512` / `SHA1` / `sha-1` / `sha-256` / `sha-512`) All of those work correctly in Node.js, but this polyfill silently returns highly predictable ouput Under Node.js (only with `pbkdf2/browser` import, unlikely) / Bun (`pbkdf2` top-level import is affected), the memory is not zero-filled but is uninitialized, as `Buffer.allocUnsafe` is used Under browsers, it just returns zero-filled buffers (Which is also critical, those are completely unacceptable as kdf output and ruin security) ### Were you affected? The full list of arguments that were **not** affected were literal: * `'md5'` * `'sha1'` * `'sha224'` * `'sha256'` * `'sha384'` * `'sha512'` * `'rmd160'` * `'ripemd160'` Any other arguments, e.g. representation variations of the above ones like `'SHA-1'`/`'sha-256'`/`'SHA512'` or different algos like `'sha3-512'`/`'b...

A vulnerability was found in PySpur-Dev pyspur up to 0.1.18. It has been classified as critical. Affected is the function SingleLLMCallNode of the file backend/pyspur/nodes/llm/single_llm_call.py of the component Jinja2 Template Handler. The manipulation of the argument user_message leads to improper neutralization of special elements used in a template engine. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used.

A Server-Side Request Forgery (SSRF) vulnerability exists in the RequestsToolkit component of the langchain-community package (specifically, langchain_community.agent_toolkits.openapi.toolkit.RequestsToolkit) in langchain-ai/langchain version 0.0.27. This vulnerability occurs because the toolkit does not enforce restrictions on requests to remote internet addresses, allowing it to also access local addresses. As a result, an attacker could exploit this flaw to perform port scans, access local services, retrieve instance metadata from cloud environments (e.g., Azure, AWS), and interact with servers on the local network. This issue has been fixed in version 0.0.28.

### Impact The connection limiter is implemented incorrectly. It allows an arbitrary amount of simultaneously incoming connections (TCP, UDP and Unix socket) for the services `letmeind` and `letmeinfwd`. Therefore, the command line option `num-connections` is not effective and does not limit the number of simultaneously incoming connections. `letmeind` is the public network facing daemon (TCP/UDP). `letmeinfwd` is the internal firewall daemon that only listens on local Unix socket. Possible Denial Of Service by resource exhaustion. ### Affected versions All versions `<= 10.2.0` are affected. ### Patches All users shall upgrade to version `10.2.1`. ### Workarounds Untested possible workarounds: - It might be possible to limit the number of active connections to the `letmeind` port (default 5800) via firewall. - The resource consumption of the service might be restricted with a service manager such as systemd. ### Severity: If a (D)DoS is run against the service, *something* is...