NCSC-NL

AI Helped Expose Old PHP Bugs. Here Is How to Find Every Runtime You Need to Patch A security patch is easy to approve. Finding every PHP runtime hidden in an old container, appliance, control panel, or forgotten staging server is the harder part. That problem became urgent after PHP disclosed two critical remote code execution flaws, CVE-2026-109618 and CVE-2026-109619, known together as PHP2Shell. The PHP project released fixed versions on October 21, 2026. Its advisory says any PHP installation serving web requests could be at risk, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed. The project's rating of the risk is highest for mod_php, where a demonstrated request could reach the flaw before application code ran. (PHP security advisory) The discovery story needs careful attribution. Calif Research says it found the first PHP2Shell bugs during its audit. OpenAI's account says GPT-5.6 Sol helped Calif identify the critical flaw, while Wiz describes a separate, later audit that used both Gemini 4 Argon and GPT-5.6 Sol. Wiz says Argon made a significant contribution to its discovery. These accounts support a narrower claim: AI-assisted research helped expose these issues. They do not mean an AI autonomously found every flaw or built the full exploit chain. (Calif Research's account, OpenAI's account, Wiz's account) For operators, the urgent question is practical: which PHP runtimes serve real traffic, and how do you prove they were updated and restarted? Here is a cautious inventory and patch-verification workflow. It does not exploit anything. It helps you find the runtime that a package list or a single php -v command can miss. Start with the exact fixed versions The PHP project's October 21 security release lists these fixed upstream versions: - PHP 8.5.12 - PHP 8.4.27 - PHP 8.3.36 - PHP 8.2.35 Linux distributions and long-term-support vendors may backport security fixes without changing the upstream version number in the same way. PHP says to check with the vendor for updated packages. PHP 8.1 and older no longer receive updates from the PHP project, though a distribution or vendor may provide its own backport. Do not declare an old-looking version vulnerable or fixed based only on the version string. Confirm the package's vendor advisory or build provenance. (PHP advisory) The report from the Dutch National Cyber Security Centre is useful here because it tracks both PHP itself and downstream software that may bundle PHP. Its inventory listed 948 products on November 4, with 215 marked vulnerable and 185 fixed at that snapshot. Those counts change as maintainers update the list, so treat them as a dated inventory, not a current universal total. (NCSC-NL PHP2Shell tracker) Why php -v is not a complete audit A shell command named php usually reports the command-line interpreter selected by your current PATH. A website may instead use PHP-FPM behind Nginx, an Apache module, a container image, a hosting control panel, or PHP embedded inside a third-party appliance. Those may be different builds. A machine can have multiple PHP versions installed at once. Updating the CLI package does not prove that the process serving requests was updated, and replacing a package does not prove that old workers have exited. Think of this as an inventory problem with three layers: - Hosts: virtual machines, physical servers, cloud instances, and staging systems. - Runtimes: package installs, custom builds, containers, and bundled copies. - Traffic paths: the service or appliance that actually accepts web requests. A clean result in one layer does not clear the other two. The NCSC-NL guidance explicitly recommends identifying PHP-based applications and checking third-party images, appliances, and embedded runtimes separately. (NCSC-NL operational guidance) Step 1: List every place PHP could run Start with your asset inventory, cloud console, deployment configuration, and hosting panel. Search for PHP-related service names and image tags in infrastructure code. Include production, staging, build workers that serve previews, and appliances managed by another team. On each Linux host you administer, these read-only commands provide useful clues: command -v php || true php -v 2>/dev/null || true php --ini 2>/dev/null || true ps -eo pid,comm,args | grep -E '[p]hp-fpm|[p]hp-cgi|[a]pache2|[h]ttpd|[l]itespeed' systemctl --type=service --state=running | grep -Ei 'php|apache|httpd|nginx|litespeed' They are discovery aids, not a complete scanner. Process names vary by operating system and package. A reverse proxy such as Nginx may pass requests to PHP-FPM, so seeing Nginx alone tells you little about the PHP version. Likewise, a process list can show a service without identifying the image or package that supplied its binary. For Debian- or Ubuntu-based hosts, inspect installed packages as a second view: dpkg-query -W -f='${Package} ${Version}\n' 'php*' 2>/dev/null For RPM-based hosts, check the package database with the package tool used by that system. Do not assume the package name is identical across distributions or third-party repositories. If the system uses a hosting panel, consult its supported runtime list too. Panel-managed PHP builds can live outside the operating system's standard package paths. The point is to gather evidence from multiple places, not to trust one command. Record the hostname, application, runtime source, serving mode, reported version, owner, and next action. If you cannot identify the runtime owner, mark the asset as unresolved rather than treating it as safe. Step 2: Check containers and bundled products A host can be patched while a container continues to run an older PHP image. List the containers that are actually running, then trace each one to its image and deployment definition: docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}' This only reports containers visible to the Docker daemon you queried. Repeat for each cluster, account, and environment, and use your orchestrator's deployment inventory for Kubernetes or other platforms. For every PHP image, identify its base image and rebuild from an image containing a vendor-fixed runtime. A tag such as latest is not proof that the deployed image changed; compare immutable image digests or your registry's build metadata. Also check products that embed PHP rather than exposing a PHP package directly. The NCSC-NL tracker names downstream software and points to supplier advisories. A product may require a vendor firmware or appliance update even when you cannot run php -v on it. For hosted services, ask the provider whether the relevant fleet or service component has been patched, and request the affected product version or rollout status. (NCSC-NL product inventory) This is where a version-only policy often fails. “The server is on PHP 8.4” leaves unanswered which build, which host, and which process. A more useful record says: “The public web tier runs the vendor package with the security fix; the FPM service was restarted; the running process now reports the expected build.” Step 3: Patch through the owner of the runtime For a standard distribution package, use that distribution's security update process and verify its advisory. For a container, rebuild and redeploy the image. For a managed platform, apply the provider's update process. For a custom build, use the relevant PHP release and deployment process, then verify the binary and all service workers. Do not copy a package command from a different operating system or panel. A command that appears to succeed may update the wrong PHP stream or leave the serving service untouched. The official PHP page says Linux distributions and LTS vendors received patches in advance, which is why the vendor's package status matters. (PHP security advisory) After deployment, restart or reload the relevant PHP and web-server processes using the service manager and procedure for your platform. Then check that the old workers are gone. The NCSC-NL guidance also calls out restarting workers when mitigation steps are used. A replaced executable on disk is not enough if a long-running process still has the old code mapped in memory. (NCSC-NL operational guidance) Step 4: Verify the serving process, not just the package Use a platform-specific health check that identifies the PHP version from the web-serving path. For example, an application can expose a temporary, access-controlled diagnostic endpoint that returns only the runtime version and SAPI. Remove it immediately after checking. Do not publish a public phpinfo() page: it can disclose configuration and environment details unrelated to this patch. For PHP-FPM, verify the package or image used by the pool, confirm the service restarted, and inspect the running process list. For Apache mod_php, check the Apache module and the PHP build loaded by Apache. For a containerized service, verify the deployed image digest as well as the runtime inside the running container. For appliances and managed services, use the vendor's version report or written confirmation. Keep a small evidence record for each asset: - The package, image digest, appliance build, or vendor update that contains the fix. - The service or deployment that was restarted or rolled out. - A post-update check showing the serving runtime is the expected build. - Any exception, owner, and deadline if an asset could not be updated. The goal is not paperwork for its own sake. This record helps prevent an old canary, preview environment, or secondary node from being forgotten after the main application passes its health check. If patching is delayed PHP's project has described temporary mitigations, including disabling session upload progress and reviewing settings such as memory_limit, post_max_size, and PHP 8.5's fatal_error_backtraces. The NCSC-NL guidance explicitly says these steps are not complete fixes. PHP's October 23 informational advisory also recommends session.upload_progress.enabled=0 until the next regular bug-fix release for an unlikely additional RCE vector, CVE-2026-115560. It notes that the risk depends on an unusual combination of session-handler configuration and application behavior. (PHP advisory and update, NCSC-NL guidance) Treat these as temporary risk reduction, not a substitute for the vendor-fixed runtime. Do not blindly change memory or request-size limits on a busy service without checking application requirements. Test configuration changes, document them, and schedule the actual patch. A separate operational point matters: Singapore's Cyber Security Agency published an alert on November 3, 2026, describing active exploitation against selected network and security products, including reports of attackers chaining PHP2Shell with a separate Linux kernel flaw. That is not evidence that every PHP installation has been compromised. It is a reason to check product-specific vendor guidance and review logs for systems that could have been exposed. (Singapore CSA alert) What AI changes, and what it does not The public accounts describe more than one audit, with different researchers and different models involved. Calif says its audit found the first PHP2Shell bugs. OpenAI says GPT-5.6 Sol helped identify the critical flaw. Wiz later reports a separate investigation that used Gemini 4 Argon and GPT-5.6 Sol, with Argon making a significant contribution. These are the organizations' own accounts of their research, not independent measurements of how much work a model did. (Calif Research, OpenAI, Wiz) The useful lesson is not “AI automatically hacks old software.” The evidence here is narrower: capable models contributed to researchers' audits of a mature codebase, and those audits found serious flaws. Years of deployed versions and rarely audited products still need human owners who can inventory, update, restart, and verify them. The defenders' work is less glamorous: know what is running, know who owns it, update the right artifact, restart the right process, and verify the result. That is exactly the kind of work that becomes more important when vulnerability discovery speeds up. A short checklist to keep - Inventory: include hosts, containers, staging, control-panel runtimes, and appliances. - Identify the serving mode: CLI version alone does not identify PHP-FPM, mod_php, or a bundled runtime. - Use vendor evidence: confirm upstream fixed versions or vendor backports. - Deploy and restart: update the artifact that serves requests, then ensure old workers exit. - Verify: check the live runtime or vendor build, not only the package manager's success message. - Track exceptions: assign an owner and deadline to anything still unknown or unpatched. - Review exposure: follow product-specific advisories and investigate suspicious activity where appropriate. The hard part of this incident is not typing an update command. It is finding the copy of PHP nobody remembers deploying. A reliable inventory turns that into a finite list instead of a guess. I write about software engineering, security, and AI. Subscribe if you want the next practical breakdown. Have you found a PHP runtime in a place your normal inventory missed? What check exposed it? Save this checklist for your next runtime patch cycle. Sources: - PHP security advisory and releases - NCSC-NL PHP2Shell operational information and software inventory - Calif Research: PHP2Shell, a tale of two PHP remote vulnerabilities - OpenAI: GPT-5.6 Sol and PHP2Shell research - Wiz: AI-assisted vulnerability discovery - Singapore Cyber Security Agency alert on active exploitation - Docker security update for PHP2Shell

PHP2Shell, Stand 4. November: Das niederländische NCSC führt 948 Produkte mit PHP, 215 davon noch verwundbar. PHP steckt auch in Geräten und Admin-Oberflächen. Unser Rat: alles inventarisieren, Updates einspielen, danach PHP-Prozesse neu starten. NCSC-NL/php2shell

Docker Security Dispatch — Issue 8: Two Shells, 17,000 CVEs, and No Time to Patch 🐚 In December 2021, Log4Shell gave the security industry a shocking Christmas present. Five years later, the security scene makes Log4Shell look like a relaxing afternoon. October 2026 brought us PHP2Shell, Node2Shell, and a poisoned LiteLLM release. Well, also a GitLab CVE, and an NGINX CVE, and an OpenCode CVE—you get the picture. Actually, we had more high and critical CVEs in October 2026 than we had in the whole of 2021. !Docker Security Dispatch 8 Welcome to Docker Security Dispatch 8, reviewing October 2026. This month: two shells, a compromised release pipeline, the growing gap between exploitation and patching, and some Docker commands to help us survive the next security apocalypse. Plus, some discount codes for books, a meetup in the Black Forest, my adventures at BaselOne, and a trip to J-Fall! 🐳 Key takeaways - October brought 17,013 CVEs, including 8,059 High and Critical findings. - Patch PHP and Node.js; investigate and rotate exposed credentials after LiteLLM compromise. - Rebuild, redeploy, verify—and limit what a compromised workload can reach. In This Issue - Book discounts - The CVE avalanche - Time to patch - Two shells - LiteLLM - Docker news - Practical defenses - Community spotlight - Recent work * 🎁 Discounts: Books Before the Bugs Time to get some security books? - 20% off Packt books: Use code AIDOCKER20 at Packt. - 50% off the Docker and Kubernetes Security ebook: Use code DSD8DKS, or [open the checkout with the discount applied](buy.containersecurity.dev[discount_code]=DSD8DKS). Prefer paper? Docker and Kubernetes Security is also available in paperback on Amazon. !Books in the woods of the Black Forest Unfortunately, purchasing a security book does not automatically patch your production containers. I've checked. 😅 * 🌋 The CVE Avalanche: October 2026 vs. 2021 Remember Log4Shell? CVE-2021-44228 affected Apache Log4j, a widely used Java logging library, and could allow remote code execution (RCE). It wasn't just about patching one library. Organizations had to find Log4j buried inside applications, dependencies, and products they didn't even realize contained it. Then people started to talk about SBOMs. And Docker added the docker sbom command. The command has since been removed and replaced with: docker scout sbom --format list <image> Now, consider October 2026. !CVE publication trends According to CRACI's CVE publication statistics, the numbers were:[^1] | Period | Published CVEs | High + Critical CVEs | | ---------------- | -------------: | -------------------: | | Entire 2021 | 19,862 | 4,324 | | October 2025 | 4,235 | 1,706 | | October 2026 | 17,013 | 8,059 | Of October's findings, 6,536 were High and 1,523 were Critical, for a combined 8,059. That's nearly twice as many High and Critical CVEs as in all of 2021, using CRACI's recorded severity scores. Many older records lack scores, so this isn't a like-for-like measure of risk. Every time a CVE is published, the defenders are notified as well as the attackers. Then it's a race. * ⏱️ Time to Patch: A Race Against Time How long does it take to patch a vulnerability? A patch has to travel a long way before it protects production: identify the affected application, update its dependencies, rebuild, test, deploy, and verify. For example, with PHP2Shell, first update the PHP base image:[^2] FROM dhi.io/php:8.4.27-fpm Then rebuild and redeploy (assuming you use Compose): docker compose build --pull --no-cache docker compose up -d --force-recreate Then verify: docker compose exec <service> php -v # or docker scout sbom <image> --format list | grep -i php Each step takes time. An attacker only needs a reachable weakness. Time to patch measures the defender's remediation work. Time to exploit measures when attackers start exploiting a vulnerability relative to patch availability. Google's M-Trends 2026 research shows how far that window has shifted: | Year | Mean time to exploit | | ---- | ----------------------: | | 2018 | 63 days | | 2024 | −1 day | | 2025 | −7 days (estimated) | A negative value means exploitation began, on average, before a patch was released, for the vulnerabilities studied.[^3] Even immediate patching can leave us behind. Prepare to contain an attacker as well as patch the bug. * 🐚 PHP2Shell and Node2Shell: Two Shells in One Day The 21st of October was a particularly interesting Wednesday for software engineers. We had RCE risks in two different ecosystems. These RCE exploits were not the first and will not be the last. And, as the trend suggests, we will see more of these nice CVEs in the near future. And, as the time to exploit suggests, we are already vulnerable before there is a published patch. So, what to do? We can try and reduce the blast radius with minimal images, rootless execution, and fewer tools. No shell doesn't mean no RCE; the runtime still needs its patch. If you still have not patched your PHP, check this walkthrough: how-to-fix-php2shell For Node2Shell, update the Node.js runtime too. On the 24.x branch, the fix released on the 21st of October was 24.22.1: FROM node:24.22.1 Rebuild the image with no cache, redeploy, and check the version:[^4] docker compose exec <service> node --version We will get back to reducing the blast radius. * ☠️ LiteLLM: When the Release Pipeline Is the Attacker On the 21st of October, LiteLLM's release pipeline shipped credential-stealing malware in litellm==1.107.0 and official images tagged v1.107.0, latest, main-latest, and main-stable.[^5] Remember Issue 6's malicious package with valid provenance? Here we go again. If affected code ran: isolate, investigate, revoke or rotate accessible credentials, and rebuild from verified clean inputs. Work from a clean environment: starting Python or pip in the affected one could retrigger the malware. Check digests and exposure windows in the full incident report; cached artifacts remain dangerous after registry removal.[^6] * 🐳 Docker News - Sandboxes, v0.48–v0.50.1: Kits v3 gained capability groups, bundled skills, Git identity and SSH signing; later releases added persistent kit volumes, configurable host mounts, cloud inspection, and tighter host/credential protections.[^7] v0.50.1 fixes sandbox startup.[^8] Even the sandbox needs maintenance. - Desktop security: 4.97.0 fixes CVE-2026-99999, where malformed IPv4 checksum metadata could corrupt the VM network stack, and CVE-2026-114409, which exposed third-party credentials in logs/diagnostics. Update and sanitize retained diagnostic copies.[^9] - eMudhra: Compromised CA keys could enable service impersonation. Docker refreshed sandbox templates, but updating sbx alone doesn't fix existing sandboxes: refresh their images or CA stores and restart applications.[^10] - DHI's busy week: Following PHP2Shell/eMudhra, Docker ran 16,567 package and image builds in 48 hours. The rebuild report explains the trust-store updates.[^11] That's a lot of coffee for a build system. * 🛡️ What Can We Actually Do? Big Picture. We cannot manually review 17,000 CVEs every month. Fortunately, we don't need to. Start with what your application actually ships and what attackers can reach. 1. Find the Actionable CVEs Docker Scout can narrow the vulnerability list to fixable High and Critical findings:[^12] docker scout cves \ --only-fixed \ --only-severity critical,high \ <image> To look specifically for vulnerabilities listed in CISA's Known Exploited Vulnerabilities catalog: docker scout cves \ --only-cisa-kev \ <image> The first view hides findings without fixes; the second highlights known exploitation. Neither is your complete risk inventory. 2. Rebuild, Don't Just Update the Dockerfile After updating your vulnerable dependencies and base image: docker build --pull --no-cache \ -t <image> . Then scan the resulting image, run your tests, deploy it, and verify the runtime in production. A patched Dockerfile sitting in Git does nothing for an old container still running in production. 3. Reduce the Damage Before the Next CVE My Security Immediate Plan (SIP) covers agent isolation, dependency cooldowns, hardened builds, attestations, and vulnerability gates. For prevention, run your coding agent in a sandbox: sbx policy init deny-all sbx policy ls sbx run --clone opencode . Sandboxing keeps the AI agent and malicious packages away from your host files, except for the ones you mounted into it. Secrets are injected into the requests without the agent having access to them. And exfiltration of the secrets can be blocked using network policies. * 🐳 Community Spotlight The Docker community has been very busy over the past month as well. I think we owe it to the awesome Mexican food: Faeka Ansari shares her first Docker Captains Summit experience in Mexico: handwritten welcome letters, community connections, and why agent permissions belong outside the agent. Come for the Caribbean sunrise, stay for the security boundaries. Check if you can spot my face in the article. Docker Captains Summit: Mexico 2026 Faeka Ansari — Community connections and agent security lessons from her first summit. Nick Janetakis takes us through Docker Captain's Summit in Mexico, with friendships, behind-the-scenes moments, and enough group photos to test a camera's horizontal scaling. Docker Captain's Summit in Mexico Nick Janetakis — Friends, behind-the-scenes moments, and a very busy camera. Back at the terminal, Ajeet Raina at Collabnix walks through What's New in Docker Sandboxes Kits v3 (v0.48.0), building a mixin with bundled skills, Git identity, and scoped SSH signing. Even the agent needs to learn that borrowing your keys doesn't mean borrowing the whole house. What's New in Docker Sandboxes Kits v3 (v0.48.0) Ajeet Raina · Collabnix — A hands-on mixin with skills, Git identity, and scoped SSH signing. And Matteo Bisi brings an OVHcloud CLI Supply Chain Compromise user playbook: check exposure, isolate, rotate credentials, and verify what you rebuild. The source was clean; the release binaries weren't. Apparently, reading the recipe doesn't tell you who poisoned the coffee. OVHcloud CLI Supply Chain Compromise: A User Playbook Matteo Bisi — Check exposure, rotate credentials, and recover from poisoned release binaries. Docker's The CVE That Did Not Exist, by Ajeet Singh Raina and Pratik Singh, follows a review bot inventing a vulnerability and recommending drastic remediation. We already have 17,000 CVEs. Please stop generating DLC. Coding Agent Horror Stories: The CVE That Did Not Exist Ajeet Singh Raina and Pratik Singh · Docker — A review bot invents a vulnerability and a dangerous response. Çiğdem Kadakoğlu explores Docker Sandboxes: Local vs Cloud, explaining where your agents run, what sbx move actually transfers, and why your secrets and network policies don't automatically follow. Well, this article is in Turkish, but we're working on an English piece on sbx cloud, and it's only fitting since she was writing on the plane. ✈️ Docker Sandboxes: Local vs Cloud Çiğdem Kadakoğlu — Where agents run and what moves between local and cloud sandboxes. In Turkish. Written something the Docker security community should read? Send it my way for DSD 9. Practical lessons, experiments, and stories welcome. Bonus points if the coffee survives. ☕ * 🎙️ Recent Work ☕ SIP for Java: Coming to JAVAPRO I teamed up with Catherine Edelveis to write SIP: Security Immediate Plan for Java, a collaborative piece that will be published in JAVAPRO. Five practical controls, from AI agents and Maven/Gradle inputs to hardened images and release checks—with a Spring Boot example. sip-for-java 🐳 Hackdockerfest in Freiburg: Worms, Python, and AI Agents On the 27th of October, Docker Freiburg and Black Forest teamed up with the Python User Group Freiburg for Hackdockerfest at JobRad. I helped organize the evening and presented the Security Immediate Plan for Python. Docker Captain Marco Franzon covered SBX and AI Agent Activity Tracking and shared his token-consumption tracking resources. Check the resources here. !A group selfie with smiling attendees seated on wooden tiers at JobRad. 🇨🇭 BaselOne: Securing Java in Asgard On the 15th of October at BaselOne, the Commandos defended Java in Asgard—here's the practical Spring Boot companion article. 🇳🇱 Coming Up: J-Fall 2026! I'll be at J-Fall in Ede, the 11th–12th of November as a room host—find the red fedora and say hello! 🎩 * Until Next Time Two shells, a poisoned release, and 17,000 CVEs. Hopefully, we won't get a third shell in November; otherwise we will have to learn how to use the three seashells! Also, remember, remember: tomorrow is the 5th of November, so harden your images before that Guy gets into your containers. * [^1]: CRACI. CVE Publication Trends. Publication-date statistics, October 2026. [^2]: NCSC-NL. PHP2Shell Operational Information. [^3]: Google Cloud. FinOps for SecOps: How to Optimize the Agentic SOC for Value. Cites M-Trends 2026 mean time-to-exploit figures; the 2025 figure is an estimate. [^4]: Node.js Project. Security releases of the 21st of October 2026. [^5]: LiteLLM. The Attack Chain Behind the v1.107.0 Release. [^6]: LiteLLM. Incident report for the 21st of October 2026. Affected artifacts, exposure windows, and remediation guidance. [^7]: Docker Docs. Docker Sandboxes Release Notes. [^8]: Docker. Sandboxes v0.50.1 Release. [^9]: Docker Docs. Docker Desktop 4.97.0 Release Notes. [^10]: Docker Docs. Docker Sandboxes Response to eMudhra CA Compromise. [^11]: Docker. PHP2Shell and eMudhra Patched. [^12]: Docker Docs. Docker Scout CVE Command Reference. <!-- devto-source: containersecurity.dev --> <!-- devto-content: 93f9e5d81eccc638ac5d253c2d1c2e322767e4bb2d1f40a086347fe59235c225 -->

php2shell、製品ベースの統計だと今日時点でまだ2割ぐらいしか完了してないのか。こりゃマズイね。 NCSC-NL/php2shell t.co

Le Nationaal Cber Security Centrum (NCSC-NL) consolident dans un dépôt Github des infos sur les mises à jour de produits embarquant PHP. (Source ANSSI). NCSC-NL/php2shell

Топ-9 GitHub за 3 дня: reylo и 3d-model-anything Обзор: топ-9 новых репозиториев GitHub за 20–23 октября 2026 — новые проекты GitHub и open source, которые быстрее всех набрали звёзды. В выпуске: типизированный импорт .sql в TypeScript, скан комнаты на iPhone в сцену Three.js и сканер уязвимости PHP. 1. colinhacks/reylo — Импорт .sql-файлов в TypeScript с типами из схемы БД, без кодогенерации. (Rust, +753 ★) 2. wesbos/3d-model-anything — iPhone-приложение и навык для агента: скан комнаты → сцена Three.js. (Swift, +606 ★) 3. assetnote/php2shell-scanner — Консольный сканер уязвимостей CVE-2026-109618 и CVE-2026-109619 в PHP. (Python, +343 ★) 4. zita-ch/supermimic_vibed — Неофициальное воспроизведение SuperMimic: управление гуманоидом G1 в Isaac Lab 3. (Python, +327 ★) 5. rossark0/rossark-motion-skill — Навык для Claude Code: оживляет нарисованное — персонажей, сцены, иконки. (Swift, +322 ★) 6. raymondchins/Bridgeplay — Windows-игры из Steam на Mac с Apple Silicon, установка в один клик. (Scala, +272 ★) 7. NCSC-NL/php2shell — Сводка NCSC-NL по уязвимостям PHP CVE-2026-109618 и CVE-2026-109619. (Python, +236 ★) 8. helloianneo/ian-xhs-carousel — Навык Claude Code: статья или заметка → серия картинок 3:4 для Xiaohongshu. (HTML, +232 ★) 9. qianshuixia/shrimpreel — Шаблон сайта «одно фото → ИИ-видео по вирусному шаблону» на Cloudflare. (TypeScript, +219 ★) Источник: GitHub Search API, репозитории созданы с 2026-10-20, отсортированы по звёздам. Лидер: colinhacks/reylo Остальные: wesbos/3d-model-anything, assetnote/php2shell-scanner, zita-ch/supermimic_vibed, rossark0/rossark-motion-skill, raymondchins/Bridgeplay, NCSC-NL/php2shell, helloianneo/ian-xhs-carousel, qianshuixia/shrimpreel #GitHub #opensource #программирование Каждые 3 дня — 10 новых open-source проектов GitHub, быстрее всех набравших звёзды. Подписывайся, чтобы не пропустить следующий выпуск.

If anyone needs a growing list of vendors affected by php2shell. The Netherlands National Cybersecurity Center is so kind to publish their list on GitHub. You can ctrl +f the .md list on Github. github.com/NCSC-NL/php2shell/blob/main/software/c…

No, sorry. Full stop. The php vulnerabilities are real. GitHub is nonaligned, & run by geeks who know their stuff. php2shell vulnerabilities (CVE-2026-109618, CVE-2026-109619) NCSC-NL/php2shell

Testing the AWS WAF Mitigations for PHP2Shell on Both CloudFront and an ALB --- title: Testing the AWS WAF Mitigations for PHP2Shell on Both CloudFront and an ALB published: true description: 'I deployed the AWS WAF rules published for PHP2Shell (CVE-2026-109618 / 109619) on CloudFront (64 KB body inspection) and on an ALB (fixed 8 KB) with AWS CDK and measured inspection boundaries, false positives, per-layer thresholds and origin bypass.' tags: 'aws, security, cdk, php' cover_image: null organization_id: 2794 id: 4897722 date: '2026-10-22T16:10:45Z' --- Introduction On 2026-10-21 the PHP project disclosed PHP2Shell (CVE-2026-109618 / CVE-2026-109619): CVSS v4.0 9.2, unauthenticated remote code execution (PHP security advisory, CERT-EU Security Advisory 2026-018). As a stopgap until PHP can be upgraded, an AWS Security Blog post published four AWS WAF custom rules: PHP2Shell, Block-Multipart-FormData, Block-Oversize-Body and RateLimit-Posts. The AWS Security Bulletin also points to SizeRestrictions_BODY in AWSManagedRulesCommonRuleSet and to the PHP managed rule group (version 2.3, now the default), which adds protection for CVE-2026-109619. Classmethod (a Japanese company that provides AWS consulting and operations support) has already tested the AWS Security Blog rules thoroughly on an ALB, including the fact that PHP_SESSION_UPLOAD_PROGRESS placed after the first 8 KB of the body goes through. This article reproduces that test on both CloudFront and an ALB and verifies what was still open: - How far does raising CloudFront's body inspection limit (16 KB default, 64 KB max) get you? - How does the ALB's Web ACL behind CloudFront affect the result? - What changes when the origin only accepts traffic through CloudFront? - How long does the rate-based rule take to react once the threshold is crossed? 📁 Code: waf-php2shell-mitigation (part of AWS CDK Reference Architectures). > Note > AWS WAF is a mitigation, not a fix. Upgrading to PHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 or later is the only complete remediation. PHP 8.1 and older are also affected but are end-of-life, so there is no official fixed release (the PHP team published minimal source backports, and some distributions and LTS vendors provide backported packages). Move to a supported version. TL;DR The AWS Security Blog rules are a stopgap until PHP is upgraded; the AWS Security Blog post itself states that the real fix is upgrading PHP. As a stopgap, the rules behaved as specified on both CloudFront and the ALB. AWS WAF, however, inspects a request body only from the start up to a size limit: 8 KB on an ALB (fixed), 16 KB by default on CloudFront, up to 64 KB (AWS WAF documentation). On the ALB, a string ending at byte 8,192 was blocked; shifting it by one byte let it through. The Block-Oversize-Body rule from the same post (a size limit meant for CVE-2026-109618), when set to BLOCK, also stops requests whose bodies go past that limit. How to configure that rule depends on your setup: - If you use CloudFront, raise the inspection limit to 64 KB and block bodies larger than 64 KB with Block-Oversize-Body. The whole body is then inspected, and legitimate requests up to 64 KB still pass. - With CloudFront + ALB + WAF, set the ALB's "block bodies over 8 KB" rule to COUNT and let the ALB accept traffic from CloudFront only. Left in BLOCK, the ALB stops legitimate requests that CloudFront already allowed. If the ALB Web ACL includes AWSManagedRulesCommonRuleSet, override its SizeRestrictions_BODY (blocks bodies over 8 KB) to COUNT for the same reason. - If you expose only an ALB, blocking bodies over 8 KB is the baseline. According to the AWS Security Blog post, both CVEs sit on the multipart/form-data processing path, so an app that takes no file uploads and only accepts JSON over 8 KB could block Block-Multipart-FormData instead of using the size limit (not verified in this article). An app that accepts file uploads over 8 KB cannot be fully protected by WAF, so prioritize the PHP upgrade. If your app changes session.name or session.upload_progress.name from the defaults, rewrite the rule strings to the actual names. Matching is case-sensitive, so this also applies when only the letter case differs. Architecture !Architecture Client ─▶ CloudFront + Web ACL (us-east-1, 64 KB body inspection) ─▶ ALB + Web ACL (ap-northeast-1, fixed 8 KB) ─▶ Lambda container (nginx + PHP-FPM 8.4.27 + Lambda Web Adapter) Client ─────────▶ ALB direct (comparison only, allow-listed IP) A WAF decision does not depend on the PHP version behind it, so the origin runs a patched PHP 8.4.27 as a Lambda container image. On the PHP side, it applies these server-side mitigations from the AWS Security Blog post: ; php.ini session.upload_progress.enabled = 0 memory_limit = -1 ; the real ceiling is the Lambda memory size post_max_size = 8M ; PHP-FPM pool pm = static pm.max_children = 1 pm.max_requests = 1 ; replace the worker after every request Telling which WAF and which rule acted, from HTTP headers With WAF on both CloudFront and the ALB, a bare 403 does not tell you which layer answered. Every rule therefore names itself: const ruleAction = (ruleName: string, action: RuleAction): wafv2.CfnWebACL.RuleActionProperty => action === 'BLOCK' ? { block: { customResponse: { responseCode: 403, responseHeaders: [{ name: 'x-php2shell-blocked-by', value: `${label}:${ruleName}` }] } } } : { count: { customRequestHandling: { insertHeaders: [{ name: `php2shell-${label}-${ruleName.toLowerCase()}`, value: 'counted' }] } } }; BLOCK returns x-php2shell-blocked-by: cloudfront:PHP2Shell; COUNT inserts x-amzn-waf-php2shell-alb-oversize: counted into the origin request, and the PHP app echoes it back. Headers inserted by the CloudFront Web ACL travel through the ALB to the origin, and the BLOCK response header keeps its own name (no x-amzn-waf- prefix). Note that clients can also send headers starting with x-amzn-waf-. If your application changes its behavior based on these headers in production, add a rule that blocks x-amzn-waf- headers arriving from outside, as the AWS WAF documentation describes. Result 1: rule conditions (reproducing the ALB test on both layers) | Request | via CloudFront | ALB direct | |---------|----------------|------------| | POST, cookie PHPSESSID + PHP_SESSION_UPLOAD_PROGRESS in body | 403 | 403 | | POST, both strings in body | 403 | 403 | | POST, PROGRESS only / cookie only | 200 | 200 | | PUT, both strings in body | 200 | 200 | | multipart PROGRESS field + cookie | 403 | 403 | | lowercase cookie key phpsessid | 200 | 200 | | lowercase php_session_upload_progress in body | 200 | 200 | | JSON or text/plain containing both strings (false positive) | 403 | 403 | The rule uses TextTransformation: NONE, so it only matches PHP's default names. If your app renames the session cookie or the upload progress field, change the rule strings too. Result 2: string position vs inspection limit Cookie PHPSESSID, with PHP_SESSION_UPLOAD_PROGRESS ending at byte N (oversize rule in COUNT): | N | ALB direct | CloudFront KB_16 | CloudFront KB_64 | |---|-----------|--------------------|--------------------| | 8,192 | 403 | 403 | 403 | | 8,193 | 200 | 403 | 403 | | 16,385 | 200 | 200 | 403 | | 65,536 | 200 | 200 | 403 | | 65,537 | 200 | 200 | 200 | WAF logs agree: requestBodySizeInspectedByWAF is 8192 on the ALB and 65536 on CloudFront KB_64, and larger bodies carry oversizeFields: ["REQUEST_BODY"]. Result 3: oversize rule in BLOCK (8,192 bytes) Everything from 8,193 bytes is blocked regardless of position. So is a legitimate ~19 KB JSON POST with no rule string at all. An API that accepts JSON over 8 KB cannot use this as is. Result 4: with WAF on both CloudFront and the ALB, the ALB blocks legitimate requests CloudFront can inspect the first 64 KB of the body, so I raised CloudFront's Block-Oversize-Body threshold to 65,536 bytes. CloudFront then passes legitimate requests up to 64 KB and blocks bodies too large to inspect in full. The ALB's Web ACL is where this goes wrong. Putting CloudFront in front of an ALB that already had WAF, or adding the same rules to both layers as defense in depth, is common. Even when the origin only accepts CloudFront, requests through CloudFront are evaluated again by the ALB Web ACL. | ALB Block-Oversize-Body (8,192 bytes) | Legit 19 KB JSON | PROGRESS at byte 65,537 | |-----------------------------------------|------------------|-------------------------| | BLOCK | 403 alb:Oversize | 403 cloudfront:Oversize | | COUNT | 200 | 403 cloudfront:Oversize | (Both through CloudFront; CloudFront blocks above 65,536 bytes.) At first I thought raising CloudFront's limit would be enough. With the ALB rule in BLOCK, though, the ALB's 8 KB rule stops the 19 KB JSON that CloudFront inspected and allowed. To benefit from CloudFront's setting, the ALB size rule has to be COUNT. Result 5: restricting ALB access to CloudFront COUNT on the ALB opens a different problem: a request sent straight to the ALB skips CloudFront, and the ALB inspects only 8 KB. A request with PROGRESS ending at byte 8,193, sent directly, was 403 with the ALB rule in BLOCK and 200 with it in COUNT. If you follow the AWS best practice and restrict the ALB to traffic from CloudFront, the Result 4 fix (COUNT on the ALB) is not a problem. Setting it to COUNT while the ALB is still directly reachable, however, is dangerous. As the documentation describes, I combined a security group and a custom header. The security group admits only the CloudFront origin-facing managed prefix list (com.amazonaws.global.cloudfront.origin-facing). That list is shared by every CloudFront distribution, so on its own it also lets other distributions in. I therefore set an X-Origin-Verify origin custom header on CloudFront, and the ALB listener rule forwards only requests whose header value matches (default action 403). const cloudFrontPrefixList = ec2.PrefixList.fromLookup(this, 'CloudFrontOriginFacing', { prefixListName: 'com.amazonaws.global.cloudfront.origin-facing', }); albSecurityGroup.addIngressRule(ec2.Peer.prefixList(cloudFrontPrefixList.prefixListId), ec2.Port.tcp(80)); listener.addAction('FromCloudFront', { priority: 10, conditions: [elbv2.ListenerCondition.httpHeader('X-Origin-Verify', [originVerifyValue])], action: elbv2.ListenerAction.forward([targetGroup]), }); This approach relies on keeping the header name and value secret. For this verification CloudFront talks to the ALB over HTTP (port 80); the documentation recommends HTTPS and rotating the header regularly. Another option is to keep the ALB off the internet and connect an internal ALB to CloudFront as a VPC origin. For Results 1–4, I had added an exception that let my own IP address reach the ALB directly, for comparison. After removing that exception and redeploying, a direct curl to the ALB got no response at all, not even a 403, and timed out: the security group drops the traffic before it reaches the ALB. Through CloudFront, requests still returned 200, and requests with the PHP2Shell pattern were still blocked with 403. Other observations | Check | Result | |-------|--------| | RateLimit-Posts (100 per 60 s, COUNT) at ~2.4 req/s | first match on request #138, 57 s in | | 1,100,000-byte body, ALB → Lambda | 413 (1 MB Lambda target limit), not in the ALB WAF log | | WCU | CloudFront 50 / ALB 45 (AWSManagedRulesCommonRuleSet alone is 700) | | pm.max_requests=1 | FPM worker PID changes on every request | | Lambda container cold start | 3.2 s first, 0.2 s after; ~48 MB memory | The rate-based rule first matched on request #138 (in COUNT; in BLOCK, blocking would start there). The threshold is 100 per 60 seconds, so about 16 seconds and 38 requests went through after it was crossed. If you set the threshold to exactly the number you can tolerate, requests that arrive while detection lags go through on top of it. The overshoot is roughly "request rate × lag": here, 2.4 req/s × ~16 s ≈ 38. Faster attacks overshoot more, so set the threshold below what you can tolerate. The AWS WAF documentation also says rate-based rules are not meant for precise rate limiting, and that the detection lag is usually under 30 seconds but can stretch to minutes. Cost About $40/month if left running (ALB ~$18, two Web ACLs $10, eight rules $8, plus requests). With KB_64, only requests whose bodies exceed 16 KB pay an extra $0.30 per million per additional 16 KB. The verification itself, deploy to destroy within a few hours, cost under $1. Wrap-up The AWS Security Blog rules behave as specified on both CloudFront and the ALB, but only for strings within the inspected part of the body. Even with CloudFront's limit raised to 64 KB, an 8 KB rule left on the ALB blocks legitimate requests, and a directly reachable ALB lets requests through with everything past 8 KB uninspected. Configure WAF for the whole request path rather than for CloudFront and the ALB separately. That said, every measure verified here is a mitigation. Upgrade PHP first. References - Using AWS WAF to apply mitigations for PHP2Shell RCE vulnerabilities (AWS Security Blog) - PHP security advisory (2026-10-21) - PHP security advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618) - PHP security advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619) - CERT-EU Security Advisory 2026-018: Critical Vulnerabilities in PHP - NCSC-NL php2shell operational information - Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot - AWS Security Bulletin 2026-143-AWS - Classmethod: Trying the AWS WAF rules from the AWS Security Bulletin (2026-143-AWS) and the AWS Security Blog to mitigate PHP2Shell - Restrict access to Application Load Balancers (CloudFront Developer Guide) - AWS WAF: Considerations for managing body inspection - AWS WAF: Rate-based rule caveats - AWS WAF pricing

A common question regarding #php2shell (CVE-2026-109618 & CVE-2026-109619) in #php is; "what's vulnerable?" The awesome people at NCSC-NL have provided the answer. If it's on this list, it's vulnerable. (It's a very long list in alphabetical order) NCSC-NL/php2shell