Security, written for humans.

01What happened

On October 21, 2026, PHP released fixes for two vulnerabilities in its request-handling core, nicknamed php2shell:

• CVE-2026-109618: when PHP runs out of memory while reading a request, it can leave internal data half-built, and the clean-up code then treats it as valid. Crafted multipart requests can trigger this even when they look like they respect your size limits.
• CVE-2026-109619: internal state from one request can survive after its memory is freed, so a later request handled by the same worker can reuse it.

Both can lead to remote code execution without authentication, with the privileges of your web server's PHP user. Exploitation attempts were seen before disclosure, and on October 26 both CVEs were added to the US government's catalog of known exploited vulnerabilities.

02Am I affected?

Almost certainly, if you run PHP on the web and haven't updated since October 21. Every way of serving PHP is affected: Apache with mod_php, PHP-FPM, php-cgi and LiteSpeed. Apache with mod_php is considered the highest-risk setup.

Check the version your website actually runs. It's often different from the one you get with php -v on the command line. Put this in a temporary file, open it in your browser, then delete the file immediately:

<?php echo PHP_VERSION, ' · ', PHP_SAPI;

03Patch, then restart

Updating the package is not enough on its own: running PHP processes keep the old, vulnerable code in memory until they restart. On a typical Debian/Ubuntu server the sequence looks like this (adjust the version and service names to yours):

# 1. Update PHP packages
sudo apt update && sudo apt upgrade

# 2. Restart PHP-FPM (if you use it)
sudo systemctl restart php8.3-fpm

# 3. Restart Apache (always, if you use mod_php)
sudo systemctl restart apache2

Then repeat the version check from step 2. On shared hosting, you can't do this yourself: choose the newest PHP version in your control panel, and ask your host to confirm they've patched and restarted PHP.

04Can't patch yet? Temporary mitigations

These reduce your exposure while you schedule the update. They don't fix the flaws, so patching is still required.

• Turn off session upload progress: session.upload_progress.enabled = 0. This closes the session-based attack path. It also covers a related flaw, CVE-2026-115560, which the October 21 releases don't fix.
• Take memory exhaustion off the table: set memory_limit = -1 at the server level so scripts can't lower it. This is a trade-off: a runaway script can now use more memory, so treat it as temporary.
• On PHP 8.5: also set fatal_error_backtraces = 0.
• Restart all PHP workers after changing any of these.

session.upload_progress.enabled = 0
memory_limit = -1
; PHP 8.5 only:
fatal_error_backtraces = 0

Shrink what attackers can send

The memory bug is reached through large or complex form uploads. Keep request sizes realistic: post_max_size = 8M if your site doesn't take uploads (around 32M if it does), with upload_max_filesize below it. If your site never accepts file uploads, you can refuse multipart requests at the web server, before they ever reach PHP:

if ($content_type ~* "multipart/form-data") { return 415; }

<If "%{CONTENT_TYPE} =~ m#multipart/form-data#i">
    Require all denied
</If>

Test your contact forms and login pages afterwards. Only do this where nothing on the site needs uploads.

05Use the layer in front of your server

If your site sits behind an edge network or web application firewall run by your hosting or DNS provider, check whether it has published rules for php2shell and make sure they're switched on. Then make sure attackers can't simply go around it: your server should only accept web traffic from that provider, not from the whole internet. Edge rules are a stopgap, not a substitute for patching.

If you can't patch or mitigate quickly, the official advice is blunt: consider taking the site offline until you can.

06Check whether you were already hit

Attacks started before the patch existed, so patching now doesn't prove nobody got in earlier. Look for:

• PHP files changed recently that you didn't change, especially in upload folders:

find /var/www -type f -name '*.php' -newermt 2026-10-15 -ls

• Unexpected processes running as your web user (www-data, apache, nginx) and outbound connections you can't explain.
• New cron jobs, SSH keys or admin accounts on the server or inside your CMS.
• PHP worker crashes (segmentation faults, out-of-memory errors) in your logs since mid-October. Missing log entries don't prove you're safe.

Finally, remember PHP that hides inside other things: Docker images (rebuild them, since restarting a container keeps the old image), appliances, control panels and bundled apps. Check each vendor's updates.

07Where SmartKiller fits, honestly

We want to be clear about this, because the wrong expectation is dangerous: SmartKiller cannot block php2shell, and neither can any firewall written in PHP. SmartKiller runs as the first PHP code on each page, but this attack happens earlier, while PHP itself is still reading the request. By the time any PHP code runs, the vulnerable step has already happened.

What SmartKiller keeps doing is everything it was built for: stopping floods, scanners, bad bots and attack patterns at the application level. It catches the noisy reconnaissance that usually comes before an attack (bursts of 404s, known hacking tools) and gives you a record of who's probing your site in the Security Center. Use it alongside a patched PHP, not instead of one.

Official references

• Canadian Centre for Cyber Security — AL26-026
• UK NCSC — Critical security issue affecting PHP
• FBI IC3 — Public service announcement

Why hardening matters

php2shell lets an attacker run code as your PHP user. What they can do next depends on what that user is allowed to do. A hardened server turns "they took over everything" into "they got a foothold we could see and contain".

01Stay on a supported PHP version

PHP 8.1 and older don't get regular security releases any more, and php2shell is the reminder that this matters. Plan an upgrade to 8.3 or newer. SmartKiller 3.0 runs on PHP 7.4+, so it won't hold you back.

02Stop advertising your version

expose_php = Off removes the X-Powered-By: PHP/8.x.y header that tells automated scanners exactly which bugs to try.

03Never show errors to visitors

display_errors = Off and log_errors = On. Error messages leak file paths, database names and code details. Keep them in the log, where only you can read them.

04Disable shell functions you don't use

Most websites never need to run system commands. Removing these functions makes it much harder to turn a foothold into full control:

disable_functions = exec,shell_exec,system,passthru,proc_open,popen,pcntl_exec

05Fence PHP into your site's folder

open_basedir limits which folders PHP can read and write. Set it per site, for example /var/www/example.com/:/tmp/, so a compromised site can't read other sites or system files.

06Make code read-only for the web user

Your PHP files should be owned by your deploy user, not by the web server user. The web user only needs write access to the folders that truly need it (uploads, cache). That stops an attacker from quietly editing your code to plant a backdoor.

07Never execute PHP from uploads

Upload folders are where attackers drop web shells. On Apache, put this .htaccess inside the uploads folder:

<FilesMatch "\.(php|phtml|phar)$">
    Require all denied
</FilesMatch>

On nginx, add a location for the uploads path that returns 403 for .php files before your PHP handler.

08Keep request sizes realistic

post_max_size and upload_max_filesize should match what your site really needs, not the largest value someone once set "just in case". Mirror the limit at the web server too (client_max_body_size on nginx, LimitRequestBody on Apache), so oversized requests are refused before PHP sees them.

09One site, one PHP user

If you host several sites on one server, give each its own PHP-FPM pool running as its own system user. A compromise then stays inside one site instead of spreading to all of them.

And keep the application layer guarded

Server hardening and application-level protection work together. SmartKiller handles the constant background noise (scanners, floods, bad bots, attack patterns in URLs) and shows you who's probing your site, so you notice trouble early. Pair it with a patched, hardened PHP and you've covered both layers.

SmartKiller has always had one job: decide, before your application does anything, whether a request deserves to reach it. Version 2.1 did that well — but getting it running meant pasting include lines into your pages, editing a PHP function for Cloudflare, and living with a dashboard that showed you the basics. 3.0 removes every one of those chores.

01Install without touching your code

The new install flow is four steps: upload the smartkiller folder to your site root, open /smartkiller/install.php, enter your database details and create an admin, then choose Automatic protection.

Automatic mode uses PHP's auto_prepend_file so SmartKiller runs before every PHP page on your site — WordPress, Laravel, custom PHP, any CMS. The wizard picks the right place for your server:

The lines are wrapped in clearly marked BEGIN / END SmartKiller comments, and you can remove them with one click from Security Center → Integration. Already using another tool that relies on auto_prepend_file? SmartKiller detects it and chains it, so the other tool keeps working.

If your host doesn't allow Automatic mode, Manual mode is still one line. On WordPress, put it at the top of wp-config.php:

<?php require_once $_SERVER['DOCUMENT_ROOT'] . '/smartkiller/guard.php'; ?>

Running a static site? Integration → Protect .html pages (Apache/LiteSpeed) makes visitors pass through the firewall before the HTML file is served.

02A real Security Center

The old dashboard is gone. The new console at /smartkiller/dashboard.php is organised around the questions you actually ask when something feels off:

03A fairer escalation model

In 2.1, tripping a limit meant an immediate block. 3.0 separates mistakes from patterns:

Clear-cut attacks skip the warning: known hacking tools, fake search-engine bots and vulnerability scans go straight to quarantine. Every number above can be changed in Firewall Rules.

04New ways to spot attackers

• Fake search bots. Real crawlers never send attack payloads. A visitor claiming to be Googlebot that does is quarantined on the spot.
• Vulnerability scans. SmartKiller now watches your site's 404 responses. 20 not-found pages from one IP within 5 minutes looks like a scanner, not a person.
• More hacking tools. The signature list covers sqlmap, nikto, nmap, masscan, zgrab, wpscan, acunetix, nuclei, dirbuster, gobuster, ffuf, feroxbuster and more.
• Strict mode (advanced). Allow only the pages you list, with * wildcards. Great for small, fixed sites; not recommended for WordPress.

05Incident IDs and Bunker Mode

Every block page now shows an Incident ID. When a visitor says "I got blocked", ask for it, search it in Incidents, and see the exact reason and URL. And when things get really bad, Bunker Mode locks the whole site down behind a maintenance page — with HTTP 503, so search engines don't drop your rankings. Both get their own article below.

06Protected downloads

Put files in a files folder next to smartkiller (or choose another folder in Firewall Rules) and link to them through the firewall. By default each IP can download 10 files per 24 hours.

/smartkiller/download.php?file=MyApp.zip

07Built to never break your site

A firewall that takes your site down is worse than no firewall. So 3.0 follows one golden rule: fail open. If SmartKiller ever hits an internal problem — its database is down, say — your website keeps working and the error goes to the PHP error log.

• All code lives in its own SmartKiller namespace, and config is a returned array, not global constants — so nothing collides with WordPress's DB_HOST and friends.
• Strict database error reporting is switched on only while SmartKiller's own code runs; your site keeps its own settings.
• Internal files like config.php, logs and backups are denied by the bundled .htaccess.

One more thing: the package includes smartkiller/assets/wallpaper.png, the official SmartKiller wallpaper. It's a gift — put it on your desktop.

The big picture

SmartKiller runs a fast, layered series of checks before your application code starts. Good visitors pass through without noticing anything — no CAPTCHA, no delay. Bad ones are stopped and shown a clear page explaining what happened.

The checks, in order

1. Who is this IP?One database query returns its status: Trusted, Blocklisted, Quarantined, Watchlist or Normal. Trusted IPs (your office, your phone) skip everything below.
2. Is Bunker Mode on?If you've locked the site down, everyone who isn't Trusted gets the maintenance page.
3. Is it already blocked?Blocklisted IPs are stopped. Quarantined IPs are stopped until their hour is up — then released automatically to the Watchlist.
4. Is it a search engine?24 crawlers — Google's bots, Bing, Yandex, Baidu, DuckDuckBot, Applebot and social previewers like Slack, Discord, Telegram and WhatsApp — are let through. Unless one sends an attack payload: then it's a fake, and it's quarantined.
5. Is it a hacking tool?Scanners like sqlmap, nikto and wpscan identify themselves in their user-agent. They go straight to quarantine.
6. Is the page allowed?Only if you've turned on Strict mode: requests for pages that aren't on your list count as an offense.
7. Does the URL look like an attack?The URL — both raw and decoded — is checked against your signatures: SQL injection, XSS, path traversal, code injection, probes for .env, .git and wp-config.php.
8. Too many requests?By default, 120 requests per 60 seconds. Watchlist IPs get half that.
9. Hammering reload?Repeat hits on the same URL within 3 seconds are counted. More than 15 in a minute is a refresh flood.

If the request survives all of that, it's logged and your page loads normally.

After your page responds

SmartKiller's work doesn't end when your page starts. At shutdown it looks at the response your site sent. A 404 is recorded — and a burst of them from one IP is flagged as a vulnerability scan. Successful pages are counted in Visitors, including how much data each IP was served.

What a blocked visitor sees

A clean page with the raptor, their IP, an Incident ID, and a live countdown until they can try again. Under the hood, the response is built to be search-engine-safe:

HTTP/1.1 429 Too Many Requests
Retry-After: 3600
X-Robots-Tag: noindex, nofollow
Cache-Control: no-store

You can set your website name, a contact link (for example your Telegram) and its button text in Firewall Rules → Block page, so legitimate visitors always have a way to reach you.

Two layers, two jobs

Cloudflare can't easily know that one IP downloaded your files 30 times today, or that your site is being slowly scanned for old plugins. And if someone finds your server's real IP, they can skip Cloudflare entirely. SmartKiller lives in your code, so it's there either way.

The real-IP problem

Behind Cloudflare, every request appears to come from a Cloudflare server. The visitor's real IP travels in a header called CF-Connecting-IP. If a firewall ignores it, it rate-limits Cloudflare instead of the attacker — and blocks everyone at once.

In 2.1 the fix was to uncomment a line in getRealIP(). It worked, but it had a quiet flaw: anyone can send that header. An attacker hitting your server directly could put any IP they liked in it — even one of your Trusted IPs.

How 3.0 fixes it

No code editing. In Firewall Rules → Network & data, turn on "Website is behind Cloudflare". The console even tells you whether it detects Cloudflare in front of your site.

With the option on, SmartKiller trusts CF-Connecting-IP only when the request really arrives from one of Cloudflare's published IPv4 and IPv6 ranges. Anyone else's header is ignored.

// The Cloudflare header is trusted only when the request really comes from Cloudflare.
if ($S['trust_cloudflare'] && $cf !== '' && behind_cloudflare()) $ip = $cf;

Do you need Cloudflare at all?

No. SmartKiller works perfectly as a standalone firewall on any PHP + MySQL hosting, and for most small and medium sites it's enough. Start without Cloudflare; if you add it later, it's one checkbox.

What rate limiting actually does

It's a simple rule: "You can make this many requests in this window. After that, you wait." It's one of the most effective, least disruptive defences you can add. Real people almost never hit a sensible limit. Bots — which fire requests as fast as your server answers — hit it almost immediately.

Sliding windows, not fixed buckets

SmartKiller counts every request from an IP in the last N seconds, measured from right now. A fixed window resets on the clock (say, every minute on the minute), and a bot can game it by bursting just before and just after the reset. A sliding window always reflects recent behaviour, so there's no reset to exploit.

Separate counters for separate abuse

One global limit forces a bad choice: strict enough to catch bots means strict enough to annoy power users. So SmartKiller watches four different behaviours, each with its own threshold:

Stricter for the suspicious, not for everyone

Here's the 3.0 idea we like most. After a first offense, an IP lands on the Watchlist — and its request limit is cut in half (never below 5). Everyone else keeps the full, generous limit.

That means you can set a comfortable limit for real visitors, and still clamp down hard on anyone who has already shown bad behaviour once.

Offenses and escalation

Tripping a limit once is not a ban. Each violation adds one offense: the first is a warning, offenses two to four bring a one-hour quarantine, and the fifth puts the IP on the permanent Blocklist for your review.

• A real person who mashes F5 gets a warning page and carries on.
• A bot that keeps coming back after every quarantine climbs the ladder and is eventually removed from your traffic for good.

The steps

1. Upload the new folderPut the smartkiller folder in your site root, next to your old v2 files.
2. Run the installer with the same databaseOpen /smartkiller/install.php and enter your existing database details. The wizard detects v2 and upgrades it in place.
3. Choose Automatic protectionFrom now on, SmartKiller runs before every PHP page — no include lines needed.
4. Remove the old filesDelete smartkiller.php, raptor.php, dashboard.php, download.php and create_user.php from your site root.
5. Remove the old include linesTake the v2 include lines out of your pages. With Automatic mode they're no longer needed.

What the upgrade fixes for you

The migration is idempotent — safe to run on a fresh install, a v2 database, or a 3.0 database you've already upgraded. Along the way it cleans up two things from 2.x:

• Offense history is kept. v2 used a database trigger that wiped an IP's offense count every time it was quarantined, so repeat offenders never reached the Blocklist. 3.0 removes it.
• Ordinary visitors leave the Watchlist. v2 stored every visitor in its tracking table, which made normal people look suspicious. 3.0 moves them into the new Visitors statistics.

Bunker Mode: one switch, full lockdown

Bunker Mode puts your whole site behind a maintenance page. Everyone sees it — except IPs in your Trusted Zone, who browse normally. When you switch it on, SmartKiller automatically adds your current IP to the Trusted Zone so you don't lock yourself out.

It's built to be safe for SEO. The page is served with:

HTTP/1.1 503 Service Unavailable
Retry-After: 3600
X-Robots-Tag: noindex, nofollow

503 tells search engines "temporarily unavailable, come back later" — so a few hours of lockdown won't cost you your rankings.

When to use it

• You're under a sustained attack and want breathing room while you investigate.
• You've found a vulnerability and need to patch it before anyone else finds it.
• You're doing risky maintenance and want only your team on the site.

Incident IDs: every block has a receipt

Every block page shows a short Incident ID — something like 7F3A9C21DE. Behind it, SmartKiller stores the IP, the reason, the URL that triggered it and the time.

When someone writes in saying they were blocked, you don't have to guess. Ask for the ID, search it in Incidents, and you'll see exactly what happened. From there, IP Lookup shows that IP's full story — status, offenses, recent incidents — and you can release it, trust it or block it in one click.