Critical CVE Vulnerability in PHP and GitLab: What It Means and What Measures Have Romanian Website Admins Taken

On October 21, 2026, IT teams around the world had a busy day. The PHP project released fixes for two critical vulnerabilities, dubbed “PHP2Shell,” and GitLab released an emergency patch for a vulnerability with a maximum score. Each CVE vulnerability in this wave has a critical score. PHP vulnerabilities are so important because they affect the language that runs behind a large part of the internet, from blogs and online stores to government portals.

In Romania, the National Cyber ​​Security Directorate (DNSC) issued separate alerts for PHP and GitLab.

In this article, we explain what a CVE vulnerability means and how to read the CVSS score, what these vulnerabilities do specifically, what consequences they had in the first days, and what steps you need to follow if you manage a server, a website, or a GitLab instance.

What Is a CVE Vulnerability and What Does the CVSS Score Show?

A CVE vulnerability is a publicly known security breach that has been given a unique identifier in the Common Vulnerabilities and Exposures catalog. The format is simple: the year and a sequence number, for example CVE-2026-109618. This way, manufacturers, agencies, and security teams talk about the same problem without confusion.

The CVSS (Common Vulnerability Scoring System) measures the severity of a vulnerability on a scale of 0 to 10. Scores between 9.0 and 10.0 are considered critical. The calculation takes into account the attack method, the need for an account or victim interaction, and the impact on the confidentiality, integrity, and availability of data.

Version 3.1 of the standard and version 4.0, released in November 2023, do not give directly comparable scores. CVSS v4.0 adds, among other things, a metric for the conditions necessary for the attack and separately assesses the impact on connected systems. Basically, a 9.2 in v4.0 and a 10.0 in v3.1 send the same message: update now.

Critical PHP Vulnerability: What Is PHP2Shell

The two flaws, CVE-2026-109618 and CVE-2026-109619, are collectively known as “PHP2Shell.” Both could allow an unauthenticated attacker to execute code on the server, i.e. take control of it. Each PHP vulnerability in this pair is in the language core, not in a specific application or plugin.

In short:

• CVE-2026-109618, Out of Memory (OOM) corruption. When PHP runs out of memory, processing stops abruptly, and some internal request data remains only half-initialized. When cleaned up, PHP treats them as valid, and the attacker can exploit this confusion.
• CVE-2026-109619, residual global state. Some internal data survives after its memory has been freed. A subsequent request, processed by the same worker, can use it before it is reset, a classic use-after-free issue.

Any PHP installation that serves web requests is at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. The PHP team considers mod_php to be the most vulnerable because the demonstrated exploit works before any lines of application code are executed. Therefore, the site’s authentication system does not stop the attack.

The fixes were released on October 21, at 14:00 UTC, in versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Versions 8.1 and older no longer receive official updates. However, for 7.4, 8.0, and 8.1, the PHP team has released minimal patches to the source code.

The scale is huge. PHP runs on nearly 70% of websites with a known server-side language, including behind WordPress. Palo Alto Networks has identified over 22.6 million potentially vulnerable instances exposed online; this figure does not represent unique sites or confirmed vulnerabilities. The vulnerabilities were discovered using artificial intelligence.

On October 23, the PHP team announced yet another code execution issue, CVE-2026-115560, that was not fixed by the October 21 updates. This only occurs in a rare combination of configuration and code, and it is recommended that the session.upload_progress function be disabled until the next release.

GitLab CVE-2026-110264: A CVE Vulnerability with a Maximum Score

Also on October 21, GitLab released a critical patch for 12 vulnerabilities in the Community (CE) and Enterprise (EE) editions. The most severe, CVE-2026-110264, received the maximum score of 10.0 in CVSS v3.1.

The issue is an integer overflow that occurred when compiling a specially crafted regular expression. It could allow an unauthenticated user to execute arbitrary code on the GitLab server. The CVSS vector explains the score: network attack, low complexity, no account, no interaction, and with an impact that exceeds the vulnerable component.

All versions from 7.0 up to the patched versions: 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 and 19.5.1 are affected. GitLab.com is already running the patched version, and GitLab Dedicated customers do not need to do anything. This is only for those who host their own GitLab (self-managed installations).

Why is this so important? A GitLab server holds source code, CI/CD pipelines, and often secrets like API keys or deployment credentials. Compromising it can open the way to the entire infrastructure and even customers, through an attack on the software delivery chain.

At the time of release, there was no public exploit or confirmed attack. However, the precedent is worrying: on October 12, GitLab had patched CVE-2026-97229, a similar flaw in the CI/CD regular expression compiler, also with a score of 10.0. A public exploit for this appeared within a few days. GitLab also published two detection rules, which track crashes in the Onigmo regular expression engine and bursts of errors when rendering Org mode files.

What Were the Consequences of the Vulnerabilities

PHP2Shell went from warning to actual attack attempts very quickly. Amazon detected a first exploit attempt on October 17, four days before the public announcement. After the patches were published, exploits appeared within hours, and Amazon now describes large-scale exploit attempts.

The reaction of the authorities was swift. Cybersecurity agencies in the US, UK, EU, Canada, Australia and Japan called for immediate updates of important websites. The FBI and NSA even recommended taking offline systems that cannot be updated quickly. Websites in Finland, the Netherlands, Belgium and France were shut down or partially functional, and in Japan, Nomura and Mitsubishi UFJ temporarily suspended some online services.

What Romanian Website Administrators Did

DNSC warned that “any PHP server that is not updated and exposed to the Internet should be considered at high risk of compromise”. According to Observator News, the directorate notified approximately 16,000 entities. In the first days, administrators in several areas chose between quick updates and preventive shutdown:

1. Public administration. The Romanian Police website and the pages of the county inspectorates were temporarily unavailable for maintenance and security updates. The City Hall of Sector 4 temporarily suspended its electronic platforms, and the Tulcea City Hall restricted access to the portal to protect citizens’ data.
2. Education. The Babeș-Bolyai University in Cluj-Napoca and the West University in Timișoara have preventively suspended certain online services and applications.
3. Energy. A large natural gas supplier has preventively closed its website for security updates.
4. Online sales. A cinema ticket sales website has been temporarily closed for urgent security updates.
5. Hosting. cyber_Folks has applied the fixes to all PHP versions on its servers, without any action from shared hosting customers. However, unmanaged VPS customers are responsible for the update themselves.
6. Software development. Zitec activated WAF rules before the official patches and rebuilt project images within 15 minutes of publishing the corrected versions. The company had not reported any confirmed attacks at the time of the press release.

However, the remediation is progressing unevenly. An analysis by ValidSoftware, published on October 26, shows that most public institutions that display a patchable PHP version have updated it. In a sample of private .ro sites, less than half were updated. In addition, a “not insignificant” number of institutions are still running PHP 8.1 or older, without official support.

An important detail for site owners: updating your theme or plugins does not fix a PHP vulnerability in the language core. PHP itself must be updated, either by you or your hosting provider. For visitors, the available information does not indicate that simply accessing an affected site would infect their device.

How to Respond to a Critical CVE Vulnerability: Concrete Steps for Site Administrators

• Take inventory. Identify all servers, containers, and third-party applications running PHP or GitLab, including devices that have PHP embedded. Check the version with php -v, as well as the one actually used by PHP-FPM or Apache.
• Update immediately. PHP should be brought to 8.5.12, 8.4.27, 8.3.36, 8.2.35, or to the patched packages of your distribution. GitLab self-managed should be brought to one of the patched versions. After the update, restart all PHP-FPM workers.
• Prioritize systems exposed to the internet. If you can’t update them immediately, isolate them from the public network until the patch is applied.
• Use temporary measures only as a failover solution. For PHP, set session.upload_progress.enabled=0 in php.ini or the FPM pool, not via ini_set() or .user.ini, then restart the workers. For PHP 8.5, add fatal_error_backtraces=0. The PHP team emphasizes that only an upgrade will completely resolve the issue.
• Look for signs of compromise starting October 17. Analyze web server and application logs, processes, files, new accounts, and unusual outbound connections. For GitLab, use the detection rules published by the vendor.
• Plan for upgrades. The GitLab upgrade includes database migrations, so single-node instances will experience an outage during the upgrade. PHP 8.2 will no longer receive security patches after December 31, 2026, and 8.1 and older versions are no longer receiving them.

Organizations with clear inventory, upgrade procedures, and active monitoring responded the same day. The lesson is also valid for developers: a secure application depends on server configuration, dependencies, and updates, not just on the code written.

At NewTech Academy, we train software development and cybersecurity specialists on real-world scenarios like this. If you want to learn how to prevent, detect, and respond to incidents, discover the IT and Cybersecurity Course.

Conclusion: Security Is Learned, Not Improvised

October’s incidents show how much the window between announcement and attack has shortened. PHP2Shell shows that a critical CVE vulnerability can be exploited even before the patch. Amazon notes that AI-assisted analysis is increasingly turning a patch into a working exploit, so response times are now measured in hours, not weeks.

Frequently Asked Questions About This CVE Vulnerability