jQuery before 3.4.0, as used in Drupal, Backdrop CMS, and other products, mishandles jQuery.extend(true, {}, ...) because of Object.prototype pollution. If an unsanitized source object contained an enumerable __proto__ property, it could extend the native Object.prototype.

jquery prior to 1.9.0 allows Cross-site Scripting attacks via the load method. The load method fails to recognize and remove "<script>" HTML tags that contain a whitespace character, i.e: "</script >", which results in the enclosed script logic to be executed.

All versions of the package n158 is vulnerable to Command Injection due to improper input sanitization in the 'module.exports' function. **Note:** To execute the code snippet and potentially exploit the vulnerability, the attacker needs to have the ability to run Node.js code within the target environment. This typically requires some level of access to the system or application hosting the Node.js environment.

All versions of the package keep-module-latest is vulnerable to Command Injection due to missing input sanitization or other checks and sandboxes being employed to the installModule function. **Note:** To execute the code snippet and potentially exploit the vulnerability, the attacker needs to have the ability to run Node.js code within the target environment. This typically requires some level of access to the system or application hosting the Node.js environment.

All versions of the package bwm-ng is vulnerable to Command Injection due to improper input sanitization in the 'check' function in the bwm-ng.js file. **Note:** To execute the code snippet and potentially exploit the vulnerability, the attacker needs to have the ability to run Node.js code within the target environment. This typically requires some level of access to the system or application hosting the Node.js environment.

Dolibarr before 17.0.1 allows remote code execution by an authenticated user via an uppercase manipulation: <?PHP instead of <?php in injected data.

An exponential ReDoS (Regular Expression Denial of Service) can be triggered in the jquery-validation npm package, when an attacker is able to supply arbitrary input to the url2 method

Bouncy Castle BC Java before 1.66, BC C# .NET before 1.8.7, BC-FJA before 1.0.1.2, 1.0.2.1, and BC-FNA before 1.0.1.1 have a timing issue within the EC math library that can expose information about the private key when an attacker is able to observe timing information for the generation of multiple deterministic ECDSA signatures.

Code Injection in GitHub repository nilsteampassnet/teampass prior to 3.0.9.

Ruby on Rails 2.3.9 and 3.0.0 does not properly handle nested attributes, which allows remote attackers to modify arbitrary records by changing the names of parameters for form inputs.

Multiple cross-site scripting (XSS) vulnerabilities in the mail_to helper in Ruby on Rails before 2.3.11, and 3.x before 3.0.4, when javascript encoding is used, allow remote attackers to inject arbitrary web script or HTML via a crafted (1) name or (2) email value.

Ruby on Rails 2.1.x, 2.2.x, and 2.3.x before 2.3.11, and 3.x before 3.0.4, does not properly validate HTTP requests that contain an X-Requested-With header, which makes it easier for remote attackers to conduct cross-site request forgery (CSRF) attacks via forged (1) AJAX or (2) API requests that leverage "combinations of browser plugins and HTTP redirects," a related issue to CVE-2011-0696.

Ruby on Rails 2.1 before 2.1.3 and 2.2.x before 2.2.2 does not verify tokens for requests with certain content types, which allows remote attackers to bypass cross-site request forgery (CSRF) protection for requests to applications that rely on this protection, as demonstrated using text/plain.

Camaleon CMS v2.7.0 was discovered to contain a Server-Side Template Injection (SSTI) vulnerability via the formats parameter.

A certain algorithm in Ruby on Rails 2.1.0 through 2.2.2, and 2.3.x before 2.3.4, leaks information about the complexity of message-digest signature verification in the cookie store, which might allow remote attackers to forge a digest via multiple attempts.

Multiple SQL injection vulnerabilities in Ruby on Rails before 2.1.1 allow remote attackers to execute arbitrary SQL commands via the (1) :limit and (2) :offset parameters, related to ActiveRecord, ActiveSupport, ActiveResource, ActionPack, and ActionMailer.

A cross-site scripting vulnerability flaw was found in the auto_link function in Rails before version 3.0.6.

A certain algorithm in Ruby on Rails 2.1.0 through 2.2.2, and 2.3.x before 2.3.4, leaks information about the complexity of message-digest signature verification in the cookie store, which might allow remote attackers to forge a digest via multiple attempts.

### Impact Unicode RIGHT-TO-LEFT OVERRIDE characters can be used to mask the original filename. ### Reported-By Thanks to the report from Mio Li [wulilixi1@gmail.com](mailto:wulilixi1@gmail.com) ### Patches ``` commit 17e791afb90c9ad27c65f63c6be14f2f6a3a9d60 Author: Daniel Valdivia <18384552+dvaldivia@users.noreply.github.com> Date: Tue May 23 08:47:12 2023 -0700 Replace RIGHT-TO-LEFT OVERRIDE unicode (#2828) Signed-off-by: Daniel Valdivia <18384552+dvaldivia@users.noreply.github.com> ``` ### Workarounds Workarounds are to remove the concerned file and rewrite it properly with the right file and extensions. Avoid using RTLO characters in your filenames.

Rekor's goals are to provide an immutable tamper resistant ledger of metadata generated within a software projects supply chain. A malformed proposed entry of the `intoto/v0.0.2` type can cause a panic on a thread within the Rekor process. The thread is recovered so the client receives a 500 error message and service still continues, so the availability impact of this is minimal. This has been fixed in v1.2.0 of Rekor. Users are advised to upgrade. There are no known workarounds for this vulnerability.

A vulnerability was found in the libtiff library. This security flaw causes a heap buffer overflow in extractContigSamples32bits, tiffcrop.c.

A vulnerability was found in the libtiff library. This flaw causes a heap buffer overflow issue via the TIFFTAG_INKNAMES and TIFFTAG_NUMBEROFINKS values.

Craft is a CMS for creating custom digital experiences. Cross site scripting (XSS) can be triggered by review volumes. This issue has been fixed in version 4.4.7.

### Impact With specially crafted requests, incorrect authorization decisions may be made by Pomerium. ### Patches We are releasing patch fixes to address this vulnerability going back to `v0.17.X`. Please upgrade to: - v0.22.2 - v0.21.4 - v0.20.1 - v0.19.2 - v0.18.1 - v0.17.4 ### For more information If you have any questions or comments about this advisory: - Open an issue in [pomerium/pomerium](https://github.com/pomerium/pomerium/issues) - Email us at [security@pomerium.com](mailto:security@pomerium.com)

A security issue was discovered in secrets-store-csi-driver where an actor with access to the driver logs could observe service account tokens. These tokens could then potentially be exchanged with external cloud providers to access secrets stored in cloud vault solutions. Tokens are only logged when [TokenRequests is configured in the CSIDriver object](https://kubernetes-csi.github.io/docs/token-requests.html) and the driver is set to run at log level 2 or greater via the -v flag. This issue has been rated MEDIUM [. and assigned CVE-2023-2878 ### Am I vulnerable? You may be vulnerable if [TokenRequests is configured in the CSIDriver object](https://kubernetes-csi.github.io/docs/token-requests.html) and the driver is set to run at log level 2 or greater via the -v flag. To check if token requests are configured, run the following command: ```bash kubectl get csidriver secrets-store.csi.k8s.io -o jsonpath="{.spec.tokenRequests}" ``` To check if tokens are being logged, examine the secrets-store container log: ```bash kubectl logs -l app=secrets-store-csi-driver -c secrets-store -f | grep --line-buffered "csi.storage.k8s.io/serviceAccount.tokens" ``` ### Affected Versions - secrets-store-csi-driver < 1.3.3 ### How do I mitigate this vulnerability? Prior to upgrading, this vulnerability can be mitigated by running secrets-store-csi-driver at log level 0 or 1 via the -v flag. ### Fixed Versions - secrets-store-csi-driver >= 1.3.3 To upgrade, refer to the documentation: https://secrets-store-csi-driver.sigs.k8s.io/getting-started/upgrades.html#upgrades ### Detection Examine cloud provider logs for unexpected token exchanges, as well as unexpected access to cloud vault secrets. If you find evidence that this vulnerability has been exploited, please contact [security@kubernetes.io](https://groups.google.com/) ### Acknowledgements This vulnerability was reported by Tomer Shaiman @tshaiman from Microsoft.

Craft is a CMS for creating custom digital experiences on the web. The platform does not filter input and encode output in Quick Post validation error message, which can deliver an XSS payload. Old CVE fixed the XSS in label HTML but didn’t fix it when clicking save. This issue was patched in version 4.4.6.

The fix for CVE-2023-24998 was incomplete for Apache Tomcat 11.0.0-M2 to 11.0.0-M4, 10.1.5 to 10.1.7, 9.0.71 to 9.0.73 and 8.5.85 to 8.5.87. If non-default HTTP connector settings were used such that the maxParameterCount could be reached using query string parameters and a request was submitted that supplied exactly maxParameterCount parameters in the query string, the limit for uploaded request parts could be bypassed with the potential for a denial of service to occur.

Highlight is an open source, full-stack monitoring platform. Highlight may record passwords on customer deployments when a password html input is switched to `type="text"` via a javascript "Show Password" button. This differs from the expected behavior which always obfuscates `type="password"` inputs. A customer may assume that switching to `type="text"` would also not record this input; hence, they would not add additional `highlight-mask` css-class obfuscation to this part of the DOM, resulting in unintentional recording of a password value when a `Show Password` button is used. This issue was patched in version 6.0.0. This patch tracks changes to the `type` attribute of an input to ensure an input that used to be a `type="password"` continues to be obfuscated.

Craft is a CMS for creating custom digital experiences on the web. Cross-site scripting (XSS) can be triggered via the Update Asset Index utility. This issue has been patched in version 4.4.6.

A lateral privilege escalation vulnerability in XXL-Job v2.4.1 allows users to execute arbitrary commands on another user's account via a crafted POST request to the component /jobinfo/.

A flaw was found in Keycloak. This flaw depends on a non-default configuration "Revalidate Client Certificate" to be enabled and the reverse proxy is not validating the certificate before Keycloak. Using this method an attacker may choose the certificate which will be validated by the server. If this happens and the KC_SPI_TRUSTSTORE_FILE_FILE variable is missing/misconfigured, any trustfile may be accepted with the logging information of "Cannot validate client certificate trust: Truststore not available". This may not impact availability as the attacker would have no access to the server, but consumer applications Integrity or Confidentiality may be impacted considering a possible access to them. Considering the environment is correctly set to use "Revalidate Client Certificate" this flaw is avoidable.

Jenkins HashiCorp Vault Plugin 360.v0a_1c04cf807d and earlier does not properly mask (i.e., replace with asterisks) credentials in the build log when push mode for durable task logging is enabled.

In Spring Boot versions 3.0.0 - 3.0.6, 2.7.0 - 2.7.11, 2.6.0 - 2.6.14, 2.5.0 - 2.5.14 and older unsupported versions, there is potential for a denial-of-service (DoS) attack if Spring MVC is used together with a reverse proxy cache.

Craft is a CMS for creating custom digital experiences on the web. A malformed RSS feed can deliver an XSS payload. This issue was patched in version 4.4.6.

Those using HtmlUnit to browse untrusted webpages may be vulnerable to Denial of service attacks (DoS). If HtmlUnit is running on user supplied web pages, an attacker may supply content that causes HtmlUnit to crash by a stack overflow. This effect may support a denial of service attack.This issue affects htmlunit before 2.70.0.

A cross-site request forgery (CSRF) vulnerability in Jenkins LDAP Plugin allows attackers to connect to an attacker-specified LDAP server using attacker-specified credentials.

Jenkins Ansible Plugin 204.v8191fd551eb_f and earlier stores extra variables 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.

A carefully crafted request on several JSPWiki plugins could trigger an XSS vulnerability on Apache JSPWiki, which could allow the attacker to execute javascript in the victim's browser and get some sensitive information about the victim. Apache JSPWiki users should upgrade to 2.12.0 or later.

A carefully crafted request on several JSPWiki plugins could trigger an XSS vulnerability on Apache JSPWiki, which could allow the attacker to execute javascript in the victim's browser and get some sensitive information about the victim. Apache JSPWiki users should upgrade to 2.12.0 or later.

Jenkins SAML Single Sign On(SSO) Plugin 2.0.2 and earlier does not perform hostname validation when connecting to miniOrange or the configured IdP to retrieve SAML metadata, which could be abused using a man-in-the-middle attack to intercept these connections.

### Impact Users of the podSecurity (`validate.podSecurity`) subrule in Kyverno 1.9. See the [documentation](https://kyverno.io/docs/writing-policies/validate/#pod-security) for information on this subrule type. Users of Kyverno v1.9.2 and v1.9.3 are affected. ### Patches v1.9.4 v1.10.0 ### Workarounds To work around this issue without upgrading to v1.9.4, temporarily install individual policies for the respective Seccomp checks in baseline [here](https://kyverno.io/policies/pod-security/baseline/restrict-seccomp/restrict-seccomp/) and restricted [here](https://kyverno.io/policies/pod-security/restricted/restrict-seccomp-strict/restrict-seccomp-strict/). ### References * https://kyverno.io/docs/writing-policies/validate/#pod-security * https://github.com/kyverno/kyverno/pull/7263

A NULL pointer dereference flaw was found in Libtiff's LZWDecode() function in the libtiff/tif_lzw.c file. This flaw allows a local attacker to craft specific input data that can cause the program to dereference a NULL pointer when decompressing a TIFF format file, resulting in a program crash or denial of service.

A flaw was found in LibRaw. A heap-buffer-overflow in raw2image_ex() caused by a maliciously crafted file may lead to an application crash.

Storing Passwords in a Recoverable Format in GitHub repository pimcore/customer-data-framework prior to 3.3.10.

There exists a heap buffer overflow in nasm 2.16.02rc1 (GitHub commit: b952891).

Open redirect vulnerability in Tornado versions 6.3.1 and earlier allows a remote unauthenticated attacker to redirect a user to an arbitrary web site and conduct a phishing attack by having user access a specially crafted URL.

Cross-site scripting (XSS) vulnerability in IFrame type Remote Apps in Liferay Portal 7.4.0 through 7.4.3.30, and Liferay DXP 7.4 before update 31 allows remote attackers to inject arbitrary web script or HTML via the Remote App's IFrame URL.

A vulnerability, which was classified as problematic, was found in SiteServer CMS up to 7.2.1. Affected is an unknown function of the file /api/stl/actions/search. The manipulation of the argument ajaxDivId leads to cross site scripting. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. VDB-229818 is the identifier assigned to this vulnerability.

Cross-site scripting (XSS) vulnerability in the App Builder module's custom object details page in Liferay Portal 7.3.0 through 7.4.0, and Liferay DXP 7.3 before update 14 allows remote attackers to inject arbitrary web script or HTML via a crafted payload injected into an App Builder custom object's `Name` field.

Cross-site scripting (XSS) vulnerability in the Modified Facet widget in Liferay Portal 7.1.0 through 7.4.3.12, and Liferay DXP 7.1 before fix pack 27, 7.2 before fix pack 18, 7.3 before update 4, and 7.4 before update 9 allows remote attackers to inject arbitrary web script or HTML via a crafted payload injected into a facet label.

Stored cross-site scripting (XSS) vulnerability in Form widget configuration in Liferay Portal 7.1.0 through 7.3.0, and Liferay DXP 7.1 before fix pack 18, and 7.2 before fix pack 5 allows remote attackers to inject arbitrary web script or HTML via a crafted payload injected into a form's `name` field.

The Object module in Liferay Portal 7.4.3.4 through 7.4.3.60, and Liferay DXP 7.4 before update 61 does not segment object definition by virtual instance in search which allows remote authenticated users in one virtual instance to view object definition from a second virtual instance by searching for the object definition.

Cross-site scripting (XSS) vulnerability in the Account module in Liferay Portal 7.4.3.21 through 7.4.3.62, and Liferay DXP 7.4 update 21 through 62 allows remote attackers to inject arbitrary web script or HTML via a crafted payload injected into a user's (1) First Name, (2) Middle Name, (3) Last Name, or (4) Job Title text field.

An issue was discovered in Auth0 auth0-aspnet and auth0-aspnet-owin. Affected packages do not use or validate the state parameter of the OAuth 2.0 and OpenID Connect protocols. This leaves applications vulnerable to CSRF attacks during authentication and authorization operations.

An issue was discovered in Auth0 auth0-aspnet and auth0-aspnet-owin. Affected packages do not use or validate the state parameter of the OAuth 2.0 and OpenID Connect protocols. This leaves applications vulnerable to CSRF attacks during authentication and authorization operations.

In Liferay Portal 7.3.0 and earlier, and Liferay DXP 7.2 and earlier the default configuration does not require users to verify their email address, which allows remote attackers to create accounts using fake email addresses or email addresses which they don't control. The portal property `company.security.strangers.verify` should be set to true.

A cross-site scripting (XSS) vulnerability in Open Networking Foundation ONOS from version v1.9.0 to v2.7.0 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the url parameter of the API documentation dashboard.

A cross-site scripting (XSS) vulnerability in Open Networking Foundation ONOS from version v1.9.0 to v2.7.0 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the url parameter of the API documentation dashboard.

The Dynamic Data Mapping module in Liferay Portal 7.4.3.67, and Liferay DXP 7.4 update 67 does not limit Document and Media files which can be downloaded from a Form, which allows remote attackers to download any file from Document and Media via a crafted URL.

Cross-site scripting (XSS) vulnerability in Layout module in Liferay Portal 7.3.4 through 7.4.3.68, and Liferay DXP 7.3 before update 24, and 7.4 before update 69 allows remote attackers to inject arbitrary web script or HTML via a crafted payload injected into a container type layout fragment's `URL` text field.

Cross-site scripting (XSS) vulnerability in the Web Content Display widget's article selector in Liferay Liferay Portal 7.4.3.50, and Liferay DXP 7.4 update 50 allows remote attackers to inject arbitrary web script or HTML via a crafted payload injected into a web content article's `Title` field.

### Summary When building packages directly from source control, file permissions on the checked-in files are not maintained. ### Details When building packages directly from source control, file permissions on the checked-in files are not maintained. When nfpm packaged the files (without extra config for enforcing its own permissions) files could go out with bad permissions (chmod 666 or 777). ### PoC Create a default nfpm structure. Within the test folder, create 3 files named `chmod-XXX.sh`. Each script has file permissions set corresponding with their file names (`chmod-777.sh` = `chmod 777`). Below each file and permissions can be seen. ```console $ ls -lart test total 24 -rwxrwxrwx 1 user group 11 May 19 13:15 chmod-777.sh -rw-rw-rw- 1 user group 11 May 19 13:16 chmod-666.sh drwxr-xr-x 5 user group 160 May 19 13:19 . -rw-rw-r-- 1 user group 11 May 19 13:19 chmod-664.sh drwxr-xr-x 10 user group 320 May 19 13:29 .. ``` Below is the snippet nfpm configuration file of the contents of the package. The test folder and files has no extra config for enforcing permissions. ```yaml contents: - src: foo-binary dst: /usr/bin/bar - src: bar-config.conf dst: /etc/foo-binary/bar-config.conf type: config - src: test dst: /etc/test/scripts ``` The next step is to create a deb package. ```console $ nfpm package -p deb # Create dep package using deb packager... created package: foo_1.0.0_arm64.deb ``` When on a Ubuntu VM, install the foo package which was created ```console $ sudo dpkg -i foo_1.0.0_arm64.deb # Installing deb package within Ubuntu Selecting previously unselected package foo. (Reading database ... 67540 files and directories currently installed.) Preparing to unpack foo_1.0.0_arm64.deb ... Unpacking foo (1.0.0) ... Setting up foo (1.0.0) ... ``` Looking at `/etc/test/scripts` and viewing the permissions. Permissions are passed exactly the same as the source. ```console $ ls -lart /etc/test/scripts total 20 -rwxrwxrwx 1 root root 11 May 22 12:15 chmod-777.sh -rw-rw-rw- 1 root root 11 May 22 12:16 chmod-666.sh -rw-rw-r-- 1 root root 11 May 22 12:19 chmod-664.sh drwxr-xr-x 3 root root 4096 May 22 13:00 .. drwxr-xr-x 2 root root 4096 May 22 13:00 . ``` ## Solution To prevent world-writable files from making it into the packages, add the ability to override the default permissions of packaged files using a umask config option in the packaging spec file. This feature in nfpm would allow applying a global umask across any files being packaged, therefore, with the correct configuration, preventing world-writable files without needing to list permissions on each and every file in the package ### Impact Vulnerability is https://cwe.mitre.org/data/definitions/276.html https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N Anyone using nfpm for creating packages and not checking/setting file permissions before packaging could result in bad permissions for files/folders.

### Summary When building packages directly from source control, file permissions on the checked-in files are not maintained. ### Details When building packages directly from source control, file permissions on the checked-in files are not maintained. When nfpm packaged the files (without extra config for enforcing its own permissions) files could go out with bad permissions (chmod 666 or 777). ### PoC Create a default nfpm structure. Within the test folder, create 3 files named `chmod-XXX.sh`. Each script has file permissions set corresponding with their file names (`chmod-777.sh` = `chmod 777`). Below each file and permissions can be seen. ```console $ ls -lart test total 24 -rwxrwxrwx 1 user group 11 May 19 13:15 chmod-777.sh -rw-rw-rw- 1 user group 11 May 19 13:16 chmod-666.sh drwxr-xr-x 5 user group 160 May 19 13:19 . -rw-rw-r-- 1 user group 11 May 19 13:19 chmod-664.sh drwxr-xr-x 10 user group 320 May 19 13:29 .. ``` Below is the snippet nfpm configuration file of the contents of the package. The test folder and files has no extra config for enforcing permissions. ```yaml contents: - src: foo-binary dst: /usr/bin/bar - src: bar-config.conf dst: /etc/foo-binary/bar-config.conf type: config - src: test dst: /etc/test/scripts ``` The next step is to create a deb package. ```console $ nfpm package -p deb # Create dep package using deb packager... created package: foo_1.0.0_arm64.deb ``` When on a Ubuntu VM, install the foo package which was created ```console $ sudo dpkg -i foo_1.0.0_arm64.deb # Installing deb package within Ubuntu Selecting previously unselected package foo. (Reading database ... 67540 files and directories currently installed.) Preparing to unpack foo_1.0.0_arm64.deb ... Unpacking foo (1.0.0) ... Setting up foo (1.0.0) ... ``` Looking at `/etc/test/scripts` and viewing the permissions. Permissions are passed exactly the same as the source. ```console $ ls -lart /etc/test/scripts total 20 -rwxrwxrwx 1 root root 11 May 22 12:15 chmod-777.sh -rw-rw-rw- 1 root root 11 May 22 12:16 chmod-666.sh -rw-rw-r-- 1 root root 11 May 22 12:19 chmod-664.sh drwxr-xr-x 3 root root 4096 May 22 13:00 .. drwxr-xr-x 2 root root 4096 May 22 13:00 . ``` ## Solution To prevent world-writable files from making it into the packages, add the ability to override the default permissions of packaged files using a umask config option in the packaging spec file. This feature in nfpm would allow applying a global umask across any files being packaged, therefore, with the correct configuration, preventing world-writable files without needing to list permissions on each and every file in the package ### Impact Vulnerability is https://cwe.mitre.org/data/definitions/276.html https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N Anyone using nfpm for creating packages and not checking/setting file permissions before packaging could result in bad permissions for files/folders.

A security issue was discovered in ingress-nginx where a user that can create or update ingress objects can use a newline character to bypass the sanitization of the `spec.rules[].http.paths[].path` field of an Ingress object (in the `networking.k8s.io` or `extensions` API group) to obtain the credentials of the ingress-nginx controller. In the default configuration, that credential has access to all secrets in the cluster.

### Impact If Synapse and a malicious homeserver are both joined to the same room, the malicious homeserver can trick Synapse into accepting previously rejected events into its view of the current state of that room. This can be exploited in a way that causes all further messages and state changes sent in that room from the vulnerable homeserver to be rejected. Synapse homeservers are affected by this issue if and only if they are joined to rooms which members of untrusted homeservers are joined or invited to. - Synapse homeservers in rooms available over public federation **are** affected. - Synapse homeservers with federation disabled are not affected. - Synapse homeservers in a closed federation containing only trusted servers are not affected. - Synapse homeservers which are only joined to rooms with federation disabled[^1] are not affected. ### Patches Administrators of homeservers with federation enabled are advised to upgrade to 1.68.0 or higher. ### Workarounds * Federation can be disabled by setting [`federation_domain_allow list`](https://matrix-org.github.io/synapse/latest/usage/configuration/config_documentation.html#federation_domain_allow list) to an empty list (`[]`). ### References - https://github.com/matrix-org/synapse/pull/13723 [^1]: See `m.federate` in the [`m.room.create` definition](https://spec.matrix.org/v1.4/client-server-api/#mroomcreate). ### For more information If you have any questions or comments about this advisory, e-mail us at [security@matrix.org](mailto:security@matrix.org).

The Object module in Liferay Portal 7.4.3.4 through 7.4.3.48, and Liferay DXP 7.4 before update 49 does properly isolate objects in difference virtual instances, which allows remote authenticated users in one virtual instance to view objects in a different virtual instance via OAuth 2 scope administration page.

### Impact The Matrix Federation API allows remote homeservers to request the *authorisation events* of events in a room. This is necessary so that a homeserver receiving some events can validate that those events are legitimate and permitted in their room. However, in versions of Synapse up to and including 1.68.0, a Synapse homeserver answering a query for authorisation events does not sufficiently check that the requesting server should be able to access them. Authorisation events include power level events (the list of user IDs and their power levels at the time) and relevant membership events (including the display name of the sender of that event), as well as events like `m.room.create`, `m.room.third_party_invite` and `m.room.join_rules`. Non-authorisation events are unaffected, so it isn't possible to e.g. extract message contents this way. This issue is only exploitable when a malicious actor knows the ID of a target room and the ID of an event from that room. In most cases, this makes exploitation infeasible. This issue is of negligible consequence for public rooms given that any server can easily join the room in order to be allowed to view authorisation events. Further, deployments in a closed federation where all homeservers are trustworthy are not affected. ### Patches The issue was patched in Synapse 1.69.0. Homeserver administrators are advised to upgrade. ### Workarounds Synapse can be configured with a list of servers that it is allowed to federate with [`federation_domain_allow list`]. If this list is in use and all the servers on the list are trusted not to exploit this issue, then this issue is of no consequence. This workaround is not practical for homeservers participating in open federation as interaction with any server not on the list would have to happen indirectly through servers that are, leading to inconsistent delays in message delivery. `federation_domain_allow list` list ### References Fixed in https://github.com/matrix-org/synapse/pull/13823. ### For more information If you have any questions or comments about this advisory, e-mail us at security@matrix.org.

### Impact Websites that use `Website.user_vars` property in versions. ### Patches It affects versions v2.0.1 to v2.4.0. Please upgrade to v2.4.1 ### Workarounds Do not use `Website.user_vars` in websites when using versions v2.0.1 to v2.4.0. Also, do not use `Website.signin_user()` in version v2.4.0 only. ### Explanation ToUI is using Flask-Caching (SimpleCache) to store user variables. My misunderstanding was that these caches are stored in the client's browser, but it seems that these are stored in the server side.

### Impact A malicious user on a Synapse homeserver X with permission to create certain state events can disable outbound federation from X to an arbitrary homeserver Y. Synapse instances with federation disabled are not affected. #### Details The Matrix protocol allows homeservers to provide an `invite_room_state` field on a [room invite](https://spec.matrix.org/v1.5/client-server-api/#mroommember) containing a [summary of room state](https://spec.matrix.org/v1.5/client-server-api/#stripped-state). In versions of Synapse up to and including v1.73.0, Synapse does not limit the size of `invite_room_state`, meaning that it was possible to create an arbitrarily large invite event. An attacker with an account on a vulnerable Synapse homeserver X could exploit this by having X create an over-sized invite event in a room with a user from another homeserver Y. Once acknowledged by the invitee's homeserver, the invite event would be sent in a batch of events to Y. If the malicious invite is so large that the entire batch is rejected as too large, X's outgoing traffic to Y would become "stuck", meaning that messages and state events created by X would remain unseen by Y. ### Patches Synapse 1.74 refuses to create oversized `invite_room_state` fields. Server operators should upgrade to Synapse 1.74 or newer urgently. ### Workarounds There are no robust workarounds. This attack needs an account on Synapse homeserver X to deny federation from X to another homeserver Y. As a partial mitigation, Synapse operators can disable open registration to limit the ability of attackers to create new accounts on homeserver X. If homeserver X has been attacked in this way, restarting it will resume outgoing federation by entering "catchup mode". For catchup mode to ignore the oversized invites, every attacked room must have a correctly-sized event sent by X which is newer than any oversized invite. This is difficult to arrange, and does not prevent the attacker from repeating their attack. ### References - https://github.com/matrix-org/synapse/issues/14492 was caused by this issue. - https://github.com/matrix-org/synapse/issues/14642 includes the patch described above. ### For more information If you have any questions or comments about this advisory, e-mail us at [security@matrix.org](mailto:security@matrix.org).

Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') in ckan.

Multiple cross-site scripting (XSS) vulnerabilities in the Plugin for OAuth 2.0 module's OAuth2ProviderApplicationRedirect class in Liferay Portal 7.4.3.41 through 7.4.3.52, and Liferay DXP 7.4 update 41 through 52 allow remote attackers to inject arbitrary web script or HTML via the (1) code, or (2) error parameter.

Improper Neutralization in org.igniterealtime.openfire:xmppserver.

Skyscreamer Open Source Nevado JMS v1.3.2 does not perform security checks when receiving messages. This allows attackers to execute arbitrary commands via supplying crafted data.

SQLite JDBC is a library for accessing and creating SQLite database files in Java. Sqlite-jdbc addresses a remote code execution vulnerability via JDBC URL. This issue impacting versions 3.6.14.1 through 3.41.2.1 and has been fixed in version 3.41.2.2.

### Impact A specially crafted Socket.IO packet can trigger an uncaught exception on the Socket.IO server, thus killing the Node.js process.

Insecure Default Initialization of Resource Vulnerability in Apache Software Foundation Apache InLong.This issue affects Apache InLong: from 1.5.0 through 1.6.0. Users registered in InLong who joined later can see deleted users' data. Users are advised to upgrade to Apache InLong's 1.7.0 or cherry-pick https://github.com/apache/inlong/pull/7836 https://github.com/apache/inlong/pull/7836 to solve it.

Vyper is a pythonic Smart Contract Language for the ethereum virtual machine. In contracts with more than one regular nonpayable function, it is possible to send funds to the default function, even if the default function is marked `nonpayable`. This applies to contracts compiled with vyper versions prior to 0.3.8. This issue was fixed by the removal of the global `calldatasize` check in commit `02339dfda`. Users are advised to upgrade to version 0.3.8. Users unable to upgrade should avoid use of nonpayable default functions.

iden3 snarkjs through 0.6.11 allows double spending because there is no validation that the publicSignals length is less than the field modulus.

### Impact This issue only impacts users who: - Have a HTTP policy that applies to multiple `toEndpoints` AND - Have an allow-all rule in place that affects only one of those endpoints In such cases, a wildcard rule will be appended to the set of HTTP rules, which could cause bypass of HTTP policies.

### Impact Potential for cross-site scripting in `posthog-js`. ### Patches The problem has been patched in `posthog-js` version 1.57.2. ### Workarounds - This isn't an issue for sites that have a Content Security Policy in place. - Using the HTML tracking snippet on PostHog Cloud always guarantees the latest version of the library – in that case no action is required to upgrade to the patched version. ### References We will publish details of the vulnerability in 30 days as per our [security policy](https://posthog.com/handbook/company/security#policies).

An attacker who has gained access to an admin account can perform RCE via null-byte injection Vendor: The Apache Software Foundation Versions Affected: Apache OpenMeetings from 2.0.0 before 7.1.0

An attacker that has gained access to certain private information can use this to act as other user. Vendor: The Apache Software Foundation Versions Affected: Apache OpenMeetings from 3.1.3 before 7.1.0

In Hazelcast through 5.0.4, 5.1 through 5.1.6, and 5.2 through 5.2.3, configuration routines don't mask passwords in the member configuration properly. This allows Hazelcast Management Center users to view some of the secrets.

Insecure Default Initialization of Resource Vulnerability in Apache Software Foundation Apache InLong.This issue affects Apache InLong: from 1.5.0 through 1.6.0. Users registered in InLong who joined later can see deleted users' data. Users are advised to upgrade to Apache InLong's 1.7.0 or cherry-pick https://github.com/apache/inlong/pull/7836 https://github.com/apache/inlong/pull/7836 to solve it.

### Impact Since Requests v2.3.0, Requests has been vulnerable to potentially leaking `Proxy-Authorization` headers to destination servers, specifically during redirects to an HTTPS origin. This is a product of how `rebuild_proxies` is used to recompute and reattach the `Proxy-Authorization` header to requests when redirected. Note this behavior has _only_ been observed to affect proxied requests when credentials are supplied in the URL user information component (e.g. `https://username:password@proxy:8080`). **Current vulnerable behavior(s):** 1. HTTP → HTTPS: **leak** 2. HTTPS → HTTP: **no leak** 3. HTTPS → HTTPS: **leak** 4. HTTP → HTTP: **no leak** For HTTP connections sent through the proxy, the proxy will identify the header in the request itself and remove it prior to forwarding to the destination server. However when sent over HTTPS, the `Proxy-Authorization` header must be sent in the CONNECT request as the proxy has no visibility into further tunneled requests. This results in Requests forwarding the header to the destination server unintentionally, allowing a malicious actor to potentially exfiltrate those credentials. The reason this currently works for HTTPS connections in Requests is the `Proxy-Authorization` header is also handled by urllib3 with our usage of the ProxyManager in adapters.py with `proxy_manager_for`. This will compute the required proxy headers in `proxy_headers` and pass them to the Proxy Manager, avoiding attaching them directly to the Request object. This will be our preferred option going forward for default usage. ### Patches Starting in Requests v2.31.0, Requests will no longer attach this header to redirects with an HTTPS destination. This should have no negative impacts on the default behavior of the library as the proxy credentials are already properly being handled by urllib3's ProxyManager. For users with custom adapters, this _may_ be potentially breaking if you were already working around this behavior. The previous functionality of `rebuild_proxies` does not make sense in any case, so we would encourage any users impacted to migrate any handling of Proxy-Authorization directly into their custom adapter. ### Workarounds For users who are not able to update Requests immediately, there is one potential workaround. You may disable redirects by setting `allow_redirects` to `False` on all calls through Requests top-level APIs. Note that if you're currently relying on redirect behaviors, you will need to capture the 3xx response codes and ensure a new request is made to the redirect destination. ``` import requests r = requests.get('http://github.com/', allow_redirects=False) ``` ### Credits This vulnerability was discovered and disclosed by the following individuals. Dennis Brinkrolf, Haxolot (https://haxolot.com/) Tobias Funke, (tobiasfunke93@gmail.com)

Craft CMS is an open source content management system. In affected versions of Craft CMS an unrestricted file extension may lead to Remote Code Execution. If the name parameter value is not empty string('') in the View.php's doesTemplateExist() -> resolveTemplate() -> _resolveTemplateInternal() -> _resolveTemplate() function, it returns directly without extension verification, so that arbitrary extension files are rendered as twig templates. When attacker with admin privileges on a DEV or an improperly configured STG or PROD environment, they can exploit this vulnerability to remote code execution. Code execution may grant the attacker access to the host operating system. This issue has been addressed in version 4.4.6. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Attacker can access arbitrary recording/room Vendor: The Apache Software Foundation Versions Affected: Apache OpenMeetings from 2.0.0 before 7.1.0

Insecure Default Initialization of Resource Vulnerability in Apache Software Foundation Apache InLong.This issue affects Apache InLong: from 1.5.0 through 1.6.0. Users registered in InLong who joined later can see deleted users' data. Users are advised to upgrade to Apache InLong's 1.7.0 or cherry-pick https://github.com/apache/inlong/pull/7836 https://github.com/apache/inlong/pull/7836 to solve it.

Insecure Default Initialization of Resource Vulnerability in Apache Software Foundation Apache InLong.This issue affects Apache InLong: from 1.5.0 through 1.6.0. Users registered in InLong who joined later can see deleted users' data. Users are advised to upgrade to Apache InLong's 1.7.0 or cherry-pick https://github.com/apache/inlong/pull/7836 https://github.com/apache/inlong/pull/7836 to solve it.

Insecure Temporary File in GitHub repository huggingface/transformers prior to 4.30.0.

Allocation of Resources Without Limits or Throttling in GitHub repository froxlor/froxlor prior to 2.0.16.

Cross Site Scripting (XSS) Vulnerability in Fetlife rollout-ui version 0.5, allows attackers to execute arbitrary code via a crafted url to the delete a feature functionality.

Boxo, formerly known as go-libipfs, is a library for building IPFS applications and implementations. In versions 0.4.0 and 0.5.0, if an attacker is able allocate arbitrary many bytes in the Bitswap server, those allocations are lasting even if the connection is closed. This affects users accepting untrusted connections with the Bitswap server and also affects users using the old API stubs at `github.com/ipfs/go-libipfs/bitswap` because users then transitively import `github.com/ipfs/go-libipfs/bitswap/server`. Boxo versions 0.6.0 and 0.4.1 contain a patch for this issue. As a workaround, those who are using the stub object at `github.com/ipfs/go-libipfs/bitswap` not taking advantage of the features provided by the server can refactor their code to use the new split API that will allow them to run in a client only mode: `github.com/ipfs/go-libipfs/bitswap/client`.

Storage of Sensitive Data in a Mechanism without Access Control in GitHub repository francoisjacquet/rosariosis prior to 11.0.

Jenkins jira-ext Plugin 0.8 and earlier stored credentials unencrypted in its global configuration file on the Jenkins master where they could be viewed by users with access to the master file system.