ghsa

A flaw was found in Keycloak. Under specific circumstances, HTML entities are not sanitized during user impersonation, resulting in a Cross-site scripting (XSS) vulnerability. ## Details This issue is the result of code found in the exception here: [https://github.com/keycloak/keycloak/blob/48835576daa158443f69917ac309e1a7c951bc87/services/src/main/java/org/keycloak/authentication/AuthenticationProcessor.java#L1045](https://github.com/keycloak/keycloak/blob/48835576daa158443f69917ac309e1a7c951bc87/services/src/main/java/org/keycloak/authentication/AuthenticationProcessor.java#L1045) ## Steps to reproduce When using the legacy admin console: 1. Sign in as Admin user in first tab. 2. In that tab create new user in keycloak admin section > intercept user creation request and modify it by including malicious js script there (in username field). 3. Sign in as newly created user in second tab (same browser window but second tab). 4. Navigate back to first tab where you are signed in as ...

A vulnerability in Imperative framework which allows already-privileged local actors to execute arbitrary shell commands via plugin install/update commands, or maliciously formed environment variables. Impacts Zowe CLI.

### Impact Resource properties secured with the `security` option of the `ApiPlatform\Metadata\ApiProperty` attribute can be disclosed to unauthorized users. The problem affects most serialization formats, including raw JSON, which is enabled by default when installing API Platform. Custom serialization formats may also be impacted. Only collection endpoints are affected by the issue, item endpoints are not. The JSON-LD format is not affected by the issue. The result of the security rule is only executed for the first item of the collection. The result of the rule is then cached and reused for the next items. This bug can leak data to unauthorized users when the rule depends on the value of a property of the item. This bug can also hide properties that should be displayed to authorized users. ### Patches This issue impacts the 2.7, 3.0 and 3.1 branches. Upgrade to v2.7.10, v3.0.12 or v3.1.3. ### Workarounds Replace the `cache_key` of the context array of the Serializer inside a c...

From issue: Problem description Currently, the refresh token is valid indefinitely. This is bad security practice. Desired solution The refresh token should get a validity of 24-48 hours. Additional context When implementing this, also check that the refresh token returns a new refresh token When implementing this, also adapt the UI so that it logs out if refresh token is no longer valid. When implementing this, ensure that nodes refresh their token periodically so that they do not have to be restarted manually. ### Impact ### Patches None available ### Workarounds None available

### Impact Assigning existing users to a different organization is currently possible. It may lead to unintended access: if a user from organization A is accidentally assigned to organization B, they will retain their permissions and therefore might be able to access stuff they should not be allowed to access. ### Patches Update to 3.8.0 ### Workarounds None ### References None ### For more information If you have any questions or comments about this advisory: * Email us at [vantage6@iknl.nl](mailto:vantage6@iknl.nl)

### Impact We are incorporating the password policies listed in https://github.com/vantage6/vantage6/issues/59. One measure is that we don't let the user know in case of wrong username/password combination if the username actually exists, to prevent that bots can guess usernames. However, if a wrong password is entered a number of times, the user account is blocked temporarily. This way you could still find out which usernames exist. ### Patches Update to 3.8.0+ ### Workarounds No ### References https://github.com/vantage6/vantage6/issues/59 ### For more information If you have any questions or comments about this advisory: * Email us at [vantage6@iknl.nl](mailto:vantage6@iknl.nl)

Affected versions of this crate were using a debug assertion to validate the `last` parameter of `partial_sort()`. This would allow invalid inputs to cause an out-of-bounds read instead of immediately panicking, when compiled without debug assertions. All writes are bounds-checked, so the out-of-bounds memory access is read-only. This also means that the first attempted out-of-bounds write will panic, limiting the possible reads. The accessible region is further limited by an initial bounds-checked read at `(last / 2) - 1`, i.e., it is proportional to the size of the vector. This bug has been fixed in v0.2.0.

Affected version of this crate had implementation of `From<&mut AsciiStr>` for `&mut [u8]` and `&mut str`. This can result in out-of-bounds array indexing in safe code. The flaw was corrected in commit [8a6c779](https://github.com/tomprogrammer/rust-ascii/pull/63/commits/8a6c7798c202766bd57d70fb8d12739dd68fb9dc) by removing those impls.

### Impact The malicious user is able to update a crafted `config` file into repository's `.git` directory in combination with crafted file deletion to gain SSH access to the server on case-insensitive file systems. All installations with [repository upload enabled (default)](https://github.com/gogs/gogs/blob/f36eeedbf89328ee70cc3a2e239f6314f9021f58/conf/app.ini#L127-L129) on case-insensitive file systems (Windows, macOS, etc.) are affected. ### Patches Make sanitization of upload path to `.git` directory to be case-insensitive. Users should upgrade to 0.12.11 or the latest 0.13.0+dev. ### Workarounds Disable [repository upload](https://github.com/gogs/gogs/blob/f36eeedbf89328ee70cc3a2e239f6314f9021f58/conf/app.ini#L127-L129). ### References https://huntr.dev/bounties/18cf9256-23ab-4098-a769-85f8da130f97/ ### For more information If you have any questions or comments about this advisory, please post on https://github.com/gogs/gogs/issues/7030.

Cross-site Scripting (XSS) - Stored in GitHub repository microweber/microweber 1.3.2 and prior. A patch is available and anticipated to be part of version 1.3.3.