Half-Shot

**Name of the Vulnerable Software and Affected Versions** matrix-hookshot versions 5.4.1 and earlier matrix-hookshot versions 6.0.1 and earlier **Description** The issue is related to a Denial of Service (DoS) condition that can occur when the software is configured with GitHub support. This happens due to a missing check, allowing the software to crash on restart. The impact is greater when untrusted users can add their own GitHub organizations to connect their room to a repository. The vulnerability is exploited by insufficient validation of unusual or exceptional states when connecting to the GitHub platform, potentially allowing a remote attacker to cause a denial of service. **Recommendations** For matrix-hookshot version 5.4.1 and earlier, update to version 5.4.2 to resolve the issue. For matrix-hookshot version 6.0.1 and earlier, update to version 6.0.2 to resolve the issue.

**Name of the Vulnerable Software and Affected Versions** matrix-hookshot versions prior to 4.5.0 **Description** The issue affects matrix-hookshot, a Matrix bot for connecting to external services like GitHub, GitLab, JIRA, and more. Instances with enabled transformation functions, specifically those that have `generic.allowJsTransformationFunctions` in their config, may be vulnerable to an attack where it is possible to break out of the `vm2` sandbox. This problem is more likely to affect users who have allowed untrusted users to apply their own transformation functions. The threat is reduced, though not eliminated, for users who have only enabled a limited set of trusted users. **Recommendations** For versions prior to 4.5.0, upgrade to version 4.5.0 or above, which includes a new sandbox library for better protection. For users unable to upgrade, disable `generic.allowJsTransformationFunctions` in the config as a temporary workaround.

**Name of the Vulnerable Software and Affected Versions** matrix-appservice-irc versions prior to 1.0.1 **Description** The issue allows an attacker to craft a command with newlines that would not be properly parsed, enabling them to pass a string of commands as a channel name, which would then be executed by the IRC bridge bot. **Recommendations** For versions prior to 1.0.1, upgrade to version 1.0.1 or above to resolve the issue. As a temporary workaround, consider disabling dynamic channels in the config to disable the most common execution method.

**Name of the Vulnerable Software and Affected Versions** matrix-appservice-bridge versions 4.0.0 through 8.1.1 matrix-appservice-bridge versions 9.0.0 **Description** A malicious Matrix server can use a foreign user's MXID in an OpenID exchange, allowing a bad actor to impersonate users when using the provisioning API. The library does not check that the servername part of the `sub` parameter (containing the user's *claimed* MXID) is the same as the servername we are talking to. A malicious actor could spin up a server on any given domain, respond with a `sub` parameter according to the user they want to act as and use the resulting token to perform provisioning requests. **Recommendations** For matrix-appservice-bridge versions 4.0.0 through 8.1.1, update to version 8.1.2 or later. For matrix-appservice-bridge version 9.0.0, update to version 9.0.1 or later. As a temporary workaround, consider disabling the provisioning API. If the bridge does not use the provisioning API, you are not vulnerable.

**Name of the Vulnerable Software and Affected Versions** Matrix-appservice-bridge versions 2.6.0 and earlier **Description** The issue concerns the Matrix communication program's application services, specifically the bridging service. If a bridge has room upgrade handling turned on in the configuration, any `m.room.tombstone` event encountered will be used to unbridge the current room and bridge into the target room. However, the target room `m.room.create` event is not checked to verify if the `predecessor` field contains the previous room. This allows any malicious admin of a bridged room to repoint the traffic to a different room without the new room being aware. **Recommendations** For versions 2.6.0 and earlier, update to version 2.6.1 or greater to resolve the issue. As a temporary workaround for versions 2.6.0 and earlier, consider disabling the automatic room upgrade handling by removing the `roomUpgradeOpts` key from the `Bridge` class options.