The Most Secure Way to Build a Website: Languages and Stacks Compared

As of 23 October 2026, the PHP project has fixed PHP2Shell, and in the same week Node.js and Ruby both shipped their own security releases. That is the short answer to "which language is most secure for a website?": every major web runtime ships security fixes, and no stack is patch-free. The more useful questions are how much code your site exposes to the internet, whether that code runs on a supported version, and who applies the fixes.

PHP2Shell has led some business owners to ask whether they should leave PHP. The flaw was a memory-safety bug in the C code of the PHP engine, not a mistake in the PHP code that websites are written in. Python and Ruby, whose runtimes are also implemented largely in C, fixed their own use-after-free bugs this year. JavaScript sites had React2Shell, a 10.0-rated flaw in React Server Components.

This guide compares languages and stacks using the projects' own security pages, government memory-safety guidance and what each architecture puts on the public internet. It doesn't crown a winner, because the evidence doesn't support one.

What PHP2Shell Tells You About Languages

PHP2Shell is two flaws, CVE-2026-109618 and CVE-2026-109619, in the PHP engine. PHP's advisories classify both as CWE-416, "use after free," a memory-safety bug class. The PHP engine is written mainly in C, according to its GitHub repository. The fix was a new PHP build plus a restart, not changes to WordPress, Drupal or any site's own code. Our explainer on what PHP2Shell is covers the details, and the fixed versions list shows which builds to install.

So the lesson isn't "PHP code is unsafe." It is that every interpreted language rests on a runtime, and runtimes are large programs that need patching. Python and Ruby show the same pattern: their 2026 memory-safety fixes were in C-implemented code underneath the language.

Every Runtime Patches: The Past Year in One Table

Here are recent security fixes from each project's own announcements. These are examples, not a full list, and severity labels are the projects' own. Python's advisory records carry no severity score, so none is given.

Two points stand out. First, the Ruby fixes only affect apps that compile attacker-controlled regular expressions, and Ruby notes that "Regexp.timeout does not protect against these bugs." Scope details like this matter more than the headline. Second, React2Shell is in CISA's Known Exploited Vulnerabilities catalog, added on 5 December 2025. As of the catalog released on 23 October 2026, PHP2Shell is not. A JavaScript stack is not a shelter from exploited flaws.

What the Memory-Safety Guidance Actually Says

CISA, the NSA, the FBI and international partners published The Case for Memory Safe Roadmaps in December 2023. It says "memory safety vulnerabilities are the most prevalent type of disclosed software vulnerability," names C and C++ as "examples of memory unsafe programming languages," and lists C#, Go, Java, Python, Rust and Swift as memory safe. PHP doesn't appear in the document at all.

The same roadmap is careful about what that list means. Memory safe languages "will almost certainly need to rely on libraries written in languages such as C and C++," and "most developers will need to work in a hybrid model." Python and Ruby are good examples: the use-after-free fixes in the table above were in parts of their runtimes and libraries written in C. The roadmap also says "No one MSL is right for all programming needs," and it is aimed at software manufacturers planning long-term changes, not at a business choosing a website stack.

Our article on whether AI hacking will kill WordPress looks at the same guidance from the WordPress side. The takeaway for a website owner: language choice matters to the people who write runtimes and libraries. For you, the runtime's support status and patch path matter more.

Support Windows Matter More Than the Language Name

Every language project stops fixing old versions. Once a branch reaches end of life (EOL), new flaws in it go unfixed by the project. Node.js puts it bluntly: "End-of-Life versions are always affected when a security release occurs."

An unmaintained Node or Python site on an EOL version is in the same position as a PHP 7.4 site: the project has moved on. For PHP2Shell, the PHP project made an exception and published source-only backports for 7.4, 8.0 and 8.1, but it released no official builds for them. Our guide to upgrading old PHP safely covers that path.

Attack Surface Beats Language

Attack surface is everything on your site an attacker can reach: pages that run code, forms, logins, APIs, admin panels and file uploads. OWASP's attack surface cheat sheet advises reducing it "by simplifying the model," "not storing confidential data that you don't absolutely have to" and "turning off features and interfaces that aren't being used." It also warns that attack surface "will increase over time as you add more interfaces and user types and integrate with other systems."

The Five Eyes cyber agencies made the same point in June 2026: "Challenge whether systems need to be exposed at all and isolate those that do not." For a website, that translates into practical questions that have nothing to do with the language name:

• Does every page need code running on a server at request time, or could most pages be prebuilt files?
• Is the admin panel reachable by anyone on the internet?
• How many plugins, packages or modules does the site load, and who updates them?
• Are forms and file uploads limited to what the business actually needs?

Third-party code is part of the surface on every stack. A Node.js app pulls in npm packages; a WordPress site pulls in plugins. OWASP's 2025 Top 10 lists "Software Supply Chain Failures" as its own category. Our guide to plugin, app and package supply chain security covers that risk.

Stack Options Compared

Here is how the common ways to build a business website compare on the questions above. "Who patches the runtime" is the PHP2Shell question: who had to install the fix.

Our guides on static versus dynamic website security and the most secure website platforms go deeper on the first five rows, and our headless and custom website security guide covers dependencies, secrets and API routes.

Managed Runtimes: Who Patches the Language for You

Cloud providers showed during PHP2Shell that "who patches" depends on how you deploy, even with the same language. Their own notices, as of 22 and 23 October 2026:

• Google Cloud. App Engine standard (PHP 8.2 and newer) apps "are updated automatically." App Engine flexible apps "are not updated automatically," so customers must redeploy. Google adds: "Container images you build yourself are your responsibility."
• AWS. Elastic Beanstalk customers "with Managed Platform Updates enabled will receive the update automatically during their next maintenance window." Lightsail instances can't be updated in place; customers create new instances from updated blueprints.
• Microsoft Azure. App Service on Linux rolled out patched built-in PHP images, but "If you run PHP in a custom container, or bring your own PHP runtime, App Service does not patch it."

The same split applies to Node.js, Python and Ruby on those platforms. A built-in, provider-managed runtime gets patched for you. A container you built yourself has to be rebuilt and redeployed by you, whatever language is inside it.

Questions to Ask Before You Choose a Stack

1. Who will apply runtime, framework and plugin updates, and how quickly after a critical release?
2. Is the runtime version on a supported branch, and when does that support end?
3. How much of the site has to run code on a public server? Could more of it be prebuilt?
4. Is the admin or content backend exposed to the whole internet, or limited?
5. How many third-party packages or plugins will it depend on, and who reviews them?
6. If you use a cloud platform, are you on its managed runtime or your own container?
7. What does the vendor's shared responsibility page say stays with you?

If a developer answers these well, the language they prefer is a reasonable choice. If nobody can answer the first question, no language will make the site safe.

Conclusion

As of 23 October 2026, PHP, Node.js, Python, Ruby and React have all shipped serious security fixes within the past year, and PHP2Shell was a memory bug in the C engine beneath PHP, not a flaw in the websites built on it. The most secure way to build a website is the stack with the smallest public attack surface you can live with, a supported runtime version and a named owner who applies fixes quickly. If you run PHP today, patch it and restart it first; our emergency PHP patching team can help, and stack changes can be planned afterward. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions