php2shell-scanner

PHP2Shell: The PHP Vulnerability Everyone Is Talking About Right Now (And How to Fix It) If you have been seeing "PHP hacked", "PHP vulnerability" or "PHP2Shell" everywhere lately — in tech news, on Twitter, or from developer friends — you are not imagining it. This is real. It is serious. And most PHP website owners have no idea they are vulnerable right now. Let me break it down simply. No jargon. No panic. Just fix it. --- 🤔 Who Is This Blog For? Everyone. Seriously. - Website owners - Web developers (PHP, Laravel, WordPress, CodeIgniter) - Beginners who just heard about this and are confused - Anyone running a PHP website — even on shared hosting --- 🐚 What Is PHP2Shell? PHP2Shell is the name given to two critical vulnerabilities: - CVE-2026-109618 - CVE-2026-109619 Both are rated CVSS 9.2 out of 10 — that is near-maximum severity. In plain English: > An attacker with no login, no account, and no prior access to your website can run any command they want on your server. Delete files. Steal data. Install malware. All without you knowing. Affected PHP versions: | Branch | Vulnerable Below | |--------|-----------------| | PHP 8.2 | 8.2.35 | | PHP 8.3 | 8.3.36 | | PHP 8.4 | 8.4.27 | | PHP 8.5 | 8.5.12 | | PHP 8.1 and older | ❌ No official patch ever | > Real attacks are already happening. Security researchers found PHP2Shell was used to compromise 24 firewalls — including US government-affiliated targets — in under 15 minutes. --- 🔍 Step 1: Check If Your Website Is Vulnerable A security company called Assetnote released a free, safe scanner. > ✅ It does NOT exploit anything. It just sends a large request and checks if your server crashes — which signals vulnerability. --- Install dependencies: pip install h11 tqdm Download the scanner: Get it from the official GitHub: 👉 assetnote/php2shell-scanner > ⚠️ Important: Only run the scanner against websites you own or have permission to test. Running it against others' websites without permission is illegal. Run it against your website: python scanner.py -u https://yourwebsite.com --verbose What the result means: | Result | Meaning | |--------|---------| | [VULNERABLE] | 🔴 Patch immediately | | [NOT VULNERABLE] | 🟢 You are safe | | [FIXED] | 🟢 Already patched | | [INCONCLUSIVE] | 🟡 Check PHP version manually | --- 🖥️ Step 2: Check Your PHP Version Manually php -v If you see anything below the versions in the table above — you are vulnerable. For example this is vulnerable: PHP 8.2.12 (cli) (built: Oct 24 2023) This is safe: PHP 8.2.35 (cli) (built: Oct 26 2026) --- 🔧 Step 3: Fix It On XAMPP (Windows): 1. Go to 👉 windows.php.net 2. Download PHP 8.2.35 Thread Safe (VS16 x64) 3. Extract it into C:\xampp\php\ — replace all old files 4. Copy your old php.ini back from your backup 5. Restart Apache from XAMPP Control Panel On Ubuntu / Debian Server: sudo apt update && sudo apt install php8.2 php -v On cPanel Hosting: cPanel → Software → Select PHP Version → Choose 8.2.35 or higher On Shared Hosting: Contact your hosting provider and simply ask: > "Can you update my PHP to the latest stable version? There is a critical security vulnerability in older versions." Most good hosts like SiteGround, Kinsta, and Cloudways have already patched this automatically. --- ✅ Step 4: Verify the Fix Run the scanner again: python scanner.py -u https://yourwebsite.com --verbose You should now see: [NOT VULNERABLE] https://yourwebsite.com - Verdict: FIXED That means you are safe. 🎉 --- 🧠 Understanding What Actually Happened (Techy Part) For those who want to know the actual mechanism: PHP has a feature called session upload progress that tracks file uploads. Under specific memory conditions, PHP runs out of memory (OOM) mid-request before resetting its internal state. A follow-up request from an attacker in the same server worker process can then read that stale memory — leaking internal memory addresses. With those addresses, the attacker builds a second crafted request that writes a forged object into PHP's memory, hijacks the execution flow through a technique called a ROP chain, and lands inside zif_system — PHP's internal function that runs shell commands. The result: remote code execution with no login required. That is why the patch says "Avoid state corruption via bailout" — it resets request state properly before memory is exhausted. --- 💬 Now Go Tell Your Friends Next time someone says "PHP is vulnerable" — you can say: > "I already checked mine and fixed it. Now it's your turn." If your website is simple, this guide is enough to do it yourself. If your setup is complex — custom server, Docker, multiple PHP versions, or you are just not sure — drop a comment below and I will help you out. --- Found this helpful? Share it with a PHP developer friend who might not know about this yet. You might save their website today.

PHP2Shell: patch PHP now, then check --- title: "PHP2Shell: patch PHP now, then check" published: true tags: php, security, cybersecurity, webdev canonical_url: dunime.com --- Originally published on the Dunime blog. Two critical PHP flaws let an attacker run code on a web server without logging in. What changed on 21 October, which sites it touches, and what to do today. > If a website runs on PHP, it is in scope. On 21 October 2026 the PHP project shipped fixes for two critical flaws that can let an unauthenticated attacker run code on the web server, and said that updating is the only complete fix. What changed On 20 October the PHP security team gave advance notice of a release fixing two critical vulnerabilities, both rated CVSS v4.0 9.2. On 21 October it published PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 with a security advisory headed "update now". The pair is widely reported under the name PHP2Shell. - CVE-2026-109618, code execution via out-of-memory corruption: out-of-memory handling can interrupt PHP while internal request data is only partly set up, and request cleanup may then treat that invalid data as valid. - CVE-2026-109619, code execution via stale global state: internal state belonging to one request can survive after its memory has been freed, and a later request handled by the same worker may use it. In PHP's words, there are no complete mitigations and updating is the only safe choice. On 23 October PHP added an informational note: keep session.upload_progress.enabled=0 until the next regular bugfix release, to close an unlikely related vector it will document as CVE-2026-115560. On exploitation: BleepingComputer reported on 21 October that Cloudflare's CTO said the company was already observing early attacks against both flaws before the patches shipped. The UK NCSC alert of the same day asks organisations to update immediately; it does not itself state that the flaws are being exploited. Who it applies to PHP's advisory puts every PHP installation that serves web requests at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It rates the risk highest for mod_php, where a demonstrated exploit lets an unauthenticated request trigger the attack before any application code runs. - CMS and web apps: WordPress, Drupal, Joomla, Magento, phpMyAdmin and Nextcloud all run on PHP. Help Net Security, reporting Searchlight Cyber's research, names all six as software on which exploitation has been confirmed. A fully updated plugin or theme does not help if the PHP underneath is unpatched. - Shared hosting and cPanel: on shared hosting the provider usually owns the PHP build. The PHP version picker in the panel shows which branch a site uses, but whether that build carries the 21 October fix is the host's answer to give. - Old PHP: PHP 8.1 and older no longer get updates from the PHP project. Some Linux distributions and long-term-support vendors backport fixes, so ask the vendor. PHP also published minimal source backports for 7.4, 8.0 and 8.1 for people who build from source. PHP 8.2 itself reaches end of life on 31 December 2026. - Agencies and IT teams: anyone who runs sites for others owns an inventory problem today. The NCSC asks for discovery of every PHP installation, internet-facing first, and warns not to limit the search to outdated PHP versions. > Patching the plugin is not patching PHP. What to do today - 1. Find every PHP install. Start with internet-facing sites, then internal tools. Include appliances and products that bundle PHP, and apply their vendors' updates as they arrive. - 2. Check the version. On a server, php -v shows the command-line build. The web server can run a different build, so also check the hosting panel or your package manager. Distribution packages may carry the fix under their own version numbering, so confirm with the vendor's security notice rather than the number alone. - 3. Update. Move to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or the patched package from your distribution or LTS vendor, internet-facing systems first. Restart PHP-FPM or Apache so every worker runs the new build. - 4. If you cannot update yet, reduce exposure. PHP's interim measures narrow specific attack paths but do not make a server safe. They are listed in the next section. - 5. If even that is not possible: the NCSC says to consider taking the system offline until it is fully mitigated, and, if it cannot be updated or disabled straight away, to check it for signs of compromise and backdoors first. - 6. Check the logs. Look for new or changed PHP files in upload and cache folders, unexpected admin accounts, and bursts of large multipart POST requests, memory-exhaustion errors or crashed PHP-FPM workers. A server that was exposed before patching should be checked, not just patched. - 7. Know who to call. Your hosting provider for the PHP build, your application vendor for bundled PHP, and an incident response team if you find signs of compromise. In India, cyber incidents are reported to CERT-In. Interim mitigations PHP published Only for systems that cannot be updated immediately. PHP is explicit that these reduce exposure to specific attack paths and do not make an installation safe. - For CVE-2026-109618: set memory_limit=-1 in a way applications cannot override, such as php_admin_value in the FPM pool or Apache configuration, and check nothing sets a finite limit back. Set a low post_max_size: 8M for applications without file uploads, 32M if uploads are needed, with upload_max_filesize below it. Use a container or cgroup limit, ideally one that kills only the affected worker; PHP warns not to substitute RLIMIT_AS or RLIMIT_DATA. - For CVE-2026-109619: set session.upload_progress.enabled=0 in php.ini, the FPM pool or server configuration (not ini_set() or .user.ini) and restart every worker. On PHP 8.5, also set fatal_error_backtraces=0 and restart. Remove invalid or deprecated per-request settings that emit diagnostics, and fix fatal errors and timeouts an attacker can reach. - What does not help: hiding errors with error_reporting, display_errors or the @ operator. A free scanner, and its catch On 22 October Searchlight Cyber released php2shell-scanner, a free, open-source command-line tool (github.com/assetnote/php2shell-scanner) that tests whether a host shows the vulnerable behaviour rather than only reading a version number. It first tries to produce a PHP memory-exhaustion error, then looks for a PHP-FPM worker dying mid-request, and only as a last resort reads the advertised PHP version. - The catch: detection deliberately pushes PHP into an out-of-memory condition. The researchers call this "fundamentally risky in nature" and ask for care and caution. Each tested path can receive a small control request and three probes totalling about 29 MiB. - False positives: the README warns that a patched build can return the same empty HTTP 500 when a probe exceeds a low memory_limit, so check any "vulnerable" result against the installed version and vendor backports. - Run it only on systems you own or are authorised in writing to test, and in a maintenance window. It is a check after patching, not a reason to delay the patch. Questions people ask What is PHP2Shell? The name widely used for CVE-2026-109618 and CVE-2026-109619, two critical PHP vulnerabilities fixed on 21 October 2026 that can allow unauthenticated remote code execution on web servers running PHP, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. Which PHP versions fix PHP2Shell? PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older no longer receive updates from the PHP project; some Linux distributions and LTS vendors provide backported fixes, and PHP published minimal source backports for 7.4, 8.0 and 8.1. My WordPress site is on shared hosting. What should I do? Check the PHP version in your hosting panel and ask your host whether their PHP build includes the 21 October 2026 fixes. Updating WordPress, plugins and themes does not fix PHP itself. If the host cannot confirm, ask when it will, and follow the NCSC advice for systems that cannot be patched. Sources - PHP: Security advisory, critical remote code execution vulnerabilities, update now (21 Oct 2026), and 20 and 23 Oct notices - PHP: PHP 8.4.27 release announcement - NCSC (UK): Critical security issue affecting PHP (21 Oct 2026) - Searchlight Cyber: High fidelity detection mechanism for php2shell (22 Oct 2026) - php2shell-scanner on GitHub (README) - BleepingComputer, 21 Oct 2026: PHP ships emergency patches for critical PHP2Shell flaws - Help Net Security, 22 Oct 2026: PHP2Shell scanner tool --- Dunime maps live threats like this one to the specific checks and defences that answer them: dunime.com. Not sure what's exposed? Dunime's VAPT checks whether unpatched services like this are reachable and exploitable across your estate. Published by Dunime Technologies — custom software, automation and cybersecurity, Delhi NCR, India.

Detect the newest PHP remote crash bugs instantly ⚡ ⭐ GitHub Repository: assetnote/php2shell-scanner In this video, we explore php2shell-scanner, an open-source project that a specialized Python scanner that detects critical PHP memory-exhaustion vulnerabilities using deeply nested array payloads.. #github #coding #opensource #programming #developer

AI agent skills for PHP2Shell: what each one checks PHP2Shell (CVE-2026-109618 and CVE-2026-109619) is a pair of flaws in PHP itself. The PHP project fixed them on 21 October 2026 in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12 (php.net advisory). Within two days, several teams published skills for coding and operations agents (Claude Code, Codex, Devin and others) that look for affected PHP and help update it. We read the skill files of the ones below. This post lists what each one inspects, how it decides whether a build has the fix, and whether it waits for your approval before it changes anything. Disclosure: we run php2shell.fyi, a passive checker for PHP2Shell. None of the tools below is ours. The question that matters most Some Linux distributions ship the fix under the old version number. Ubuntu 24.04 has the fix in php8.3 8.3.6-0ubuntu0.24.04.13 (USN-8948-1). RHEL 9 has it in php-8.0.30-8.el9_8.1 (RHSA-2026:87151). Chainguard has it in 8.4.26-r4. A tool that compares only the upstream number (8.3.6 is lower than 8.3.36) reports these fixed servers as vulnerable. An agent that trusts that answer may try to "fix" a server that is already fixed. So the first column we checked is: does the tool compare the full package version? The skills | Skill | Publisher | What it inspects | Full package version? | Changes | |---|---|---|---|---| | phpcheck-server | OpenAI | The PHP binary or Apache module that serves the site, its package, the OS, containers | Yes | Check only | | phpcheck-url | OpenAI | The Server and X-Powered-By headers of one URL | No, and it says so | Check only | | fix-php-vuln | Cognition | Repositories: Dockerfiles, CI, Helm, Terraform, Ansible, Chef, Puppet | Yes | Only after you pick the repos; then one pull request per repo | | php2shell | Chainguard | Chainguard and Wolfi images, SBOMs, Kubernetes workloads | Yes (apk revisions) | Each change needs approval | | php2shell-response | Iurii Rogulia (community) | Hosts, images, hosting accounts, repositories | Yes | Read-only unless you say otherwise | What the skill files say, in their own words: - OpenAI phpcheck-server: "Compare the full package revision against vendor guidance covering both CVEs. An older upstream version alone does not prove vulnerability." It also asks whether the web workers restarted after the update, and says: "Do not run exploit probes." - OpenAI phpcheck-url: "HTTP headers cannot tell whether the version contains a backported fix." Use it for a first look, not for a verdict. - Cognition fix-php-vuln: "Never compare php -v with upstream numbers to decide this." Discovery ends with: "Stop. Show the table and ask which repos to patch." - Chainguard php2shell: "Every change needs the user's explicit approval first". It also warns: "Never compare version strings as text (-r10 is newer than -r4)". - php2shell-response: "A distribution package may carry the fix under an older version number: check the vendor changelog or advisory, never compare version strings alone." Its mode: "Read-only unless the user says otherwise." Tools that compare only the upstream number These are useful, but read their "vulnerable" answer as a question, not a verdict, on Ubuntu, RHEL and Chainguard: - The ProjectDiscovery Nuclei template for CVE-2026-109618. Its version fallback marks a patch number below the fixed one as vulnerable, so 8.3.6-0ubuntu0.24.04.13 counts as vulnerable. It also marks every version below 8.2 as end of life. - The Assetnote scanner. When it sees no crash signal, it falls back to the X-Powered-By number with the same comparison. - Some community skills compare versions with sort -V on the upstream number only. Before you let an agent change a server - Give it read access first, and ask for a table: runtime, path, version, package, status. - Check that it reads the PHP that serves the site (PHP-FPM, the Apache module, LiteSpeed), not only php -v on the command line. - Ask it to show the restart step. Old PHP processes keep the old code until they stop. ps -eo pid,lstart,cmd | grep -i '[p]hp' shows when each one started. - Do not let it fetch or run public proof-of-concept code. Most public PHP2Shell "PoC" repositories are attack tools, and their code is not reviewed. We keep a read-first prompt, our own SKILL.md and this comparison up to date on php2shell.fyi. The fixed releases, the distribution builds and the mitigations are on php2shell.fyi, with a source for each fact.

#PHP2Shell : Un outil cli de détection CVE-2026-109618 et CVE-2026-109619 assetnote/php2shell-scanner

Топ-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, быстрее всех набравших звёзды. Подписывайся, чтобы не пропустить следующий выпуск.

You can use this scanner to check for PHP-to-shell vulnerabilities. - assetnote/php2shell-scanner Use it only on systems you own or have permission to test. t.co

"High Fidelity Detection Mechanism for #php2shell (CVE-2026-109618 and CVE-2026-109619)" by @SLCyberSec Blog slcyber.io Scanner assetnote/php2shell-scanner #PHP t.co

Assetnote published php2shell scanner assetnote/php2shell-scanner

Assetnote published php2shell scanner assetnote/php2shell-scanner