Security Vulnerabilities, CVEs

Jenkins OpenId Connect Authentication Plugin 2.6 and earlier improperly determines that a redirect URL after login is legitimately pointing to Jenkins, allowing attackers to perform phishing attacks.

Jenkins OpenId Connect Authentication Plugin 2.6 and earlier stores a password of a local user account used as an anti-lockout feature in a recoverable format, allowing attackers with access to the Jenkins controller file system to recover the plain text password of that account, likely gaining administrator access to Jenkins.

Missing permission checks in Jenkins Nexus Platform Plugin 3.18.0-03 and earlier allow attackers with Overall/Read permission to connect to an attacker-specified HTTP server using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins.

A cross-site request forgery (CSRF) vulnerability in Jenkins Nexus Platform Plugin 3.18.0-03 and earlier allows attackers to connect to an attacker-specified HTTP server using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins.

Missing permission checks in Jenkins Nexus Platform Plugin 3.18.0-03 and earlier allow attackers with Overall/Read permission to send an HTTP request to an attacker-specified URL and parse the response as XML.

A cross-site request forgery (CSRF) vulnerability in Jenkins Nexus Platform Plugin 3.18.0-03 and earlier allows attackers to send an HTTP request to an attacker-specified URL and parse the response as XML.

A missing permission check in Jenkins Scriptler Plugin 342.v6a_89fd40f466 and earlier allows attackers with Overall/Read permission to read the contents of a Groovy script by knowing its ID.

Jenkins Scriptler Plugin 342.v6a_89fd40f466 and earlier does not restrict a file name query parameter in an HTTP endpoint, allowing attackers with Scriptler/Configure permission to delete arbitrary files on the Jenkins controller file system.

When processing a PGP/MIME payload that contains digitally signed text, the first paragraph of the text was never shown to the user. This is because the text was interpreted as a MIME message and the first paragraph was always treated as an email header section. A digitally signed text from a different context, such as a signed GIT commit, could be used to spoof an email message. This vulnerability affects Thunderbird < 115.6.

The signature of a digitally signed S/MIME email message may optionally specify the signature creation date and time. If present, Thunderbird did not compare the signature creation date with the message date and time, and displayed a valid signature despite a date or time mismatch. This could be used to give recipients the impression that a message was sent at a different date or time. This vulnerability affects Thunderbird < 115.6.

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. It's possible to execute a Velocity script without script right through the document tree. This has been patched in XWiki 14.10.7 and 15.2RC1.

MindsDB is a SQL Server for artificial intelligence. Prior to version 23.11.4.1, the `put` method in `mindsdb/mindsdb/api/http/namespaces/file.py` does not validate the user-controlled name value, which is used in a temporary file name, which is afterwards opened for writing on lines 122-125, which leads to path injection. Later in the method, the temporary directory is deleted on line 151, but since we can write outside of the directory using the path injection vulnerability, the potentially dangerous file is not deleted. Arbitrary file contents can be written due to `f.write(chunk)` on line 125. Mindsdb does check later on line 149 in the `save_file` method in `file-controller.py` which calls the `_handle_source` method in `file_handler.py` if a file is of one of the types `csv`, `json`, `parquet`, `xls`, or `xlsx`. However, since the check happens after the file has already been written, the files will still exist (and will not be removed due to the path injection described earlier), just the `_handle_source` method will return an error. The same user-controlled source source is used also in another path injection sink on line 138. This leads to another path injection, which allows an attacker to delete any `zip` or `tar.gz` files on the server.

Grackle is a GraphQL server written in functional Scala, built on the Typelevel stack. The GraphQL specification requires that GraphQL fragments must not form cycles, either directly or indirectly. Prior to Grackle version 0.18.0, that requirement wasn't checked, and queries with cyclic fragments would have been accepted for type checking and compilation. The attempted compilation of such fragments would result in a JVM `StackOverflowError` being thrown. Some knowledge of an applications GraphQL schema would be required to construct such a query, however no knowledge of any application-specific performance or other behavioural characteristics would be needed. Grackle uses the cats-parse library for parsing GraphQL queries. Prior to version 0.18.0, Grackle made use of the cats-parse `recursive` operator. However, `recursive` is not currently stack safe. `recursive` was used in three places in the parser: nested selection sets, nested input values (lists and objects), and nested list type declarations. Consequently, queries with deeply nested selection sets, input values or list types could be constructed which exploited this, causing a JVM `StackOverflowException` to be thrown during parsing. Because this happens very early in query processing, no specific knowledge of an applications GraphQL schema would be required to construct such a query. The possibility of small queries resulting in stack overflow is a potential denial of service vulnerability. This potentially affects all applications using Grackle which have untrusted users. Both stack overflow issues have been resolved in the v0.18.0 release of Grackle. As a workaround, users could interpose a sanitizing layer in between untrusted input and Grackle query processing.

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.

Resque is a Redis-backed Ruby library for creating background jobs, placing them on multiple queues, and processing them later. Reflected XSS issue occurs when /queues is appended with /"><svg%20onload=alert(domain)>. This issue has been patched in version 2.6.0.

Resque is a Redis-backed Ruby library for creating background jobs, placing them on multiple queues, and processing them later. The following paths in resque-web have been found to be vulnerable to reflected XSS: "/failed/?class=<script>alert(document.cookie)</script>" and "/queues/><img src=a onerror=alert(document.cookie)>". This issue has been patched in version 2.2.1.

Resque (pronounced like "rescue") is a Redis-backed library for creating background jobs, placing those jobs on multiple queues, and processing them later. resque-web in resque versions before 2.1.0 are vulnerable to reflected XSS through the current_queue parameter in the path of the queues endpoint. This issue has been patched in version 2.1.0.

XWiki Platform is a generic wiki platform. Starting in 2.3 and prior to versions 14.10.15, 15.5.2, and 15.7-rc-1, anyone who can edit an arbitrary wiki page in an XWiki installation can gain programming right through several cases of missing escaping in the code for displaying sections in the administration interface. This impacts the confidentiality, integrity and availability of the whole XWiki installation. Normally, all users are allowed to edit their own user profile so this should be exploitable by all users of the XWiki instance. This has been fixed in XWiki 14.10.15, 15.5.2 and 15.7RC1. The patches can be manually applied to the `XWiki.ConfigurableClassMacros` and `XWiki.ConfigurableClass` pages.

XWiki Platform is a generic wiki platform. Starting in 2.3 and prior to versions 14.10.15, 15.5.2, and 15.7-rc-1, there is a reflected XSS or also direct remote code execution vulnerability in the code for displaying configurable admin sections. The code that can be passed through a URL parameter is only executed when the user who is visiting the crafted URL has edit right on at least one configuration section. While any user of the wiki could easily create such a section, this vulnerability doesn't require the attacker to have an account or any access on the wiki. It is sufficient to trick any admin user of the XWiki installation to visit the crafted URL. This vulnerability allows full remote code execution with programming rights and thus impacts the confidentiality, integrity and availability of the whole XWiki installation. This has been fixed in XWiki 14.10.15, 15.5.2 and 15.7RC1. The patch can be manually applied to the document `XWiki.ConfigurableClass`.

XWiki Platform is a generic wiki platform. Starting in 4.5-rc-1 and prior to versions 14.10.15, 15.5.2, and 15.7-rc-1, the search administration interface doesn't properly escape the id and label of search user interface extensions, allowing the injection of XWiki syntax containing script macros including Groovy macros that allow remote code execution, impacting the confidentiality, integrity and availability of the whole XWiki instance. This attack can be executed by any user who can edit some wiki page like the user's profile (editable by default) as user interface extensions that will be displayed in the search administration can be added on any document by any user. The necessary escaping has been added in XWiki 14.10.15, 15.5.2 and 15.7RC1. As a workaround, the patch can be applied manually applied to the page `XWiki.SearchAdmin`.

XWiki Platform is a generic wiki platform. Prior to versions 14.10.15, 15.5.2, and 15.7-rc-1, the Solr-based search in XWiki discloses the email addresses of users even when obfuscation of email addresses is enabled. To demonstrate the vulnerability, search for `objcontent:email*` using XWiki's regular search interface. This has been fixed in XWiki 14.10.15, 15.5.2 and 15.7RC1 by not indexing email address properties when obfuscation is enabled. There are no known workarounds for this vulnerability.

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.

Home Assistant is open source home automation software. Prior to version 2023.12.3, the login page discloses all active user accounts to any unauthenticated browsing request originating on the Local Area Network. Version 2023.12.3 contains a patch for this issue. When starting the Home Assistant 2023.12 release, 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. The rationale behind this is to make the login more user-friendly and an experience better aligned with other applications that have multiple user-profiles. However, as a result, all accounts are displayed regardless of them having logged in or not and for any device that navigates to the server. This disclosure is mitigated by the fact that it only occurs for requests originating from a LAN address. But note that this applies to the local subnet where Home Assistant resides and to any private subnet that can reach it.

yii2-authclient is an extension that adds OpenID, OAuth, OAuth2 and OpenId Connect consumers for the Yii framework 2.0. In yii2-authclient prior to version 2.2.15, the Oauth2 PKCE implementation is vulnerable in 2 ways. First, the `authCodeVerifier` should be removed after usage (similar to `authState`). Second, there is a risk for a `downgrade attack` if PKCE is being relied on for CSRF protection. Version 2.2.15 contains a patch for the issue. No known workarounds are available.

Speckle Server provides server, frontend, 3D viewer, and other JavaScript utilities for the Speckle 3D data platform. A vulnerability in versions prior to 2.17.6 affects users who: authorized an application which requested a 'token write' scope or, using frontend-2, created a Personal Access Token (PAT) with `token write` scope. When creating a new token an agent needs to authorise the request with an existing token (the 'requesting token'). The requesting token is required to have token write scope in order to generate new tokens. However, Speckle server was not verifying that other privileges granted to the new token were not in excess of the privileges of the requesting token. A malicious actor could use a token with only token write scope to subsequently generate further tokens with additional privileges. These privileges would only grant privileges up to the existing privileges of the user. This vulnerability cannot be used to escalate a user's privileges or grant privileges on behalf of other users. This has been patched as of version 2.17.6. All operators of Speckle servers should upgrade their server to version 2.17.6 or higher. Any users who authorized an application with 'token write' scope, or created a token in frontend-2 with `token write` scope should review existing tokens and permanently revoke any they do not recognize, revoke existing tokens and create new tokens, and review usage of their account for suspicious activity. No known workarounds for this issue exist.