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.
Wondering whether it is safe to connect your sites?
This page is for security researchers: how to report a vulnerability, our response targets and our safe harbour terms. If you are deciding whether to connect your own or your clients' sites to mySites.guru, read Is it safe to connect my clients' sites to mySites.guru? instead. It covers what you share when you connect a site, how the connector and platform are secured, and who has access on our side.
Report a vulnerability
Email phil@phil-taylor.com with what the issue is, where you found it, the steps to reproduce it, and what an attacker could do with it. A short proof of concept is worth more than a scanner report.
You do not need to be a customer, and you do not need a formal write-up. A clear email is enough. Please report privately and give us a chance to fix it before going public.
Using AI to help find or draft the report is fine. What matters is that a person has read it before it reaches us: the issue needs to be real, reproducible, and described in terms you understand, not passed straight through from a model or scanner. Reports that read as unreviewed AI output, generic best-practice nitpicks, or a list of unverified claims get closed without much attention, the same as they would from a person submitting the same thing.
What we commit to
- Acknowledge your report
- 3 working days
- Initial assessment and severity
- 10 working days
- Fix for a critical or actively exploited issue
- Usually same week
- Fix for everything else
- By severity
- Public disclosure, coordinated with you
- Within 90 days
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 run a bug bounty programme or a bounty payment process, and reports are handled on the terms above. For an exceptional report I may personally consider a payment, at my discretion.
Scope
In scope
- manage.mysites.guru, the web application and its API
- worker.mysites.guru, background job processing
- monitor.mySites.guru, the uptime monitoring engine
- utility.mySites.guru, inbound mail processing
- The connectors we distribute for Joomla 3/4/5/6, WordPress and the generic platform
- Our OAuth2 and MCP endpoints
Out of scope
- Vulnerabilities in Joomla, WordPress or third-party extensions themselves. Report those to the vendor.
- Vulnerabilities in a customer's own site that we monitor. Those belong to the site owner.
- Findings with no demonstrated impact: missing headers with no exploit path, SPF/DMARC configuration, version disclosure, self-XSS, raw scanner output.
- The connector payload cipher (the RSA + RC4 layer) reported as weak in itself. It runs inside TLS for obfuscation and speed, and it is not what authenticates a request. We will read any report that demonstrates defeating the request validation callback.
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.
Connector calls are signed with Web Bot Auth (Ed25519), so a firewall can verify they came from us. The public key is at manage.mysites.guru/.well-known/http-message-signatures-directory.
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
We treat the connector as software placed on the EU market, and the platform as the remote data processing solution it depends on, which puts both inside the scope of the EU Cyber Resilience Act (Regulation (EU) 2024/2847). See our full CRA statement for where we sit in law.
On that basis, from 11 September 2026 we report actively exploited vulnerabilities and severe incidents to ENISA and our national CSIRT within 24 hours of becoming aware of them, with a fuller notification at 72 hours and a final report within 14 days. Reporting a vulnerability to us privately helps us meet those deadlines. It does not put you under any obligation.
Last reviewed . Machine-readable version of this policy: /.well-known/security.txt (RFC 9116).