#oauth

### Summary In previous authentik versions, invitations were considered valid regardless if they are expired or not, thus relying on background tasks to clean up expired ones. In a normal scenario this can take up to 5 minutes because the cleanup of expired objects is scheduled to run every 5 minutes. However, with a large amount of tasks in the backlog, this might take longer. ### Patches authentik 2025.8.5 and 2025.10.2 fix this issue; for other versions the workaround below can be used. ### Workarounds Users can create a policy that explicitly checks whether the invitation is still valid, and then bind it to the invitation stage on your invitation flow, and deny access if the invitation is not valid. ```python return not context['flow_plan'].context['invitation'].is_expired ``` ### For more information If users have any questions or comments about this advisory: - Email the authentik team at [security@goauthentik.io](mailto:security@goauthentik.io).

### Summary When authenticating with `client_id` and `client_secret` to an OAuth provider, authentik creates a service account for the provider. In previous authentik versions, authentication for this account was possible even when the account was deactivated. Other permissions are correctly applied and federation with other providers still take assigned policies correctly into account. ### Patches authentik 2025.8.5 and 2025.10.2 fix this issue, for other versions the workaround below can be used. ### Workarounds You can add a policy to your application that explicitly checks if the service account is still valid, and deny access if not. ```python return request.user.is_active ``` ### For more information If you have any questions or comments about this advisory: - Email us at [security@goauthentik.io](mailto:security@goauthentik.io).

Austin, TX/USA, 18th November 2025, CyberNewsWire

Identity security fabric (ISF) is a unified architectural framework that brings together disparate identity capabilities. Through ISF, identity governance and administration (IGA), access management (AM), privileged access management (PAM), and identity threat detection and response (ITDR) are all integrated into a single, cohesive control plane. Building on Gartner’s definition of “identity

Phishing attacks are no longer confined to the email inbox, with 1 in 3 phishing attacks now taking place over non-email channels like social media, search engines, and messaging apps. LinkedIn in particular has become a hotbed for phishing attacks, and for good reason. Attackers are running sophisticated spear-phishing attacks against company executives, with recent campaigns seen targeting

Mattermost versions 10.11.x <= 10.11.3, 10.5.x <= 10.5.11, 10.12.x <= 10.12.0 fail to validate the relationship between the post being updated and the MSTeams plugin OAuth flow which allows an attacker to edit arbitrary posts via a crafted MSTeams plugin OAuth redirect URL.

### Impact All deployments of OAuth2 Proxy in front of applications that normalize underscores to dashes in HTTP headers (e.g., WSGI-based frameworks such as Django, Flask, FastAPI, and PHP applications). Authenticated users can inject underscore variants of X-Forwarded-* headers that bypass the proxy’s filtering logic, potentially escalating privileges in the upstream app. OAuth2 Proxy authentication/authorization itself is not compromised. ### Patches This change mitigates a request header smuggling vulnerability where an attacker could bypass header stripping by using different capitalization or replacing dashes with underscores. The problem has been patched with v7.13.0. By default all specified headers will now be normalized, meaning that both capitalization and the use of underscores (_) versus dashes (-) will be ignored when matching headers to be stripped. For example, both `X-Forwarded-For` and `X_Forwarded-for` will now be treated as equivalent and stripped away. However...

### Summary If the "claims_parameter_supported" parameter is activated, it is possible through the "oidc-claims-extension.groovy" script, to inject the value of choice into a claim contained in the id_token or in the user_info. Authorization function requests do not prevent a claims parameter containing a JSON file to be injected. This JSON file allows users to customize claims returned by the "id_token" and "user_info" files. This allows for a very wide range of vulnerabilities depending on how clients use claims. For example, if some clients rely on an email field to identify a user, users can choose to entera any email address, and therefore assume any chosen identity.

Active Directory remains the authentication backbone for over 90% of Fortune 1000 companies. AD's importance has grown as companies adopt hybrid and cloud infrastructure, but so has its complexity. Every application, user, and device traces back to AD for authentication and authorization, making it the ultimate target. For attackers, it represents the holy grail: compromise Active

### Summary _Short summary of the problem. Make the impact and severity as clear as possible. A flawed implementation of the Kubernetes aggregation layer's authentication flow could enable bypassing RBAC controls. ### Details _Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer._ It was discovered that the `virt-api` component fails to correctly authenticate the client when receiving API requests over mTLS. In particular, it fails to validate the CN (Common Name) field in the received client TLS certificates against the set of allowed values defined in the `extension-apiserver-authentication` configmap. The Kubernetes API server proxies received client requests through a component called aggregator (part of K8S's API server), and authenticates to the `virt-api` server using a certificate signed by the CA specified via the `--requestheader-client-ca-file` CLI flag. This CA bundle is primarily used in the context of aggr...