Security policy

mySites.guru is operated by Blue Flame Digital Solutions Limited, United Kingdom. If you have found a vulnerability in our platform or in the connector we install on customer sites, we want to hear about it, and we will not take legal action against you for telling us.

Connecting a site does not make it less secure

We design assuming our own systems will eventually be attacked, and we build for what happens after that rather than assuming it will not. The connector on your site authenticates every instruction before acting on it, so even someone with complete access to our own database could not use that access to run a command on a customer's server. The same boundary holds in the other direction: a site that gets compromised, through us or through anything else, has no path back into mySites.guru itself.

Connecting a site does not open it up to anyone else. Access runs through mySites.guru to you and no one else, over an encrypted connection, with the same layered security built into the platform from day one rather than added later.

That containment is deliberate. The platform runs across multiple layers, spread over several physical servers, largely as distributed, read-only Docker services, so a single compromised component does not hand an attacker anywhere further to go. We do not publish every layer of that design. Doing so would only help someone looking for a way in. What is described here is real, and it is the product of more than a decade running this service, most of it hard-won.

Connecting a site to mySites.guru does not add risk to it. The whole point of the architecture above is that it removes risk instead.

What we commit to

We will keep you updated as we work through it, credit you when the fix ships if you want the credit, and tell you honestly if we decide not to fix something and why. These are outside limits, not the norm: in practice we are usually much faster.

Safe harbour

We will not pursue or support legal action against anyone who reports a vulnerability in good faith under this policy, provided you:

• •Use only your own sites and your own account for testing.
• •Do not access, modify or retain another customer's data. If you encounter someone else's data by accident, stop and tell us.
• •Do not degrade the service. No denial of service, no load testing, no automated scanning that generates significant traffic.
• •Do not use social engineering, physical attacks, or attacks against our staff or suppliers.
• •Give us a reasonable window to fix the problem before disclosing it.

We do not currently run a paid bug bounty. Reports are handled on the terms above.

Scope

If you have found a vulnerability in a CMS extension that affects many of our customers, we would still like to know, so we can add detection for it even though it is out of scope for a report about us.

Problems in our dependencies

If you find a problem in one of our third-party dependencies rather than in our own code, tell us anyway. We report it upstream to whoever maintains the component and share any patch we write, as required by Article 13(6) of the EU Cyber Resilience Act, and we mitigate it on our side in the meantime. We keep a CycloneDX software bill of materials for the platform and regenerate it on every dependency change.

Security updates and support period

Security updates are free and delivered automatically. The connector updates itself in place on your server when a new version is released, with no action required from you or your host. For that to work, the connector directory must remain writable by the web server user, which is covered on the information for web hosts page.

We provide security updates for the platform and for every supported connector for the lifetime of your subscription. There is no fixed cut-off date after which a subscribing customer stops receiving security fixes.

Regulatory context

Last reviewed 29 August 2026. Machine-readable version of this policy: /.well-known/security.txt (RFC 9116).