PHP Vulnerability

You see the advisory, you see the severity rating, and you think you understand the risk, and then you patch it and move on, and that is where most people stop thinking about it.

The question worth asking is what actually happens after the exploit succeeds, because the answer explains why a single unpatched PHP version is not just a bug report, it is an open door into everything the server can reach, and the sequence of events that follows is remarkably consistent across incidents.

Here is what actually happens, step by step.

Important Disclaimer

This article is intended for educational and defensive purposes only, and the information shared here is meant to help site owners and administrators understand the consequences of exploitation so they can prioritize patching and detection.

Do not use these techniques against systems you do not own or do not have explicit written permission to test, because unauthorized access and investigation is illegal in most jurisdictions.

The author assumes no liability for any damages, legal consequences, or other outcomes resulting from the use or misuse of this information, so always work within your authorization, and stay legal, stay ethical, stay responsible.

Minute One: Code Execution Under the Web User

The first thing that happens is that the attacker gets code execution inside the PHP process, and that means the code runs as the web server user, which on Linux is usually www-data and on Windows is the application pool identity.

That user is not an administrator, and that is the one small mercy in the whole scenario, and it does not limit the damage nearly as much as people assume, because the web user owns the application files, can read the configuration, can connect to the database, and can reach every internal service that the application itself can reach.

The practical consequence is that from the very first second, the attacker has the same access as your application, and your application is the thing that holds the data.

The First Five Minutes: Reconnaissance

Attackers do not start by doing damage, they start by understanding where they landed, and the first few minutes are almost always quiet.

They read the configuration files to find database credentials, API keys, and secret tokens, they list the application files to identify the framework and its version, they check the environment variables for cloud credentials, and they look at the network interfaces to work out whether this host can reach other systems.

They also check whether the exploit is repeatable, because a reliable entry point is worth keeping, and they check whether there are other vulnerable services on the same host, because lateral movement is easier than re-exploiting the same bug.

None of this is noisy, and none of it writes an obvious file, which is why the first five minutes are usually invisible.

The First Hour: Establishing Persistence

Once the attacker knows what they have, they make sure they can get back, and they do that by planting several independent footholds so that losing one does not end the intrusion.

The most common mechanism is a web shell, which is a small script that accepts commands through HTTP and executes them under the web user, and it is favoured because it survives reboots, does not need a listener, and blends into normal traffic.

They will plant more than one, in more than one directory, and they will often hide them inside legitimate files, so that deleting the obvious one does not remove the access.

Alongside the web shells, they may add a scheduled task or a cron job that re-downloads the payload if it disappears, and they may create a new low-privilege operating system user that they can log in as if the web shell is discovered.

This is the stage that makes cleanup so difficult, because the vulnerability you patched is not the persistence they installed.

The First Day: Credential and Data Theft

Once persistence is in place, the attacker turns to collection, and the target is almost always the database and the credentials that unlock the rest of the environment.

They dump the application database, which contains customer records, password hashes, order history, and private messages, and they export configuration files that contain third-party API keys, which are often more valuable than the site itself because those keys unlock cloud accounts, payment processors, and email systems.

They also read the environment for cloud metadata credentials, because a compromised web server on a cloud platform can often request temporary credentials from the instance metadata service, and those credentials can be used to move into the cloud account.

The data is then packaged and transferred out, often in small chunks over HTTPS to a legitimate looking endpoint, which is why data theft rarely shows up as a spike in network graphs.

The First Week: Escalation and Lateral Movement

If the attacker's goal is more than data theft, the next phase is escalation, and this is where the web user's limited privileges become a problem that the attacker solves with local vulnerabilities.

They look for a kernel exploit that works on this host, or a misconfigured sudo rule, or a writable service binary, and if any of those exist, they move from the web user to root or administrator.

From there, they pivot, using the credentials they stole earlier to reach the database server, the internal admin panel, the backup storage, and the CI/CD pipeline, and each hop gives them more data and more leverage.

This is the stage where a single web application compromise becomes a network wide incident, because the web server is rarely the only thing the web server can reach.

The Endgame: What the Attacker Chooses

At this point the attacker has options, and which one they choose depends on who they are and what they want.

• Ransomware is the loudest outcome, and it usually arrives after the data has already been stolen, because the encryption is the pressure and the data is the leverage.
• Site defacement is less common against businesses and more common against high profile targets, and it is often used to make a statement rather than to make money.
• Silent persistence is the outcome that costs the most in the long run, because a quiet attacker who stays for months collects far more than one who triggers an alarm.
• Use of the server for further crime is another outcome, and it is often overlooked, because a compromised host is valuable as a relay for spam, phishing, credential stuffing, and further exploitation.
• Sale of access is the final option, and it is increasingly common, because the initial attacker may not be the one who wants the data, and the access itself has a market price.

Real Two Scenarios

Scenario 1: The Patch That Came Too Late

The Setup

A small business runs a custom PHP application on a single cloud server, and the team sees the advisory for a critical remote code execution issue, and they schedule the patch for the end of the week.

The Attack

The server is scanned within hours of the disclosure going public, and the attacker exploits it the same day, and by the time the patch is applied three days later the web shells are already in place.

The Result

The patch closes the door, and the attacker is already inside, and the access survives the update, and the data theft continues for another three weeks before the outbound traffic is noticed.

The Lesson

Patching stops new exploitation and it does not remove persistence, which is why the check for compromise has to follow the patch.

Scenario 2: The Cloud Credential Cascade

The Setup

A web application runs on a cloud virtual machine, and the instance has an attached role with broad permissions because it was easier to configure that way.

The Attack

The attacker exploits the PHP vulnerability, reads the instance metadata service, and obtains temporary credentials for the attached role, and those credentials allow access to the storage bucket that holds the database backups.

The Result

The attacker does not need to escalate on the host at all, because the cloud credentials are enough, and the backups are downloaded directly from storage, and the site owner finds out when the customer data appears for sale.

The Lesson

The blast radius of a PHP vulnerability is not the server, it is everything the server can authenticate to.

How to Spot the Damage Early

Detection matters as much as prevention, and these are the signals worth watching.

• Process lineage under web workers. A PHP-FPM or Apache worker that spawns sh, bash, curl, or wget is almost always compromised, and this is the highest fidelity signal available.
• New executable files in upload and temporary directories. Attackers write tools to disk, and those files appear where the application writes, so a baseline of normal file creation makes the anomaly obvious.
• Outbound connections from the web server. A compromised host calls home, so unfamiliar destinations and uncommon ports are worth investigating, especially when they originate from the web user.
• Unexpected scheduled tasks and cron jobs. Persistence often includes a re-download mechanism, and those show up in the task scheduler and in crontab.
• New operating system users. A low privilege account created after the application was deployed is a persistence mechanism, and it is easy to miss if nobody reviews the user list.
• Database query anomalies. A sudden large export, or a query pattern that does not match the application, is a sign that the database is being drained.

Quick Reference: Exploitation Impact Checklist

The Bottom Line

When a hacker exploits a PHP vulnerability, they do not stop at the code execution, they use it as a starting point, and the sequence is consistent, reconnaissance first, then persistence, then data theft, then escalation, and finally whichever endgame fits their business model.

The version number is the door, and what happens after is the incident, and the difference between a contained event and a full breach is usually how quickly someone notices the signs.

Patch fast, then check for compromise, because the exploit is only the beginning of the story.

FAQ

What does a PHP vulnerability actually give an attacker?

It gives code execution as the web server user, which means access to the application files, the configuration, the database, and anything the application can reach on the network.

Can a PHP exploit lead to full server takeover?

Yes, if the attacker can escalate privileges using a local vulnerability or a misconfiguration, and in cloud environments they can often reach broader access without escalating on the host at all.

How quickly do attackers act after a disclosure?

Very quickly, and public proof of concept code accelerates it further, which is why the exposure window between disclosure and patching is the most dangerous period.

Does patching remove an attacker who is already inside?

No, patching closes the entry point, and persistence mechanisms such as web shells and scheduled tasks survive the update, so the check for compromise has to follow the patch.

What is the most reliable sign of exploitation?

A web server process that spawns a shell or a downloader, because legitimate PHP code almost never does that.

What should I check first after patching?

Process lineage under web workers, new executable files in upload directories, recent cron jobs and scheduled tasks, and outbound connections from the web server.