Latest from Reqad

On 21 October 2026 the PHP project published a security advisory for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, that can allow unauthenticated remote code execution. Every PHP installation that serves web requests is affected: PHP-FPM, Apache with mod_php, php-cgi and the rest. The PHP project rates the risk highest for mod_php.

The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. For PHP 7.4, 8.0 and 8.1 the PHP security team published minimal source backports. PHP 5.x and 7.0–7.3 get nothing from upstream.

Update first. Mitigation is not a fix.

The only complete fix is updating to a patched version and restarting every PHP process. The PHP project is clear about this: there are no complete mitigations. Please don't treat a configuration change as a replacement for the update.

PHP 7.4 and 8.x on EL8 / EL9

Reqad installs PHP from the remi repository. On 21 October remi published fixed builds of PHP 7.4, 8.0, 8.1, 8.2, 8.3, 8.4 and 8.5 for EL8 and EL9. As root:

dnf update 'php*'

Afterwards, check that every PHP-FPM service (php82-php-fpm, php83-php-fpm…, the panel's own reqad-php-fpm) and, if any site uses mod_php, Apache have restarted. A worker that started before the update keeps running the old code.

PHP 5.6 on EL8: no fix from remi

remi's newest PHP 5.6 for EL8 is php56-php-5.6.40-47.el8.remi, published on 2 July 2026. You can check this yourself in remi's EL8 package list. That build does not contain these fixes, and nothing newer had appeared there by 22 October. remi has no PHP 5.6 for EL9 and no PHP 5.4 for EL8 or EL9 at all. Its PHP 7.0–7.3 builds for EL8 were last updated in July and August, so they are not fixed either.

PHP 7.2 (and 7.0, 7.1, 7.3): move to PHP 7.4

There is no fixed PHP 7.2 from remi, and Reqad does not provide one either. The same goes for 7.0, 7.1 and 7.3. The only way to close these vulnerabilities for those sites is to move them to PHP 7.4, which remi has fixed (or to a newer version). Applications that run on 7.2 or 7.3 usually run on 7.4 with few or no changes. Switch each site's PHP version in the panel, test it, and once no site uses the old version any more, remove it.

Patched packages from Reqad

We have ported the fix to the old versions that hosting customers still depend on:

PHP 5.4 and 5.6 (EL8, EL9) use the same package names, paths and services as remi's (php56-php-*, /opt/remi/php56, php56-php-fpm), so they install over remi's packages and the panel keeps working as before. The EL8 PHP 5.6 build is remi's own 5.6.40-47 with the fix added. When remi publishes a newer fixed release, it will replace ours automatically. The one exception is php56-php-oci8: we don't ship it, so a server that has remi's oci8 package installed can't take this update. On a server with access to the premium repository:

dnf install reqad-repo-premium (once)
dnf update 'php54*' 'php56*'

Access to the premium repository is given per server with a premium subscription.

PHP 7.4 on CentOS 7 replaces remi's PHP 7.4 system packages (php-*). remi's EL7 repository stopped at 7.4.33-15, so ours is a rebuild of remi's current 7.4.33-31, which carries the PHP project's 7.4 backport and the other security fixes published since -15. It is in our free EL7 repository.

To install it:

1. Add the server's IP address in your reqad.com account (free).
2. Add the repository, as root:

   echo '[reqad]
   name=Reqad $releasever - $basearch
   baseurl=https://repo.reqad.net/el$releasever/RPMS/$basearch
   gpgkey=https://repo.reqad.net/REQAD-RPM-GPG-KEY-PUBLIC
   gpgcheck=1
   enabled=1
   ' > /etc/yum.repos.d/reqad.repo

3. Update PHP:

   yum clean all && yum update 'php*'

4. Restart Apache or PHP-FPM.

Two changes in the PHP 5.x builds are visible. When a script runs out of memory, the PHP process now ends at once instead of carrying on. On PHP-FPM the visitor sees a 502 instead of a 500, and the error is still written to the error log. Session upload progress (session.upload_progress) is turned off.

PHP 5.4 and 5.6 have been end-of-life for years. These packages close this hole, but sites still on them should move to a supported version.

If you cannot update immediately

• memory_limit=-1, set so that applications can't change it (php_admin_value in the FPM pool or the Apache configuration), and check that no pool, folder or application sets a limit again. Note that this lets a single script use all of the server's memory.
• A low post_max_size: 8M for applications without uploads, 32M where uploads are needed, with upload_max_filesize below it.
• Request limits at the web server or proxy: request size, number of fields, multipart parts and headers. These limits must also apply to requests without a usable Content-Length.
• session.upload_progress.enabled=0 in php.ini or the FPM pool (not ini_set() or .user.ini), then restart every worker.
• On PHP 8.5: fatal_error_backtraces=0, then restart every worker.
• Remove invalid or deprecated settings that applications apply on each request.

The advisory has the full list and details. Then update as soon as you can.

The WordPress Toolkit used to be a list of sites with a Log in button. Now every site has a page of its own. Click Manage on any tracked site and you get an overview, a speed report, performance switches and a Security tab that hardens the site in one pass - with no config files to edit and no plugin to install.

An overview of the site

Summary cards show the WordPress version (flagged latest, outdated or insecure), the PHP version, the active theme, how many plugins are active and how many are waiting for updates, the account's disk usage and the state of its SSL certificate - next to a screenshot of the home page. Log in takes you straight into wp-admin as an administrator, without the password.

The page opens instantly from the last known state of the site and refreshes itself a second later, so you are never waiting on WordPress to boot just to look at it.

PageSpeed scores

Add a free Google PageSpeed Insights API key in Settings and each site gets a PageSpeed card: mobile and desktop tested at the same time, the four Lighthouse scores - performance, accessibility, best practices and SEO - and the Core Web Vitals behind them. The same test supplies the screenshot, so servers with no browser installed get one too.

Performance, applied live

• Nginx cache - pages served from nginx's FastCGI cache instead of PHP, with logged-in users, carts and checkouts never cached, and the Reqad Cache Purger plugin clearing it whenever content changes.
• Disable WP cron - a real system cron job every 2 minutes instead of cron running on visitors' page loads, now logged to ~/logs/cron.log.
• Search engine indexing - switch it off on staging and development copies.
• Maintenance mode - visitors get a "back soon" page with HTTP 503, so search engines come back later instead of dropping pages, while you keep working on the live site.

Security in one click

The Security tab holds 17 hardening measures. Tick Select recommended, press Apply changes, and each row reports what is now in force. Unticking a measure reverts it.

• Web server rules - block xmlrpc.php, wp-config.php, readme.html, dot-files, backups and database dumps; refuse PHP in wp-includes, uploads and cache directories; stop author scans and aggressive crawlers; and send HSTS, X-Frame-Options and nosniff headers.
• WordPress - hide the WordPress version from pages, feeds and script URLs; disable file editing and script concatenation in the dashboard; turn off pingbacks; or move the login page to an address of your choice.
• Files and keys - make sure all eight security keys and salts are strong, and lock wp-config.php down to its owner.

Blocked requests answer 404, not 403: to a scanner, a protected file looks exactly like a missing one.

Login only from your IPs

For sites where only you log in, one option shuts password guessing down entirely: wp-login.php and the core update screens answer only to the IPs you list. Reqad adds the server's own addresses automatically so WordPress updates keep working, leaves password-protected posts open to everyone, and warns you before applying a list that would lock you out. If your IP changes anyway, the panel's Log in button still gets you in.

Error pages for every site

Every site now has clean 403, 404, 500, 502, 503 and 504 pages, in light and dark, that do not name the web server. WordPress keeps its own themed 404 and maintenance pages - Reqad's only appear where WordPress does not answer.

A fix worth updating for

While building the security rules we found that on nginx servers the vhost's rule refusing PHP inside wp-content/uploads never matched, because it came after the PHP handler. New vhosts are generated correctly, and updating Reqad corrects every existing vhost automatically - tested and rolled back if nginx rejects the result.

The full walkthrough is in the documentation: WordPress Toolkit.

Reqad now scans inbound mail for malware. ClamAV is available as a first-class part of the panel: one command installs it, the Email page shows what it is doing, and a single button decides whether infected mail is tagged or rejected.

The interesting part is not ClamAV itself — it is what it scans with. Stock ClamAV signatures are strong on known binaries and weak on exactly what arrives by SMTP: phishing bodies, scam text, macro-laden documents and disguised attachments. Reqad therefore ships a curated set of third-party signature feeds alongside the official ones.

Installing it

On any Reqad server:

curl -sL https://repo.reqad.net/install-clamav.sh | bash

That installs the ClamAV engine, the Reqad service layer, the signature feeds, and fetches the initial database. Scanning stays off until you switch it on, so nothing about your mail flow changes until you decide it should.

The signature feeds

• Sanesecurity — phishing, scam and 419 bodies, malicious Office and RTF macros, bad URLs, spam image hashes and rogue-software signatures.
• Foxhole — container signatures that match on what is inside an archive. A ZIP holding invoice.pdf.exe is caught on the filename pattern, whatever the payload is, so a brand-new campaign is blocked without waiting for a signature to exist for it.
• URLhaus (abuse.ch) — URLs actively used to distribute malware.

Together these take a server from roughly 3.63 million to 3.69 million signatures, and the additions are concentrated precisely where mail threats live.

Tag first, reject later

Turning scanning on starts it in tag mode. Every message gets X-Virus-Scanned and X-Virus-Status headers and a line in the exim log — for clean mail as well as infected — and nothing is ever rejected. You can watch real traffic and see exactly what would have been blocked.

When you are satisfied, one click switches to reject, and infected mail is refused at SMTP time so the sender gets a bounce rather than the message disappearing into a quarantine nobody reads.

The order matters. These are community-maintained signatures with no vendor QA behind them, and a false positive that bounces a customer's invoice is worse than a missed sample. Tagging first turns that from a gamble into a measurement.

What the panel shows

A ClamAV card on Email reports the engine version, the total signature count, how long ago the database was updated, every extra database currently loaded with its own signature count, and whether exim is actually wired to the scanner — because clamd can be running perfectly while scanning nothing at all, and those two states look identical from a service list.

Updates

Official signatures update continuously in the background. The third-party feeds come from a Reqad mirror over HTTPS, so your server makes one request to us instead of every server in the fleet hammering the volunteer-run mirrors that publish them. Each database is GPG-verified against the publisher's own key before it is installed — a key shipped with the package, never fetched at runtime — so our mirror is a convenience, never something you have to trust.

Reqad serves WordPress sites from a full-page nginx FastCGI cache, which is what makes them fast — but a cached page is only useful while it is still correct. Reqad Cache Purger, our new companion WordPress plugin, closes that gap: it clears exactly the pages that changed, the moment they change.

It is now on WordPress.org, with the source on GitHub under GPL-2.0+. You do not need to download it by hand: open Reqad → WordPress Toolkit → Manage on any tracked installation and install and activate it in one click.

What it does today (v1.1.1)

• Works with nothing configured — on a Reqad server the plugin talks to the /purge location that nginx already provides, so activating it is the whole setup.
• Automatic, targeted purging — publishing, updating, unpublishing or trashing a post or page clears its own permalink, the home page and its public taxonomy archives, instead of throwing away the entire cache.
• Manual purge button — a one-click site-wide wildcard purge from the WordPress admin bar, for when you want a clean slate.
• Terms and comments — creating, editing or deleting a term purges its archive and the home page; new and moderated comments purge the post they belong to.
• Full-cache triggers where they matter — theme switches, menu and widget changes and Customizer saves purge everything, because they can affect every page.
• WooCommerce aware — product and category changes are detected automatically and purge the shop page along with the usual targets.
• Optional cache warmer — a background WP-Cron job re-fetches purged URLs so the next visitor still gets a warm cache.
• Settings and diagnostics — a settings page with a purge-endpoint override for proxy setups, an SSL-verification toggle, WP-Cron control and a built-in cache self-test; the X-FastCGI-Cache header is registered with WordPress Site Health.
• Sensible skips — post types with no front-end URL (menu items, revisions, orders) never trigger a pointless purge.

Requires WordPress 6.0+ and PHP 7.4+, and an nginx build with the ngx_cache_purge module — which is exactly what Reqad installs by default.

Reqad now includes a built-in File Manager — browse, edit and manage the files of any hosting account without leaving the panel.

• Account-level browsing — open it straight from the Accounts list; navigate the account home with a clickable breadcrumb and see size, permissions and modification time at a glance, with symlink awareness.
• Full file operations — upload, download, create files and folders, rename, change permissions with an owner/group/other grid, and delete single items or whole folders in bulk.
• Built-in code editor — edit text files with syntax highlighting for PHP, JavaScript, CSS, HTML, Python, shell and SQL, plus line wrapping and Ctrl+S to save.
• Archives — compress any selection to .zip or .tar.gz and download it in one click, or extract an uploaded archive into a folder of your choice.
• Secure by design — every operation runs as the account’s own user and is jailed to that account’s home directory, so files keep correct ownership and count against the right quota.

The June 2026 release focuses on hardening and modernisation across mail and PHP.

• Dovecot 2.4 & Roundcube 1.7.x — updated mail stack with improved TLS defaults and plugin compatibility.
• Isolated panel PHP-FPM master — the Reqad panel now runs under its own dedicated PHP-FPM pool with a private php.ini, hardened independently from hosted sites.
• PHP settings from the UI — recommended disable_functions, OPcache and APCu tuning are now configurable directly from the dashboard.
• Section access control — features that are disabled by the administrator now return a clean 403 instead of partially loading.

A feature-heavy month for Reqad, with improvements to WordPress management, Apache configuration and account migration.

• WordPress scanner across subfolders — detects installations at any depth, displays a path column, and uses prepared statements throughout.
• Apache hybrid PHP-FPM pools — Apache template now supports per-account PHP version switching via isolated PHP-FPM pools.
• cPanel transfer wizard — a new multi-step migration flow handles domains, PHP versions and databases in one guided process.
• Performance — accounts & email lists gained search and re-pagination; dashboard caching is notably faster.

April brings self-management capabilities and important hardening for hosted accounts.

• One-click self-update — update Reqad directly from the dashboard with a live output stream; the panel survives PHP-FPM restarts mid-update.
• Autoresponders — create, edit and delete autoresponders with start/end date ranges; all replies are DKIM-signed automatically.
• Roundcube and phpMyAdmin auto-update scripts — preserve config files and installed plugins across version upgrades.
• Per-account PHP-FPM hardening — each account gets open_basedir, disable_functions, an isolated tmp directory and separated log files.

The March release extends system-level management features significantly.

• SSH key management — add, delete and auto-convert SSH2 public keys per account from the panel UI.
• PHP Modules tab — install or uninstall PHP extensions per version with a live progress stream.
• Telemetry & update banner — Reqad now checks for new versions and shows a dashboard banner when an update is available.
• Cron jobs — full add/edit/delete management for both global server crons and per-user schedules.
• Database user passwords — change MariaDB account passwords directly from the panel.

We are excited to announce that Reqad is now open source under the GPL-3.0 license.

Reqad is a self-hosted hosting control panel designed as a modern alternative to cPanel/WHM, built in-house by Webdev SRL (Bucharest) — a company that has been running hosting infrastructure since 2002.

• Account management, email (exim/dovecot/Roundcube/SpamAssassin), DNS, SSL, MariaDB, PHP-FPM (multi-version), backups and WordPress tooling.
• Full support for Rocky Linux 8 and 9 (x86_64); arm64 support is on the roadmap.
• Nginx + PHP-FPM or Apache as the web stack.

The source code will be available on GitHub. Self-hosting is and will remain free.