Release Notes for v0.65.3
Security Fix: Race Condition in Role Validation
What was affected
A race condition in the user role validation logic could allow permission checks to succeed based on stale role data. Under very specific timing conditions, concurrent requests during a role change (e.g., while an admin was being demoted) could bypass intended authorization checks.
Exploit Potential
If an administrator account was being demoted while simultaneously performing privileged actions, a race window existed where the system could still treat the user as having elevated permissions.
In a coordinated scenario involving two administrator accounts, this could potentially allow privilege escalation — for example, promoting a user to Owner during the demotion window.
Conditions Required
Exploitation required:
• Two administrator accounts.
• One administrator being actively demoted.
• Concurrent privileged requests executed precisely during the demotion process.
• Precise timing to trigger the race condition.
This issue required intentional coordination and timing, making it unlikely to occur accidentally.
What’s New
Client & Mobile Improvements
- Batched macOS DNS domains to avoid truncation issues.
#5368 - Ensured route settlement on iOS before handling DNS responses.
#5360 - Added logging of lock acquisition time in message handling for improved observability.
#5393
Relay Improvements
- Reduced QUIC initial packet size to 1280 bytes (IPv6 minimum MTU) for better compatibility.
#5374
Management Improvements
- Fixed possible race condition on user role change.
#5395 - Added docker login step in management tests.
#5323
Self-Hosted Updates
- Added a migration script for upgrading from pre-v0.65.0 to post-v0.65.0 combined setup.
#5350 - Removed unused configuration example from self-hosted setup.
#5383
Miscellaneous
- Updated timestamp format to include milliseconds.
#5387
Full Changelog: v0.65.2…v0.65.3