Most of the WordPress, Joomla, and plugin bugs that hit my inbox last year had the same root cause: somebody wrote PHP without understanding how PHP handles types, sessions, or file paths. If you can’t read the buggy code, you can’t write a working exploit. And you definitely can’t tell the customer how to patch it.

This article is the start of a new PHP and Web Security Tutorial Series on the blog. The plan is simple — work through PHP the way serious web researchers like Orange Tsai work through it: backend first, vulnerabilities second, tooling last. By the end of the series you’ll be reading plugin source code instead of guessing at payloads.

Why PHP still matters in web security

PHP runs about 75% of the websites whose server-side language can be detected, and WordPress alone runs around 40% of all websites on the internet. That’s not a sentimental number — it’s the surface area of nearly every weekly bug bounty payout, every “WordPress plugin RCE” disclosure on the Patchstack feed, and most of the supply-chain incidents that hit small e-commerce in the last two years.

Where you’ll meet PHP in real engagements:

  • WordPress and its 60,000+ plugin ecosystem. Every Patchstack bulletin you’ve ever read is a PHP plugin shipping a footgun. Most of the high-severity ones are missing current_user_can(), broken nonce checks, or unsanitised SQL — all things you can only spot if you can read the code.
  • Laravel SaaS. A surprising amount of B2B SaaS is Laravel. The vulnerabilities aren’t the same as WordPress (Laravel’s auth and ORM are generally solid), but the framework conventions hide their own bugs: Storage::disk('local') paths, queue serialization, signed-URL bypasses.
  • Legacy enterprise PHP. Banks, telcos, and government portals still run PHP 5.6 / 7.0 stacks they’re afraid to touch. These are the engagements where you’ll see custom session handlers, hand-rolled crypto, and eval() in production.
  • Hosting panels. cPanel, DirectAdmin, ISPConfig, Plesk extensions — all PHP. The shared-hosting plane is one of the most under-audited pieces of the web.
  • APIs and microservices behind a PHP front door. Plenty of “we’re modern, we use Go!” companies still have a PHP gateway that handles auth and rate-limits before the request ever reaches the new stack.

That’s a long surface to ignore.

Why learn PHP before advanced web hacking

The mistake I see junior researchers make over and over: they jump straight to tools. They run sqlmap against a parameter. They pipe ffuf at a path. They follow a YouTube tutorial that says “intercept this request in Burp, change this header, get RCE.” Sometimes it works. Most of the time it doesn’t, and they have no idea why.

The researchers who consistently land big bounties read source. Orange Tsai’s blog is the canonical example — his Black Hat talks on Imagick, ProxyLogon, and PHP filter chains all start from somebody patient enough to open a plugin file in a text editor and ask “what happens if I pass php://filter/... here?” That patience is the entire skill. Tools amplify it; they don’t replace it.

When you understand the backend, three things change at once:

  1. You can predict vulnerabilities from naming patterns — a ?file= parameter going through include() is a different threat model from one going through file_get_contents(), and a senior auditor sees the difference before opening the file.
  2. You can chain bugs that would individually be “interesting but unexploitable” — a string-to-int comparison plus a file path concat plus a missing wp_verify_nonce is three small bugs that compose into critical RCE.
  3. You can patch what you found. That matters for client deliverables, for HackerOne reports that need a remediation section, and for your own credibility as someone who actually understands the stack.

That’s why this series starts with PHP fundamentals before any vulnerability class. The bug list comes after the language.

What this tutorial series will cover

The full reading list, grouped roughly by depth:

Foundations

  • PHP fundamentals for security (variables, scopes, comparison operators, superglobals)
  • The HTTP request lifecycle from socket to $_SERVER
  • Sessions and cookies — including session.use_strict_mode, session hijacking, session fixation
  • Authentication and authorization patterns in WordPress, Laravel, and hand-rolled apps

Classical web vulnerabilities

  • SQL injection — including second-order, blind, and ORM-specific patterns
  • Cross-Site Scripting (XSS) — reflected, stored, DOM, and the under-discussed mutation XSS
  • Cross-Site Request Forgery (CSRF) and how WordPress’s nonce model actually works

File-system bugs

  • File upload vulnerabilities — including double-extension, magic byte, and .htaccess-bundling tricks
  • Local File Inclusion (LFI) and how php://filter chains turn it into RCE
  • Remote File Inclusion (RFI) — when allow_url_include is still on
  • PHP stream wrappers as both a feature and an attack surface

PHP internals

  • Deserialization (unserialize, PHAR, gadget chains) — the Orange Tsai PHAR-via-md5_file family
  • Type juggling — loose comparison, hash collisions, 0e... strings
  • SSRF in PHP, including DNS rebinding against gethostbyname()-based allow-lists

Server-side

  • Apache, Nginx, and PHP-FPM basics — how requests actually route and where misconfigurations live
  • Source code review as a learning method — what to look for in plugin trees, how to use grep and Semgrep effectively

This is the PHP and Web Security Tutorial Series as I’d teach it to someone who already writes a bit of Python or JavaScript and wants to take web seriously.

Who this series is for

  • Cybersecurity beginners who already know basic networking and want a real entry point into web. PHP is the most accessible language for understanding what a web app actually does at the request level.
  • SOC analysts moving into offensive security. You’ve watched the attacks land on production — now learn the language they hit.
  • Pentesters who can run automated tools but want to start finding bugs by reading code. This is where the salary curve bends.
  • Bug bounty hunters who want consistent payouts on WordPress, custom CMS, and SaaS targets. Tool-driven hunting plateaus fast; source review doesn’t.
  • Developers who write PHP and want to stop shipping the same five bugs. Most of the patches in the WordPress changelog are mistakes that the original author could have avoided with a one-paragraph awareness of the threat model.
  • Security engineers who want to grow into web specialists. The companies hiring senior web security engineers are looking for people who can write a secure framework, not just audit one.

If you’re in any of those buckets, the series will pay back the time.

How each tutorial will be structured

Every article in the series follows the same five-part shape so you can read or skim consistently:

  1. Explanation — what the bug class is, where it appears, and the mental model for spotting it.
  2. Vulnerable code — a minimal PHP snippet that demonstrates the bug. Always runnable locally with php -S 127.0.0.1:8000.
  3. Exploitation — the actual request, payload, or code that triggers it. With explanation of why it works, not just what to copy-paste.
  4. Secure fix — the corrected code, with the dangerous pattern called out specifically.
  5. Key lessons — three to five takeaways you can apply to other audits.

That format keeps the writing honest. If I can’t show you vulnerable and fixed versions of the same code, I don’t really understand the bug class well enough to teach it.

Where it makes sense, I’ll also reference real CVEs and real-world bug reports — WordPress plugin advisories from Patchstack, HackerOne disclosures, and the occasional Orange Tsai writeup that I’ll annotate with the parts that are easy to miss on a first read.

Conclusion — start from PHP

If you take one thing from this article: read the code. Tools find one bug at a time; reading code lets you find ten by inference. The cheapest way to start is to learn the language the bugs are written in.

The PHP and Web Security Tutorial Series kicks off here. Next up: PHP fundamentals for security — the comparison operators, the superglobals, and the small handful of language quirks that explain about half of all real-world PHP CVEs. After that we’ll work through the HTTP lifecycle, then start the vulnerability deep-dives.

If you want to follow along, bookmark the Tutorials category and subscribe to the RSS feed — every article in the series will land there. If you’ve been hunting WordPress plugins on bug bounty platforms, you’ll start spotting bugs you used to miss within the first three articles. If you’re a developer, you’ll write better PHP by article five.

PHP isn’t glamorous. It’s just where the bugs are.

Coming up in the series (internal links will go live as articles ship):

  • PHP Fundamentals for Security: Comparison Operators, Superglobals, and the Loose-Typing Trap
  • The HTTP Request Lifecycle in PHP: From Socket to $_SERVER
  • SQL Injection in PHP: From mysql_query to PDO Bind-Param Pitfalls
  • Cross-Site Scripting (XSS) in PHP Applications
  • CSRF and WordPress Nonces Explained
  • File Upload Vulnerabilities: Double Extensions, Magic Bytes, and .htaccess Bundling
  • Local File Inclusion (LFI) and php://filter Chains to RCE
  • PHP Object Injection: Deserialization, PHAR, and Gadget Chains
  • PHP Type Juggling: Loose Comparison, Hash Collisions, and 0e... Strings
  • SSRF in PHP: DNS Rebinding and Allow-List Bypasses
  • Apache, Nginx, and PHP-FPM for Web Hackers
  • Source Code Review for WordPress Plugins: A Practical Workflow

If there’s a topic you want pulled forward, drop it in the comments on any article in the series and I’ll re-order.

Further reading: Orange Tsai’s blog is required reading for anyone serious about web security research. Start with his PHAR series and his PHP filter chain talks — both are exemplars of the source-first approach this series is built around.