CVEs don’t get issued “resolved” statuses… They are either reserved, published, or rejected (technically NVD have a few extra for published). That’s just junk data in that tool you’re using. Use authoritative sources like cve.org or nvd.nist.gov.

You can see the CPEs on NVD and they’re old versions of Plex (and were old when the vulns were published).

You’re aware those CVEs are only relevant for ancient versions of Plex and were fixed long ago?

You’re going to need to back up your claim otherwise you might as well be lying as there’s no CVE like this I can find nor any public disclosure.

Plex have a bug bounty program and a responsive security team too.

Post your security report.

Have you had anyone with experience with security look at this thing? There’s a lot of really questionable practices in your schedule shell scripts. I especially find how you’re handling VPN secrets kinda worrying. And the backup_challenge_clients.sh script isn’t robust at all. Your nginx config has a few bad choices like lack of try_files, the regex \.php$. It’s definitely not hardened so I hope people don’t put this Internet facing.

I’ve spent like 5min in the GitHub to get a feel for the project maturity. Personally, I don’t think this is suitable for actual use yet.

If you’ve not done any security assessments on your project yet, you might not want to (a) call it “Safe”box and (b) might not want to start charging money for it until you do.

I worry you’re setting yourself up for a hard-to-shake-off embarrassment should a nasty vuln be found. Maybe a name like “selfbox” etc that drops the connotation of security would be safer.

Edit: Kudos on the project website though! Looks fricking gorgeous.

I’m sure there’s a decent fork. Read the code; there’s not much to it!

If you’re on the same network, take a look at snapdrop. It’s basically cross platform AirDrop.

What’s the context in which you’re needing to share files?

My first thought is host your own FTP server and send people credentials to log into it with and upload.