#auth

### Summary Untrusted, user-controlled data from the HTTP Proxy-Authorization header can induce a denial of service state. ### Details Untrusted data is extracted from the user-controlled HTTP Proxy-Authorization header and passed to Extension::try_from and flows into parse_ttl_extension where it is parsed as a TTL value. If an attacker supplies a TTL of zero (e.g. by using a username such as 'configuredUser-ttl-0'), the modulo operation 'timestamp % ttl' will cause a division by zero panic, causing the server to crash causing a denial-of-service. The code assumed to be responsible for this can be found here: https://github.com/0x676e67/vproxy/blob/ab304c3854bf8480be577039ada0228907ba0923/src/extension.rs#L173-L183 ### PoC 1. Download and run the latest version of vproxy 2. Send a cUrl request like the following, adjusting address and port as necessary: ```curl -x "http://test-ttl-0:test@127.0.0.1:8101" https://google.com``` 3. Wait for a cUrl error indicating "Proxy CONNECT aborted...

The `--gitlab-group` flag for group-based authorization in the GitLab provider stopped working in the v7.0.0 release. Regardless of the flag settings, authorization wasn't restricted. Additionally, any authenticated users had whichever groups were set in `--gitlab-group` added to the new `X-Forwarded-Groups` header to the upstream application. While adding GitLab project based authorization support in #630, a bug was introduced where the user session's groups field was populated with the `--gitlab-group` config entries instead of pulling the individual user's group membership from the GitLab Userinfo endpoint. When the session groups where compared against the allowed groups for authorization, they matched improperly (since both lists were populated with the same data) so authorization was allowed. ### Impact This impacts GitLab Provider users who relies on group membership for authorization restrictions. Any authenticated users in your GitLab environment can access your application...

A Privilege Escalation vulnerability was identified in the Keycloak identity and access management solution, specifically when FGAPv2 is enabled in version 26.2.x. The flaw lies in the admin permission enforcement logic, where a user with manage-users privileges can self-assign realm-admin rights. The escalation occurs due to missing privilege boundary checks in role mapping operations via the admin REST interface. A malicious administrator with limited permissions can exploit this by editing their own user roles, gaining unauthorized full access to realm configuration and user data. This issue has been fixed in versions 26.2.6, and 26.3.0.

There is a flaw with the first login flow where, during a IdP login, an attacker with a registered account can initiate the process to merge accounts with an existing victim's account. The attacker will subsequently be prompted to "review profile" information, which allows the the attacker to modify their email address to that of a victim's account. This triggers a verification email sent to the victim's email address. If the victim clicks the verification link, the attacker can gain access to the victim's account. While not a zero-interaction attack, the attacker's email address is not directly present in the verification email content, making it a potential phishing opportunity. This issue has been fixed in versions 26.0.13, 26.2.6, and 26.3.0.

Cybersecurity researchers have disclosed now-patched critical security flaws in the firmware of Dahua smart cameras that, if left unaddressed, could allow attackers to hijack control of susceptible devices. "The flaws, affecting the device's ONVIF protocol and file upload handlers, allow unauthenticated attackers to execute arbitrary commands remotely, effectively taking over the device,"

Google has announced that it's making a security feature called Device Bound Session Credentials (DBSC) in open beta to ensure that users are safeguarded against session cookie theft attacks. DBSC, first introduced as a prototype in April 2024, is designed to bind authentication sessions to a device so as to prevent threat actors from using stolen cookies to sign-in to victims' accounts and gain

Red Hat OpenShift sandboxed containers 1.10 has been released, bringing enhanced security and isolation capabilities to your Red Hat OpenShift environments. This marks the general availability of confidential containers on Microsoft Azure, and introduces the new Red Hat build of Trustee, which provides attestation services so your confidential workloads can run with integrity in the cloud. OpenShift sandboxed containers delivers a lightweight and powerful way to run workloads in isolation. Confidential containers add an additional layer for hardware-protected environments, leveraging Trusted E

OpenShift confidential containers (CoCo) is now generally available for Microsoft Azure. You can extend the security capabilities of Red Hat OpenShift by using OpenShift confidential containers, which allows you to deploy and manage confidential workloads with enhanced data protection and integrity. This release marks a significant milestone, providing a robust solution for enterprises seeking to protect sensitive applications and data on Azure. It addresses critical security concerns by isolating workloads within a hardware-protected trusted execution environment, helping ensure that data re

SQL Injection vulnerability in Bacula-web before v.9.7.1 allows a remote attacker to execute arbitrary code via a crafted HTTP GET request.

### Description There's an SSRF in the file upload processing system that allows remote attackers to make arbitrary HTTP requests from the server without authentication. The vulnerability exists in the serialization/deserialization handlers for multipart form data and JSON requests, which automatically download files from user-provided URLs without proper validation of internal network addresses. The framework automatically registers any service endpoint with file-type parameters (`pathlib.Path`, `PIL.Image.Image`) as vulnerable to this attack, making it a framework-wide security issue that affects most real-world ML services handling file uploads. While BentoML implements basic URL scheme validation in the `JSONSerde` path, the `MultipartSerde` path has no validation whatsoever, and neither path restricts access to internal networks, cloud metadata endpoints, or localhost services. The documentation explicitly promotes this URL-based file upload feature, making it an intended but i...