Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
5 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact If SVG or JPEGXL thumbnailers are enabled (they are disabled by default), a user may upload a file which claims to be either of these types and request a thumbnail to invoke a different decoder in ImageMagick. In some ImageMagick installations, this includes the capability to run Ghostscript to decode the image/file. If MP4 thumbnailers are enabled (also disabled by default), the same issue as above may occur with the ffmpeg installation instead. MMR uses a number of other decoders for all other file types when preparing thumbnails. Theoretical issues are possible with these decoders, however in testing they were not possible to exploit. Patches This is fixed in MMR v1.3.8. MMR now inspects the mimetype of media prior to thumbnailing, and picks a thumbnailer based on those results instead of relying on user-supplied values. This may lead to fewer thumbnails when obscure file shapes are used. This also helps narrow scope of theoretical issues with all decoders MMR uses for…
Recommended action: Upgrade to 1.3.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Matrix Media Repo (MMR) is vulnerable to server-side request forgery, serving content from a private network it can access, under certain conditions. Patches This is fixed in MMR v1.3.8. Workarounds Restricting which hosts MMR is allowed to contact via (local) firewall rules or a transparent proxy. References https://owasp.org/www-community/attacks/ServerSideRequestForgery https://learn.snyk.io/lesson/ssrf-server-side-request-forgery/ https://www.agwa.name/blog/post/preventingserversiderequestforgeryingolang
Recommended action: Upgrade to 1.3.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact MMR makes requests to other servers as part of normal operation, and these resource owners can return large amounts of JSON back to MMR for parsing. In parsing, MMR can consume large amounts of memory and exhaust available memory. Patches This is fixed in MMR v1.3.8. Workarounds Forward proxies can be configured to block requests to unsafe hosts. Alternatively, MMR processes can be configured with memory limits and auto-restart. Running multiple MMR processes concurrently can help ensure a restart does not overly impact users.
Recommended action: Upgrade to 1.3.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact MMR before version 1.3.5 is vulnerable to unbounded disk consumption, where an unauthenticated adversary can induce it to download and cache large amounts of remote media files. MMR's typical operating environment uses S3-like storage as a backend, with file-backed store as an alternative option. Instances using a file-backed store or those which self-host an S3 storage system are therefore vulnerable to a disk fill attack. Once the disk is full, authenticated users will be unable to upload new media, resulting in denial of service. For instances configured to use a cloud-based S3 storage option, this could result in high service fees instead of a denial of service. Patches MMR 1.3.5 introduces a new default-on "leaky bucket" rate limit to reduce the amount of data a user can request at a time. This does not fully address the issue, but does limit an unauthenticated user's ability to request large amounts of data. Operators should note that the leaky bucket implementation…
Recommended action: Upgrade to 1.3.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact MMR before version 1.3.5 allows, by design, unauthenticated remote participants to trigger a download and caching of remote media from a remote homeserver to the local media repository. Such content then also becomes available for download from the local homeserver in an unauthenticated way. The implication is that unauthenticated remote adversaries can use this functionality to plant problematic content into the media repository. Patches MMR 1.3.5 introduces a partial mitigation in the form of new endpoints which require authentication for media downloads. The unauthenticated endpoints will be frozen in a future release, closing the attack vector. Workarounds Though extremely limited, server operators can use more strict rate limits based on IP address. References https://github.com/matrix-org/matrix-spec-proposals/pull/3916
Recommended action: Upgrade to 1.3.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.