All Activity

Unfortunately, I have never tested this; we don’t have an AlmaLinux 8.x server.

If you are concerned about false positives, you may delete the file and utilize the CWP PHP, as those PHP versions have been corrected.

Upstream CWP officially resolved this exact issue today (October 30, 2026) by deploying a rewritten, native updater (update_roundcube) that specifically targets Roundcube 1.6.20 LTS and handles all CWP-specific integrations. Upgrade Roundcube to 1.6.20 via native CWP script /scripts/update_roundcube I ran it on Alma 9 without any issues.

While the script is a well-crafted community workaround for an earlier CWP bug, it is now obsolete and counterproductive for most CWP powered servers. Running it will hijack your server's package update mechanism with persistent systemd guards and will break webmail proxy routing and CWP panel Single Sign-On (SSO). ▕ Furthermore, upstream CWP officially resolved this exact issue today (October 30, 2026) by deploying a rewritten, native updater (update_roundcube) that specifically targets Roundcube 1.6.20 LTS and handles all CWP-specific integrations. Upgrade Roundcube to 1.6.20 via native CWP script /scripts/update_roundcube

@Sandeep B. Any news on a fix for this false positive that keeps popping up? Thanks

A security patch was issued on the 27th.

Good evening, just a quick question, could we use the php-manager to install php Snuffleupagus? I prefer php-manager has its enabled to allow me to install php 8.5.12 and php-fpm with ease so wondering if at first is it possible and also what would the command be please?

2019 to keep

Your /usr/local/cwp/php71/ is probably PHP 8.3.36 Do a /usr/local/cwp/php71/bin/php -v to see Ours have intl.so under: /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20170718/intl.so /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so But I am not sure which one to keep and which one to remove...

I also found some posts on this and the CWP forum referring to the following directory: /usr/local/cwp/php71/bin I don't have that directory. I have: [root@cwp8 ~]# ls /usr/local/cwp/php71 etc lib php.d tmp var

Thank you for sharing the fruits of your labor! I have CWP installed on AlmaLinux 8.x. After using the Standalone CWP PHP CLI Build Manager, I get the following error: PHP Warning: PHP Startup: Unable to load dynamic library 'intl' (tried: /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20230831/intl (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20230831/intl: cannot open shared object file: No such file or directory), /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20230831/intl.so (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20230831/intl.so: cannot open shared object file: No such file or directory)) in Unknown on line 0I do have /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20170718/intl.so not the version listed in the error. I have an old web app that uses PHP 7.3 so that version is still enabled in CWP if that matters. How do I resolve this issue?

From October 26 through November 3, 2026, enjoy three spooktacular deals: 70% off your first month of VPS hosting, 20% off renewals, and a free domain with VPS payments of 6 months or more. Get 70% Off Your First Month Order a new VPS in Israel, India, or Russia and save 70% on your first month. Promo code: UFOWEEN70 Get 20% Off VPS Renewals Already a customer? Renew your VPS in any location for any billing term and get 20% off. Promo code: BOO20 Get a Free Domain with Your VPS → Pay for 6 months or more: Get a free 1-year domain registration (.RU, .РФ, or .XYZ). → Pay for 12 months or more: Get a free 1-year domain registration (.DIGITAL, .TOP, or .SHOP). 💡 How to Get the Most Out of This Deal New customers: Order a VPS for 1 month using UFOWEEN70, then renew it for 6 months or more using BOO20. You’ll get 70% off your first month, 20% off your renewal, and a free domain! Existing customers: Renew your VPS for 6 months or more using BOO20 to get 20% off your renewal and a free domain! How to claim your free domain: Pay for at least 6 months of VPS hosting and submit a ticket to our Sales team by November 3, 2026. Include your preferred available domain name. 🎃 Take advantage of the offers before November 3: https://ufo.hosting/

i will add the patch in v6

Thanks for the great work on php-manager @Sandeep B. Would it be possible to change the repository of 7.4 from php.net to take advantage of the backported fixes?

The PHP manager does not modify any Perl versions and relies on the base Perl version installed on the operating system. To resolve this issue, please execute the command by copying all and pasting them into your SSH terminal. dnf module reset perl && dnf module enable perl:5.26 && dnf distro-sync 'perl*' && dnf check

Is there a permanent fix to get rid of it? I clear it, and it's back the next day.

Also, after an earlier version of php-manager (v3) installed dependencies, now I am in dependency hell. I have a mismatch of perl 5.26 and 5.32 modules installed, so now dnf doesn't run smoothly. How to straighten it out? Which track do you recommend for AlmaLinux 8? Error: Problem 1: cannot install the best update candidate for package net-snmp-agent-libs-1:5.8-33.el8_10.x86_64 - problem with installed package net-snmp-agent-libs-1:5.8-33.el8_10.x86_64 - package net-snmp-agent-libs-1:5.8-33.el8_10.x86_64 from @System requires libperl.so.5.26()(64bit), but none of the providers can be installed - cannot install the best update candidate for package perl-libs-4:5.26.3-423.el8_10.1.x86_64 - cannot install both perl-libs-4:5.32.1-475.module_el8.10.0+4278+b5f6cf5f.x86_64 from appstream and perl-libs-4:5.26.3-423.el8_10.1.x86_64 from @System - cannot install both perl-libs-4:5.32.1-475.module_el8.10.0+4278+b5f6cf5f.x86_64 from appstream and perl-libs-4:5.26.3-422.el8.0.1.x86_64 from baseos - cannot install both perl-libs-4:5.32.1-475.module_el8.10.0+4278+b5f6cf5f.x86_64 from appstream and perl-libs-4:5.26.3-423.el8_10.1.x86_64 from baseos - cannot install both perl-libs-4:5.32.1-475.module_el8.10.0+4278+b5f6cf5f.x86_64 from appstream and perl-libs-4:5.26.3-423.el8_10.x86_64 from baseos Problem 2: problem with installed package perl-utils-5.26.3-423.el8_10.1.noarch - cannot install the best update candidate for package perl-utils-5.26.3-423.el8_10.1.noarch - package perl-utils-5.32.1-475.module_el8.10.0+4278+b5f6cf5f.noarch from appstream requires perl-libs = 4:5.32.1-475.module_el8.10.0+4278+b5f6cf5f, but none of the providers can be installed - problem with installed package perl-DBI-1.641-11.module_el8.10.0+4309+f7cd2555.x86_64 - cannot install the best update candidate for package perl-DBI-1.641-11.module_el8.10.0+4309+f7cd2555.x86_64 - package perl-DBI-1.641-11.module_el8.10.0+4309+f7cd2555.x86_64 from @System requires libperl.so.5.26()(64bit), but none of the providers can be installed - package perl-DBI-1.641-11.module_el8.10.0+4309+f7cd2555.x86_64 from appstream requires libperl.so.5.26()(64bit), but none of the providers can be installed - package perl-DBI-1.641-11.module_el8.10.0+4312+43cd95d3.x86_64 from appstream requires perl(:MODULE_COMPAT_5.24.4), but none of the providers can be installed - package perl-DBI-1.641-11.module_el8.10.0+4312+43cd95d3.x86_64 from appstream requires libperl.so.5.24()(64bit), but none of the providers can be installed - package perl-DBI-1.641-11.module_el8.10.0+4311+a4e46aec.x86_64 from appstream requires perl(:MODULE_COMPAT_5.30.1), but none of the providers can be installed - package perl-DBI-1.641-11.module_el8.10.0+4311+a4e46aec.x86_64 from appstream requires libperl.so.5.30()(64bit), but none of the providers can be installed - cannot install both perl-libs-4:5.32.1-475.module_el8.10.0+4278+b5f6cf5f.x86_64 from appstream and perl-libs-4:5.26.3-423.el8_10.1.x86_64 from @System - cannot install both perl-libs-4:5.32.1-475.module_el8.10.0+4278+b5f6cf5f.x86_64 from appstream and perl-libs-4:5.26.3-422.el8.0.1.x86_64 from baseos - cannot install both perl-libs-4:5.32.1-475.module_el8.10.0+4278+b5f6cf5f.x86_64 from appstream and perl-libs-4:5.26.3-423.el8_10.1.x86_64 from baseos - cannot install both perl-libs-4:5.32.1-475.module_el8.10.0+4278+b5f6cf5f.x86_64 from appstream and perl-libs-4:5.26.3-423.el8_10.x86_64 from baseos - cannot install both perl-libs-4:5.32.1-475.module_el8.10.0+4278+b5f6cf5f.x86_64 from appstream and perl-libs-4:5.24.4-404.module_el8.1.0+6019+b22674e1.x86_64 from appstream - cannot install both perl-libs-4:5.32.1-475.module_el8.10.0+4278+b5f6cf5f.x86_64 from appstream and perl-libs-4:5.30.1-452.module_el8.4.0+2179+01326e37.x86_64 from appstream Problem 3: problem with installed package perl-interpreter-4:5.26.3-423.el8_10.1.x86_64 - cannot install the best update candidate for package perl-interpreter-4:5.26.3-423.el8_10.1.x86_64 - package perl-interpreter-4:5.32.1-475.module_el8.10.0+4278+b5f6cf5f.x86_64 from appstream requires perl-libs(x86-64) = 4:5.32.1-475.module_el8.10.0+4278+b5f6cf5f, but none of the providers can be installed - problem with installed package postfix-2:3.4.8-2.centos.8+p18.0.24.0+t200128.1353.x86_64 - cannot install the best update candidate for package postfix-2:3.4.8-2.centos.8+p18.0.24.0+t200128.1353.x86_64 - package postfix-2:3.4.8-2.centos.8+p18.0.24.0+t200128.1353.x86_64 from @System requires perl(Date::Calc), but none of the providers can be installed - package postfix-2:3.4.8-2.centos.8+p18.0.24.0+t200128.1353.x86_64 from cwp requires perl(Date::Calc), but none of the providers can be installed - package perl-Date-Calc-6.4-9.el8.noarch from appstream requires perl(:MODULE_COMPAT_5.26.3), but none of the providers can be installed - package perl-Date-Calc-6.4-9.el8.noarch from @System requires perl(:MODULE_COMPAT_5.26.3), but none of the providers can be installed - perl-libs-4:5.26.3-423.el8_10.1.i686 from baseos does not belong to a distupgrade repository - perl-libs-4:5.26.3-422.el8.0.1.i686 from baseos does not belong to a distupgrade repository - perl-libs-4:5.26.3-423.el8_10.i686 from baseos does not belong to a distupgrade repository - cannot install both perl-libs-4:5.32.1-475.module_el8.10.0+4278+b5f6cf5f.x86_64 from appstream and perl-libs-4:5.26.3-423.el8_10.1.x86_64 from @System - cannot install both perl-libs-4:5.32.1-475.module_el8.10.0+4278+b5f6cf5f.x86_64 from appstream and perl-libs-4:5.26.3-422.el8.0.1.x86_64 from baseos - cannot install both perl-libs-4:5.32.1-475.module_el8.10.0+4278+b5f6cf5f.x86_64 from appstream and perl-libs-4:5.26.3-423.el8_10.1.x86_64 from baseos - cannot install both perl-libs-4:5.32.1-475.module_el8.10.0+4278+b5f6cf5f.x86_64 from appstream and perl-libs-4:5.26.3-423.el8_10.x86_64 from baseos

PHP-FPM may fail to start with this error: PHP Fatal error: Unable to start pcre module in Unknown on line 0One possible cause is conflicting PCRE libraries under /usr/local/lib. If diagnostics identify these libraries as the cause, quarantine them instead of permanently deleting them. Back up the libraries and check ApacheThe following command moves matching files into a backup directory. If Apache’s configuration test fails, it restores them automatically. Moving shared libraries may affect other applications when they start or restart. Keep the printed backup path. Copy all and paste in SSH terminal: ( set -e backup=$(mktemp -d /root/libpcre-backup.XXXXXXXX) echo "Backup directory: $backup" find /usr/local/lib -maxdepth 1 -name 'libpcre*' \ -exec mv -t "$backup" {} + if ! /usr/local/apache/bin/httpd -t; then find "$backup" -maxdepth 1 -name 'libpcre*' \ -exec mv -t /usr/local/lib {} + echo "Apache check failed; files restored." exit 1 fi )Restart CWP PHP-FPM servicesAfter the Apache check passes, restart the running or failed PHP-FPM services. This briefly interrupts PHP requests on websites using those services. The command discovers installed services named php-fpm.service or php-fpmNN.service. It leaves inactive, non-failed services stopped. Copy all and paste in SSH terminal: systemctl list-unit-files -t service | awk '$1 ~ /^php-fpm[0-9]*\.service$/ {print $1}' | while IFS= read -r service; do if systemctl is-active -q "$service" || systemctl is-failed -q "$service"; then echo "Restarting $service" if systemctl restart "$service"; then systemctl is-active "$service" else echo "Restart failed: $service" SYSTEMD_PAGER=cat systemctl status -l "$service" fi fi doneVerify recoveryCheck the affected websites and PHP-FPM logs after restarting. Apache reporting Syntax OK alone does not confirm PHP-FPM recovery. If the same error remains or another application fails, restore the quarantined libraries using the printed backup directory and investigate the runtime library dependencies before making further changes.

The bug could let an attacker take over a system just by sending it malicious compressed data, with no login needed. That works both ways: a hacker could hijack an unpatched server, or a malicious server could hijack an unpatched user’s device. "During this red-teaming exercise, we also found a vulnerability that allows for unauthenticated remote code execution in Brotli, a widely-deployed compression library included in many pieces of software such as Node.js, Bun, and Envoy. The flaw could let an attacker run their own code on affected systems by sending or replying with malicious compressed data, without any need to create a user account. That is, an unpatched server that accepts compressed input could be taken over by a malicious client, and an unpatched client that accepts compressed input (such as “curl --compressed”) could be taken over by a malicious server. This root cause issue was actually fixed in the Brotli source code in February, but it wasn’t known at the time that it gave rise to a security vulnerability and there was no more recent release of Brotli. Since Brotli is built into other software, any software which includes this library needs to take the update too, followed by the users of that software. We disclosed the vulnerability to Brotli and other downstream projects such as Node.js, which released or are currently releasing security updates, and Brotli cut new release versions and published a CVE. Source: https://x.com/OpenAI/status/2113766354386084338 More details on the patch and mitigations below: Patch the PlanetBrotli vulnerability (CVE-2026-111497) — Patch the PlanetBrotli decoder vulnerability: affected software, fixed releases, and how to disable Brotli decoding while you patch.

its a false positive alert

A THIRD remote code execution vulnerability has JUST been disclosed, only 48 HOURS after PHP released emergency patches for two critical security flaws. And this one is STILL UNPATCHED. Here's what we know: NEW RCE DISCOVERED: CVE-2026-115560 could allow attackers to remotely execute malicious code on affected PHP servers. NO PATCH AVAILABLE: Even servers updated with Wednesday's emergency security fixes aren't patched against this new vulnerability. SPECIFIC CONFIGURATIONS AT RISK: The flaw requires an unusual combination of PHP session settings and application code. DEFAULT FEATURE INVOLVED: PHP's session upload progress feature is enabled by default and is part of the vulnerable configuration. OFFICIAL MITIGATION: PHP recommends setting session.upload_progress.enabled=0 until the next release. THIRD RCE IN 48 HOURS: Two critical flaws were patched Wednesday. Now another has been disclosed before a fix is available. PHP powers nearly 70% of websites with a known server-side language. THREE remote code execution vulnerabilities disclosed in just DAYS. And now another reminder that even applying the latest security patches doesn't guarantee you're protected against every newly discovered flaw. "Only a narrow setup is at risk. PHP says the problem can occur when a web application does all of the following: sets the session.serialize_handler option to php_binary or php_serialize in its configuration, then changes that option to php while running by calling ini_set(), and makes that change before it calls session_start(). Session upload progress must also still be turned on. An application that never changes the serialize handler while running can leave the feature on and is not exposed through this path. PHP says this setup is unlikely in practice. The action is one line. PHP recommends setting session.upload_progress.enabled=0 until the next routine bugfix release. This is the same setting it already listed as a mitigation in the October 21 advisory for CVE-2026-109619." [link to thehackernews.com (secure)] uploadprogress : An extension to track progress of a file upload. Trun it off! (For now) : session.upload_progress.enabled=0

Again my thanks to Sandeep re php-manager I got the 8.5.12 update.

Did v5 fix the below error in CWP?? Thanks

Still no joy. With or without Postgres installed (via CWP) -- after applying your suggestions (confirming everything is base OS provided). I still get (for both 8.3.36 and 8.5.12): checking for PostgreSQL support for PDO... yes checking for pg_config... not found configure: error: Cannot find libpq-fe.h. Please specify correct PostgreSQL installation path ERROR: PHP 8.3.36 configure FAILED. Build stopped; make was NOT run.

🔥[Qyrax.net] Halloween: 80% OFF your first VPS month in 11 US states — from $0.60🔥 Celebrate Halloween with Qyrax! From October 23 through November 4, 2026, get 80% off the first month of any new VPS in the US. Promo code: SPOOKY80 Order your VPS: https://qyrax.net 🎃Why choose Qyrax? NVMe storage — fast storage for databases and applications. KVM virtualization — reliable virtualization with full root access. 11 US locations — choose the location closest to your users. Migration assistance — our support team can help you transfer files, databases, and configurations from your current provider. 🎃Test your latency before ordering Use these test IPs to check connectivity from your location: Arizona (AZ), Phoenix — 2.56.117.1 California (CA), Silicon Valley — 213.59.112.1 Colorado (CO), Denver — 5.180.23.1 Florida (FL), Miami — 171.22.111.1 Georgia (GA), Atlanta — 45.136.115.1 Illinois (IL), Chicago — 45.149.112.1 Michigan (MI), Detroit — 139.28.234.1 New York (NY), New York — 185.161.70.1 Texas (TX), Dallas — 45.66.164.1 Virginia (VA), Ashburn — 194.36.38.1 Bandwidth: All plans include 32 TB of monthly traffic. If you exceed this limit, your port speed will be capped at 100 Mbps until the start of the next month. 🎃How to claim your discount: Visit https://qyrax.net, log in to the billing panel, and select your preferred plan and location. Choose a 1-month billing cycle and apply the promo code SPOOKY80 at checkout. Complete your payment — your server will be deployed in just 15–30 minutes. Need help moving? Open a support ticket after deployment, and our team will handle the migration for you. Have any questions? Reply to this thread or open a ticket in your client area at https://qyrax.net. 🎃Happy Halloween!🎃