Wernerina

**Name of the Vulnerable Software and Affected Versions** Argo Workflows versions 4.0.0 through 4.0.4 **Description** A nil pointer dereference in the `rbacAuthorization()` function within `server/auth/gatekeeper.go` can lead to a denial of service for SSO users. This occurs when `SSO DELEGATE RBAC TO NAMESPACE` is set to `true` and a user's claims match a namespace-level RBAC rule but not an SSO-namespace rule. Specifically, when the `getServiceAccount(claims, ssoNamespace)` function returns nil, the `loginAccount` variable remains nil; if a matching `namespaceAccount` is found, the `precedence()` function is called with the nil `loginAccount`, causing a panic when attempting to access `serviceAccount.Annotations`. **Recommendations** Update Argo Workflows to version 4.0.5.

**Name of the Vulnerable Software and Affected Versions** OpenProject versions prior to 17.3.0 **Description** Two-factor authentication (2FA) OTP verification in the 'confirm otp' action of the `two factor authentication` module lacks rate limiting, lockout mechanisms, or failed-attempt tracking. The `brute force block after failed logins` setting only tracks password login failures and does not apply to the 2FA stage. Additionally, the `fail login` and `stage failure` functions do not increment counters, lock accounts, or introduce delays. Because the default Time-based One-Time Password (TOTP) drift window of ±60 seconds allows multiple valid codes simultaneously, an attacker with a user's password can brute-force the 6-digit TOTP code. This same issue affects backup code verification, potentially allowing a complete 2FA bypass. **Recommendations** Update to version 17.3.0.

Name of the Vulnerable Software and Affected Versions Kedro versions prior to 1.3.0 Description Kedro is susceptible to a critical Remote Code Execution (RCE) issue stemming from the unsafe utilization of `logging.config.dictConfig()` with user-controlled input. The software permits setting the logging configuration file path through the `KEDRO LOGGING CONFIG` environment variable, loading it without proper validation. The logging configuration schema supports a special `()` key, which allows for the instantiation of arbitrary callables. An attacker can leverage this to execute arbitrary system commands during application startup. The vulnerability is addressed by implementing validation to reject the unsafe `()` factory key in logging configurations before passing them to `dictConfig()`. Recommendations Upgrade to Kedro version 1.3.0 or later. If upgrading is not immediately possible: - Do not allow untrusted input to control the `KEDRO LOGGING CONFIG` environment variable. - Restrict write access to logging configuration files. - Avoid using externally supplied or dynamically generated logging configurations. - Manually validate logging YAML to ensure it does not contain the `()` key.

**Name of the Vulnerable Software and Affected Versions** vLLM versions 0.10.1 through 0.17.x **Description** vLLM is an inference and serving engine for large language models (LLMs). Starting with version 0.10.1 and continuing through version 0.17.x, two model implementation files hardcode `trust remote code=True` when loading sub-components. This bypasses the user’s explicit `--trust-remote-code=False` security setting, potentially enabling remote code execution via malicious model repositories, even when the user has disabled remote code trust. The vulnerability occurs because the system does not respect the user-defined security opt-out. The affected files override the user's setting without any warning or log entry. A malicious Hugging Face repository targeting either architecture can achieve code execution on the inference server. **Recommendations** Versions 0.10.1 through 0.17.x are vulnerable and should be updated to version 0.18.0 or later.