cyberszkola/Case study: PHP2Shell

Case study · free narrated lab

PHP2Shell: how to check whether a PHP patch works

Walk through the PHP2Shell incident step by step: from the php.net warning to proof that the fix works. In the browser, no sign-up.

9 phases · about 18 min · voice-over in PL, EN, RO · no sign-up

Launch the labWhat you will see
Send the link to your computerLaunch anyway

Bramblewood Academy and Harbourline Cloud are fictional; the public record is real. The lab shows what the attack did, never how to trigger it. Facts as of: · Sources

Want to practise this yourself?Web Security PROA course in attacking and defending web applications: 132 labs in the browser.Edition starts 16 November 2026See the course
PHP2Shell · case study

The commands and scripts in the lab are written for the fictional servers of this simulation. Do not copy them as they are to your own server: stopping a container, editing php.ini or replacing PHP files can take a service down.

The lab opens in Guided mode: you go step by step, at your own pace. Would you rather watch the whole thing play out on its own? Switch the mode to Auto.

The demo and the labs work best on a computer — a laptop or a desktop.

Voice-over: a synthetic voice. Once started, the lab downloads about 22 MB of data.

Want to learn this?

A lab from the Web Security PRO course: the application in the browser, the HTTP request inspector and the tutor
This is what a lab in the course looks like: the application, the tools and the tutor in one browser window.

Web and applicationsWaitlist

Web Security PRO

A course in attacking and defending web applications. You practise on your own in 132 browser labs: reconnaissance, vulnerabilities, proof and checking the fix.

Edition starts
16 November 2026
Planned first-edition price
€189 including tax
Environment
In your browser, no installation
See the Web Security PRO course Notify me at launch

The course follows the OWASP Web Security Testing Guide (WSTG), the widely used guide to testing the security of web applications.

In the course, you do it yourself

Four skills from this case

  • Identify the server and its versionand check whether the banner tells the truth. As in phase 2.
  • Find forgotten hosts and risky settingsa second hostname for the same application, and a phpinfo page that must not be public. As in this case.
  • Prove a vulnerability without guessingwith a control that could have come out differently. As in phase 5.
  • Check that the fix really workswith a retest, not by the version number. As in phase 8.

The PHP2Shell case is a separate lab, outside the course's 132 labs. Web Security PRO teaches web application testing — not patching container images or running incident response.

Map to OWASP WSTG (advanced)
  1. What you see in the case

    A version banner is a lead, not proof.

    Where you practice it in the courseServer fingerprinting through headers and errorsWSTG-INFO-02
    Chapter and opening date

    Chapter 01 · Application reconnaissance

  2. What you see in the case

    A second hostname leads to the same application.

    Where you practice it in the courseFinding applications on a shared serverWSTG-INFO-04
    Chapter and opening date

    Chapter 01 · Application reconnaissance

  3. What you see in the case

    What stands between the internet and the server.

    Where you practice it in the courseArchitecture and dependency mapWSTG-INFO-10
    Chapter and opening date

    Chapter 01 · Application reconnaissance

  4. What you see in the case

    Known vulnerabilities in server software, and the retest after the fix.

    Where you practice it in the courseNetwork infrastructure configurationWSTG-CONF-01
    Chapter and opening date

    Chapter 02 · Configuration and deployment

  5. What you see in the case

    phpinfo as an instrument that must not be public.

    Where you practice it in the courseApplication platform configurationWSTG-CONF-02
    Chapter and opening date

    Chapter 02 · Configuration and deployment

  6. What you see in the case

    A database dump kept outside the application directory.

    Where you practice it in the courseBackup and forgotten filesWSTG-CONF-04
    Chapter and opening date

    Chapter 02 · Configuration and deployment

  7. What you see in the case

    The trace a shell started by the web server leaves behind.

    Where you practice it in the courseOS command injectionWSTG-INPV-12
    Chapter and opening date

    Chapter 07 · Input data and injection

Chapters 01 and 02 open in the first two weeks of the edition. Once a chapter is unlocked, it stays open.

See all 132 labs

Lab walkthrough

Four days in nine phases.

Tuesday evening: the advance notice. Wednesday: inventory, logs, isolation, the fix and the proof. Thursday: the restart that undid the fix. Friday: a third flaw and closing the incident.

In the lab you play the person on call at a fictional organization; “we” in the narration means its team. You type nothing: the steps run the commands themselves, and the tutor shows you where to look.

  1. Read the notice before the release

    php.net announces upcoming fixes for two critical flaws, with no details yet. A plan takes shape: inventory, exposure, stopgaps, the fix and the proof.

  2. Fingerprint your own host, outside and inside

    Headers and a scan from outside, the PHP version and module from inside. A second hostname leads to the same application.

  3. Is this the demonstrated configuration?

    The advisories are now public. A script that compares version numbers gives the right verdict for the wrong reason, and nothing on the request path filters traffic in front of the server.

Show the other 6 phases

  1. What the attack looked like from inside

    The error log and the access log on one clock: crashed server workers and a run of HTTP 500 responses from one address. Verdict: exposure confirmed, compromise not ruled out.

  2. Compromise check with controls; the verified dump

    Three checks for traces, each with a control that could have come out differently, and what you may conclude from them. Before any change: a database dump, verified before anyone relies on it.

  3. Offline, and the stopgap that costs nothing here

    The service is taken offline, and the cost of that decision is stated plainly. The setting php.net recommends closes one attack path but does not remove the vulnerability.

  4. 0 upgraded: the image has no package database

    The package manager has nothing to update. The fix goes into the container from the distribution's signed packages — and you need to know exactly where it stays.

  5. Prove the fix by the build the server loads, not by the banner

    The banner still shows PHP/8.3.6. What decides it is the build date, the module file the web server loads, and a check that can come out either way.

  6. The Restart that undid the patch; the 23 October follow-up

    A restart from the provider's panel recreates the container, and the old build comes back. Then the fix is applied again, a third flaw follows on Friday, and the case closes with seven lessons.

Lessons that carry over

Seven rules that apply beyond this flaw.

  1. Inventory every hostname, not just the public one.
  2. Exposure is not compromise: write down what you can prove, and what you cannot rule out.
  3. Trust only checks that can come out either way.
  4. Before you change anything, take a verified database dump.
  5. A stopgap closes one attack path. Only an update fixes the flaw.
  6. Prove the fix by the build the server actually loads, not by the banner.
  7. Some restarts recreate the container, so check the build after every restart.

Case study: PHP2Shell

Downloadable checklist

Does the server load the patched PHP? Eight checks.

The list sums up the method from the case. It does not replace the vendor's or the hosting provider's guidance, and it is not a guide to testing other people's systems.

This is educational material, not instructions for your server: test every change in a test environment first, with a current backup, and make it at your own risk.

  1. Before you change anything, take a database dump and verify it. Keep it outside the application directory.
  2. Inventory every hostname the server answers to, not just the public address.
  3. Do not judge the fix by the X-Powered-By banner or by the version number. Some distributions backport fixes without changing the number: Ubuntu 24.04 shows 8.3.6 before the patch and after it.
  4. Compare the build date from php -v and from the Build Date field in phpinfo with the date of the fix in the distribution package's changelog.
  5. Check the PHP module file the web server loads. The command line and the web server can use different builds.
  6. Run phpinfo only on a page that is not publicly reachable, and delete it after the check.
  7. Trust only checks that can come out either way. A check script must be able to return both “not patched” and “patched”, and “cannot tell” when the data cannot settle it.
  8. After every restart from the provider's panel and every image update, check the build again. Some restarts recreate the container.

php.net recommends setting session.upload_progress.enabled = 0 until the next regular PHP release, also after the 21 October update. The setting closes one attack path; only the update removes the vulnerability.

See the whole incident in the free narrated lab (in your browser, no sign-up): cyberszkola.pl/php2shell

Facts as of:

Download the checklist (PDF)

Two A4 pages: the checklist with a QR code to the free lab, and the sources.

Sources

  1. PHP security advisory GHSA-w8hw-w9fx-j79w — CVE-2026-109618, RCE via OOM corruption
  2. PHP security advisory GHSA-6wmf-4rv5-p3rp — CVE-2026-109619, RCE via stale global state
  3. php.net — advance notice of 20 October 2026
  4. php.net — informational advisory: session upload progress (23 October 2026, CVE-2026-115560)
  5. CERT-EU Security Advisory 2026-018 — Critical Vulnerabilities in PHP (v1.2)
  6. Ubuntu Security — CVE-2026-109618 (package table, USN-8948-1/2)
  7. Launchpad — php8.3 8.3.6-0ubuntu0.24.04.13 (changelog: SECURITY UPDATE, CVE-2026-109618/109619)
  8. Tenable — php2shell FAQ (updated 28 October 2026)
  9. Datadog Security Labs — PHP2Shell: what the logs and processes show (updated 23 October 2026)
  10. Varonis — PHP2Shell: the log pattern to hunt for
  11. NCSC-NL — third-party software that embeds PHP (inventory aid, referenced by CERT-EU)
  12. CISA — Known Exploited Vulnerabilities Catalog
  13. OWASP WSTG-CONF-01: Test Network Infrastructure Configuration
  14. OWASP WSTG-INFO-02: Fingerprint Web Server
  15. OWASP WSTG-INFO-08: Fingerprint Web Application Framework
Poster of the SQL injection lab from the Web Security PRO course: the ShopMart shop

A lab from the course

See a full lab from the Web Security PRO course: SQL injection

From a parameter in a product URL to data from the database and a retest after the fix. No sign-up, in the browser.

Open the demo on the course page

First edition

Next step: practice it yourself.

Starts 16 November 2026 · 13 weeks, a new chapter every Monday · 365 days of access · consumers: 14 days to get a refund, no reason needed

  • 132 technical labs: WSTG topics and original extensions.
  • Access for 365 days from purchase, with no automatic renewal.
  • Interactive guidance with a tutor, narration and browser-based tools. No Docker, VPN or local lab installation.
  • Certificate of completion in English, with a verification code.
  • The course is available in Polish and English.

People on the list get news of enrolment and the full offer before enrolment opens to the public.

The PHP2Shell lab is free and works without signing up. The sign-up form is only for the Web Security PRO waitlist.

Web Security PRO

Join the waitlist

Have a question? Email me

You can withdraw your consent at any time. This signup covers the selected course — we will not add you to the lists for the other courses automatically.

For teams

Talk this case through as a team.

You can forward the link to this page or run the lab at a team meeting. The seven lessons and the checklist are ready to print.

Web Security PRO for companies: team licences, a VAT invoice and a free pilot before you buy.

Ask for a quote

Sources and where the facts stand

Public facts, a fictional organization.

Facts as of:

The public timeline comes from the advisories and notices below. The organization, its provider, the servers, addresses, logs and numbers in the lab are fictional; the IP addresses come from ranges reserved for documentation. The lab cites 21 public sources.

Timeline and sources
  1. 20.10.2026 — php.net announces upcoming fixes for two critical flaws (CVSS 9.2).
  2. 21.10.2026 — releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and two GitHub advisories; Ubuntu publishes a fixed build that keeps the version number 8.3.6.
  3. 23.10.2026 — php.net reports a third flaw (CVE-2026-115560), to be fixed in the regular release cycle, and advises keeping the stopgap setting.
  4. 26.10.2026 — CISA adds CVE-2026-109618 and CVE-2026-109619 to the KEV catalog.

Questions

Good to know.

Is this a real incident?

The flaws CVE-2026-109618 and CVE-2026-109619, and the public timeline, are real and described in the sources. Bramblewood Academy, Harbourline Cloud, their servers, addresses and logs, and the numbers in the lab are fictional.

Does the lab show how to carry out the attack?

No. It shows what the defender sees in the server's logs, processes and configuration, and how to assess exposure. It contains no requests, payloads or tools that would let anyone trigger the flaw.

Can I use the lab's commands on my own server?

Not as they are. Commands that only read data, such as the PHP version, response headers or logs, usually change nothing. Those that switch the Docker context, stop a container, edit php.ini or replace PHP files are written for the lab's fictional server and can take a production service down. Follow the vendor's and your provider's guidance, test every change in a test environment first, with a current backup, and make it at your own risk.

Do I need to sign up or create an account?

No. The lab is free and runs in the browser, without an account and without giving an email address. The forms on this page are only for the Web Security PRO waitlist and are optional.

How long does it take, and how do the modes differ?

Auto mode takes about 18 minutes and runs by itself, like a narrated video. In Guided mode you go step by step with the Next and Back buttons, at your own pace. The narration text is on screen, so the lab also works without sound.

What do I need to run it?

A computer with a screen of at least 1280 × 720 and an up-to-date browser. Once started, the lab downloads about 22 MB of data. On a phone you can read the description and the lessons, and send the link to your computer.

Why does the lab close when developer tools are opened?

It is content protection, the same as in the other demos on cyberszkola.pl. Close the developer tools and click “Return to the lab”; in Guided mode the “Chapters” strip lets you jump to the chapter you choose.

How does this case relate to Web Security PRO?

It is a separate, free lab, outside the course's 132 labs, built in the same environment. In Web Security PRO you practice the same method yourself — reconnaissance, evidence and re-checking the fix — from the application-testing side. The course does not teach patching container images or running incident response.

Jacek Wlodarczyk

Project author

Jacek Wlodarczyk

Creator of Cyberwiedza, cyberszkola and AI SecLabs. In these courses, I connect explanations of mechanisms with practice, observation and decisions you need to justify.

Running a command is not enough. What matters is what its output confirms, what it does not confirm and what the next step should be.

More about the author