Thank you for your interest in Lychee. We take security seriously and appreciate your help in keeping Lychee safe. This document aims to facilitate the reporting of advisories, and provide information of how our process goes.
Lychee uses a rolling release system, we do not backport fixes to previously released versions. Those are the versions where we accept vulnerability reports.
| Version | Supported |
|---|---|
| master | ✔️ |
| latest release | ✅ |
| < latest release | ❌ |
| < 7.0 | ❌ |
As described in our contribution guide, if you discover a security vulnerability within Lychee, please contact us directly on discord or open a draft advisory here. All security vulnerabilities will be promptly addressed.
Tip
In order to help us triage your report, we encourage you to provide us with a Proof of Concept (PoC) demonstrating the vulnerability. This will help us understand the issue and prioritize it accordingly. You can use our demo environment to test your PoC (non-destructively). For destructive testing, please use your own environment and provide us with a clear explanation of the steps to reproduce the issue.
Please do not report security vulnerabilities which are direct output of your own tools. Make sure to verify the issue manually and provide a clear explanation of the vulnerability, including steps to reproduce it. We are starting to see a lot of reports which are generated by automated AI scanners and contains hallucinations or do not consider parts of the codebase.
Caution
For each low quality report that is closed, you gain 1 strike: ⚾
3 strikes ( ⚾⚾⚾ ) and you will be blocked from this repository.
We see have seen a few reports mentionning issues which we consider part of the intended design of Lychee.
If you are thinking about reporting an issue regarding the api/v2/Diagnostics endpoint,
please note that it is intentionally public and does not require authentication.
The responses from this endpoint do not contain any sensitive information or secrets and have been anonymized.
Its main goal is to allow users to easily diagnose issues with their Lychee installation even if they can't log in.
We do not accept vulnerability reports related to DNS rebinding attacks on fopen when USE_FOPEN_FOR_URL_IMPORTS is enabled.
We know that this setting switches URL-based imports from curl to PHP's native fopen. Unlike curl, fopen performs its own DNS resolution with no built-in mechanism to detect or prevent DNS rebinding — there is no supported way to mitigate this at the application level while still using fopen.
Deliberately enabling USE_FOPEN_FOR_URL_IMPORTS and then expecting the system to be immune to DNS rebinding is not a valid threat model. Putting the system into a known-vulnerable configuration and then reporting the resulting exposure is not considered a security vulnerability in Lychee.
We do not consider this a vulnerability because the import from server feature is only available to admin users. The path traversal issue is mitigated by the fact that only trusted users can access this functionality.
Furthermore, in the case where there are multiple admins, the owner of the Lychee installations can even disable it this functionality completely by adding the following to the .env
DISABLE_IMPORT_FROM_SERVER=true