Report a security vulnerability

What's in scope

Everything Melanite publishes:

• The Melanite device image: the operating system and runtime for the Melanite Panel and other Raspberry Pi CM5 installations, including its web interface and APIs.
• The Melanite Docker image.
• The Melanite companion app.
• melanite.io: the website, the customer portal and the API behind them.

Not all of these are publicly released yet. If you have a build from us, it's in scope.

Out of scope

• Services run by others, such as our hosting provider, our CDN or our payment provider. Please report those to them.
• Vulnerabilities in third-party components that don't affect Melanite. If one does, tell us: we'll fix it on our side and pass it on to the component's maintainers.
• A device administrator running their own HTML and JavaScript on HMI pages. That's the feature, not a flaw. A way for someone else to inject script is in scope.
• Working around the licence check on a device you control. The licence isn't a security boundary. Forging a validly signed licence token, however, is in scope.
• Denial-of-service and load tests, spam, social engineering, and physical attacks on people or premises.
• Findings without a demonstrated impact, such as scanner output on its own, missing headers or version strings.

Test safely

Melanite controls real machines, so how you test matters as much as what you find.

• Test only on devices, containers and accounts you own or have explicit permission to test. Never on someone else's installation.
• Don't test on an installation that drives motors, heaters or anything else that can hurt people or damage equipment. Use a bench setup instead.
• On melanite.io, use accounts you created yourself. Don't access, change or delete other people's data. If you come across personal data, stop, don't keep it, and tell us.
• No denial of service, and no guessing passwords for other people's accounts.

How to report

Email security@melanite.io. A good report tells us:

• What's affected: the product and version (device image version, Docker tag, app version) or the URL.
• What an attacker could do, and what they need first: network access, an account, physical access.
• How to reproduce it, with a proof of concept if you have one.
• Whether anyone else knows, for example because it's already public or being exploited.
• Whether and how you'd like to be credited.

We don't have a PGP key yet. If you'd rather not send details by plain email, send a short message without them first and we'll agree on a safer way to exchange them.

Please don't use the contact form or public channels for vulnerabilities. We use what you send only to handle your report; see section 6 of the privacy policy.

What happens next

1. Within 5 business daysWe confirm that your report has arrived.
2. Within 10 business daysWe tell you whether we could reproduce it, how serious we think it is and what we plan to do.
3. Until it's fixedWe keep you updated, and you can ask for the status at any time.
4. When the fix shipsWe publish an advisory on this page and credit you, if you'd like.

We don't reply to messages that only ask for payment or only contain out-of-scope findings.

Business days are Monday to Friday, excluding public holidays in Rhineland-Palatinate, where we're based. We're a small team: these are targets we hold ourselves to, not guarantees. If you haven't heard from us in time, write again. If that doesn't work either, you can turn to CERT-Bund at BSI, Germany's national coordinator for vulnerability disclosure.

Coordinated disclosure

Please keep the details private until a fix is released or 90 days after your report, whichever comes first. After that, publishing is up to you.

If a fix needs longer, we'll explain why and ask you for more time. That's a request, not a condition.

Melanite devices often run offline and install updates when their owners decide to, so a fix reaches machines more slowly than a change to a website. For that reason we may ask for a short delay after a release, again as a request.

If a vulnerability is being actively exploited, we may agree with you to publish sooner, so people can protect themselves. Where appropriate, we request a CVE identifier for the advisory.

Safe harbour

If you act in good faith and follow this policy, we consider your research on our systems authorised. We won't take legal action against you or file a criminal complaint over it. If someone else takes action against you for research that followed this policy, we'll make it known that you had our authorisation.

Good faith means:

• You follow the testing rules above.
• You use a vulnerability only as far as needed to show it exists, and delete any data you obtained once the case is closed.
• You give us the time set out under coordinated disclosure.
• You don't make demands. Asking for payment in return for not publishing isn't good faith.

This covers only our systems and our own rights. We can't grant permission on behalf of others, such as our providers or a customer whose machine runs Melanite. Unsure whether something is covered? Ask us first at security@melanite.io.

No bug bounty

We don't pay rewards for reports. If you'd like, we'll thank you publicly, in the advisory for what you found.

EU Cyber Resilience Act

The Cyber Resilience Act (Regulation (EU) 2024/2847) requires manufacturers to report actively exploited vulnerabilities in their products. That duty has applied since 11 September 2026, and we follow it. If a vulnerability you report is being actively exploited, we notify it through ENISA's Single Reporting Platform to CERT-Bund at BSI, Germany's designated coordinator, and to ENISA, within the Act's deadlines:

• an early warning within 24 hours of becoming aware of it;
• a vulnerability notification within 72 hours;
• a final report no later than 14 days after a fix or mitigation is available.

We also inform affected users and tell them what to do. Our notifications describe the vulnerability; they name you only if you agree.

Advisories

No advisories have been published yet.