A security report about this project may be a safety report. Safe Kiln Controller switches several kilowatts into a kiln. If you have found something that lets an attacker start or prolong heating, say so in the first line and we will treat it as the safety matter it is, not as a web bug.

Email security@bitcrushtesting.com. That address is the single point of contact required by Article 13(17) of the Cyber Resilience Act, and it is read by a person rather than a ticket queue.

Please do not open a public issue for something exploitable. Public issues are the right place for everything else, including hardening suggestions and the "this looks wrong but I cannot exploit it" category.

What helps, in rough order of usefulness:

• the firmware version (GET /api/info, or the local display's info screen) and the board revision from the label;
• what you had access to: the LAN, the board, a debugger, the update service;
• what the device did, and what you expected;
• whether heating was involved, and whether the independent cutout of SYS-HW-13 was fitted on the unit you tested.

You do not need a proof of concept. A clear description of the mechanism is worth more than an exploit we have to reverse.

If a fix will take longer than 90 days, we will say so and why rather than let the date pass quietly. If you intend to publish, tell us when; we would rather coordinate than be surprised, and we will not ask you to delay indefinitely.

Credit is given in the advisory unless you ask us not to. There is no bug bounty: this is a small project and we would rather be honest about that than imply a payment that is not coming.

Separately from this policy, and not at the reporter's discretion: an actively exploited vulnerability or a severe incident is reported to ENISA and the relevant CSIRT within 24 hours as an early warning, with a notification within 72 hours and a final report within 14 days, under Article 14 of the Cyber Resilience Act. Those obligations apply from 11 September 2026. Users are informed without undue delay in the same cases.

Security fixes are released separately from functional changes wherever that is feasible, marked as security releases in the update manifest, and accompanied by an advisory (SWR-UPD-16).

The device checks update.bitcrushtesting.com once a day, verifies a signed manifest against a key compiled into its own firmware, and announces an available release on the local display. It installs only when somebody confirms there; it never installs by itself, and nothing on the network can initiate, authorise or cancel an install.

That last property is deliberate and is the reason an update may sit unapplied: rebooting a kiln controller into untried firmware unattended, with a load inside, is not an acceptable trade for promptness (docs/security.md §6.2, SWR-UPD-12). If you own one of these, installing an offered update is your step, and docs/security.md §10.1 is the rest of what the design asks of you.

A local update over USB is the recovery path when the service is unreachable or an image will not confirm itself (SWR-UPD-14).

• The firmware in this repository, both microcontrollers.
• The REST API and the browser assets.
• The update path, the manifest format and tools/update-manifest.py.
• The provisioning tools, tools/secure-boot.py and tools/prod-data.py.
• The safety supervisor's trip logic, where a defect in it is a safety matter whether or not anybody can trigger it remotely.

Each of these is written down, argued, and carried as a named residual risk in docs/security.sdoc. A report that restates one of them adds nothing; a report that shows one is worse than documented, or combines with something else into an attack, is very welcome.

That last row matters for anyone testing: a vulnerability in code that has never been built for a device is a real finding about the design, but please say which you mean.

• The user's network, router, browser or WiFi infrastructure, except where this project depends on them and says so.
• Denial of service that requires being on the LAN already: the control loop and the safety supervisor are isolated from the network by construction (SEC-08), so the worst case is a lost web interface, not a lost kiln. If you can show otherwise, that is in scope and important.
• Social engineering, and anything requiring the operator to confirm a firmware install they were not expecting. We would still like to hear about the latter if the prompt is misleading.

The threat model is not a paragraph in this file. It is docs/security.md with its nodes in docs/security.sdoc: seven assets, six adversaries, fifteen threats, fifteen security goals and thirteen residual risks, each with who carries it. §7 is the part worth reading first, on why a security compromise of this device is a safety event.