3.9.5

A security release. It closes a two-factor bypass on the customer panel, several ways a customer could make the panel write files as root, and one SQL injection. Update.

Before you update​

• 3.9.5 repairs what the 3.9.4 update left undone. On a server where the 3.9.4 update ended with "1 version-specific script failed", 3.9.5 re-applies every 3.9.4 step that can have failed (AI plans, rspamd, the scheduled jobs, the country database, the vhosts) and installs the panel engines under the names the panels run.
• Anonymous FTP is switched off on AlmaLinux, Rocky and other RHEL-family servers. The installer's FTP hardening only knew Debian's layout, so on the RHEL family anonymous logins were accepted. FTP now also offers TLS with the host's certificate.
• Databases and logins of accounts deleted before 3.9.5 are listed, not dropped. Deleting an account left its databases, MariaDB logins and PostgreSQL role behind. Deletion now removes them; the update lists the ones already orphaned for the administrator to review.

Security​

• Two-factor sign-in on 2083 could be bypassed. The second step took the account from the form, so a code could be sent to any account and read back from the session cookie. The second step now answers only for the account whose password was checked, and only a hash of the code is kept. POST /api/login now checks email codes too, and suspended accounts are refused on the API.
• The file manager acted as root. Saving, the Trash, cron files, archive extraction and compression could be pointed through a customer's symlink at any file on the server, and a file name starting with - became an option to tar or zip. Every file-manager operation now runs as the account.
• SQL injection in the MySQL privileges API's host parameter.
• Admin: a reseller could read any file through a symlink in the resource-usage and export views; email codes were stored readable in the cookie; resellers could change plans, CPU/RAM, IPs and owners outside their allowances.
• Login tokens were world-readable; HMAC keys and several database passwords were passed on command lines; suspending an account did not end its sessions on servers using valkey; logout left the session alive.
• vhost overrides can no longer name directives that make the web server open files or run programs as root.

New​

• App Store in HiTechAdmin: install, repair, update and remove PHP versions and extensions, runtimes, web engines, databases, mail, caches, security and backup engines, and every module — as background jobs. Core components can be repaired, never removed.
• A new HiTechAdmin dashboard with every function as a grouped icon tile, a filter, and the changelog and user activity on their own pages.
• The customer panel's sidebar is ten areas; each opens onto its sections. Tables scroll inside the page instead of spilling over the menu.
• Live usage: CPU, memory, disk I/O and processes update every second, measured against what the account can actually use.
• Hosting nodes (first stage): register a node, place a new account on it, and the customer panel, its pages, Git deploys and scheduled jobs act on it there. Single-server installs are unchanged.
• A Rust front door for 2083, off by default, behind a HiTechAdmin switch.
• Everything from outside comes from the mirror first, checked by checksum, with the publisher as fallback; panel pages no longer load libraries from CDNs.
• Settings are forms: backup defaults, DNS provider credentials, application environment variables and the container dialog no longer ask for KEY=VALUE text.
• Importers from Enhance and ispmanager; every importer the admin offers now ships with the release.
• Webmail: back-channel sign-out, full-text search ranked by where the words are, dark-mode bodies, pinned messages, a Snoozed view, HTML attachments in place, swipe between messages, and more.
• A welcome guide in every new mailbox; database exports stream; backups compress at low priority; notifications fit a phone.
• Background tasks never slow the server: every task unit runs behind the web server, and every page has a budget for how many CLI calls it may make.

Third-party modules and the DevKit​

Other vendors can now build modules for HiTechCloud Panel, and an administrator can install them. See Third-party modules.

• A module is a signed package (.hcm) with a versioned manifest: its id, vendor, version, the panel versions it supports, the permissions it asks for, the events it wants, the pages it adds, its commands, its settings and its dependencies.
• Installed by the Super Administrator from Server > Third-party modules (2087) or hitechcloudcli modules install, after a review page that shows who signed it and every permission it asks for. Packages are verified (Ed25519) against keys the administrator trusts before anything is unpacked; an upgrade must come from the same signer; unsigned packages are refused unless the administrator allows them and confirms each one.
• Sandboxed: each module runs as its own unprivileged system user in a hardened systemd unit with memory, CPU and process limits, sees only its own data directory, and never runs as root.
• Module API: a local socket where a module, with a token bound to its own system user, reads the accounts, domains and plans its permissions allow and suspends or unsuspends accounts if allowed - only accounts whose plan includes the module, unless the administrator approved all accounts.
• Hooks: account created, suspended, unsuspended and deleted, plan changed, domain added and removed, certificate issued and renewed, backup finished and customer login, delivered signed in the background with retries for about a day. A panel action never waits for a module.
• Pages: a module can add pages and dashboard tiles to the customer panel (per plan, as the feature ext.<id>) and pages to the administrator panel, shown inside the panel's layout in a sandboxed frame that has no access to the viewer's session; every request it makes goes through the panel's login and CSRF checks.
• Settings a module declares are a real form on its page; secrets are never shown again.
• New event: certificate.issued (a certificate's first issue) and account.login join the panel's event hooks.

The HiTechCloud DevKit ships as integrations/devkit: the integration guide in English and Vietnamese, starter templates, two complete example modules, and the devkit tool that validates, packages, signs and runs a module against a local mock panel.

Billing modules​

WHMCS, ClientExec, Blesta, FOSSBilling, HostBill, Paymenter and WISECP were fixed and extended in their own repositories (see 3.9.4's notes for the details); WHMCS gains Server Sync and WISECP account import.

Also in 3.9.5​

• HiTechAdmin speaks Vietnamese (and English), with German, Spanish, French, Portuguese, Russian, Turkish and Chinese machine-written and marked for review. Each administrator picks a language in their profile.
• Favourites on the HiTechAdmin dashboard, kept per login on the server.
• Third-party modules and the DevKit. Other vendors can build modules for 2083 and 2087 with the DevKit (Rust tool, starters in PHP, Node, Python, Go and Rust, docs in English and Vietnamese). Modules are signed packages, approved permission by permission, and run as their own user in a sandbox — never as root and never outside the scope the administrator approved.
• Hosting nodes: INSTALL.sh --role node --panel <address> sets up a node that only the panel can reach, and HiTechAdmin's Connect database joins it to the panel's database.
• App Store: PHP extensions per version, web engines installed without becoming the default, and "not available on this OS" where that is true.
• More work runs in the background: account suspend/delete, WebEngine moves, the Repair Kit, account checks, server tools, mailbox and alias bulk deletes, permission fixes, and more; no page waits on php.net or a public-IP service any more.
• Settings that used to be files now have pages: keyboard shortcuts, custom notification services, customer notification defaults, FTP client settings, pure-ftpd settings; DNS provider credentials keep a blank field's stored value.