PHP vulnerabilities give regulators new grounds for decrying “insecure” foreign hosting. We examine what’s already in place, what could change, and what our measurements have revealed.

Websites go offline because of PHP

On October 20, 2026, the PHP team announced an emergency release to fix two critical vulnerabilities with a CVSS v4.0 score of 9.2. The team advanced the release by a day. According to BleepingComputer, details of the vulnerabilities had leaked through a Hacker News post. On October 21, at about 14:00 UTC, PHP released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The vulnerabilities, CVE-2026-109618 and CVE-2026-109619, received the collective name PHP2Shell (from PHP to shell: through a flaw in PHP, an attacker gets a command shell on the server). They allow unauthenticated remote code execution on the server. Wiz researchers demonstrated exploitation on default WordPress, Drupal and Joomla images.

Exploitation attempts began before the patches came out. Cloudflare blocked them with its WAF starting at 03:02 UTC on October 21.

On October 22, the National Coordination Centre for Computer Incidents (NKTsKI, which operates under the FSB, Russia’s Federal Security Service) sent a letter through GosSOPKA (the state system for detecting, preventing and responding to computer attacks) to critical information infrastructure (CII) operators. In the letter, NKTsKI instructed them to update PHP, scan their servers with antivirus software and check logs for signs of compromise. If a quick update is impossible, operators should “consider temporarily restricting external access to vulnerable web servers, up to and including shutting them down.”

By itself, this requirement is standard practice. CERT-EU (the cybersecurity service for EU institutions) recommended isolating resources that cannot be updated quickly from the public internet. The US National Security Agency recommended taking such systems offline. Government bodies in Germany, France, Belgium and the Netherlands took their websites offline. In the Netherlands, the list included the Port of Rotterdam, the websites of the five largest political parties, and several hospitals.

“Security” already served as a pretext for restrictions

Date	What happened
March 2, 2022	NKTsKI published lists of 17,576 IP addresses and 166 domains to block and advised moving DNS zones to Russian providers, citing DDoS attacks
October 24, 2024	The director of TsMU SSOP (the Centre for Monitoring and Control of the Public Communications Network, run by the Roskomnadzor-affiliated Radio Frequency Centre) announced a “security scanner” that checks the entire Runet (the Russian segment of the internet) and can block vulnerabilities at the TSPU level (TSPU: the state-installed DPI equipment on ISP networks)
December 07, 2024	RKN (Roskomnadzor, Russia’s internet and media regulator) stated that it cannot protect websites on foreign hosting from DDoS attacks and threatened to restrict eight foreign providers
February 28, 2025	RKN Order No. 51 required operators to submit the addresses of subscriber equipment linked to TSPU, officially to counter attacks (our analysis)
September 06, 2025	Connections to websites behind Cloudflare, Hetzner, DigitalOcean and others started stalling after about 16 KB of data, and Cloudflare confirmed it
March 01, 2026	Government Resolution No. 1667 on centralised management of the public communications network took effect, obliging hosting providers to follow TsMU SSOP instructions (our analysis)
August 2026	RKN moved to blocking entire hosting provider subnets (our analysis)
September 11, 2026	GRChTs (the General Radio Frequency Centre, a Roskomnadzor subsidiary) instructed operators to address a vulnerability in MikroTik routers.
October 07, 2026	At the request of TsMU SSOP, Selectel blocked the Xbox DNS account, a private DNS service.e
October 20, 2026	PHP announced an emergency fix for critical vulnerabilities
October 22, 2026	NKTsKI instructed CII operators to update PHP or restrict access to their websites

RKN used PHP2Shell for new blocks

Possible censorship scenarios

1. Blocking the subnets of more foreign hosting providers that still work from Russia, justified by the claim that “foreign hosting is unsafe.”
2. Blocking Russian servers tagged as “vulnerable” through the TsMU SSOP “security scanner,” following the pattern of the MikroTik story and the Xbox DNS case.

Blocking foreign subnets offers no protection against PHP2Shell. PHP powers 90.8% of Russian-language websites, so the Runet has more vulnerable servers inside than outside. Attackers can target them from any address, including Russian ones. Blocking subnets does not stop these attacks.

The NKTsKI letter could cut Russian websites off from the outside world

The NKTsKI letter refers to “restricting external access.” Some Russian government websites are already closed to foreign and data centre IP addresses. Before the State Duma elections, we recorded timeouts when accessing election commission websites from Europe. The National Digital Archive project also tracks which government websites are unavailable from abroad. After the NKTsKI letter, this practice will most likely spread to CII websites. Users abroad and users on VPNs will lose access to an even larger share of Russian resources.

Certain signs show that this scenario is coming true

These are the likely events that would signal the scenario is starting to play out:

• NKTsKI bulletins or new waves of subnet blocking that cite PHP2Shell;
• statements by RKN or TsMU SSOP that link PHP to foreign hosting and websites;
• GRChTs instructions to operators or TsMU SSOP instructions to hosting providers about “vulnerable” servers.

What is at risk

Nodes. Right now, VPNs on the VLESS, Shadowsocks and AmneziaWG protocols more or less work in Russia. But the protocol won’t help if the block is by IP address and the server itself is unreachable.

Subscription servers. If the subscription server’s subnet is blocked, your users won’t be able to update their configs.

The VPN service website and user dashboard. If they sit in the same subnet, users won’t be able to pay for a subscription or download instructions and configs.

The “scanner” may tag a Russian entry server in your cascaded VPN setup as “vulnerable.” The same applies to a node running a PHP decoy site (for example, WordPress used for camouflage). Such a tag gives a formal pretext for a block or for instructions to the hosting provider.

Our October 25 measurements

Our methodology

On October 25, 2026, we measured access to several foreign hosting providers.

Our nodes:

• a reference node (EU, home broadband) for comparison,
• two measurement nodes in Russia (Moscow and Saint Petersburg, in data centres of the same hosting provider),
• a measurement node in Russia (Saint Petersburg, home broadband).

From each node, we ran four tests against foreign hosting providers: ping, a TCP connection, a TLS handshake, and a transfer of about 1 MB. On our own servers and Cloudflare, we tested the transfer in both directions. On the rest, we tested downloads only. The targets were our own test servers at four hosting providers (two in Finland and two in Germany), plus public test files from OVH, Cloudflare and Vultr.

Hosting	Moscow (DC)	Saint Petersburg (DC)	Saint Petersburg (home broadband)	Reference (EU)
Hostkey, Finland, test server	TCP connects, TLS handshake never completes	TCP connects, TLS handshake never completes	TCP connects, TLS handshake never completes	works
Hetzner, Germany, test server	Works	Works	Download only; upload hangs until timeout	works
Small hosting provider, Finland, test server	works	works	works	works
Small hosting provider, Germany, test server	works	works	works	works
OVH (public file)	Download only (the service does not support upload tests)	Download only (the service does not support upload tests)	Download only (the service does not support upload tests)	works
Cloudflare (public file)	Download only (the service does not support upload tests)	Download only (the service does not support upload tests)	Download only (the service does not support upload tests)	works
Vultr, Germany (public file)	Download only (the service does not support upload tests)	Download only (the service does not support upload tests)	Download only (the service does not support upload tests)	works

Ping reached all targets from all nodes. However, the TLS handshake did not complete on every server. From home broadband in Saint Petersburg, downloads from the Hetzner server went through. Uploads did not: the server received zero bytes of data (in 3 out of 3 attempts).

Hostkey

From all three Russian nodes, a TCP connection to one of our Hostkey servers succeeded, but the TLS handshake never completed (10 out of 10 attempts). The server saw every connection and waited for the handshake to continue, then closed the connection on timeout. During the same minutes, the server worked without any issues from the reference node in the EU.

The result did not depend on the SNI (the site name the client sends at the start of the handshake). From the home node in Saint Petersburg, we tried two different names that are not blocked in Russia (nvidia.com and example.com). The result was the same.

Three short packets with no payload establish a TCP connection. Then the client sends the first TLS handshake message, and the exchange stops there. The filter lets the TCP connection through but drops the encrypted data. Since the site name made no difference, this is clearly a block by IP address.

This is no longer an isolated Hostkey case. In one of the VPN Generator “brigades” (self-managed server groups in the VPN Generator service), keys on a Hostkey server stopped working. Its users started complaining on the afternoon of October 21. Around the same time, another Hostkey server, unrelated to VPN Generator, also became unreachable from Russia regardless of protocol. Our October 25 measurements confirmed this.

Two unrelated servers at the same hosting provider stopped working at the same time. This strongly suggests that the authorities blocked some of the provider’s subnets.

The Hostkey block and its relation to PHP2Shell?

For now, there is no reason to think so. The first complaints arrived around 11:00 UTC on October 21, about three hours before PHP released the fixes. At that point, no technical details of the vulnerabilities were public (the October 20 announcement did not include them), and NKTsKI sent its letter the following day.

The Hostkey block coincided with PHP2Shell in timing. Waves of VPN blocking hit regularly throughout 2026. VPN Generator reported outages on September 4, September 21 and October 15. We laid out the timeline of earlier waves in analysis No. 37. The pattern is clear: subnets that host VPN servers get blocked in waves.

Recommendations for VPN service developers

1. Spread your nodes across different hosting providers and autonomous systems. The Hostkey case shows that a single wave of subnet blocking takes down every server inside those subnets, regardless of protocol or owner (whether it is a mass-market service or your own self-hosted family VPN).
2. Keep your subscription server separate from your nodes. Host a backup subscription URL with a different provider in a different autonomous system, and configure several URLs in the client. Then a block on one subnet won’t cut users off from config updates.
3. Test reachability from Russia with a full TLS handshake, not just TCP. With a block like the one at Hostkey, a port check with nc -zv will show the port as open, even though the server is effectively unreachable. For TLS-based protocols, the minimal check looks like this:

openssl s_client -connect your_server:port -servername your_SNI

For VLESS, you need a real client (Xray, sing-box), as we recommended in analysis No. 37. Run these checks regularly, ideally automatically, from the major mobile carriers and popular home ISPs.

4. Keep several communication channels with users that work without a VPN. Telegram does not work in Russia without a VPN, making it insufficient as a standalone channel. If you communicate with users by email, send instructions and configs to non-Russian mailboxes such as Gmail. Do not send anything at all by regular email to Yandex or Mail.ru addresses. The mail provider can read unencrypted messages and will hand over any information at any request from law enforcement. Another channel is Delta Chat, an end-to-end encrypted messenger that runs over email. It works even under allowlist mode (when only approved services are reachable), including through Russian email providers, yet only you and the user can read the conversation.
5. Make the decoy sites on your nodes static, with no PHP and no CMS. Nobody can hack static HTML through an interpreter vulnerability. This does not guarantee your node won’t be blocked, but it leaves the “scanner” nothing to latch onto formally.
6. If you run a cascaded VPN, keep only the bare essentials on the Russian entry server: no dashboards, websites or PHP services.
7. Update PHP everywhere you use it: billing, landing pages, control panels. Versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 include the fixes. For the 8.1 branch and older, you need backports from your distribution or an upgrade to a supported version.