v1.2.1 — Security fix (file manager) + upgrade path repair

This is a security release. Upgrading is recommended for all installs, and especially for anyone hosting more than one customer.

Security

Fixes a vulnerability in the file manager that allowed an authenticated, non-administrative account to read from and write to paths outside its own home directory, reaching other tenants' document roots. Because the panel process is a member of every tenant's group by design, application-level path scoping was the only boundary between accounts — so writing a script into another tenant's web root meant code execution as that tenant.

The root-executed permissions helper was reachable with the same unvalidated path.

Technical detail is deliberately held back until people have had a chance to upgrade, and will be published as a GitHub Security Advisory shortly. Reported by kta1kri, who handled it responsibly throughout.

Hardening that went in alongside it:

• Every file manager mutation now runs through a helper anchored to an open descriptor on the tenant's home, so containment is a property of how the write happens rather than a check performed beforehand
• The sudo rules granted to the web process are now an explicit allowlist instead of a wildcard over a directory
• The panel's own directory tree is no longer group-writable by the web process

Fixed

• The upgrader could silently do nothing. The installer chmods the scripts it deploys, git tracks the executable bit, and two scripts were committed with the wrong mode — so a deployed tree always read as dirty, git pull refused, and because its exit status was never checked the script carried on and reported success while staying on the old commit. For a security release that means believing you are patched when you are not. A failed pull now aborts loudly, and the success message names the deployed commit.
• Installer wrote a broken APP_URL on IPv6-capable hosts (#10). curl icanhazip.com resolves over IPv6 where available and returns a bare IPv6 address, which is not a valid URI host — Laravel then failed every command with Invalid URI: Host is malformed, including the create-admin step, so the install could not be completed. Detection now prefers IPv4, validates the result, and falls back through the host's own routing address. Reported by vikaar996.
• New accounts appeared to have an empty file manager. usermod does not reach already-running PHP-FPM workers, so a newly created account's home stayed unreadable to the panel until something else restarted them. Account creation now handles this.
• Account creation returned a 500 when the request omitted the optional notify field — after the account had already been created, so a retry hit a duplicate.
• Running the test suite on a server truncated the live panel database, because phpunit.xml pointed at the configured connection while the suite applies RefreshDatabase.

Upgrading

Use the one-liner, not the copy of the script already on your server:

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

This matters for this release specifically. The script on disk came from the version you are upgrading from, so it contains the silent-failure bug described above and cannot fix itself. The one-liner fetches a script that can. After upgrading, confirm the commit the upgrader prints matches this release.

Fresh installs are unaffected and use the normal installer.