#git

In Django 3.2 before 3.2.25, 4.2 before 4.2.11, and 5.0 before 5.0.3, the django.utils.text.Truncator.words() method (with html=True) and the truncatewords_html template filter are subject to a potential regular expression denial-of-service attack via a crafted string. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232 and CVE-2023-43665.

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

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

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

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

### Summary With the default configuration of tls-listener, a malicious user can open 6.4 `TcpStream`s a second, sending 0 bytes, and can trigger a DoS. ### Details The default configuration options make any public service using `TlsListener::new()` vulnerable to a slow-loris DoS attack. ```rust /// Default number of concurrent handshakes pub const DEFAULT_MAX_HANDSHAKES: usize = 64; /// Default timeout for the TLS handshake. pub const DEFAULT_HANDSHAKE_TIMEOUT: Duration = Duration::from_secs(10); ``` ### PoC Running the HTTP TLS server example: https://github.com/tmccombs/tls-listener/blob/6c57dea2d9beb1577ae4d80f6eaf03aad4ef3857/examples/http.rs, then running the following script will prevent new connections to the server. ```rust use std::{net::ToSocketAddrs, time::Duration}; use tokio::{io::AsyncReadExt, net::TcpStream, task::JoinSet}; #[tokio::main] async fn main() { const N: usize = 1024; const T: Duration = Duration::from_secs(10); let url = "127.0.0.1:3000"; ...

### Summary Due to the improper URL protocols filtering of links specified in the `link.argocd.argoproj.io` annotations in the application summary component, an attacker can achieve cross-site scripting with elevated permissions. ### Impact All unpatched versions of Argo CD starting with v1.0.0 are vulnerable to a cross-site scripting (XSS) bug allowing a malicious user to inject a javascript: link in the UI. When clicked by a victim user, the script will execute with the victim's permissions (up to and including admin). This vulnerability allows an attacker to perform arbitrary actions on behalf of the victim via the API, such as creating, modifying, and deleting Kubernetes resources. ### Patches A patch for this vulnerability has been released in the following Argo CD versions: * v2.10.3 * v2.9.8 * v2.8.12 ### Workarounds There are no completely-safe workarounds besides **upgrading**. The safest alternative, if upgrading is not possible, would be to create a [Kubernetes admis...

### Impact If you have a NetFraming based CoreWCF service, extra system resources could be consumed by connections being left established instead of closing or aborting them. There are two scenarios when this can happen. When a client established a connection to the service and sends no data, the service will wait indefinitely for the client to initiate the NetFraming session handshake. Additionally, once a client has established a session, if the client doesn't send any requests for the period of time configured in the binding ReceiveTimeout, the connection is not properly closed as part of the session being aborted. The bindings affected by this behavior are NetTcpBinding, NetNamedPipeBinding, and UnixDomainSocketBinding. Only NetTcpBinding has the ability to accept non local connections. ### Patches The currently supported versions of CoreWCF are v1.4.x and v1.5.x. The fix can be found in v1.4.2 and v1.5.2 of the CoreWCF packages. ### Workarounds There are no workarounds. ### R...

### Impact Any users whom would not desire a traceback to be included in their logs whenever an error is raised in their code will be affected. If users have inadvertently created a scenario in their code that could cause a traceback to include sensitive information _and_ a malicious entity gained access to their log stream, this could create an issue. ### Patches None yet... users will need to upgrade to `0.4.*` ### Workarounds No particularly reasonable ones at present. ### References * https://cwe.mitre.org/data/definitions/453.html * https://www.invicti.com/web-vulnerability-scanner/vulnerabilities/stack-trace-disclosure-python/

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