Files
SealShare/config
Andreas Reinhold / reiniandClaude Opus 5.5 6578335568 Fix the security audit's findings
ShareDownload::$authenticated was a public property without #[Locked],
so a visitor with a share's link but not its password could set it from
the browser and see the file list: names, folder paths, sizes and
whether the share holds a text. The contents stayed protected; the flag
is now locked, and a test tries to set it.

Sessions hold the keys of the password shares a recipient unlocked, and
were stored unencrypted in the sessions table wherever SESSION_ENCRYPT
was not set, which includes every Docker install. They are now
encrypted unless SESSION_ENCRYPT=false. Share keys never live in the
session, so every share stays readable; people sign in again once.

The container generated an APP_KEY when none was set, printed it to the
logs and generated another on the next start, which left the shares
without a password unreadable. It now refuses to start without one and
says how to create it; docker-compose.example.yml requires it for both
services. The command it names, and the README's, now pass
--entrypoint php: the image's entrypoint ignores its arguments, so
"docker run <image> php artisan key:generate --show" never ran it.

Every proxy is trusted, so the password-reset mail built its link from
a host a forged X-Forwarded-Host could choose. It is now built from
APP_URL.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-08 23:23:00 +02:00
..
2026-09-26 07:00:17 +02:00
2026-10-08 23:23:00 +02:00