The weakness
Two serious flaws in PHP’s memory handling can let a specially crafted web request make the server run someone else’s instructions—even without a login. The nickname is php2shell. [2]
GVPH learning hub / PHP handbook
Heard about the PHP attack? Let’s make sense of it—one small lesson, one video, and one “what would you do?” at a time.
No tech background needed. No downloads. No real attacks.
The risk starts here, in vulnerable server software.
Let’s unpack it.Three small activities. A clearer next step.
0 of 3 explored01 / The 60-second version
Think of a website as a front desk. PHP can be one of the helpers behind it: preparing pages, handling forms, or talking to a database. It usually works on the server, not inside your browser. [1]
Two serious flaws in PHP’s memory handling can let a specially crafted web request make the server run someone else’s instructions—even without a login. The nickname is php2shell. [2]
An attacker could read information, change files or disrupt a service within the access the PHP process has. Application credentials or connected data may be at risk. That is a possible consequence, not proof of a breach. [4]
Owners need verified software or vendor updates. Staff need a simple way to spot concerns and report them. A website containing PHP does not, by itself, mean it has been attacked. [3]
Activity 1 / Go behind the scenes
A pretend website. Three steps. Select each one to see where the problem can happen.
Normal requests ask to open a page or submit a form. An attacker can send a deliberately unusual request to try to trigger a weakness.
You do not need to click an attacker’s email for a public server to receive a request.
A conceptual demonstration, not a working exploit. Technical basis: CERT-EU advisory and PHP permission model.
It’s more than a website question
These are places to check—not a list of confirmed vulnerable products. A web interface alone does not prove PHP is present. Exact models, software builds and vendor advice matter. [3]
Some content systems, forms, shops and web applications use PHP.
Ask: the website owner or hostSome NAS devices and business appliances bundle PHP in their control panel.
Ask: IT or the device vendorSome edge and network products have a PHP-based management interface.
Ask: the network administrator02 / Watch it click
Original GVPH illustrations with synthetic narration, English captions and full text alternatives. Press play when you’re ready.
See how a request can become a problem—and why permissions matter.
PHP is software that runs behind some websites and device management pages. Think of it as part of the engine, working behind the screen.
An attacker sends a specially crafted request to a reachable, unpatched PHP service. The weakness is in the server software, not in a person opening an email.
Certain memory handling flaws can let that request make the server run commands. Some attacks do not require a login.
An attacker may reach site files, stored information, or application credentials. The reach depends on the app's permissions and the system's configuration.
Finding PHP does not prove an attack happened. Visiting a website does not automatically infect your computer.
Owners need official updates, limited management access, and a check for signs of compromise. A patch closes the weakness. It does not erase an earlier break-in.
Illustrative explanation based on PHP, CERT-EU and PHP security guidance.
A calm response beats a rushed click. Learn what belongs with you and what belongs with IT.
If a site suddenly asks for unusual logins, downloads, or personal information, stop. Do not keep entering information just to see what happens.
Note the page address, the time, and what changed. Report it to your I.T. team or service provider using a trusted contact.
Do not try exploit tests or download an unapproved fix. Do not turn off shared clinical systems yourself. Let the responsible team coordinate.
Owners should inventory websites and devices, then verify the actual PHP or firmware version. Install the matching update from the official vendor or hosting provider.
Limit who can reach management pages. If compromise is suspected, preserve evidence and have the response team check for persistence.
Use tested backups and multifactor authentication as extra protection. They help recovery and account security, but they do not replace patches.
Activity 2 / Your turn
No trick questions. Pick a response and see why it helps. All situations are fictional.
A familiar website suddenly asks you to download a tool to protect against PHP attacks. You weren’t expecting it.
Practice for everyday decisions. A suspicious prompt is not proof of php2shell. Reporting guidance
03 / Make it useful
Choose the guidance that fits. Check items as you read; nothing is saved or sent.
Your job is to pause, capture the basics and get help through a trusted route.
Keep your devices current and contact the organization through a route you already trust.
Check the actual runtime serving each site and the firmware of each appliance.
Open the GVPH scannerAuthorized inventory only. A scan does not certify safety.
Prevention and response sources: NCSC-NL, NIST, IHS and NCSC. Learning checkmarks reset when you reload.
Activity 3 / Myth or useful fact?
Choose an answer for each statement. You can change your mind—this is practice, not a test.
Three ideas worth remembering.
Why these answers matter: HTTPS, hidden PHP, incident response.
Keep this bit for your IT team
Reviewed October 26, 2026 · A dated guide, not a live security feed.
The table is the upstream baseline for the two original php2shell flaws. Vendor package revisions and follow-up advisories also matter. Confirm the current guidance before making a change. [2] [10]
| PHP branch | Original fixed baseline |
|---|---|
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 |
Older upstream branches are unsupported. Some vendors backport fixes into older-looking version numbers. Obtain explicit confirmation for the installed package; do not rely on its number alone.
PHP recommends administrators disable session.upload_progress.enabled until the next regular bugfix release, with worker restarts. The follow-up, CVE-2026-115560, involves an unusual combination of session configuration and application behavior. Keep this separate from the two original fixes and follow the full official instructions. Read PHP’s October 23 notice.
Windows rebuilds 8.5.12-1, 8.4.27-1, 8.3.36-1 and 8.2.35-1 address a separate Brotli issue, CVE-2026-111497. The displayed PHP runtime version does not change. Verify the installed package, not just a header. Read PHP’s October 26 notice.
Servers can hide their version, and proxies may answer for them. DNS identifies addresses, not the PHP build or its patch status. Ask the administrator to verify the runtime serving the exact site and any vendor backport. Do not publish a diagnostic page to reveal it. PHP’s hiding guidance.
They can reduce specific attack paths, but they are incomplete. Use vendor or PHP guidance while arranging a verified update. Do not copy server configuration changes from this learning activity. CERT-EU recommendations.
Tiny glossary
04 / Show your sources
Technical facts come from the PHP project and security authorities. The fictional scenarios and animations are GVPH learning examples, not evidence of an incident at GVPH or elsewhere.
The reviewed advisories describe critical flaws and public exploit demonstrations. They do not establish that every PHP system is compromised or that widespread exploitation has been confirmed. This page is educational; it does not scan your device or collect your answers.
The bit to take with you
You don’t need to become a security expert to make a safer choice.
Search 20 plain-language terms and try three everyday decisions.
Explore the glossary →Next / Public health preparednessExplore outages, AI, weather and the essentials communities depend on.
Try the preparedness activities →