Bug Bounty & Vulnerability Disclosure Policy

We value the contributions of the security research community in keeping Screenly and our users safe. Learn how to responsibly report potential vulnerabilities.

We value the contributions of the security research community in keeping Screenly and our users safe. This policy outlines how to responsibly report potential vulnerabilities and what you can expect from us.

Scope

In Scope

• screenly.io (marketing site)
• *.screenlyapp.com (web application)
• Our digital signage players (Screenly Player / Player Max only)

Out of Scope

• Stage and test environments that may reside on the same domains
• Third-party services not owned or controlled by Screenly (e.g., payment providers, CDNs)
• Denial-of-service or capacity stress testing
• Social engineering, phishing, or physical attacks against employees, customers, or partners
• Known public CVEs without a practical exploit path
• Low-impact issues listed under "Non-Qualifying Issues"

Safe Harbor

We support good-faith security research. If you follow this policy, restrict testing to the in-scope systems, avoid privacy-invasive actions, and report promptly, Screenly will not pursue legal action or report your activity to law enforcement.

If you inadvertently access sensitive data, stop immediately and include only minimal evidence needed to demonstrate the issue in your report.

How to Report

We provide multiple channels for submitting vulnerabilities:

• Email: [email protected]

For complete security contact information, including PGP encryption keys, see our security.txt file which follows RFC 9116 standards.

When reporting, please include as much detail as possible using our reporting template (see below). For confidentiality, you may encrypt submissions using our PGP keys available in the security.txt file.

What to Expect

• Acknowledgement: within 3 business days
• Initial triage & ETA: within 10 business days
• Status updates: at least every 30 days until resolution
• Remediation timeline: risk-based, with coordinated disclosure after a fix is deployed

Rewards & Recognition

Screenly may award monetary bounties for valid, previously unreported vulnerabilities.

All payouts are determined at Screenly's sole discretion.

We consider factors such as impact, exploitability, quality of the report, reproducibility, and duplication. Reports that meaningfully reduce risk but do not qualify for a bounty may still receive recognition (e.g., Hall of Fame mention).

Severity Classification

Severity levels are evaluated based on the specifics of each report and are determined at Screenly’s sole discretion. The categories below serve as general guidelines rather than strict rules.

Critical

A vulnerability is Critical only if it grants full, unauthorized access to core systems or customer assets with zero interaction from the user or Screenly staff.

High

A vulnerability is High when it is exploitable and has major impact, but requires some victim interaction, has preconditions, or does not grant full control.

Medium

A vulnerability is Medium when it presents a legitimate security issue but has limited impact, requires specific conditions, or only affects non-critical data or components.

Low

A vulnerability is Low when it has minimal impact, provides no meaningful exploit path, or is primarily informational.

Rules of Engagement

Allowed

• Test only the systems listed in scope
• Use test or demo accounts
• Provide minimal proof-of-concept code that demonstrates the vulnerability

Not Allowed

• Exfiltrating or deleting sensitive data
• Large-scale automated scanning or denial-of-service attempts
• Phishing, spam, or social engineering of employees or customers
• Attacks against third-party services

Non-Qualifying Issues

Examples of findings not eligible for rewards include:

• Self-XSS that requires victim input
• Missing or misconfigured HTTP headers without exploitation impact
• Version disclosure banners
• Outdated libraries with no exploitable vulnerability
• Clickjacking on non-sensitive pages
• Rate-limit or brute-force issues with negligible impact
• Chained or multi-issue reports.

Dependent Vulnerabilities

Some vulnerabilities may rely on another issue to demonstrate impact (e.g., using a SQL injection to obtain an identifier or token required to exploit an XSS or IDOR). This is acceptable.

In such cases:

• Report each vulnerability separately
• Clearly state any dependency on another vulnerability
• Do not combine multiple vulnerabilities into a single exploit narrative

Each vulnerability will be evaluated and rewarded on its own merits, taking dependencies into account.

Why we require this:

1. It enables accurate triage, severity assessment, and remediation.
2. Different issues may have different owners, timelines, or severities.
3. Bounty eligibility is evaluated per vulnerability, not per chain.

Reporting Template

Please include the following in your submission:

• Title
• Summary: One-paragraph description and potential impact
• Asset/URL(s): e.g., https://screenlyapp.com/path
• Category: (e.g., auth bypass, IDOR, XSS, SSRF, RCE)
• Severity estimate: CVSS vector if available
• Steps to reproduce: clear, numbered steps
• Proof of Concept (PoC): requests, screenshots, or minimal exploit
• Impact: what an attacker could achieve
• Remediation ideas: optional but helpful
• Researcher contact & disclosure preference: name or handle, email/PGP, recognition preference

Disclosure & Credit

We follow coordinated vulnerability disclosure. After remediation, we may publish advisories and will credit researchers (if consent is given). Anonymous submissions are also welcome.

Additional Security Information

For additional security details and contact information, please refer to:

• Our security.txt file (RFC 9116 compliant)
• Our comprehensive Security page which details our security measures and commitment