PHP vulnerabilities explained: how to check and protect your website

The Verge reports that two flaws in PHP have put a large share of websites at risk. If your site runs on PHP, find out which version you use and apply the patched release from your host or the PHP project as soon as it is available.

Key takeaways

• The Verge reports that two vulnerabilities in the PHP programming language have put large parts of the web at risk.
• By some estimates cited in the report, up to 70 percent of websites use PHP in some capacity.
• PHP underpins widely used platforms such as WordPress and Drupal, as well as Wikipedia.
• According to the report, DeviantArt and 4Chan were temporarily taken offline after the flaws came to light.
• Site owners should confirm whether they run PHP, check the version and apply official security updates promptly.

What is happening with PHP?

The Verge reports that two vulnerabilities have been found in PHP, one of the most widely used server-side programming languages on the web. A vulnerability is a flaw that an attacker may be able to exploit. Depending on the flaw, that can mean running unauthorised code, reading data that should be private or knocking a service offline.

The source does not say exactly how the two flaws work, which PHP versions they affect or which releases fix them. This guide does not fill those gaps with guesses. It explains what PHP is and why a flaw in the language itself is serious. It also sets out the steps a website owner, developer or hosting customer can take, whatever the technical details turn out to be.

The usual fault is in a plugin, a theme or one company’s code. A fault in the language is different, because it can affect every application built on top of it. That is why a flaw at this level gets so much more attention than a typical bug in a single product.

Why is PHP in the news now?

The story is getting attention because of how widely PHP is used, and because several well-known sites have already reacted. The Verge reports that some estimates put PHP’s share at up to 70 percent of websites. That figure covers sites that use PHP “in some capacity”, so it does not mean every one of those sites is equally exposed.

The report also says DeviantArt and 4Chan were temporarily shut down after the vulnerabilities emerged. Taking a site offline is a common precaution when operators are unsure whether they are exposed. It gives them time to apply fixes or investigate. The source does not say whether either site was actually compromised, and that should not be assumed.

What does a newcomer need to know about PHP?

PHP is a scripting language that mostly runs on web servers. When someone visits a page, the server runs PHP code to build that page. The code might pull articles from a database, check a login or process a form, and the visitor’s browser only receives the finished result. Visitors never see the PHP itself.

PHP is behind several major content management systems. WordPress and Drupal, both named in the report, are built on it, and so is MediaWiki, the software that runs Wikipedia. Because these systems are popular with businesses, charities, schools and individual bloggers, PHP is present on a very large number of servers. Many of their owners have never written a line of it.

A PHP installation has several layers:

• The PHP interpreter, which is the language engine itself. This is where the reported flaws sit.
• Extensions and server modules, which connect PHP to databases, web servers and other tools.
• Applications, such as WordPress or a custom-built site.
• Plugins and themes, which add features on top of those applications.

When the fault is in the interpreter, updating WordPress or a plugin will not fix it. The PHP installation itself has to be updated.

Who is affected, and how?

Exposure depends on details that the source does not give, so it is not known exactly who is vulnerable. In broad terms, these groups need to pay attention:

• People who run their own servers, such as virtual private servers or dedicated machines, are responsible for updating PHP themselves.
• Shared hosting customers usually rely on their hosting company to update PHP, although some hosts let customers choose between versions.
• Managed platform users, such as fully hosted blogging or website builders, normally have no direct access to PHP. They depend entirely on the provider.
• Developers and agencies who maintain sites for clients may need to check many separate installations.
• Visitors to websites do not have to do anything about PHP itself. A compromised site could still expose their data, though, so the usual habits apply: unique passwords and caution with unexpected messages.

Older, unsupported PHP versions are a particular worry in any situation like this. Once a version stops receiving security fixes, it may never get a patch. The only safe route then is to upgrade to a supported version, which can mean testing the whole site for compatibility first.

Where do informed people disagree?

Several questions come up whenever a widely used language has a security problem, and people working in the field often answer them differently.

How big the risk really is. A figure such as 70 percent describes how widespread PHP is, not how many sites can be exploited. Some people treat a high usage figure as a measure of danger. Others point out that real exposure depends on configuration, version and how the vulnerable feature is used. The source does not say how many sites are actually exposed.

Patch immediately or test first. Some administrators apply security updates as soon as they are released, accepting a small risk that something breaks. Others prefer to test in a staging copy of the site first, accepting a short period of exposure. The right balance depends on how critical the site is and how severe the flaw turns out to be.

Who is responsible. On shared hosting the line between the host’s job and the customer’s job is not always clear. Customers may assume the host has dealt with the problem. Hosts may expect customers to pick a supported PHP version themselves.

Whether shutting down is proportionate. Taking a site offline, as the report says some platforms did, removes the risk for a while but costs availability. Some operators prefer temporary mitigations, such as filtering suspicious requests, so they can stay online while they wait for a fix.

What should you do now?

These steps apply whatever the technical details of the flaws turn out to be.

1. Confirm whether you use PHP. If your site runs on WordPress, Drupal, MediaWiki or a similar system, the answer is almost certainly yes. If you are unsure, ask your developer or hosting provider.
2. Find your PHP version. On a server you control, run php -v from the command line. Bear in mind that the command-line version can differ from the one the web server uses. Most hosting control panels also show the active PHP version. Some content management systems show it in a site health or status report.
3. Check official advisories. Use the PHP project’s own release announcements, your operating system’s security notices and your hosting provider’s status page. Rely on these rather than on second-hand summaries to find out which versions are affected and fixed.
4. Update PHP. On a self-managed Linux server, update through the system’s package manager or the repository you installed PHP from. Then restart the web server or PHP process so the new version is actually running. On shared hosting, select a patched version in the control panel or contact support.
5. Move off unsupported versions. If your PHP version no longer receives security updates, plan an upgrade. Test the site on a staging copy first where you can.
6. Update the rest of the stack. This will not fix an interpreter flaw. Still, bringing your content management system, plugins and themes up to date reduces your overall risk while attention is on security.
7. Watch for signs of compromise. Look for unfamiliar files, new administrator accounts, unexpected changes to pages or odd entries in server logs. Make sure you have a recent backup stored separately from the server.
8. Consider temporary protections. A web application firewall, whether from your host or a third-party service, may block known attack patterns while you wait for a patch. It does not replace one.

What should you watch for next?

Several details are not yet known from the source. These include the precise nature of the two vulnerabilities, the affected version ranges, whether attackers are actively exploiting them and whether any data has been taken. Watch for official advisories from the PHP project and from operating system vendors. These usually list fixed versions and sometimes temporary workarounds.

Hosting providers often publish status updates explaining whether they have patched their servers. Large platforms may also publish incident reports explaining why they went offline and what they found. Security researchers sometimes release technical write-ups after fixes are widely available, which can show how serious the flaws really were.

Frequently asked questions

How do I know if my website uses PHP?

If your site runs on WordPress, Drupal, MediaWiki or many other popular content management systems, it uses PHP. You can also check your hosting control panel, which usually shows the active PHP version. If someone else built or manages your site, ask them or your hosting provider directly. A professional should be able to confirm this quickly.

How do I check which PHP version I am running?

On a server you control, type php -v at the command line. The web server may use a different version from the command line, so it is worth checking both. Shared hosting control panels usually show the PHP version in a settings or software section. Some content management systems, including WordPress, show it in a built-in site health or status page.

Does updating WordPress fix the PHP vulnerabilities?

No. Updating WordPress, plugins or themes changes the application, not the PHP interpreter it runs on. The reported flaws are in PHP itself, so PHP has to be updated to a patched version. Keeping WordPress and its add-ons current is still good practice and lowers overall risk, but it will not fix a flaw at the language level.

I use shared hosting. Do I need to do anything?

Probably, at least to check. Many hosts update PHP for their customers, but some let each customer choose a version and leave older ones available. Look at your control panel and pick a supported, patched version if you have the option. Check your host’s status page or contact support to confirm they have dealt with the vulnerabilities.

Are visitors to PHP websites in danger?

The vulnerabilities affect the servers that run websites, not the devices of people visiting them. Visitors do not need to update anything for this issue. If a site were compromised, though, data stored on it, such as account details, could be at risk. Using unique passwords for each site and treating unexpected emails with caution remain sensible precautions.

Which PHP versions are affected by the vulnerabilities?

The source material does not say which PHP versions are affected or which releases contain fixes, so this guide cannot answer reliably. For accurate information, check the official PHP project’s release announcements, your operating system vendor’s security notices and your hosting provider’s updates. Do not rely on unofficial summaries that may be incomplete or out of date.

Sources and further reading

• The Verge: the technology news report describing the two PHP vulnerabilities and their effect on websites.
• The PHP project: official release announcements and security information for the language.
• Operating system vendors: security advisories for the PHP packages included in Linux distributions.
• Hosting providers: status pages and support notices explaining how they are handling PHP updates.

Surfaced from the rss:verge signal “PHP security vulnerabilities”. AI-assisted draft, editorially reviewed.