TwinRoot operates on real disks, physical boot volumes, kernel filesystems, and guest boot chains. Security-relevant issues include, but are not limited to:
- loss or corruption of user data on physical volumes;
- unauthorized access to physical Windows or Linux installations;
- privilege escalation through the host daemon, guest agents, or kernel module;
- bypass of storage ownership or boot safety checks;
- protocol forgery between host and guest components.
Please do not open a public GitHub issue for security vulnerabilities.
Report vulnerabilities privately to the TwinRoot maintainers by opening a GitHub Security Advisory on the repository, or by contacting the maintainers through the channels listed in the repository profile.
Include, where possible:
- a description of the issue and its impact;
- the components involved (host daemon, guest agent, TwinFS, hypervisor adapter, UI, protocol);
- reproduction steps in a disposable environment;
- suggested mitigation, if any.
You will receive an acknowledgement within a reasonable timeframe. Please allow time for assessment and coordination before any public disclosure.
We credit responsible reporters when a fix is released, unless you prefer to remain anonymous.
TwinRoot is designed to fail closed. Any operation involving a real disk, partition, filesystem, EFI environment, or boot volume must refuse to continue when safety cannot be verified. Refusing to start a VM is always preferable to risking data corruption. See AGENTS.md, section 10 "Storage Operations Must Fail Closed".
The following are explicitly unsupported and may cause data loss:
- Windows Fast Startup or hibernation during TwinRoot transitions;
- simultaneous block-level ownership of the same volume by two drivers;
- using TwinRoot components with irreplaceable data before they are declared stable.
See the public documentation for the current project status.