ghsa

A flaw was found in Keycloak. When an authenticated attacker attempts to merge accounts with another existing account during an identity provider (IdP) login, the attacker will subsequently be prompted to "review profile" information. This vulnerability allows the attacker to modify their email address to match that of a victim's account, triggering a verification email sent to the victim's email address. The attacker's email address is not present in the verification email content, making it a potential phishing opportunity. If the victim clicks the verification link, the attacker can gain access to the victim's account.

A vulnerability in the DocugamiReader class of the run-llama/llama_index repository, up to but excluding version 0.12.41, involves the use of MD5 hashing to generate IDs for document chunks. This approach leads to hash collisions when structurally distinct chunks contain identical text, resulting in one chunk overwriting another. This can cause loss of semantically or legally important document content, breakage of parent-child chunk hierarchies, and inaccurate or hallucinated responses in AI outputs. The issue is resolved in version 0.3.1.

### Summary Several `#dpl` parameters can leak usernames that have been hidden using revision deletion, suppression, or the `hideuser` block flag. ### Details The parameters `adduser`, `addauthor`, and `addlasteditor` output the page creator or last editor using the `%USER%` placeholder. These display the actual username, even when that name has been hidden using revision deletion, suppression (oversight), or `hideuser`. The `%CONTRIBUTOR%` placeholder, used with `addcontribution`, behaves similarly and also reveals hidden usernames. In addition, the following parameters can expose suppressed usernames when combined with `%USER%` or similar output placeholders: - `lastrevisionbefore` - `allrevisionsbefore` - `firstrevisionsince` - `allrevisionssince` These parameters reference specific revisions and allow output of user-related metadata. If a username has been hidden from those revisions, it may still appear in the output. Further, the parameters `createdby`, `notcreatedby`, `modi...

## GitHub Personal Access Token Exposure in docusaurus-plugin-content-gists ### Summary docusaurus-plugin-content-gists versions prior to 4.0.0 are vulnerable to exposing GitHub Personal Access Tokens in production build artifacts when passed through plugin configuration options. The token, intended for build-time API access only, is inadvertently included in client-side JavaScript bundles, making it accessible to anyone who can view the website's source code. ### Affected Versions - All versions < 4.0.0 ### Patched Versions - Version 4.0.0 and later ### Impact When using the affected versions with the recommended configuration pattern: ```javascript plugins: [ [ 'docusaurus-plugin-content-gists', { personalAccessToken: process.env.GITHUB_PERSONAL_ACCESS_TOKEN, }, ], ] ``` The GitHub Personal Access Token is included in the webpack bundle and exposed in production builds at: - `/build/assets/js/main.[hash].js` This allows malicious actors to: - Extract ...

Jenkins Applitools Eyes Plugin 1.16.5 and earlier stores Applitools API keys unencrypted in job config.xml files on the Jenkins controller, where they can be viewed by users with Item/Extended Read permission or access to the Jenkins controller file system.

Jenkins Warrior Framework Plugin 1.2 and earlier stores passwords unencrypted in job config.xml files on the Jenkins controller, where they can be viewed by users with Item/Extended Read permission or access to the Jenkins controller file system.

Jenkins Applitools Eyes Plugin 1.16.5 and earlier does not mask Applitools API keys displayed on the job configuration form, increasing the potential for attackers to observe and capture them.

Jenkins Xooa Plugin 0.0.7 and earlier stores the Xooa Deployment Token unencrypted in its global configuration file on the Jenkins controller, where it can be viewed by users with access to the Jenkins controller file system.

Jenkins User1st uTester Plugin 1.1 and earlier stores the uTester JWT token unencrypted in its global configuration file on the Jenkins controller, where it can be viewed by users with access to the Jenkins controller file system.

Jenkins VAddy Plugin 1.2.8 and earlier does not mask Vaddy API Auth Keys displayed on the job configuration form, increasing the potential for attackers to observe and capture them.