#auth

### Summary In Zitadel, even after an organization is deactivated, associated projects, respectively their applications remain active. Users across other organizations can still log in and access through these applications, leading to unauthorized access. Additionally, if a project was deactivated access to applications was also still possible. ### Details The issue stems from the fact that when an organization is deactivated in Zitadel, the applications associated with it do not automatically deactivate. The application lifecycle is not tightly coupled with the organization's lifecycle, leading to a situation where the organization or project is marked as inactive, but its resources remain accessible. ### PoC - Create a new Organization, create new project and setup OpenID connect. - Deactivate an Organization - Setup authentication without selecting Check for Project on Authentication - User is able to login despite the organization is deactivated ### Impact This vulnerability all...

### Impact ZITADEL's user account deactivation mechanism did not work correctly with service accounts. Deactivated service accounts retained the ability to request tokens, which could lead to unauthorized access to applications and resources. ### Patches 2.x versions are fixed on >= [2.62.1](https://github.com/zitadel/zitadel/releases/tag/v2.62.1) 2.61.x versions are fixed on >= [2.61.1](https://github.com/zitadel/zitadel/releases/tag/v2.61.1) 2.60.x versions are fixed on >= [2.60.2](https://github.com/zitadel/zitadel/releases/tag/v2.60.2) 2.59.x versions are fixed on >= [2.59.3](https://github.com/zitadel/zitadel/releases/tag/v2.59.3) 2.58.x versions are fixed on >= [2.58.5](https://github.com/zitadel/zitadel/releases/tag/v2.58.5) 2.57.x versions are fixed on >= [2.57.5](https://github.com/zitadel/zitadel/releases/tag/v2.57.5) 2.56.x versions are fixed on >= [2.56.6](https://github.com/zitadel/zitadel/releases/tag/v2.56.6) 2.55.x versions are fixed on >= [2.55.8](https://github.com/...

### Impact ZITADEL's user grants deactivation mechanism did not work correctly. Deactivated user grants were still provided in token, which could lead to unauthorized access to applications and resources. Additionally, the management and auth API always returned the state as active or did not provide any information about the state. ### Patches 2.x versions are fixed on >= [2.62.1](https://github.com/zitadel/zitadel/releases/tag/v2.62.1) 2.61.x versions are fixed on >= [2.61.1](https://github.com/zitadel/zitadel/releases/tag/v2.61.1) 2.60.x versions are fixed on >= [2.60.2](https://github.com/zitadel/zitadel/releases/tag/v2.60.2) 2.59.x versions are fixed on >= [2.59.3](https://github.com/zitadel/zitadel/releases/tag/v2.59.3) 2.58.x versions are fixed on >= [2.58.5](https://github.com/zitadel/zitadel/releases/tag/v2.58.5) 2.57.x versions are fixed on >= [2.57.5](https://github.com/zitadel/zitadel/releases/tag/v2.57.5) 2.56.x versions are fixed on >= [2.56.6](https://github.com/zitad...

Once a user's device is infected as part of an ongoing Flax Typhoon APT campaign, the malware connects it to a botnet called Raptor Train, initiating malicious activity.

### Impact The profile location routine in the referencevalidator commons package is vulnerable to [XML External Entities](https://owasp.org/www-project-top-ten/2017/A4_2017-XML_External_Entities_(XXE)) attack due to insecure defaults of the used Woodstox WstxInputFactory. A malicious XML resource can lead to network requests issued by referencevalidator and thus to a [Server Side Request Forgery](https://owasp.org/www-community/attacks/Server_Side_Request_Forgery) attack. The vulnerability impacts applications which use referencevalidator to process XML resources from untrusted sources. ### Patches The problem has been patched with the [2.5.1 version](https://github.com/gematik/app-referencevalidator/releases/tag/2.5.1) of the referencevalidator. Users are strongly recommended to update to this version or a more recent one. ### Workarounds A pre-processing or manual analysis of input XML resources on existence of DTD definitions or external entities can mitigate the problem. ###...

### Impact There is a vulnerability in Traefik that allows the client to remove the X-Forwarded headers (except the header X-Forwarded-For). ### Patches - https://github.com/traefik/traefik/releases/tag/v2.11.9 - https://github.com/traefik/traefik/releases/tag/v3.1.3 ### Workarounds No workaround. ### For more information If you have any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues). <details> <summary>Original Description</summary> ### Summary When a HTTP request is processed by Traefik, certain HTTP headers such as X-Forwarded-Host or X-Forwarded-Port are added by Traefik before the request is routed to the application. For a HTTP client, it should not be possible to remove or modify these headers. Since the application trusts the value of these headers, security implications might arise, if they can be modified. For HTTP/1.1, however, it was found that some of theses custom headers can indeed be removed and in ...

### Summary Hello dragonfly maintainer team, I would like to report a security issue concerning your JWT feature. ### Details Dragonfly uses [JWT](https://github.com/dragonflyoss/Dragonfly2/blob/cddcac7e3bdb010811e2b62b3c71d9d5c6749011/manager/middlewares/jwt.go) to verify user. However, the secret key for JWT, "Secret Key", is hard coded, which leads to authentication bypass ```go authMiddleware, err := jwt.New(&jwt.GinJWTMiddleware{ Realm: "Dragonfly", Key: []byte("Secret Key"), Timeout: 2 * 24 * time.Hour, MaxRefresh: 2 * 24 * time.Hour, IdentityKey: identityKey, IdentityHandler: func(c *gin.Context) any { claims := jwt.ExtractClaims(c) id, ok := claims[identityKey] if !ok { c.JSON(http.StatusUnauthorized, gin.H{ "message": "Unavailable token: require user id", }) c.Abort() return nil } c.Set("id", id) return id }) ``` ### PoC Use code below to generate a jwt token ```go package main import ( "errors" ...

The explosion of thousands of rigged pagers and walkie-talkies will likely make Hezbollah operatives fear any means of electronic communication. It’s having the same effect on the Lebanese population.

A previously undocumented malware called SambaSpy is exclusively targeting users in Italy via a phishing campaign orchestrated by a suspected Brazilian Portuguese-speaking threat actor. "Threat actors usually try to cast a wide net to maximize their profits, but these attackers are focused on just one country," Kaspersky said in a new analysis. "It's likely that the attackers are testing the

By enhancing threat detection, enabling real-time risk assessment, and providing predictive insights, AI is empowering organizations to build more robust defenses against cyber threats.