#auth

### Impact Versions [v9.26.0](https://github.com/octokit/webhooks.js/releases/tag/v9.26.0), [v10.9.x](https://github.com/octokit/webhooks.js/releases/tag/v10.9.1)), [v11.1.x](https://github.com/octokit/webhooks.js/releases/tag/v11.1.1), [v12.0.x](https://github.com/octokit/webhooks.js/releases/tag/v12.0.3) all contained the code that would throw the error. Specifically, during a pentest we encountered a bug in the octokit/webhooks library (a dependency of Probot, a framework for building Github Apps). The resulting request was found to cause an uncaught exception that ends the nodejs process. The problem is caused by an issue with error handling in the @octokit/webhooks library because the error can be undefined in some cases. Credit goes to @pb82 (for the early analysis) and @rh-tguittet (for discovery). ### Patches Maintenance releases for the Error being thrown by the verify method in [octokit/webhooks.js](https://github.com/octokit/webhooks.js) * v12 - [v12.0.4](https://githu...

### Impact The Solr-based search in XWiki discloses the password hashes of all users to anyone with view right on the respective user profiles. By default, all user profiles are public. To reproduce, it is sufficient to search for `propertyvalue:?* AND reference:*.password` and then deselect the "Document" property under "Result type" in the "Refine your search" widget at the right of the search results. If this displays any passwords or password hashes, the installation is vulnerable. By default, passwords in XWiki are salted and hashed with SHA-512. On XWiki versions affected by [CVE-2022-41933](https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-q2hm-2h45-v5g3), passwords are stored in plain text if they have been set using the password reset feature. This might affect XWiki installations that are using an external authentication mechanism such that passwords aren't stored in the wiki. This vulnerability also affects any configurations used by extensions that contain ...

### Summary The login page discloses all active user accounts to any unauthenticated browsing request originating on the Local Area Network. ### Details Starting the [Home Assistant 2023.12 release](https://www.home-assistant.io/blog/2023/12/06/release-202312/), the login page returns all currently active user accounts to browsing requests from the Local Area Network. Tests showed that this occurs when: - The request is not authenticated and - The request originated locally, meaning on the Home Assistant host local subnet or any other private subnet (`10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, fd00::/8, ::ffff:10.0.0.0/104, ::ffff:172.16.0.0/108, ::ffff:192.168.0.0/112`) The rationale behind this is to make the login more user-friendly (see [release blog post](https://www.home-assistant.io/blog/2023/12/06/release-202312/)) and an experience better aligned with other applications that have multiple user-profiles. However, as a result, all accounts are displayed regardless of them ...

ONTAP 9 versions 9.12.1P8, 9.13.1P4, and 9.13.1P5 are susceptible to a vulnerability which will cause all SAS-attached FIPS 140-2 drives to become unlocked after a system reboot or power cycle or a single SAS-attached FIPS 140-2 drive to become unlocked after reinsertion. This could lead to disclosure of sensitive information to an attacker with physical access to the unlocked drives.

octokit/webhooks is a GitHub webhook events toolset for Node.js. Starting in 9.26.0 and prior to 9.26.3, 10.9.2, 11.1.2, and 12.0.4, there is a problem caused by an issue with error handling in the @octokit/webhooks library because the error can be undefined in some cases. The resulting request was found to cause an uncaught exception that ends the nodejs process. The bug is fixed in octokit/webhooks.js 9.26.3, 10.9.2, 11.1.2, and 12.0.4, app.js 14.02, octokit.js 3.1.2, and Protobot 12.3.3.

Bazarr manages and downloads subtitles. In version 1.2.4, the proxy method in bazarr/bazarr/app/ui.py does not validate the user-controlled protocol and url variables and passes them to requests.get() without any sanitization, which leads to a blind server-side request forgery (SSRF). This issue allows for crafting GET requests to internal and external resources on behalf of the server. 1.3.1 contains a partial fix, which limits the vulnerability to HTTP/HTTPS protocols.

XWiki Platform is a generic wiki platform. Starting in 7.2-milestone-2 and prior to versions 14.10.15, 15.5.2, and 15.7-rc-1, the Solr-based search in XWiki discloses the password hashes of all users to anyone with view right on the respective user profiles. By default, all user profiles are public. This vulnerability also affects any configurations used by extensions that contain passwords like API keys that are viewable for the attacker. Normally, such passwords aren't accessible but this vulnerability would disclose them as plain text. This has been patched in XWiki 14.10.15, 15.5.2 and 15.7RC1. There are no known workarounds for this vulnerability.

app/Controller/AuditLogsController.php in MISP before 2.4.182 mishandles ACLs for audit logs.

Google will soon roll out its Tracking Protection feature to some randomly chosen users in order to prepare for a full deployment.

An improper certificate validation issue in Smartcard authentication in GitLab EE affecting all versions from 11.6 prior to 16.4.4, 16.5 prior to 16.5.4, and 16.6 prior to 16.6.2 allows an attacker to authenticate as another user given their public key if they use Smartcard authentication. Smartcard authentication is an experimental feature and has to be manually enabled by an administrator.