Reporting a vulnerability
Email hello@html2wp.dev with SECURITY in the subject. Please do not report a security problem through a public GitHub issue. Issues there are public from the moment someone files them, so every user of the skill would be exposed to the problem before there was an update to install.
How to report
Include everything needed to reproduce the problem: the version or commit, the steps, and what you expected instead. A proof of concept (a working demonstration of the exploit) helps and is welcome, but you do not need one to report something.
The /v1/report endpoint described in the documentation is not the right channel for this: it is a mailbox for generator defects, and a person reads it alongside ordinary bug reports.
What to expect
- Confirmation that we received the report within 3 working days.
- An assessment of the problem and a rough timeline within 10 working days.
- A mention in the release notes if you want one, and none if you would rather not.
If it goes quiet
We are a small operation, not a company with a security team. If a report goes unanswered past those deadlines, send it again: we missed it, we are not ignoring it.
What is in scope
- The skill and the scripts in
skills/html2wp/assets/scripts/, which run on your own machine. - The conversion service at
api.html2wp.dev. - The WordPress theme the service generates, including the PHP runtime it ships and the content importer.
Things worth reporting even when they look small: anything that reads or transmits files outside the input directory and the workspace, anything that lets one conversion see another, anything in a generated theme that is reachable without authentication, and anything that makes a finished conversion hand over a theme it should have refused.
What is out of scope
- Findings against a WordPress, PHP or plugin version you chose to run, where the fix is to update it.
- The throwaway WordPress in Docker that
test-env.shuses for local verification. It has a fixed admin password on purpose, listens only on127.0.0.1, and is deleted after each run. It is a test fixture, not a deployed site. - Reports that a licence check can be removed from the client. Yes, it can: the client is yours and you can edit it. Nothing security-relevant depends on that check. The service decides what you are entitled to, and the paid parts are exactly the ones it refuses to produce without a key.
- Volumetric denial-of-service attacks (flooding the service with requests) against
api.html2wp.dev, and findings that amount to running a scanner against it.
Testing against the service
Test against your own conversions and your own licence key. Do not attempt to reach another account's jobs, artifacts or workspaces. If you believe you have found a way to, that is exactly the report to send us, and describing the method is enough. You do not need to prove it on somebody else's data.
What leaves your machine
The data page and the plugin's own README describe this, because a security policy is the wrong place to learn it for the first time. In short: the built site goes up to the service, and the conversion runs on it. The gate verdicts are reported separately and contain only names and numbers. Stage 1 filters files that look like credentials out of the payload and lists every one it dropped. If you find something that gets past that filter, it is in scope.