#oauth

Slack Morphism is an async client library for Rust. Prior to 0.41.0, it was possible for Slack OAuth client information to leak in application debug logs. Stricter and more secure debug formatting was introduced in v0.41.0 for OAuth secret types to reduce the possibility of printing sensitive information in application logs. As a workaround, do not print/output requests and responses for OAuth and client configurations in logs.

Cross-Site Request Forgery (CSRF) vulnerability in JoomUnited WP Meta SEO plugin <= 4.4.8 at WordPress allows an attacker to update the social settings.

### Impact Potential/accidental leaking of Slack OAuth client information in application debug logs. ### Patches More strict and secure debug formatting was introduced in v0.41 for OAuth secret types to avoid the possibility of printing sensitive information in application logs. ### Workarounds Don't print/output in logs request and responses for OAuth and client configurations. ### For more information If you have any questions or comments about this advisory: * Open an issue in the [repo](https://github.com/abdolence/slack-morphism-rust) * Email us at [[email protected]](mailto:[email protected])

Vulnerability in the Oracle Banking Trade Finance product of Oracle Financial Services Applications (component: Infrastructure). The supported version that is affected is 14.5. Difficult to exploit vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Banking Trade Finance. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Banking Trade Finance accessible data as well as unauthorized access to critical data or complete access to all Oracle Banking Trade Finance accessible data. CVSS 3.1 Base Score 6.4 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:N).

Logging Subsystem 5.4.3 - Red Hat OpenShift Red Hat Product Security has rated this update as having a security impact of Moderate. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.This content is licensed under the Creative Commons Attribution 4.0 International License (https://creativecommons.org/licenses/by/4.0/). If you distribute this content, or a modified version of it, you must provide attribution to Red Hat Inc. and provide a link to the original. Related CVEs: * CVE-2021-38561: golang: out-of-bounds read in golang.org/x/text/language leads to DoS

By Deeba Ahmed Checkmarx security researchers have warned about an emerging new supply chain attack tactic involving spoofed metadata commits to present malicious… This is a post from HackRead.com Read the original post: Hackers can spoof commit metadata to create false GitHub repositories

The OAuth Single Sign On WordPress plugin before 6.22.6 doesn't validate that OAuth access token requests are legitimate, which allows attackers to log onto the site with the only knowledge of a user's email address.

### Impact Authenticated users using an external identity provider can continue to use Access Tokens and ID Tokens even after they expire. Using flyteadmin as the OAuth2 Authorization Server is unaffected by this issue. ### Patches 1.1.30 ### Workarounds Rotating signing keys immediately will: * Invalidate all open sessions, * Force all users to attempt to obtain new tokens. Continue to rotate keys until flyteadmin has been upgraded, Hide flyteadmin deployment ingress url from the internet. ### References https://github.com/flyteorg/flyteadmin/pull/455 ### For more information If you have any questions or comments about this advisory: * Open an issue in [flyte repo](https://github.com/flyteorg/flyte/issues) * Email us at [flyte](mailto:[email protected])

Authentication controls added to defend against account hijack threat

Grafana is an open-source platform for monitoring and observability. In versions 5.3 until 9.0.3, 8.5.9, 8.4.10, and 8.3.10, it is possible for a malicious user who has authorization to log into a Grafana instance via a configured OAuth IdP which provides a login name to take over the account of another user in that Grafana instance. This can occur when the malicious user is authorized to log in to Grafana via OAuth, the malicious user's external user id is not already associated with an account in Grafana, the malicious user's email address is not already associated with an account in Grafana, and the malicious user knows the Grafana username of the target user. If these conditions are met, the malicious user can set their username in the OAuth provider to that of the target user, then go through the OAuth flow to log in to Grafana. Due to the way that external and internal user accounts are linked together during login, if the conditions above are all met then the malicious user will...