ghsa

### Impact [CarrierWave::Uploader::ContentTypeAllowlist](https://github.com/carrierwaveuploader/carrierwave/blob/master/lib/carrierwave/uploader/content_type_allowlist.rb) has a Content-Type allowlist bypass vulnerability, possibly leading to XSS. The validation in `allowlisted_content_type?` determines Content-Type permissions by performing a partial match. If the `content_type` argument of `allowlisted_content_type?` is passed a value crafted by the attacker, Content-Types not included in the `content_type_allowlist` will be allowed. In addition, by setting the Content-Type configured by the attacker at the time of file delivery, it is possible to cause XSS on the user's browser when the uploaded file is opened. ### Patches Upgrade to [3.0.5](https://rubygems.org/gems/carrierwave/versions/3.0.5) or [2.2.5](https://rubygems.org/gems/carrierwave/versions/2.2.5). ### Workarounds When validating with `allowlisted_content_type?` in [CarrierWave::Uploader::ContentTypeAllowlist](https:...

### Impact An authenticated backend user with the `editor.cms_pages`, `editor.cms_layouts`, or `editor.cms_partials` permissions who would normally not be permitted to provide PHP code to be executed by the CMS due to `cms.safe_mode` being enabled can write specific Twig code to escape the Twig sandbox and execute arbitrary PHP. This is not a problem for anyone who trusts their users with those permissions to usually write and manage PHP within the CMS by not having `cms.safe_mode` enabled. Still, it would be a problem for anyone relying on `cms.safe_mode` to ensure that users with those permissions in production do not have access to write and execute arbitrary PHP. ### Patches This issue has been patched in v3.4.15. ### Workarounds As a workaround, remove the specified permissions from untrusted users. ### References Credits to: - [Vasiliy Bodrov](https://github.com/whatev3n) ### For more information If you have any questions or comments about this advisory: * Email us at [h...

### Impact An authenticated backend user with the `editor.cms_pages`, `editor.cms_layouts`, or `editor.cms_partials` permissions who would normally not be permitted to provide PHP code to be executed by the CMS due to `cms.safe_mode` being enabled can craft a special request to include PHP code in the CMS template. This is not a problem for anyone who trusts their users with those permissions to usually write & manage PHP within the CMS by not having `cms.safe_mode` enabled. Still, it would be a problem for anyone relying on `cms.safe_mode` to ensure that users with those permissions in production do not have access to write and execute arbitrary PHP. ### Patches This issue has been patched in v3.4.15. ### Workarounds As a workaround, remove the specified permissions from untrusted users. ### References Credits to: - [Vasiliy Bodrov](https://github.com/whatev3n) ### For more information If you have any questions or comments about this advisory: * Email us at [hello@octobercms....

A flaw was found in the Keycloak package. This flaw allows an attacker to benefit from an LDAP query and access existing usernames in the server.

### Impact ZITADEL uses the notification triggering requests Forwarded or X-Forwarded-Host header to build the button link sent in emails for confirming a password reset with the emailed code. If this header is overwritten and a user clicks the link to a malicious site in the email, the secret code can be retrieved and used to reset the users password and take over his account. Accounts with MFA or Passwordless enabled can not be taken over by this attack. ### Patches The patched ZITADEL versions verify, that the auth requests instance is retrieved by the requests original domain (from the Forwarded or X-Forwarded-Host headers if available). If the instance can't be found using the original host or the auth request can't be found within that instance, ZITADEL throws an error. 2.x versions are fixed on >= [2.41.6](https://github.com/zitadel/zitadel/releases/tag/v2.41.6) 2.40.x versions are fixed on >= [2.40.10](https://github.com/zitadel/zitadel/releases/tag/v2.40.10) 2.39.x versio...

Jenkins MATLAB Plugin determines whether a user-specified directory on the Jenkins controller is the location of a MATLAB installation by parsing an XML file in that directory. MATLAB Plugin 2.11.0 and earlier does not perform permission checks in several HTTP endpoints implementing related form validation. Additionally, these HTTP endpoints do not require POST requests, resulting in a cross-site request forgery (CSRF) vulnerability. Additionally, the plugin does not configure its XML parser to prevent XML external entity (XXE) attacks. This allows attackers able to create files on the Jenkins controller file system to have Jenkins parse a crafted XML document that uses external entities for extraction of secrets from the Jenkins controller or server-side request forgery. MATLAB Plugin 2.11.1 configures its XML parser to prevent XML external entity (XXE) attacks. Additionally, POST requests and Item/Configure permission are required for the affected HTTP endpoints.

Jenkins NeuVector Vulnerability Scanner Plugin 1.22 and earlier does not perform a permission check in a connection test HTTP endpoint. This allows attackers with Overall/Read permission to connect to an attacker-specified hostname and port using attacker-specified username and password. Additionally, this HTTP endpoint does not require POST requests, resulting in a cross-site request forgery (CSRF) vulnerability. NeuVector Vulnerability Scanner Plugin 2.2 requires POST requests and Overall/Administer permission for the affected HTTP endpoint.

Jenkins Jira Plugin 3.11 and earlier does not set the appropriate context for credentials lookup, allowing the use of system-scoped credentials otherwise reserved for the global configuration. This allows attackers with Item/Configure permission to access and capture credentials they are not entitled to. Jira Plugin 3.12 defines the appropriate context for credentials lookup.

Jenkins MATLAB Plugin determines whether a user-specified directory on the Jenkins controller is the location of a MATLAB installation by parsing an XML file in that directory. MATLAB Plugin 2.11.0 and earlier does not perform permission checks in several HTTP endpoints implementing related form validation. Additionally, these HTTP endpoints do not require POST requests, resulting in a cross-site request forgery (CSRF) vulnerability. Additionally, the plugin does not configure its XML parser to prevent XML external entity (XXE) attacks. This allows attackers able to create files on the Jenkins controller file system to have Jenkins parse a crafted XML document that uses external entities for extraction of secrets from the Jenkins controller or server-side request forgery. MATLAB Plugin 2.11.1 configures its XML parser to prevent XML external entity (XXE) attacks. Additionally, POST requests and Item/Configure permission are required for the affected HTTP endpoints.

Jenkins Google Compute Engine Plugin 4.550.vb_327fca_3db_11 and earlier does not correctly perform permission checks in multiple HTTP endpoints. This allows attackers with global Item/Configure permission (while lacking Item/Configure permission on any particular job) to do the following: - Enumerate system-scoped credentials IDs of credentials stored in Jenkins. Those can be used as part of an attack to capture the credentials using another vulnerability. - Connect to Google Cloud Platform using attacker-specified credentials IDs obtained through another method, to obtain information about existing projects. Google Compute Engine Plugin 4.551.v5a_4dc98f6962 requires Overall/Administer permission for the affected HTTP endpoints.