ghsa

### Overview A significant security oversight was identified in Nuclei v3, involving the execution of unsigned code templates through workflows. This vulnerability specifically affects users utilizing custom workflows, potentially allowing the execution of malicious code on the user's system. This advisory outlines the impacted users, provides details on the security patch, and suggests mitigation strategies. ### Affected Users 1. **CLI Users:** Those executing custom workflows from untrusted sources. This includes workflows authored by third parties or obtained from unverified repositories. 2. **SDK Users:** Developers integrating Nuclei into their platforms, particularly if they permit the execution of custom workflows by end-users. ### Security Patch The vulnerability is addressed in Nuclei v3.2.0. Users are strongly recommended to update to this version to mitigate the security risk. ### Mitigation - **Immediate Upgrade:** The primary recommendation is to upgrade to Nuclei v3.2....

### Impact This vulnerability impacts anyone running the affected versions of Wings. The vulnerability can potentially be used to access files and directories on the host system. The full scope of impact is exactly unknown, but reading files outside of a server's base directory (sandbox root) is possible. In order to use this exploit, an attacker must have an existing "server" allocated and controlled by Wings. Details on the exploitation of this vulnerability are embargoed until March 27th, 2024 at 18:00 UTC. ### Resolution In order to mitigate this vulnerability, a full rewrite of the entire server filesystem was necessary. Because of this, the size of the patch is massive, however effort was made to reduce the amount of breaking changes. While tests were written to ensure security and functionality, there may be some semantic differences of certain operations, such as different errors being returned for example. If you notice any major semantic differences, please open an ...

### Impact Much like https://github.com/vantage6/vantage6/security/advisories/GHSA-45gq-q4xh-cp53, it is possible to find which usernames exist in vantage6 by calling the API routes `/recover/lost` and `/2fa/lost`, which send emails to users if they have lost their password or MFA token. Usernames can be found by assessing response time differences, and additionally, they can be found because the endpoint gives a response "Failed to login" if the username exists. ### Patches No ### Workarounds No

### Impact The vantage6 server has no restrictions on CORS settings. It should be possible for people to set the allowed origins of the server. The impact is limited because v6 does not use session cookies ### Patches No ### Workarounds No

### Impact OS command injection vulnerability within the Fluid project's JuicefsRuntime can potentially allow an authenticated user, who has the authority to create or update the K8s CRD Dataset/JuicefsRuntime, to execute arbitrary OS commands within the juicefs related containers. This could lead to unauthorized access, modification or deletion of data. ### Patches For users who're using version < 0.9.3 with JuicefsRuntime， upgrade to v0.9.3. ### References _Are there any links users can visit to find out more?_ ### Credits Special thanks to the discovers of this issue: Xiaozheng Zhang [[email protected]]([email protected])

### Impact "Local sync" is an Argo CD feature that allows developers to temporarily override an Application's manifests with locally-defined manifests. Use of the feature should generally be limited to highly-trusted users, since it allows the user to bypass any merge protections in git. An improper validation bug allows users who have `create` privileges but not `override` privileges to sync local manifests on app creation. All other restrictions, including AppProject restrictions are still enforced. The only restriction which is _not_ enforced is that the manifests come from some approved git/Helm/OCI source. The bug was introduced in 1.2.0-rc1 when the local manifest sync feature was added. ### Patches The bug has been patched in the following versions: * 2.10.3 * 2.9.8 * 2.8.12 ### Workarounds To immediately mitigate the risk of branch protection bypass, remove `applications, create` RBAC access. The only way to eliminate the issue without removing RBAC access is to upgrade...

Information disclosure in persistent watchers handling in Apache ZooKeeper due to missing ACL check. It allows an attacker to monitor child znodes by attaching a persistent watcher (addWatch command) to a parent which the attacker has already access to. ZooKeeper server doesn't do ACL check when the persistent watcher is triggered and as a consequence, the full path of znodes that a watch event gets triggered upon is exposed to the owner of the watcher. It's important to note that only the path is exposed by this vulnerability, not the data of znode, but since znode path can contain sensitive information like user name or login ID, this issue is potentially critical. Users are recommended to upgrade to version 3.9.2, 3.8.4 which fixes the issue.

A SSRF vulnerability using the Aegis DataBinding in versions of Apache CXF before 4.0.4, 3.6.3 and 3.5.8 allows an attacker to perform SSRF style attacks on webservices that take at least one parameter of any type. Users of other data bindings (including the default databinding) are not impacted.

### Impact Vela pipelines can use variable substitution combined with insensitive fields like `parameters`, `image` and `entrypoint` to inject secrets into a plugin/image and — by using common substitution string manipulation — can bypass log masking and expose secrets without the use of the commands block. This unexpected behavior primarily impacts secrets restricted by the "no commands" option. This can lead to unintended use of the secret value, and increased risk of exposing the secret during image execution bypassing log masking. Given by the following substitution examples: using `parameters` ```yaml steps: - name: example image: <some plugin> secrets: [ example_secret ] parameters: example: $${EXAMPLE_SECRET} ``` using `image` tag ```yaml steps: - name: example image: <some plugin>:latest${EXAMPLE_SECRET} secrets: [ example_secret ] ``` using `entrypoint` as a shim for `commands` ```yaml steps: - name: example image: <some plugin> secre...

discordrb is an implementation of the Discord API using Ruby. In discordrb before commit `91e13043ffa` the `encoder.rb` file unsafely constructs a shell string using the file parameter, which can potentially leave clients of discordrb vulnerable to command injection. The library is not directly exploitable: the exploit requires that some client of the library calls the vulnerable method with user input. However, if unsafe input reaches the library method, then an attacker can execute arbitrary shell commands on the host machine. Full impact will depend on the permissions of the process running the `discordrb` library and will likely not be total system access. This issue has been addressed in code, but a new release of the `discordrb` gem has not been uploaded to rubygems. This issue is also tracked as `GHSL-2022-094`.