On May 16th 2026 we received a responsible disclosure report from security researcher Vishal Shukla (@therawdev) identifying an obscure...
On May 16th 2026 we received a responsible disclosure report from security researcher Vishal Shukla (@therawdev) identifying an obscure remote code execution vulnerability in Backpack CRUD's telemetry code. We verified it and within 24 hours we released patches for v7, v6 and v5, then notified customers directly. We have given Backpack users a 30-day window to do composer update backpack/crud before publishing the advisory.
The attack required no authentication. The affected versions are:
The vulnerability existed in the code, but it's now patched - if you've run composer update in the past 30 days, you already have the fix.
Practical exploitation required a rare combination of conditions that most standard Laravel deployments don't have (Apache or old nginx + exec() enabled in the web PHP process + correct environment). We tested across multiple servers and couldn't trigger it on any of them. However, the vulnerability does exist under the right conditions, so it should be taken seriously.
Two conditions had to be true simultaneously:
1. PHP's exec() function was enabled. This is the default on VPS servers and Laravel Forge-managed servers. It is typically disabled on shared hosting, AWS Lambda (Vapor), and many managed platforms. Additionally, the function is sometimes enabled for CLI, but disabled for web processes.
2. The HTTP Host header reached PHP unmodified. Cloudflare and most CDNs normalize Host headers and would have blocked the malicious value before it reached your application. So do most WAF rules - they reject the request before PHP runs. However, a bare VPS without Cloudflare in front and without any WAF could be exposed - depending on the nginx / Apache version and configuration.
Conclusion: If you run on Forge or a VPS without Cloudflare (or similar), you should treat this as serious. Update and maybe even follow the check guide below.
Please run composer update backpack/crud immediately - that's it. The fix is in:
We have no reason to believe this vulnerability has been known or exploited - but we can't rule it out. To understand if your server was compromised, you can SSH into your production server and run the following commands:
Step 1 — Were you vulnerable?
Check if
php -i | grep disable_functions
php -m | grep curl
If exec appears in disable_functions, or curl is not listed — it's possible you were not vulnerable. But. The above only tests your CLI php binary. If your web server runs PHP via FPM, it has a separate php.ini and may have exec enabled/disabled independently:
grep -rn "disable_functions" /etc/php/*/fpm/php.ini 2>/dev/null
grep -rn "disable_functions" /etc/php/*/fpm/pool.d/*.conf 2>/dev/null
If exec appears in either → your web process had exec() disabled even if CLI did not. You were not vulnerable.
Even if exec() were enabled, check whether your web server or a WAF rejected the request before PHP ran. nginx has increasingly strict request-line and Host-header validation, including rejection of spaces and control characters in the Host line in 1.21.1, and later RFC 3986-aligned host validation in 1.29.4; however, you should not assume it strips every potentially dangerous character such as a single quote. On Apache, behavior depends heavily on version and configuration, including whether ModSecurity or another WAF was enabled.
Step 2 — Check for probing attempts in nginx logs
grep "'" /var/log/nginx/access.log
zgrep "'" /var/log/nginx/access.log.*.gz
No results = no probing attempts in your logs.
Additionally:
# nginx — single quotes in Host header; 400 = blocked before PHP, 200/302 = reached PHP
grep "'" /var/log/nginx/access.log | awk '{print $9}' | sort | uniq -c
zgrep "'" /var/log/nginx/access.log.*.gz | awk '{print $9}' | sort | uniq -c
# Apache
grep "'" /var/log/apache2/access.log | awk '{print $9}' | sort | uniq -c
How to interpret:
Step 3 — Look for suspicious files
ls -lat /tmp | head -40
find /var/www -name "*.php" -newer /var/www/html/index.php -not -path "*/storage/*" 2>/dev/null
Step 4 — Check for unexpected cron jobs
crontab -u www-data -l 2>/dev/null
crontab -u forge -l 2>/dev/null
Step 5 — Check for unexpected outbound connections
ss -tnp | grep -v "127.0.0.1"
sudo last | head -30
Step 6 — The hard truth about .env
If an attacker ran a command on your server, reading your .env file is the most likely first action. Linux does not log file reads by default, so there is no reliable way to detect this after the fact. If you were vulnerable (Step 1) and found evidence of probing (Step 2), treat your .env secrets as compromised and rotate them:
APP_KEY| Date | Event |
|---|---|
| May 16, 2026 | Vulnerability reported by @therawdev |
| May 17, 2026 | Verified and patched |
| May 19, 2026 | Customers notified by email |
| June 15, 2026 | Public advisory published |
| June 17, 2026 | Public blog post published |
Full credit to Vishal Shukla (@therawdev) for identifying this vulnerability and reporting it responsibly rather than exploiting it. This is exactly how coordinated disclosure should work, and it made a real difference for our customers. The internet is a better place, with people like him on the good guys' team - thank you.
Reply to the email we sent you. We're here.
— Tabacitu & the Backpack team
Subscribe to our "Article Digest". We'll send you a list of the new articles, every week, month or quarter - your choice.
What do you think about this?
Wondering what our community has been up to?
