ghsa

### Summary When using an ACL on a device connected to a bridge, Incus generates nftables rules for local services (DHCP, DNS...) that partially bypass security options `security.mac_filtering`, `security.ipv4_filtering` and `security.ipv6_filtering`. This can lead to DHCP pool exhaustion and opens the door for other attacks. ### Details In commit a7c33301738aede3c035063e973b1d885d9bac7c, the following rules are added at the top of the bridge input chain: iifname "{{.hostName}}" ether type ip ip saddr 0.0.0.0 ip daddr 255.255.255.255 udp dport 67 accept iifname "{{.hostName}}" ether type ip6 ip6 saddr fe80::/10 ip6 daddr ff02::1:2 udp dport 547 accept iifname "{{.hostName}}" ether type ip6 ip6 saddr fe80::/10 ip6 daddr ff02::2 icmpv6 type 133 accept However, these rules accept packets that should be filtered and maybe dropped by later rules in the "MAC filtering" snippet: iifname "{{.hostName}}" ether type arp arp saddr ether != {{.hwAddr}} drop iifname "{{.hostName}}" ether...

## Summary Octo-STS versions before v0.5.3 are vulnerable to unauthenticated SSRF by abusing fields in OpenID Connect tokens. Malicious tokens were shown to trigger internal network requests which could reflect error logs with sensitive information. Please upgrade to v0.5.3 to resolve this issue. This version includes patch sets to [sanitize input](https://github.com/octo-sts/app/commit/b3976e39bd8c8c217c0670747d34a4499043da92) and [redact logging](https://github.com/octo-sts/app/commit/0f177fde54f9318e33f0bba6abaea9463a7c3afd). Many thanks to @vicevirus for reporting this issue and for assisting with remediation review. ## References - https://github.com/octo-sts/app/security/advisories/GHSA-h3qp-hwvr-9xcq - https://github.com/octo-sts/app/commit/b3976e39bd8c8c217c0670747d34a4499043da92 - https://github.com/octo-sts/app/commit/0f177fde54f9318e33f0bba6abaea9463a7c3afd

### Summary A stored XSS is present in Gogs which allows client-side Javascript code execution. ### Details Gogs Version: ``` docker images REPOSITORY TAG IMAGE ID CREATED SIZE gogs/gogs latest fe92583bc4fe 10 hours ago 99.3MB ``` Application version: `0.14.0+dev` Local setup using: ```bash # Pull image from Docker Hub. docker pull gogs/gogs # Create local directory for volume. sudo mkdir -p /var/gogs # Use `docker run` for the first time. docker run --name=gogs -p 10022:22 -p 10880:3000 -v /var/gogs:/data gogs/gogs ``` The vulnerability is caused by the usage of a vulnerable and outdated component: `pdfjs-1.4.20` under public/plugins/. Read more about this vulnerability at [codeanlabs - CVE-2024-4367](https://codeanlabs.com/blog/research/cve-2024-4367-arbitrary-js-execution-in-pdf-js/). ### PoC 1. Upload the Proof of Concept file hosted at https://codeanlabs.com/wp-content/uploads/2024/05/poc_generalized_CVE-2024-4367.pdf in a repository. 2. ...

Versions of the package snyk before 1.1297.3 are vulnerable to Insertion of Sensitive Information into Log File through local Snyk CLI debug logs. Container Registry credentials provided via environment variables or command line arguments can be exposed when executing Snyk CLI in DEBUG or DEBUG/TRACE mode. The issue affects the following Snyk commands: 1. When snyk container test or snyk container monitor commands are run against a container registry, with debug mode enabled, the container registry credentials may be written into the local Snyk CLI debug log. This only happens with credentials specified in environment variables (SNYK_REGISTRY_USERNAME and SNYK_REGISTRY_PASSWORD), or in the CLI (--password/-p and --username/-u). 2. When snyk auth command is executed with debug mode enabled AND the log level is set to TRACE, the Snyk access / refresh credential tokens used to connect the CLI to Snyk may be written into the local CLI debug logs. 3. When snyk iac test is executed with...

### 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...

A session fixation vulnerability in Moodle 3.x through 3.11.18 allows unauthenticated attackers to hijack user sessions via the sesskey parameter. The sesskey can be obtained without authentication and reused within the OAuth2 login flow, resulting in the victim's session being linked to the attacker's. Successful exploitation results in full account takeover. According to the Moodle Releases page, "Bug fixes for security issues in 3.11.x ended 11 December 2023." NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

### 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...