The bubblewrap Project follows the Security and Disclosure Information Policy for the Containers Projects.

If bubblewrap is setuid root, then the goal is that it does not allow a malicious local user to do anything that would not have been possible on a kernel that allows unprivileged users to create new user namespaces. For example, CVE-2020-5291 was treated as a security vulnerability in bubblewrap.

If bubblewrap is not setuid root, then it is not a security boundary between the user and the OS, because anything bubblewrap could do, a malicious user could equally well do by writing their own tool equivalent to bubblewrap.

bubblewrap is a toolkit for constructing sandbox environments. bubblewrap is not a complete, ready-made sandbox with a specific security policy.

Some of bubblewrap's use-cases want a security boundary between the sandbox and the real system; other use-cases want the ability to change the layout of the filesystem for processes inside the sandbox, but do not aim to be a security boundary. As a result, the level of protection between the sandboxed processes and the host system is entirely determined by the arguments passed to bubblewrap.

Whatever program constructs the command-line arguments for bubblewrap (often a larger framework like Flatpak, libgnome-desktop, sandwine or an ad-hoc script) is responsible for defining its own security model, and choosing appropriate bubblewrap command-line arguments to implement that security model.

For example, CVE-2017-5226 (in which a Flatpak app could send input to a parent terminal using the TIOCSTI ioctl) is considered to be a Flatpak vulnerability, not a bubblewrap vulnerability.