ghsa

### Overview Lemur was using insecure random generation for its example configuration file, as well as for some utilities. ### Impact The potentially affected generated items include: | Configuration item | Config option name (if applicable) | Documentation link (if applicable) | Rotation option | Code reference(s) | | ----------- | ----------- | ----------- | ----------- |----------- | | Flask session secret | `SECRET_KEY` | [Flask documentation](https://flask.palletsprojects.com/en/2.2.x/config/#SECRET_KEY) | Generate a new secret and place in config; all existing sessions will be invalidated | N/A, internal to Flask | | Lemur token secret | `LEMUR_TOKEN_SECRET` | [Lemur's configuration documentation](https://lemur.readthedocs.io/en/latest/administration.html#configuration) | Generate a new secret and place in config; all existing JWTs will be invalidated and must be regenerated (including API keys) | [1](https://github.com/Netflix/lemur/blob/1b61194a936240103f3c232...

### Impact When the URL parameters contain certain special characters, it returns an error page that does not properly handle XSS vulnerabilities, allowing for the execution of arbitrary JavaScript code. Users who access the deliberately constructed URL are affected. ### Patches This vulnerability was fixed in version c910c4d28717fb860fbe064736641f379fab2c91. Please upgrade to this or a later version. ### Workarounds No.

The `execute-actions-email` endpoint of the Keycloak Admin REST API allows a malicious actor to send emails containing phishing links to Keycloak users.

A reflected cross-site scripting (XSS) vulnerability was found in the `oob` OAuth endpoint due to incorrect null-byte handling. This issue allows a malicious link to insert an arbitrary URI into a Keycloak error page.

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 [[email protected]](mailto:[email protected])

### 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 [[email protected]](mailto:[email protected])