ghsa

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"; ...

### Impact TurboBoost Commands has existing protections in place to guarantee that only public methods on Command classes can be invoked; however, the existing checks aren't as robust as they should be. It's possible for a sophisticated attacker to invoke more methods than should be permitted depending on the the strictness of authorization checks that individual applications enforce. Being able to call some of these methods can have security implications. #### Details Commands verify that the class must be a `Command` and that the method requested is defined as a public method; however, this isn't robust enough to guard against all unwanted code execution. The library should more strictly enforce which methods are considered safe before allowing them to be executed. ### Patches Patched in the following versions. - 0.1.3 - [NPM Package](https://www.npmjs.com/package/@turbo-boost/commands/v/0.1.3) - [Ruby GEM](https://rubygems.org/gems/turbo_boost-commands/versions/0.1.3) - 0.2....

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