Skip to content

Heads up: this repo pins a PHP version affected by PHP2Shell (CVE-2026-109618 / CVE-2026-109619) #401

Open

Description

@caldempsey

Hey, I ran a GitHub code search for Dockerfiles pinning an end-of-life PHP base image and your repo came up. You're getting this because of that.

What happened: On October 21 2026 the PHP project disclosed two critical unauthenticated remote-code-execution flaws in PHP core, together nicknamed "PHP2Shell" (CVE-2026-109618 and CVE-2026-109619, both CVSS 9.2). They affect every PHP build before 8.2.35, 8.3.36, 8.4.27 and 8.5.12. PHP 8.1 and older are end-of-life and get no official fix, only source backports for 7.4 / 8.0 / 8.1. The FBI and CISA have both urged operators to patch immediately or take affected systems offline.

Why this repo

Your repo has a Dockerfile building on a web-serving PHP image (php:…-apache or php:…-fpm) for a release below the patch line (7.2–8.1). Those tags get no official PHP fix, so the image serves web requests on a vulnerable PHP unless you upgrade or apply the backport. mod_php, the -apache image, is the configuration the advisory rates highest-risk.

Checklist

  1. Move the base image to a patched release: php:8.2.35, php:8.3.36, php:8.4.27 or php:8.5.12 (or newer).
  2. If you must stay on 7.4 / 8.0 / 8.1, apply the PHP security team's source backport, or get a patched package from your distro / LTS vendor.
  3. Rebuild and redeploy. A rebuild alone does not help if the tag is still below the patch line.
  4. If you can't patch right away, the FBI and CISA both say to take the system offline until it's fixed.
  5. Watch your web servers: a PHP worker process unexpectedly launching a shell or downloading files is the thing to look for.
  6. If you find signs of compromise, isolate the box, preserve your web-server and PHP logs, and report it to your local FBI field office or https://www.ic3.gov.

If you can't update immediately

These reduce exposure to specific attack paths. They are not a fix; only an update is.

  • Enforce memory_limit=-1 administratively (FPM pool or Apache config) so an application can't put a finite limit back.
  • Set session.upload_progress.enabled=0 and restart every worker.
  • On PHP 8.5, set fatal_error_backtraces=0 and restart every worker.
  • Keep post_max_size conservative and bound multipart part / header counts at your proxy.

References

Disclaimer

This is informational only and not professional security advice. I ran a search and wanted affected maintainers to hear about it. If this is a false positive, a library, an example, a test fixture, an archived project, or an image that already carries a distro backport, sorry for the noise, feel free to close.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions