Upgrading from Fossil 2.1 to something more recent hasn't been a priority; I have to go through the versions and verify no new features will cause problems when hosting untrusted repositories, and I haven't done that.
I guess you’re worried about CSRF, XSS and such?
There was an XSS fix in 2.3, and there’s one still pending for the current release. I didn’t pay attention to who noticed these problems and wanted these fixes, but if you’d asked me yesterday, I’d have guessed Chiselapp!
If you would like to volunteer to do that then it'll go faster ! :-D
Would it be easier to switch to a technology like BSD jails or Illumos zones that let you run a separate Fossil instance for each customer, so that you don’t have to worry about how multiple customers’ Fossil instances will interact?
With Fossil’s option of a single statically-linked executable, you might end up with only a handful of files in each container, so that the attack surface is little more than Fossil itself, and if exploited, all you get access to is the repository data within that single container.
cgroups based containers on Linux (e.g. Docker, though not limited to it) are reportedly not as strong as BSD jails or Illumos zones:
Yet, they may be strong enough for this purpose, given its tight scoping.
chroot() might even be strong enough given the tight scoping. None of the ways I’m aware of to escape a chroot() apply to a minimal Fossil-in-a-box configuration. Most of these methods require root access inside the chroot, and there isn’t cause for that, not even for low-numbered port binding, since your HTTPS front end could map external URLs to high-numbered internal port numbers.