Security policy

Reporting a vulnerability

Email [email protected]. Please do not open a public issue, and please do not post it anywhere else first.

What helps, in rough order of usefulness:

• Which component: the control plane, the Craft connector, the wire protocol, the recovery tool, or the hosted service.
• The version or commit you tested against.
• Steps to reproduce, ideally against a local installation rather than a live one.
• What an attacker gets out of it, in one sentence.
• Whether you intend to publish, and when.

You do not need a proof of concept, and you do not need to have exploited it. A clear description of a mistake in the code is a valid report.

What we commit to

Stage	Commitment
Acknowledgement	Within two working days, from a person, not an autoresponder.
Assessment	An initial view of severity and whether we agree it is a vulnerability, within five working days.
Updates	At least every two weeks while a fix is being prepared, and immediately if our assessment changes.
Advisory	Published when a fix is available, or 90 days after the report, whichever comes first.
Credit	Named in the advisory if you want to be, anonymous if you do not. Your choice, asked before publication.

The 90-day limit runs whether or not we have finished. A vulnerability that takes longer than that to fix is one that users need to know about so they can decide for themselves.

What is in scope

All four public repositories, and the hosted service:

• The control plane, AGPL-3.0-or-later. This is Manager itself, and what a self-hoster runs.
• The Craft connector, MIT. The plugin that runs inside a customer's own Craft installation.
• The wire protocol, MIT. The signing and payload contract between the two.
• The recovery tool, MIT. The offline command line tool that decrypts a backup artefact.
• The hosted service at the console, including billing, key wrapping and backup storage.
• This website.

Particularly welcome, because they are the claims the whole product rests on:

• Anything that lets one organisation see another organisation's data.
• Anything that lets a request be accepted without a valid signature, or a signature be replayed.
• Anything that makes a connector do something outside the three registered jobs.
• Anything that gets a credential into the platform database, or out of it.
• Anything that modifies or removes an audit event.
• Anything that lets a backup be sealed to a key the site has not pinned.

What is out of scope

• Findings from an automated scanner with no demonstrated impact.
• Missing headers or configuration on this marketing site, which holds no account, no session and no data.
• Denial of service through volume, and anything requiring physical access or a compromised end-user device.
• Social engineering of us, our customers or our suppliers.
• Vulnerabilities in Craft CMS itself. Report those to Pixel & Tonic.
• Self-hosted installations misconfigured against the documented setup. Tell us anyway if the documentation is what misled you, because that is our bug.

Safe harbour

If you make a good-faith effort to follow this policy, we will not pursue or support any legal action against you for your research, and we will say so in writing if a third party raises one.

Good faith means, concretely:

• Test against your own account, your own sites or a local installation. The source is public and runs under Docker, so there is no reason to test against somebody else's data.
• Stop as soon as you have confirmed a vulnerability. Do not pivot, do not escalate, and do not go looking through anything you reach.
• Do not modify or delete data that is not yours, and do not degrade the service for anybody else.
• If you do access personal data by accident, stop, tell us, and delete your copy.
• Give us the disclosure window above before publishing.

Supported versions

Security fixes go to the current minor release. The previous minor keeps receiving them for 90 days after it is superseded, which is enough time to plan an upgrade rather than do one the same afternoon.

Every release is tagged with an SSH-signed git tag, published with a SHA256 checksum file and a CycloneDX software bill of materials, and produced from a reproducible archive. The signing keys are listed in the repository, so you can verify a release came from us rather than trusting that it did. See verifying a release.

We do not run a bug bounty

There is no payment for a report. Manager is a small product from a small studio and a bounty we could not honour would be worse than not offering one. What you get is a fast reply from the person who wrote the code, credit in the advisory if you want it, and a fix.

If you are worried about your own installation

Self-hosted installations ship with manager:doctor, which checks the things that go wrong in practice: wildcard trusted proxies, a non-atomic replay store, missing audit triggers, an insecure session cookie, a superuser database role, missing keypairs and an open setup route. Run it after every upgrade.

If you believe a site connected to Manager has been compromised, revoke its connector from the site's settings screen. It stops reporting and loses every capability in the same transaction, and the site itself is unaffected, because Manager never had the ability to change it.