After PHP2Shell and "Black October": 10 Web Cybersecurity Measures for SMEs

October 2026 is the month in which the acceleration of AI-driven cybersecurity problems became visible, what the Wall Street Journal and the community have called "Black October" (Source: WSJ).

• October 21: The PHP project released emergency patches for PHP2Shell (CVE-2026-109618 and CVE-2026-109619), vulnerabilities in the PHP engine that allow remote code execution. Updating WordPress or Drupal is not enough, because the problem lies in the language itself, not in the PHP applications. (Source: PHP Security Advisory)

• October 21: The Node.js ecosystem received critical updates (e.g. CVE-2026-111497 in the Brotli library) against external compromise. (Source: Node.js Security Releases)

• October: Remote exploitation of the Linux kernel IPv4/TCP vulnerability (CVE-2026-98432) through a single malicious connection became public. (Source: Red Hat)

November started the same way. On November 2, attacks on IoT refrigeration systems forced defrosting in European supermarkets, causing physical damage. (Source: BleepingComputer) and many other incidents have been reported.

So here are three organisational recommendations and seven technical measures that every SME should consider. They are only the beginning.

I. Three organisational recommendations

1. Information sources and correlation with the organisation's inventory

Monitor three sources:

• official vendor alerts (PHP, Node.js, Microsoft)
• government catalogues (CISA Known Exploited Vulnerabilities)
• specialist media (BleepingComputer, SecurityWeek).

For transparency: in the case of PHP2Shell, OPTI learned about PHP2Shell from the X.com/Twitter community about 12h before PHP published the full technical details (and 24h before the updates were released).

2. Responsibility for technical intervention

The company needs people responsible for at least three stages: Detection and assessment (prioritisation), Urgent remediation (patches, controlled suspension of services) and Investigation and recovery (isolating systems, restoring). Who can temporarily stop a service and restart it?

3. Guaranteed recovery (RTO and RPO)

Protections do not eliminate risk completely. Define your RTO (maximum acceptable downtime) and RPO (maximum acceptable amount of lost data). A simple backup does not guarantee restoration if it lacks the configurations or the people to implement it, as we detailed in the complete guide in August.

II. Seven technical measures for web infrastructure

4. Immutable backup and independent monitoring

Implement the backups and procedures described above for all essential IT processes:

• Keep backups offline or immutably protected (so that attackers cannot delete them). Include files, the database and infrastructure configurations.
• Set up alerts and keep important logs separate from the monitored systems, so you do not lose the evidence if they are compromised.

5. Multi-level audit of code and exposed routes

Audit the infrastructure, HTTP routes and APIs, not just software versions:

• Start with authentication, secrets in code, APIs and access rights.
• Block unnecessary HTTP methods (e.g. reject POST if the endpoint only needs GET).
• Use tools such as Cloudflare Security Audit Skill for assisted code analysis, then validate the results technically.

Although the risk surface shrinks, such restrictions do not replace updating vulnerable technologies (e.g. PHP+PHP2Shell or node.js+Brotli).

6. Hiding servers and IP addresses

Do not expose administrative ports publicly. Use private networks such as Tailscale for administrative access (SSH). For web applications, route traffic through a reverse proxy (e.g. Cloudflare) and configure the origin server to reject any direct connection that bypasses the proxy.

7. Configure the WAF according to your real markets

If most of your customers are from U.S.A. or a few European countries:

• Do not automatically treat all worldwide traffic the same.
• Configure the Web Application Firewall (WAF) with Managed Challenges filters for traffic from unusual or high-risk regions.
• Adapt the rules to your business model so you do not block B2B integrations or legitimate customers from abroad.

8. Rate limiting against automation

A modern WAF also lets you limit the number of requests within a time interval:

• Rate limiting on login forms and APIs to stop brute-force attacks
• Set thresholds based on real traffic. Several legitimate users may share the same IP (e.g. large companies)
• Test the filters and monitor false positives.

9. Mandatory MFA and Least Privilege

Measures that can be applied to almost any application:

• Enable Multi-Factor Authentication (MFA, via SMS or, less recommended, email) for all administrative accounts.
• Apply least privilege: each user gets only the access that is strictly necessary.
• Monitor application behaviour (e.g. mass data exports) to block data exfiltration if an account is compromised.

10. Check the weakest links: shared hosting, cPanel and WordPress

Do not assume that the hosting company or the external agency is responsible unless you have guarantees to that effect. You can check:

• cPanel/WHM: cPHulk to limit repeated login attempts, MFA, IP restrictions for administration (requires the provider).
• WordPress: updating the WordPress core, plugins and themes (which should be kept to a minimum or removed, as they create a dependency on whoever built them).
• Email: MFA for Webmail access, when available. Note: on cPanel this does not automatically mean MFA for IMAP/SMTP.
• WAF: even on shared hosting, Cloudflare can add HTTP/HTTPS protection, including on the free plan (without protecting email, SSH or other interfaces that bypass it).

Conclusion: Security will mean the capacity to react

The vulnerabilities of October 2026 show that attacks hit programming languages, hardware and operating systems at the same time.

You cannot anticipate everything and you cannot have 100% guarantees, but you can build a system in which exposure decreases and business recovery is tested and guaranteed.