Coordinated Vulnerability Disclosure Policy
How to report a security vulnerability in Titan OS software
Version 3.1 · Last updated 9 September 2026
Titan OS develops the operating system and related services used in smart televisions. This policy explains how to report a security vulnerability in that software, how we handle it, and how we coordinate disclosure.
We treat every good-faith report seriously and we would rather hear about a problem than not. This policy sets predictable expectations for both sides.
1. Scope
In scope
Titan OS software integrated into smart televisions, including firmware and embedded software, and the backend and cloud services that support Titan OS functionality. This includes third-party and open-source components that ship inside Titan OS software — a vulnerability in a library, kernel or rendering engine we ship is in scope even though we did not write it.
Mobile and web applications delivered as part of a Titan OS offering.
Reports from security researchers, customers, partners, integrating brands and users alike.
Out of scope
The following are generally out of scope. If a proof of concept shows that any of them affects the confidentiality, integrity or availability of Titan OS software, we will treat it as in scope.
Physical attacks requiring disassembly, JTAG or debug ports.
Social engineering or phishing of Titan OS staff or partners.
Volumetric network flooding. Resource exhaustion and algorithmic complexity issues that can be triggered by ordinary input are in scope.
Issues affecting only rooted, modified or otherwise unsupported builds.
Interface glitches and cosmetic errors with no security impact.
Crashes that do not lead to code execution, privilege escalation, or a persistent loss of function.
Content-protection bypass.
Metadata or version disclosure that exposes nothing sensitive.
Automated scanner output submitted without any demonstration of impact.
Vulnerabilities in systems or services not owned or operated by Titan OS. This does not exclude third-party components that ship inside our software, which are in scope as stated above.
Clickjacking or open redirect on non-sensitive pages, and cross-site request forgery on non-sensitive or unauthenticated endpoints, without demonstrated impact.
Missing hardening measures that do not enable exploitation, and absence of rate limiting on non-sensitive actions.
Broken links, mixed content, error pages revealing nothing sensitive, and self-inflicted issues that cannot be used against another user.
One exception to the proof-of-concept expectation
A report that a vulnerability is being exploited against real systems is always in scope, with or without a proof of concept. Send us the evidence you have — log extracts with timestamps, indicators of compromise, the request or payload observed.
Observed exploitation is handled on a different and faster track than a vulnerability report, and we would rather receive it incomplete than not at all.
This policy does not authorise testing against third-party systems, partner infrastructure, or any service Titan OS does not own or operate.
2. How to report
Anonymous reports are accepted. Contact details let us coordinate remediation and credit you if you want to be credited.
If your finding is on a specific television, tell us the brand and model — but you do not need to work out whether the issue is ours or the brand’s before reporting it. That is our job. Report it to us, and where the finding belongs to the brand rather than to us we will pass it to that brand’s published security contact and tell you that we have. We do not pass on your identity or your contact details unless you agree to it. What the brand does with the report from there is for the brand.
What to include
Product name and model, and the affected software or firmware version, or the URL of the affected service.
A technical description with reproduction steps, and any proof of concept, logs or screenshots.
The attack vector, any preconditions for exploitation, and the impact.
Whether you have observed the vulnerability being exploited, and the evidence for that.
A suggested mitigation, if you have one.
Reports should be in English or Spanish. Please keep any hosted proof-of-concept media private. Where the same issue is reported more than once, the first reporter is credited.
3. How we handle a report
Triage normally takes a few working days. You are welcome to ask for a status update at any point, and we will respond as soon as we can. You will be told the outcome either way — accepted and being fixed, accepted and not being fixed with the reason, or out of scope with the reason. If you think an out-of-scope call is wrong, reply and say so and we will look again; that is not an appeal process, it is just us re-reading it.
4. Coordinated disclosure
Please do not disclose publicly before a fix or mitigation is available.
Ninety days from your report is our working target for coordinated disclosure. Shorter where user impact is high; longer where remediation or fleet rollout genuinely requires it, agreed with you rather than announced to you. One dependency is worth stating in advance rather than discovering at day eighty: we build and supply the fix, but the decision to deploy it to devices belongs to the company that placed the television on the market. Where that rollout is what is holding disclosure, we will say so and tell you where it stands.
Public disclosure normally coincides with the fix being available and distributable by the brands.
When we disclose, we publish what the vulnerability was, which versions were affected, its impact and severity, and what a user needs to do about it. Where publishing before the update has reached devices would raise the risk rather than reduce it, we hold publication until it has.
Where the vulnerability is in a component we ship but do not maintain, we report it to whoever maintains that component and, where we have developed a fix, we offer it to them. That route is slower than one we control, and we will tell you when a timeline depends on an upstream maintainer rather than on us.
Where a vulnerability is already being exploited, the ninety-day target does not apply. Timing is agreed case by case and the priority is getting a fix to devices.
Vulnerability communications are confidential until disclosure is coordinated, except where a statutory reporting obligation requires notification to an authority. See section 6.
5. Safe harbour
Research conducted in good faith under this policy is authorised. Titan OS will not pursue legal action against, or refer to law enforcement, a researcher who acts in good faith and within this policy — meaning you:
Avoid privacy violations, destruction of data, and disruption of service.
Test only systems you own or are authorised to test, and only Titan OS software within the scope above. A television you own is a system you own, and testing the Titan OS software on it is within this policy. That does not extend to software or services on the same television that belong to the brand or to another third party.
Do not exploit a vulnerability beyond what is needed to demonstrate it, and do not pivot, persist or exfiltrate data.
Do not disclose publicly without coordinating with us.
Using automated tools does not by itself remove this protection. What matters is that testing stays in scope and does not harm our systems or anyone else’s. If you are unsure whether something is authorised, ask us at security@titanos.tv before proceeding.
What this safe harbour does not cover
It is given by Titan OS and it binds Titan OS only. Titan OS software runs on televisions placed on the market by other companies, and it integrates components supplied by others. This policy cannot grant, and does not grant, any authorisation or protection on behalf of an integrating brand, a device manufacturer, a component supplier, a network operator or any other third party, and it does not displace any applicable law.
If your testing may touch a system or a product that is not ours, seek authorisation from whoever operates it. If you are not sure who that is, ask us and we will tell you what we can.
6. Statutory notification
Titan OS is a manufacturer under Regulation (EU) 2024/2847 Cyber Resilience Act (hereinafter, “CRA”) in respect of the operating system it supplies. From 11 September 2026, where a vulnerability in that software is being actively exploited, or where a severe incident affects its security, we are required to notify the coordinating CSIRT and ENISA within the deadlines the CRA sets. That obligation applies whatever we have agreed with you about disclosure timing, and an embargo between us cannot suspend it.
What this means for you. We will tell you when we make such a notification, and what it covered. We will not include your identity in it unless the law requires us to or you agree. Coordinating public disclosure with you is unaffected: a notification to an authority is not a public disclosure. Where the vulnerability is being actively exploited, disclosure timing is agreed case by case, as set out in section 4.
7. Personal data
Do not attempt to access personal or sensitive data. If you encounter it inadvertently: stop, do not save, copy or transfer it, and tell us immediately at security@titanos.tv so we can contain it.
If you give us contact details we use them to coordinate the report and, if you want it, to credit you. We keep the case record for as long as we need it to handle the vulnerability and to meet the record-keeping obligations that apply to us. If you would rather we held nothing about you, report anonymously (it does not reduce how seriously we treat the report).
If you have any questions about how we process your personal data or wish to exercise your rights, please contact us at data@titanos.tv
8. Credit
Titan OS does not currently offer monetary rewards. We are glad to credit reporters, or to leave you unnamed, whichever you prefer. We will ask you which, and how you want to be named, before we publish anything.
Acknowledgements
We thank the people who report security issues to us and coordinate disclosure while a fix is prepared. No entries are published yet. Nobody is listed here without their written consent, in the form they choose — name, name and employer, alias, or not at all. Where the same issue reaches us more than once, the first reporter is credited.
9. Review
This policy is reviewed at least annually, and in any event whenever the reporting obligations that apply to us change, whenever the contact channel changes, and after any case that showed the policy to be unclear. The current version is always the one published at titanos.tv, with the version number and date at the top of it.
10. Governing law
This policy, including the safe harbour in section 5, is governed by Spanish law. Any dispute arising out of or in connection with this policy shall be subject to the exclusive jurisdiction of the courts of Barcelona, Spain
