Security

Last updated 9 August 2026

Reporting a vulnerability

Email support@novapanel.dev with "security" in the subject. Please include the NovaPanel version, what you found, and how to reproduce it. You will get a reply within 72 hours.

Please don't open a public issue for a security problem, and please don't test against a server you don't own. If you need somewhere to test, say so and we'll sort something out.

Advisories

NP-2026-002 — Database password readable by any local user

Fixed in the installer on 29 August 2026, and repaired on existing servers by the panel from 1.8.6, released the same day.
Affected: servers installed before 29 August 2026, for the first 30 days after installation.
Severity: high on a server with untrusted users; low on a single-tenant box.
Found by: internal review. No exploitation has been observed.

The installer wrote a transcript of the installation to /tmp/novapanel-install.log using the default file permissions, which made it readable by every account on the server. Several of the commands it recorded include a database password on the command line, so that file contained the PostgreSQL password for the panel — and, where those components were installed, the PowerDNS and Roundcube passwords too.

Anyone with a shell or FTP account on the server could read it and connect to PostgreSQL on localhost, which grants access to every hosting account, site, password hash and licence key the panel holds. On a server you are the only user of, there is no exposure.

What you need to do: update to 1.8.6 or later and the panel deletes the file on its next start. To act sooner, run rm -f /tmp/novapanel-install.log. Ubuntu clears /tmp after 30 days, so servers installed more than a month ago are no longer exposed. If untrusted users have had access to the server since it was installed, rotating the database password is the cautious choice — the credentials are in /opt/novapanel/config/.env.

NP-2026-001 — Privilege escalation, cross-tenant access and credential exposure

Fixed in 1.6.7.7, released 6 August 2026.
Affected: all releases before 1.6.7.7.
Severity: critical.
Found by: internal security review. No exploitation has been observed.

What you need to do: update to 1.6.7.7 or later. From the admin panel, Updates → Install, or run novapanel update. There is no workaround short of updating, and several of the fixes repair state on existing servers when the panel restarts.

After updating, if your server has had FTP accounts on it, note that /etc/vsftpd/virtual_users.txt was previously world-readable and contains plaintext passwords. Permissions are corrected automatically on update, but any local user on that server could have read it in the meantime. Rotating FTP passwords is the cautious choice.

Remote code execution as root

A site's Git repository URL was passed to git clone without restriction. Git's transport-helper syntax allows a URL to name a command to execute, and deploys ran as root at the time, so any user who could set a repository URL could run commands as root on the server.

Repository URLs and branch names are now validated wherever they are set and again when a deploy runs, and the clone is restricted to known transports. Deploys also now run as the site's own user rather than as root, so the same class of bug can no longer reach beyond one account.

Cross-tenant access

Thirteen separate places accepted a resource identifier from the request without confirming the caller owned it. In a single-tenant install this is of limited interest; on a shared server it is not. The most serious:

• A mail forwarder could be created for a domain belonging to another account, intercepting that domain's inbound mail.
• A mailbox could be created on another account's domain, and wrote DNS records into that account's zone.
• Deleting a mailbox could remove DNS records belonging to a shared zone.
• An FTP account's directory could be set to a path outside its own account, taking ownership of another account's files and serving them over the wrong login.
• FTP directory and password fields could inject configuration into the FTP server.
• Deleting a site or domain removed the web server configuration before ownership was proven.
• Site statistics could be read for a site owned by someone else.
• PHP pool and database name collisions could run code, or drop a database, as another account.
• Disabling a PHP module applied to the whole server rather than one account.

All of these now verify ownership in the database query itself rather than in a separate check, so a missed call site cannot become a vulnerability.

Credential exposure in logs and error messages

Eleven operations wrote secrets to a file by piping them through a command that echoes its input, while capturing that output. The result was that private keys, mailbox password hashes, plaintext FTP passwords, database credentials and PHP pool secrets could appear in error messages and log files. Those operations now discard the echoed output.

Separately, custom TLS certificates and their private keys were briefly world-readable while being installed, and stayed that way if the permission change failed. They are now staged and moved into place with the correct permissions.

Suspension and deletion did not do what they said

Not a vulnerability in the usual sense, but worth stating plainly because operators relied on it. Suspending an account only blocked panel login: the customer's websites stayed online, their scheduled tasks and background processes kept running, and their mail and FTP logins kept working. Deleting an account left its databases, mail logins, FTP logins and DNS zones in place and functioning.

Suspension now takes hosting offline and unsuspension restores it, and deletion removes the account's resources. If you suspended or deleted an account on an older version, check that it is actually gone.

A mail setting could stop inbound delivery

Saving the mail configuration page applied a maximum message size without raising the mailbox size limits to match, and the page's own default exceeded the mail server's default limit. The result was that saving that page without changing anything could stop inbound mail delivery entirely. Fixed, and repaired automatically on affected servers.

Supported versions

Security fixes are issued for the current release only. NovaPanel updates in place from the panel, and there is no long-term-support branch — the answer to "which version is supported" is the latest one.