E
EuFSI DPP

Responsible Vulnerability Disclosure

Last updated: May 2026

Our commitment to you

Security researchers play a critical role in keeping the EuFSI Digital Product Passport platform safe. If you have found a vulnerability, we want to hear from you. This page tells you exactly how to report it, what we promise in return, and what is in and out of scope.

We follow the coordinated vulnerability disclosure model: you report privately, we acknowledge and fix, and together we agree a public disclosure date. We do not pursue legal action against researchers acting in good faith under this policy — see “Safe harbour” below.

How to report

Email security@eufsi.com. Plain-text email is acceptable for the initial report. If your finding requires sensitive proof-of-concept material, ask for a PGP-encrypted exchange in your first message and we will respond with a public key.

A useful report has at least:

  • A concise title.
  • The class of vulnerability (e.g. SSRF, IDOR, stored XSS, auth bypass, race condition).
  • The affected endpoint, page, or component (URL or file path).
  • Reproduction steps as a curl invocation, screenshot, or short script.
  • Observed impact (what an attacker could do with this).
  • Your name or handle (optional — for credit on our acknowledgements page).

You do not need to include a CVSS score, suggested fix, or polished write-up. We will compute severity ourselves; rough notes are fine.

Our promise (SLA)

StageTarget
Acknowledge receipt2 business days
Triage decision (in/out of scope, severity)5 business days
Fix or remediation plan communicated30 calendar days for High/Critical; 90 for Medium/Low
Public disclosureCoordinated with reporter; typically at fix release or 90 days

If an issue is large or requires upstream coordination, we will say so explicitly and propose a longer timeline; we will not silently let a report stall.

In scope

  • Production EuFSI DPP platform: dpp.eufsi.com, app.dpp.eufsi.com, api.dpp.eufsi.com, and the QR resolver service.
  • Authentication, authorisation, session management, RLS isolation between tenants.
  • API endpoints under api.dpp.eufsi.com.
  • QR resolver redirect path and /.well-known/gs1resolver.
  • Public DPP pages at app.dpp.eufsi.com/dpp/[slug].
  • File-upload pipelines (ClamAV, S3 pre-signed URLs).
  • AI extraction pipeline (OpenAI proxy, confidence thresholding, PII handling).
  • Email handling (Resend webhook signatures, unsubscribe flow).
  • Supplier and certifier invitation flows (token issuance, rate-limiting, enumeration safety).
  • Any vulnerability that breaks GDPR or ESPR compliance posture.

Out of scope

We appreciate the work but will not action the following classes of report:

  • Missing or weak headers in non-production environments.
  • Self-XSS that requires the user to paste attacker-supplied script into the console.
  • Third-party services we depend on (Keycloak, PostgreSQL, OpenAI) — report those upstream.
  • Theoretical denial-of-service via heavy traffic against the unauthenticated surface.
  • Reports based solely on automated-tool output without a working proof of concept.
  • Social engineering or phishing of EuFSI staff or customers.
  • Physical attacks against EuFSI offices or staff devices.
  • Disclosure of public information (server software versions, public commits, marketing paths).
  • Issues affecting only end-of-life browsers or operating systems.
  • Marketing-site issues with no data exposure (layout, broken links, theoretical clickjacking on static content).

If you are unsure whether something is in scope, send the report anyway — we will make the call and tell you.

Rules of engagement

  1. Test only on accounts you own or have explicit permission to test.
  2. Do not access, modify, or exfiltrate other tenants’ data beyond the minimum needed to demonstrate the issue.
  3. Do not disrupt the service for other users (no volumetric DoS, no destructive payloads on production data).
  4. Do not perform social engineering against EuFSI staff, customers, or sub-processors.
  5. Do not exploit the vulnerability for any purpose beyond demonstrating it to us.
  6. Give us reasonable time to fix before any public disclosure.

Safe harbour

When you act in good faith, in compliance with this policy:

  • We will not initiate or support legal action against you under applicable computer-misuse statutes.
  • We will treat your activities as authorised under the policy and bound by the rules of engagement above.
  • We will work with you if a third party raises concerns about your testing, provided you stayed within scope.

This safe harbour does not cover testing that violates the “Out of scope” or “Rules of engagement” sections, third-party data not owned by you or EuFSI, or testing that violates other applicable law.

Acknowledgements

If you would like public credit, we will include your name or handle and the date of disclosure on a forthcoming /legal/security-acknowledgements page. Tell us in your report whether you want to be credited and how you would like to be named. You can decline credit; we will respect that and keep your involvement confidential.

What we do not offer

  • Bounty payments. A formal bug-bounty programme will be announced separately if and when it launches.
  • A guarantee of public CVE assignment. We will request a CVE through an external CNA on a case-by-case basis for findings that warrant one.
  • Real-time chat. Reports go via email; we will not engage on social-media DMs, support chat, or marketing forms.

Contact

All reports: security@eufsi.com

Machine-readable summary: /.well-known/security.txt (RFC 9116).