#dos

### Summary A Server-Side Request Forgery (SSRF) vulnerability exists in the `MediaConnector` class within the vLLM project's multimodal feature set. The `load_from_url` and `load_from_url_async` methods fetch and process media from user-provided URLs without adequate restrictions on the target hosts. This allows an attacker to coerce the vLLM server into making arbitrary requests to internal network resources. This vulnerability is particularly critical in containerized environments like `llm-d`, where a compromised vLLM pod could be used to scan the internal network, interact with other pods, and potentially cause denial of service or access sensitive data. For example, an attacker could make the vLLM pod send malicious requests to an internal `llm-d` management endpoint, leading to system instability by falsely reporting metrics like the KV cache state. ### Vulnerability Details The core of the vulnerability lies in the `MediaConnector.load_from_url` method and its asynchronous ...

### Summary A resource-exhaustion (denial-of-service) vulnerability exists in multiple endpoints of the OpenAI-Compatible Server due to the ability to specify Jinja templates via the `chat_template` and `chat_template_kwargs` parameters. If an attacker can supply these parameters to the API, they can cause a service outage by exhausting CPU and/or memory resources. ### Details When using an LLM as a chat model, the conversation history must be rendered into a text input for the model. In `hf/transformer`, this rendering is performed using a Jinja template. The OpenAI-Compatible Server launched by vllm serve exposes a `chat_template` parameter that lets users specify that template. In addition, the server accepts a `chat_template_kwargs` parameter to pass extra keyword arguments to the rendering function. Because Jinja templates support programming-language-like constructs (loops, nested iterations, etc.), a crafted template can consume extremely large amounts of CPU and memory and ...

## Summary `Rack::Multipart::Parser` can accumulate unbounded data when a multipart part’s header block never terminates with the required blank line (`CRLFCRLF`). The parser keeps appending incoming bytes to memory without a size cap, allowing a remote attacker to exhaust memory and cause a denial of service (DoS). ## Details While reading multipart headers, the parser waits for `CRLFCRLF` using: ```ruby @sbuf.scan_until(/(.*?\r\n)\r\n/m) ``` If the terminator never appears, it continues appending data (`@sbuf.concat(content)`) indefinitely. There is no limit on accumulated header bytes, so a single malformed part can consume memory proportional to the request body size. ## Impact Attackers can send incomplete multipart headers to trigger high memory use, leading to process termination (OOM) or severe slowdown. The effect scales with request size limits and concurrency. All applications handling multipart uploads may be affected. ## Mitigation * Upgrade to a patched Rack vers...

## Summary `Rack::Multipart::Parser` stores non-file form fields (parts without a `filename`) entirely in memory as Ruby `String` objects. A single large text field in a multipart/form-data request (hundreds of megabytes or more) can consume equivalent process memory, potentially leading to out-of-memory (OOM) conditions and denial of service (DoS). ## Details During multipart parsing, file parts are streamed to temporary files, but non-file parts are buffered into memory: ```ruby body = String.new # non-file → in-RAM buffer @mime_parts[mime_index].body << content ``` There is no size limit on these in-memory buffers. As a result, any large text field—while technically valid—will be loaded fully into process memory before being added to `params`. ## Impact Attackers can send large non-file fields to trigger excessive memory usage. Impact scales with request size and concurrency, potentially leading to worker crashes or severe garbage-collection overhead. All Rack applications p...

The cyber world never hits pause, and staying alert matters more than ever. Every week brings new tricks, smarter attacks, and fresh lessons from the field. This recap cuts through the noise to share what really matters—key trends, warning signs, and stories shaping today’s security landscape. Whether you’re defending systems or just keeping up, these highlights help you spot what’s coming

Finance.js v4.1.0 contains a Denial of Service (DoS) vulnerability via the IRR function’s depth parameter. Improper handling of the recursion/iteration limit can lead to excessive CPU usage, causing application stalls or crashes.

An issue in finance.js v.4.1.0 allows a remote attacker to cause a denial of service via the seekZero() parameter.

### Summary Unpatched Argo CD versions are vulnerable to malicious API requests which can crash the API server and cause denial of service to legitimate clients. With the default configuration, no `webhook.gogs.secret` set, Argo CD’s /api/webhook endpoint will crash the entire argocd-server process when it receives a Gogs push event whose JSON field `commits[].repo` is not set or is null. ### Details Users can access `/api/webhook` without authentication, and when accessing this endpoint, the `Handler` function parses webhook type messages according to the `header (e.g. X-Gogs-Event)` and `body` parameters provided by the user. The `Parse` function simply unmarshals JSON-type messages. In other words, it returns a data structure even if the data structure is not exactly matched. The `affectedRevisionInfo` function parses data according to webhook event types(e.g. `gogsclient.PushPayload`). However, due to the lack of data structure validation corresponding to these events, an att...

### Summary Unpatched Argo CD versions are vulnerable to malicious API requests which can crash the API server and cause denial of service to legitimate clients. With the default configuration, no `webhook.bitbucketserver.secret` set, Argo CD’s /api/webhook endpoint will crash the entire argocd-server process when it receives a Bitbucket-Server push event whose JSON field `repository.links.clone` is anything other than an array. A single unauthenticated curl request can push the control-plane into CrashLoopBackOff; repeating the request on each replica causes a complete outage of the API. ### Details ```go // webhook.go (Bitbucket-Server branch in affectedRevisionInfo) for _, l := range payload.Repository.Links["clone"].([]any) { // <- unsafe cast link := l.(map[string]any) ... } ``` If links.clone is a string, number, object, or null, the first type assertion panics: interface conversion: interface {} is string, not []interface {} The worker goroutine created by star...

### Summary A race condition in the repository credentials handler can cause the Argo CD server to panic and crash when concurrent operations are performed on the same repository URL. ### Details The vulnerability is located in numerous repository related handlers in the `util/db/repository_secrets.go` file. For example, in the `secretToRepoCred` function. The issue manifests as a concurrent map access panic: ``` concurrent map read and map write ... goroutine 1104 [running]: github.com/argoproj/argo-cd/v2/util/db.(*secretsRepositoryBackend).secretToRepoCred(0xc000e50ea8?, 0xc000c65540) /go/src/github.com/argoproj/argo-cd/util/db/repository_secrets.go:404 +0x31e ``` The race condition occurs due to: 1. Concurrent repository credential operations (create/update/delete) accessing the same map 2. Kubernetes informer re-syncs happening simultaneously 3. Background watchers updating the same secret data 4. No mutex protection for map access A valid API token with `repositories`...