Skip to main content

PHP Security Advisory: CVE-2026-109618 and CVE-2026-109619

On October 21, 2026, the PHP project released fixes for two critical remote code execution vulnerabilities in PHP itself. Both are rated CVSS 9.2. An attacker does not need to log in to exploit them.

The flaws are in PHP, not in DreamFactory code. Every DreamFactory instance runs on PHP, so treat every instance as affected until its PHP is updated.

Updating PHP is the only complete fix

The temporary mitigation reduces your exposure, but it does not fix either vulnerability. Update PHP as soon as a patched build is available for your platform.

Docker: we rebuilt the base image​

Most DreamFactory customers run Docker. We rebuilt the DreamFactory base image dreamfactorysoftware/df-base-img:7.7 on PHP 8.5.12. You fix your instance by rebuilding your container. You do not need a new DreamFactory version.

Step 1: Find your base image​

From your df-docker directory, run:

grep '^FROM' Dockerfile
FROM line showsdf-docker versionPHPWhat to do
df-base-img:7.77.7.18.5Rebuild. No file changes.
df-base-img:7.67.6.0, 7.7.08.5Change the FROM line to df-base-img:7.7, then rebuild.
df-base-img:v77.4.0, 7.5.08.3Add one RUN line to the Dockerfile, then rebuild.
Anything elseOlder or customizedVariesContact DreamFactory support with your Dockerfile.

The prebuilt dreamfactorysoftware/df-docker:7.7.1 and latest images are not yet republished. If you pull a prebuilt image instead of building one, see Helm and prebuilt images.

Step 2: Save your APP_KEY​

The rebuild creates a new container. If docker-compose.yml does not set APP_KEY, the new container generates a new key, and every stored service password stops working ("The MAC is invalid"). Read the current key:

docker compose exec web grep '^APP_KEY=' .env

If docker-compose.yml does not already set it, add it under the web service's environment, in single quotes:

APP_KEY: 'base64:...'

Test a service after the rebuild, not only the admin login. In our testing, a rebuild without APP_KEY still let the administrator log in, but every stored service password failed with "The MAC is invalid".

Step 3: Note your DreamFactory version​

docker compose exec web grep "'version'" config/app.php

The df-docker Dockerfile clones DreamFactory from the master branch unless you name a version. A --no-cache rebuild clones it again, so without a version it upgrades DreamFactory to the latest release. You pass your current version to the build in Step 5 so that only PHP changes.

Step 4: Change the Dockerfile (df-docker 7.4.0 to 7.7.0 only)​

FROM shows df-base-img:7.6. Change the line to:

FROM dreamfactorysoftware/df-base-img:7.7

Both images run PHP 8.5, so the rest of the Dockerfile and the entrypoint stay the same.

FROM shows df-base-img:v7. Keep the FROM line. The base image v7 runs PHP 8.3 and was not rebuilt. Add these lines directly below the FROM line. They install the fixed PHP 8.3 packages during the build:

RUN apt-get update \
 && DEBIAN_FRONTEND=noninteractive apt-get install -y --only-upgrade 'php8.3-*' \
 && apt-get clean && rm -rf /var/lib/apt/lists/*

Do not change the FROM line to df-base-img:7.7 on these versions. That image runs PHP 8.5, and the df-docker 7.4.0 and 7.5.0 entrypoint starts php8.3-fpm, so the container does not start.

Step 5: Rebuild and restart​

Replace 7.5.0 with the version from Step 3:

docker compose build --pull --no-cache --build-arg BRANCH=7.5.0 web
docker compose up -d

--pull and --no-cache are required. Without them, Docker reuses cached layers and you keep the old PHP. If the build fails while it downloads packages, the package mirrors are busy. Run the build again.

Commercial installs: if your Dockerfile copies in commercial composer files, they must match the version you pass in BRANCH. Composer files for one version do not install correctly on another.

Step 6: Confirm​

docker compose exec web php-fpm8.5 -v    # df-docker 7.6.0 and later
docker compose exec web php-fpm8.3 -v    # df-docker 7.4.0 and 7.5.0
docker compose exec web grep "'version'" config/app.php

PHP must report 8.5.12 or later, or 8.3.36 or later. The DreamFactory version must match Step 3. Then log in and test one service that uses a stored password.

Helm and prebuilt images​

Prebuilt df-docker images carry the PHP they were built with. Until rebuilt tags are published, build the image from the df-docker repository as above, push it to your own registry and point your deployment at it. Keep the same APP_KEY in your deployment's environment.

df-docker older than 7.0​

These versions run on PHP versions that get no fix. Build a new DreamFactory 7.7.1 instance and move your configuration to it. See Major Version Migration.

Is there a new DreamFactory release?​

No. DreamFactory code does not change for these vulnerabilities. The fix is a patched PHP build under your existing DreamFactory.

You need a DreamFactory upgrade only if your DreamFactory version cannot run on a fixed PHP version. That applies to DreamFactory 4.x and, for the long term, to DreamFactory 5.0.0 to 7.0.0. For Docker, the patched PHP comes in a rebuilt base image. See Docker: we rebuilt the base image.

Fixed PHP versions​

PHP branchFixed inStatus
8.58.5.12Supported
8.48.4.27Supported
8.38.3.36Supported
8.28.2.35Security fixes end December 31, 2026
8.1 and olderNo fixEnd of life

Linux distributions that patch their own PHP packages, such as the standard Ubuntu and Debian repositories, often keep the old version number. For those packages, check your distribution's security notice instead of this table.

PHP's technical advisories:

The advisories explain how each flaw works, which server setups are most exposed and which settings reduce the risk. PHP has not published reproduction steps or a test case.

How exposed is your instance​

How PHP runs under your web server changes the risk. It does not change the fix: update PHP in every case.

  • Apache with mod_php, or the PHP built-in server (php -S). This is the most exposed setup, and the one the public exploit demonstrations target. The DreamFactory Linux installer uses mod_php when you choose Apache. Update these instances first.
  • PHP-FPM. The default DreamFactory installer (NGINX) and the DreamFactory Docker image run PHP-FPM. In our testing against DreamFactory on PHP-FPM, we have not reached code execution. The PHP advisory describes a harder second path that can still work on PHP-FPM, so treat these instances as lower risk, not safe.
  • IIS with FastCGI on Windows. Treat these instances as affected and update PHP.

DreamFactory does not use PHP sessions, but that does not protect you. In our testing, an unauthenticated upload to any DreamFactory URL reached the vulnerable PHP code before DreamFactory ran.

Find your upgrade path​

Your DreamFactory version decides which PHP versions it runs on. Check it before you change PHP: if you install a PHP version outside the range for your DreamFactory version, DreamFactory stops working.

To find your DreamFactory version, log in as an administrator and open System > Config > System Info, or run this from the DreamFactory root directory:

grep "'version'" config/app.php

Then find the first row that matches your instance.

Your instanceFixGuide
Docker or KubernetesRebuild on the patched base imageDocker: we rebuilt the base image
DreamFactory 7.0.1 or later, LinuxInstall the PHP patch releaseUpdating PHP on Linux
DreamFactory 7.0.1 or later, WindowsInstall the PHP patch releaseUpgrading PHP on Windows
DreamFactory 5.0.0 to 7.0.0Upgrade DreamFactory to 7.7.1. As a stopgap, run on PHP 8.3.Upgrading and Migrating DreamFactory, stopgap
DreamFactory 4.x or olderBuild a new DreamFactory 7.7.1 instance and migrateMajor Version Migration

DreamFactory 7.0.1 and later on PHP 8.0 to 8.2 must also move to a supported PHP branch. PHP 8.2 gets this fix but loses security support on December 31, 2026.

Temporary mitigation​

Use these steps only until you can update PHP. They reduce the risk. They do not remove it.

  1. Restrict network access. If the instance is reachable from the internet, limit access with a firewall rule, IP allowlist or VPN.

  2. Change PHP settings. Set these in the php.ini that your web server loads, not the command line one:

    session.upload_progress.enabled = Off
    ; PHP 8.5 only:
    fatal_error_backtraces = Off

    PHP's advisory for CVE-2026-109618 also names memory_limit = -1 as the main setting for installs that cannot update. Read the advisory before you use it: it removes PHP's per-request memory cap, so a single request can use as much memory as the server allows.

  3. Fully restart PHP. Restart PHP-FPM, Apache if it runs mod_php, or IIS. A PHP-FPM reload is not enough. Setting these values with ini_set() or .user.ini does not work.

  4. Confirm. Check the values as described in Confirm the version your web server runs.

session.upload_progress.enabled = Off blocks one confirmed attack path for CVE-2026-109619. It does nothing for CVE-2026-109618. DreamFactory does not use PHP session upload progress, so turning it off does not affect DreamFactory features.

Confirm the version your web server runs​

php -v reports the command line PHP. The web server can run a different build. To see the PHP that serves DreamFactory, ask DreamFactory itself. Log in as an administrator, then call the environment endpoint:

curl -s https://your-instance/api/v2/system/environment \
  -H "X-DreamFactory-Session-Token: YOUR_ADMIN_SESSION_TOKEN"

In the JSON response, php.core.php_version is the version the web server runs. It must be a fixed version from the table above, unless your PHP comes from your distribution's own repository. The same response shows the temporary mitigation settings:

  • php.session["session.upload_progress.enabled"]
  • php.core.memory_limit
  • php.core.fatal_error_backtraces (PHP 8.5)

Questions​

Commercial customers can reply to the advisory email or contact DreamFactory support. Tell us your deployment type, DreamFactory version and PHP version, and we will help you plan the upgrade.