ghsa

### 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 did 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 ...

Specific vulnerabilities: * Arbitrary file write in `resource_create` and `package_update` actions, using the `ResourceUploader` object. Also reachable via `package_create`, `package_revise`, and `package_patch` via calls to `package_update`. * Remote code execution via unsafe pickle loading, via Beaker's session store when configured to use the file session store backend. * Potential DOS due to lack of a length check on the resource id. * Information disclosure: A user with permission to create a resource can access any other resource on the system if they know the id, even if they don't have access to it. * Resource overwrite: A user with permission to create a resource can overwrite any resource if they know the id, even if they don't have access to it. ### Impact A user with permissions to create or edit a dataset can upload a resource with a specially crafted id to write the uploaded file in an arbitrary location. This can be leveraged to Remote Code Execution via Beaker's i...

### 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 * Federati...

### 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...

### Impact bignum releases from v0.12.2 to v0.13.0 (inclusive) used node-pre-gyp to optionally download pre-built binary versions of the addon. These binaries were published on a now-expired S3 bucket which has since been claimed by a malicious third party which is now serving binaries containing malware that exfiltrates data from the user's computer. ### Patches v0.13.1 does not use node-pre-gyp and does not have support for downloading pre-built binaries in any form, avoiding the risk of malicious downloads.

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.

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.

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.

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.