Hello all,

We recently had a security researcher (aka whitehat hacker) claim to have found a vulnerability in Composr (edit: this became CVE-2021-46360).

However, it came down to a misunderstanding of how the product functions and our fundamental long-standing design choices. I will clarify this all in this post for two reasons:

1. It is important that Composr users understand the nature of Composr
2. It is possible that "vulnerabilities" may be circulated that are in fact, not flaws in the software

Here's what was fundamentally not understood by the researcher:
Any administrator of a Composr site is assumed to have complete control over the code of the product, and can execute commands with the same access the code has. They may do this using Commandr, for example.

The researcher's contention is that we should not allow this. A malicious administrator could impact on the wider web hosting environment.

I can understand this perspective. It is good to separate roles out, to not conflate the security context of the user a CMS runs as, and the security context of the administrator using the CMS.

However, it is totally unrealistic when it comes to Composr for two reasons:

1. Commandr serves a useful purpose, it's an important component of what makes Composr such a flexible, powerful, and efficient system.
2. Composr allows third party addons to be installed via the Admin Zone. This is a fundamental thing for a webmaster to be able to do. It is also fundamental to the design of Composr that all webmaster tasks should be accomplishable through a web interface, which would be achieved via an administrator account. We do not expect our users to have to routinely use SSH, of SFTP, or other separate software, to manage fundamentals of their website; we considered being forced to use third party tools and interfaces archaic 17 years ago when we implemented ocPortal version 2. We have always aimed to make a harmonious system.

If you are running web hosting and installing Composr on someone else's behalf (or you have staff users you would not trust to have the same level to access as the Composr code has), then either:

1. Lock down the hosting so that Composr is hosted on its own account, with its own web user separate from anything else that the administrators should have access to. Or even better, put the Composr site on its own VPS.
2. Don't give the Composr users you cannot trust administrator accounts. It is possible to have different levels of staff account for this reason.

The most security-conscious webmasters may also wish to consider having both administrator and non-adminstrator accounts, so that if their active log in is ever some how compromised it would more likely be their commonly used non-administrator accounts.

We have prepared a note about this for the Composr installation tutorial, which will be updated for our next patch release.