Vulnerability Disclosure Policy

Email security@photonnow.com. Please include enough for us to reproduce it: what you did, what you expected, what happened, and the affected URL, endpoint or agent version. A proof of concept helps enormously. English or Norwegian, whichever you prefer.

We do not currently offer an encrypted channel. If your report includes a working exploit, send the description first and hold the proof of concept until we reply from this address and agree how to exchange it.

Please report privately and give us a chance to fix it before you publish. We do not require you to sign anything, and we will not ask you to stay quiet indefinitely (section 4).

• photonnow.com — the web application, this site and the dashboard.
• app.photonnow.com — the API and the endpoint devices connect to.
• *.tunnel.photonnow.com — the tunnel gateway that publishes device services to the internet.
• artifacts.photonnow.com — the file delivery service, including the signature check it runs.
• The Photon agent that runs on customer devices, its local loopback channel, and its installers.
• The public demo image (photonnow/demo), which contains the real agent.

Things we care about most: anything that crosses the boundary between two customers, anything that escapes the permission model or lets a user reach a device they were not granted, anything that lets a device act as another device, authentication and two-factor bypasses, and anything that turns a tunnel into a path we did not allocate.

• Anything belonging to our providers rather than to us — GitLab, Cloudflare, OVHcloud, Resend and Stripe run their own programmes; report it to them. The hosts in section 2 are ours even where they run on a provider’s infrastructure.
• Denial of service, load testing, and anything that degrades the service for customers. Please do not.
• Social engineering of our staff or our customers, and physical attacks.
• Reports produced solely by a scanner, with no demonstrated impact — missing hardening headers, weak TLS ciphers, cookie flags, version-disclosure banners, or a missing rate limit on an endpoint that is already limited at another layer (the edge, the sign-in path, the connection upgrade). Show us the impact, not the header.
• Behaviour that is documented and deliberate. If you think a documented decision is wrong, tell us why — that is a good report, just not a vulnerability report.
• Anything you can do with access you were legitimately given. A customer administrator can, by design, run commands on their own fleet.

• An acknowledgement within 3 working days.
• An assessment, and our view of severity and of what we intend to do, within 10 working days.
• Progress updates while we work on a fix, and word when it ships.
• Public credit if you want it — we will name you in the Hall of Fame on our Security Researcher Programme page once the fix has shipped — and no objection to you publishing 90 days after your report, sooner if the fix is out. If we need longer we will explain why and agree a date with you rather than announce one.

We do not pay cash for reports. We would rather say so at the top than have you spend a weekend on it expecting otherwise. What a report does earn — a signed letter of recommendation, a place in our Hall of Fame and a reference on request — is described on our Security Researcher Programme page.

If you research in good faith under this policy, we will not pursue or support legal action against you — and we will say so, in writing, to anyone who asks. We consider such research authorised access: it is not unauthorised (“uberettiget”) for the purposes of the Norwegian Penal Code (straffeloven §§ 204–206) or equivalent laws elsewhere, and it is expressly not a breach of our Acceptable Use Policy or our Terms of Service.

Good faith means, concretely:

• Use your own account and your own test devices. Do not touch another customer’s data, another customer’s devices or their tunnels on purpose.
• Access only the minimum needed to demonstrate the problem, and stop as soon as you have. If in doing so you see data that is not yours, do not copy, alter or keep it: tell us in your report what you saw and how much, and delete anything you obtained once we confirm we have reproduced it. Do not pivot further into our systems.
• Do not degrade the service, and do not extort — a report conditioned on payment is not a report.
• Report promptly, and give us the disclosure window in section 4.

If you are unsure whether something is within these limits, ask us first at security@photonnow.com. We would much rather answer a question than lose a report.

If someone else brings a claim against you for research that stayed within this policy, tell us and we will make our position clear to them. We cannot waive rights that belong to third parties, and nothing here authorises you to break the law.

This policy is for flaws in Photon Now itself. If you believe your own account, devices or tokens have been compromised, that is an incident, not a disclosure — write to security@photonnow.com and say so in the subject. What to do first depends on what was compromised:

• A device or its token — delete the device in the dashboard. That revokes its token at once: a deleted device can never reconnect, and a connected agent is disconnected.
• Your account or password — reset your password from the sign-in page, which signs out every session, or have an administrator in your organisation remove the user. Deleting devices does not sign an intruder out of an account.
• A tunnel — delete or disable the rule; the gateway refuses the device’s session at its next heartbeat.

Researchers who reported a vulnerability under this policy and asked to be named are listed in the Hall of Fame on our Security Researcher Programme page.