Is Open Source Lab down?

PHP has announced two critical security vulnerabilities and will publish fixed releases on Wednesday, Oct 21 at 7:00 AM PDT (14:00 UTC). If your project runs PHP on a VM or server that you manage yourself, please update PHP as soon as your package source has the fix, and restart PHP-FPM or your web server afterwards. Who needs to act: - Projects that manage their own OpenStack VMs or colocated servers and run PHP (for example WordPress, Drupal, MediaWiki, Nextcloud, phpBB or DokuWiki). - Hosts that OSL manages for you: we are patching these ourselves today, and we will contact you directly if your site needs application changes. What PHP has said: PHP rates both flaws critical (CVSS 9.2) and has not yet published which components are affected. Security researchers believe they allow remote code execution and affect PHP 5 through 8. Fixes will ship only for the supported branches 8.2, 8.3, 8.4 and 8.5. PHP 8.1 and older are end-of-life and will not get an official fix. What to do: - PHP 8.2 or newer: install your vendor's update when it appears (Remi, Ubuntu or Debian security updates, or a rebuilt Docker image), then restart PHP-FPM or the web server. - PHP 8.1 or older: plan a move to PHP 8.3 or 8.4 now. PHP 8.2's security support also ends on Dec 31, 2026. Remi's repository has backported security fixes to 7.4, 8.0 and 8.1 on a best-effort basis in the past, which can serve as a stopgap. - An end-of-life OS (CentOS 7, Ubuntu 20.04 without Ubuntu Pro, Debian 11): no free fix is expected, so please plan an OS upgrade. If you are unsure whether you are affected or need help, email [email protected].

PHP has released the fixes: 8.2.35, 8.3.36, 8.4.27 and 8.5.12, published at 6:34 AM PDT (13:34 UTC). Both flaws allow unauthenticated remote code execution. Sites that run PHP through Apache's mod_php are the most exposed, and PHP-FPM is affected too. If you run PHP on a VM or server you manage, update to the fixed release for your branch as soon as your package source has it, then restart PHP-FPM or your web server. For AlmaLinux and RHEL 8 or newer, Remi's repository is publishing the fixed packages today; there will be no fixed Remi packages for EL7. PHP 8.1 and older get no fix from PHP. Until you can move to 8.3 or 8.4, PHP's advisory suggests setting session.upload_progress.enabled=0 in php.ini and restarting PHP. That blocks one demonstrated attack path but is not a complete fix. Advisories: https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp What we are doing on the hosts OSL manages for you: - Done: we have turned session upload progress off (the stopgap above) on every running PHP host we manage. - Today: we install the fixed PHP packages as soon as Remi publishes them, and restart PHP. - Next: hosts still on PHP 7.4, 8.0 or 8.1 are moving to supported PHP versions. If your site is on one of our shared web hosts, we will contact you directly about moving it. If you need help, email [email protected].

Every PHP host that OSL manages for you is now running fixed PHP packages, as of 9:15 AM PDT (16:15 UTC). We installed Remi's fixed builds (8.2.35, 8.3.36, 8.4.27 and 8.5.12, plus Remi's backported fix for PHP 7.4 and 8.1) and restarted PHP. The session upload progress stopgap stays in place as an extra layer. If you run PHP on a VM or server you manage, please update now: an exploit for these flaws has been published. - PHP 8.2 to 8.5: update to 8.2.35, 8.3.36, 8.4.27 or 8.5.12 from Remi or your distribution's security updates, then restart PHP-FPM or your web server. - PHP 7.4 or 8.1 from Remi's repository: update to 7.4.33-31 or 8.1.34-6, which carry Remi's backported fix, then restart. These versions are still end-of-life, so plan a move to PHP 8.3 or 8.4. - Anything else, or if you can't update yet: set session.upload_progress.enabled=0 in php.ini and restart PHP. It blocks the published attack path but is not a complete fix. Sites on PHP 7.4 and 8.1 on our shared web hosts have Remi's backported fix. We will contact site owners directly about moving those sites to a supported PHP version. We'll keep this incident open while hosted projects update. If you need help, email [email protected].

Every PHP host that OSL manages for you is still running fixed PHP packages, and session upload progress is still turned off on all of them. On October 23 PHP published an advisory for a further issue, CVE-2026-115560, which has no patch yet. PHP's only mitigation for it is the same setting, session.upload_progress.enabled=0, so OSL-managed hosts need no further change. PHP will ship the fix in its next regular release. If you run PHP on a VM or server you manage: - Keep session.upload_progress.enabled=0 in php.ini or your PHP-FPM pool settings until PHP's next release. A .user.ini file or ini_set() is not enough. - If you haven't installed the October 21 fixes yet, please do so now (see our previous update). Since our last update, no OSL-managed host runs PHP 8.1 any more. Sites still on PHP 7.4 keep Remi's backported fix while we move them to supported versions with their owners: the phpBB hosts through November 18, and the sites on our shared web hosts by December 2. We'll keep this incident open until those moves are done. If you need help, email [email protected].

We're resolving this incident. Every PHP host that OSL manages for you runs the fixed PHP packages from October 21, or Remi's backported fix on PHP 7.4, and session upload progress stays turned off on all of them. If you run PHP on a VM or server you manage: - Keep session.upload_progress.enabled=0 in php.ini or your PHP-FPM pool settings. PHP has not yet released a fix for CVE-2026-115560, and that setting is its only mitigation until PHP's next regular release. - When that release comes out, update to it and restart PHP-FPM or your web server. Sites still on PHP 7.4 on OSL-managed hosts keep Remi's backported fix while we move them to supported versions with each project directly, through December 2. We won't post further updates here for those moves; each project hears from us on its own ticket. If you need help, email [email protected].

We encountered an issue that is affecting SMTP services on most of our systems. We are working on deploying a fix soon.

The fix has been deployed and all SMTP services should be back to normal.