Last updated: 22 December 2025
We publish security research, including vulnerability reports, with the primary goal of helping defenders reduce risks in the real world. When we discover a vulnerability, we try to handle it in a way that gives vendors a fair chance to fix and gives users time to protect themselves.
This page explains how we coordinate and publish discovered vulnerabilities.
If you are a vendor and you want to coordinate with us, contact labs@itresit.es.
How we handle a new vulnerability
When we confirm a security issue, we normally start by contacting the vendor (or the vendor’s security team). We do this as soon as it is practical, and we share enough information for them to reproduce the problem and understand the impact. If we have a safe proof-of-concept, we can share it privately with the vendor, but we keep it minimal and focused on validation.
If the vendor needs a secure channel to exchange sensitive details, tell us. We can use encrypted email or another method we both agree on. We do not publish encryption keys on this page; we share the details during coordination.
If we believe the issue could be relevant for specific environments we know about (for example, where exposure is likely), we may also share private mitigation guidance with those affected parties. The intent is not publicity; it is risk reduction.
CVE identifiers
When it makes sense, we will coordinate with the vendor so the vulnerability gets a unique CVE identifier. This can be done by the vendor (if they are a CNA or work with one) or through the usual CVE assignment channels. A CVE is not always possible or necessary, but we try to do it when it helps defenders.
Our usual publication window
Our default approach is coordinated disclosure with a ~90 day publication window.
We try to give vendors time to investigate, fix, and ship a patch before we publish full technical details.
This window is not a rigid rule. If the vendor is clearly working on the issue and communicating progress, we can agree on a longer timeline. If the vendor confirms a patch date, we prefer to align publication with that moment, so defenders can act immediately.
When we may publish earlier
Sometimes waiting is not the safest option. We may publish earlier if we believe users are already at risk, for example when there is credible evidence of active exploitation, when the exposure is very broad and easy to abuse, or when we cannot get any meaningful response after reasonable attempts to contact the vendor.
Even in an accelerated disclosure, we still try to publish responsibly. That means we focus on impact and mitigation first, and we avoid unnecessary “how-to” details that would make exploitation easier before defenses exist.
What we typically publish
Our public posts are written to be useful for defenders. Depending on the situation, we may include technical depth, affected versions, detection notes, mitigation steps, and a timeline of coordination. If a fix is available, we will point people to it and we will highlight the simplest protective actions.
We do not publish details just for attention. We publish because it helps the community respond.
What we avoid
We do not publish exploit code purely for harm. We also avoid releasing details that, in our judgement, would materially increase damage before reasonable mitigation exists. If we think a piece of information is too risky to put out at that moment, we will hold it back or delay it.
Legal note
We conduct our research in good faith and in line with applicable laws and regulations. This policy describes how we work; it is not a contract.
Labs at ITRES 