Reporting Security Vulnerabilities

What is responsible disclosure?

Responsible disclosure (also called coordinated vulnerability disclosure, or CVD) is a practice where a security researcher who finds a vulnerability reports it privately to the affected vendor before making it public. This gives the vendor time to investigate and fix the issue before attackers can exploit it.

The process is defined in the international standard ISO/IEC 29147. The goal is simple: protect users by fixing issues quietly and quickly, while still giving the researcher appropriate credit.

This is different from:

• Full disclosure — publishing everything immediately, with no notice to the vendor. This puts users at risk while the vendor scrambles to respond.
• Bug bounty programs — paid programs where researchers are rewarded per finding. We do not currently operate one, though we do acknowledge contributors publicly if they wish.

Responsible disclosure is considered best practice across the security industry, and it is especially important in healthcare, where a vulnerability in a clinical system could affect real patient care.

Why it matters for medical imaging

dicom.link handles medical imaging workflows. DICOM files and associated metadata can contain Protected Health Information (PHI) — patient names, dates of birth, study descriptions, and more.

Our cloud-hosted services are designed so that this data is encrypted in transit and at rest on our infrastructure, using industry-standard cryptographic algorithms and protocols. We architect our systems so that plaintext patient data is not observable by us on our side.

Some of our products run entirely on-premise, inside a customer's own secure environment. In those cases, plaintext data may exist within the customer's zone — that is expected and appropriate, since the customer controls that infrastructure.

In either deployment model, a security vulnerability in our software could potentially affect patient data. That is why we treat vulnerability disclosures as a first-priority matter, not a routine support issue.

What counts as a security vulnerability?

A security vulnerability is a weakness in software, configuration, or logic that could allow an attacker to:

• Access, modify, or delete data they should not be able to reach
• Bypass authentication or authorization controls
• Execute code on our systems or a user's device
• Intercept or tamper with data in transit
• Disrupt service availability in a meaningful way

Examples relevant to our platform include: unauthorized access to DICOM studies, session hijacking, injection flaws in API endpoints, broken access controls between accounts, and cryptographic weaknesses.

Examples that are not security vulnerabilities for our purposes: missing rate limits that do not lead to data exposure, informational HTTP headers, theoretical issues with no working proof of concept, or issues in software we do not control (browsers, CDNs, third-party services).

How to report

Send your report to support@dicom.link.

For reports containing sensitive details — working exploit code, credentials you encountered, or patient data you inadvertently accessed — please encrypt the message using our PGP public key, available at /.well-known/pgp-key.txt.

Include in your report:

1. A description of the vulnerability and which component or endpoint is affected
2. Step-by-step instructions to reproduce it
3. The potential impact — what an attacker could achieve
4. Proof of concept: code, HTTP captures, screenshots, or a screen recording
5. Your severity estimate (critical, high, medium, low, or informational)
6. Your name or handle, and whether you want to be acknowledged publicly

A report with clear reproduction steps and demonstrated impact will be triaged faster than a vague description. If you are unsure whether something is a real vulnerability, send it anyway — we would rather investigate and close a non-issue than miss something real.

What to expect after you report

We follow these response commitments:

Timelines start from the date we receive a report with enough detail to triage. Complex vulnerabilities may take longer; we will communicate openly if that happens.

We will keep you updated at agreed intervals and coordinate with you on any public disclosure. If you want to publish a write-up after the fix, we are happy to review it before it goes out.

Safe harbor

If you research in good faith and follow this policy, we will not pursue civil or criminal legal action against you for your research activities. We will treat your identity as confidential unless you consent to public acknowledgment.

Safe harbor requires that you:

• Only access data in accounts you control — do not touch real patient records
• Not exploit the vulnerability beyond what is needed to demonstrate it
• Not disrupt the service for other users
• Not disclose publicly before we have fixed the issue or the 90-day embargo has passed

Using PGP encryption

Our PGP public key is available at /.well-known/pgp-key.txt and on our Security Policy page.

To encrypt a message with GPG:

# Save our key
curl https://dicom.link/.well-known/pgp-key.txt -o dicomlink-security.asc

# Import it
gpg --import dicomlink-security.asc

# Write your report to a file, then encrypt it
gpg --armor --encrypt --recipient support@dicom.link report.txt

Attach the resulting report.txt.asc to your email.

Further reading

• Our Security Policy — full responsible disclosure policy with safe harbor terms
• ISO/IEC 29147 — international standard for vulnerability disclosure
• CERT/CC Coordinated Vulnerability Disclosure guide