Skip to content

v1.2.3 — Security fix (tenant symlinks exposing panel files)

Choose a tag to compare

View all tags
@crivion crivion released this 21 Sep 15:10
· 10 commits to main since this release
v1.2.3
ed723d6
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

This is a security release fixing one critical vulnerability. Every install should upgrade.

Security

  • Tenant symlinks could expose the panel's .env (GHSA-qjrx-xj8f-xcc8). Tenant vhosts allowed Apache to follow any symlink (FollowSymLinks), and AllowOverride All let a tenant's .htaccess turn that on for itself. A tenant's PHP could therefore symlink a file outside its home into its website and have Apache serve it. That included the panel's .env, with its APP_KEY and MySQL credentials. Tenant vhosts now use SymLinksIfOwnerMatch, so Apache only follows a symlink when the link and the file it points to have the same owner, and a tenant .htaccess can no longer switch this back.

Existing vhosts are rewritten automatically: by the upgrader on VPS installs, and at boot on Docker installs. The upgrader checks the result with apache2ctl configtest and restores the previous files if Apache rejects them.

Behaviour change

A tenant .htaccess containing Options +FollowSymLinks now makes that site return 500. Drupal's default .htaccess has this line. Change it to Options +SymLinksIfOwnerMatch or remove it. The upgrader lists every affected .htaccess file when it runs.

Upgrading

curl -sSL https://raw.githubusercontent.com/crivion/laranode/refs/heads/main/laranode-scripts/bin/laranode-upgrade.sh | bash

Once it finishes, check that the commit the upgrader prints matches this release, and read the "Hardening tenant Apache vhosts" step for any .htaccess files you need to fix.

Symlinks created before you upgrade stop working too, but anything already read through one is exposed. If you host tenants you don't fully trust, rotate the laranode MySQL password (update DB_PASSWORD in .env to match) and APP_KEY. When rotating APP_KEY:

  • Put the old key in APP_PREVIOUS_KEYS in .env. Backup destination settings and tenant database passwords are stored encrypted with it, and they can't be read without it.
  • Rotate the credentials of any backup destination (S3 keys, SFTP passwords and so on). Anyone who read the old .env could decrypt them from the database.
Assets 2
Loading