In 2026, a surprisingly large number of web servers (especially legacy PHP apps, shared hosting environments and misconfigured cloud instances) still leave dangerous stream wrappers enabled. These wrappers are one of the fastest paths from a basic LFI/SSRF bug to full remote code execution or source-code disclosure.
Disabling the most abused ones in php.ini is a high-impact, low-effort change that closes entire classes of attacks people are still seeing in bug bounties and real incidents every week.
Here’s the practical list of wrappers you should kill today, why they’re still dangerous, and the exact lines to add.
1. php://filter (Still #1 abused wrapper in 2025–2026)
This is the go-to for almost every LFI-to-RCE chain when allow_url_include is on or when combined with file-upload misconfigs.
Real attacks right now
1. include("php://filter/convert.base64-encode/resource=index.php") → full source disclosure
2. php://filter/write=convert.base64-decode/resource=webshell.php → upload webshell via LFI
Fix
ini
allow_url_fopen = Off
allow_url_include = Off
If you absolutely cannot turn allow_url_fopen off (very rare in modern apps), at least block the filter chain:
ini
disable_functions = php_strip_tags,show_source,highlight_file,readfile,file_get_contents,include,include_once,require,require_once
2. expect:// (Command execution when expect extension is loaded)
Even though expect is not shipped by default anymore (PHP 8.1+), plenty of older servers still have it installed.
Real attack
include("expect://whoami");
include("expect://id");
include("expect://rm -rf /var/www");
Fix
ini
disable_functions = expect://*
; or uninstall the expect extension completely (best option)
3. data:// (Base64 RCE via include)
Very popular in file-upload-to-RCE chains.
Real attack
include("data://text/plain;base64,PD9waHAgc3lzdGVtKCd3aG9hbWknKTsgPz4=");
Fix
ini
allow_url_include = Off ; kills data:// include
If you must keep allow_url_include on (legacy code):
ini
disable_functions = data://*
4. phar:// (Phar deserialization RCE)
Still abused when phar stream wrapper is enabled + file upload exists.
Real attack Upload a .php file disguised as .jpg → include("phar://uploaded.jpg/malicious.php")
Fix
ini
phar.readonly = On
; ideally disable the phar extension entirely if you don’t need it
5. file:// (Local file disclosure / SSRF)
Abused in SSRF-to-local-file chains when allow_url_fopen = On.
Real attack
file_get_contents("file:///etc/passwd");
file_get_contents("file:///proc/self/environ");
Fix
ini
allow_url_fopen = Off
Recommended Minimal Hardening Block for php.ini (Add This)
ini
; === Critical wrappers & functions to disable ===
allow_url_fopen = Off
allow_url_include = Off
phar.readonly = On
; Block dangerous wrappers & functions
disable_functions = php_strip_tags,show_source,highlight_file,system,passthru,exec,shell_exec,proc_open,popen,pcntl_exec,ini_set,ini_alter,dl,curl_exec,curl_multi_exec,parse_ini_file,parse_ini_string,mail,putenv,expect://,data://,phar://,file://
; Optional but useful for extra safety
disable_classes = DirectoryIterator,Directory,GlobIterator,SplFileInfo,SplFileObject
Quick Validation After Changes
Run this to confirm:
php -i | grep -E "allow_url_fopen|allow_url_include|disable_functions|phar.readonly"
You should see:
allow_url_fopen => Off => Off
allow_url_include => Off => Off
phar.readonly => On => On
disable_functions => [long list including expect://, data://, phar://, etc.]
Why This Still Matters in 2026
1. Many shared hosting providers and legacy PHP apps (WordPress <6.5, old custom CMS) still run with allow_url_fopen = On
2. php://filter + LFI is still one of the highest-payout bug-bounty chains
3. expect:// survives on a surprising number of old Debian/Ubuntu servers
4. data:// + file upload = RCE in seconds on misconfigured apps
Turn these off globally if you can. If you can’t (legacy code), isolate that application behind a strict WAF and consider containerizing or migrating it.
One php.ini change can close entire classes of attacks that are still being reported every week.
Check your servers today, if allow_url_fopen = On is still there on an internet-facing PHP instance, treat it as a high-priority fix.
