This edition focuses on three vulnerabilities that land straight on the MSP’s desk. A critical PHP vulnerability (PHP2Shell) is being widely scanned and affects virtually every web hosting environment, an SQL injection flaw in Arista VeloCloud Orchestrator is being actively exploited, and GitLab has fixed a flaw with the maximum score of 10.0 that affects twelve years of releases.
- PHP2Shell: two critical PHP flaws give attackers code execution without logging in, with scanning already under way
- Arista warns of actively exploited SQL injection in VeloCloud Orchestrator
- GitLab fixes critical CVSS 10.0 flaw affecting self-managed installations going back twelve years
PHP2Shell: two critical PHP flaws give attackers code execution without logging in, with scanning already under way
| Vulnerability | Two flaws in the memory management and error handling of PHP itself, allowing an attacker to run code on the server without authentication. According to The Hacker News, all releases in the 7.x and 8.x series are affected |
| CVE number | CVE-2026-109618 and CVE-2026-109619 |
| CVSS score | 9.2 (both) |
| Actively exploited | Yes, according to The Hacker News. Amazon spotted the first attempt on 17 October 2026, with the first attacks using the leaked proof of concept on 21 October. Not all sources confirm successful exploitation |
| Patch available | Yes, since 21 October 2026: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (according to secondary sources; check php.net). No fix is available for end-of-life branches |
How can the vulnerability be exploited?
Both flaws sit in code that almost every request touches, and according to The Hacker News, the PHP Foundation describes them as difficult to fix without breaking compatibility. They were discovered by researchers at Calif, OpenAI and Wiz. Details and a proof of concept leaked ahead of the planned release, prompting the PHP Foundation to bring the release forward by a day. Amazon saw a first attempt as early as 17 October and the first attacks using the leaked code on 21 October, with multiple attackers appearing to be active. Pantheon blocked more than 60,000 suspicious requests on 21 October, and Cloudflare is seeing attackers modify their payloads to evade filters. Fake PoCs containing malware are also circulating on GitHub. According to Dutch IT Channel, several Dutch websites, including those of the Dutch House of Representatives and the Dutch NCSC, were taken offline as a precaution.
What could the consequences be?
A successful attack gives direct access to the web server’s file system and database. Detection is difficult: according to CrowdStrike, the workers remain stable, responses return HTTP 200 and the application log stays empty. The only trace is a single memory-limit error in the web server’s error log, which is often dismissed as noise. VulnCheck counts more than 2.6 million internet-facing hosts running PHP, a large proportion of which run on outdated branches.
What should IT administrators do now?
Update PHP to the patched version for your branch, or install the packages from your hosting provider (CloudLinux, for example, has released fixes for ea-php52 through ea-php85). If you host customers on end-of-life versions, migrating is the only real solution; in the meantime, deploy WAF rules, such as those from Cloudflare or AWS. Search error logs for memory-limit errors and check whether PHP processes are unexpectedly launching shells or downloading files, as the FBI advises. Do not trust PoCs from GitHub without checking them.
Arista warns of actively exploited SQL injection in VeloCloud Orchestrator
| Vulnerability | SQL injection in Arista VeloCloud Orchestrator (VCO), the central management platform for VeloCloud SD-WAN. On-premises releases prior to 5.2.3.18, 6.1.3.10 and 6.4.2.12 are affected |
| CVE number | CVE-2026-114625 |
| CVSS score | 9.9 |
| Actively exploited | Yes, confirmed by Arista in its advisory of 22 October 2026 |
| Patch available | Yes: VCO 5.2.3.18, 6.1.3.10 and 6.4.2.12. Hosted and Dedicated orchestrators have already been patched |
How has this been exploited?
According to The Hacker News, an attacker needs network access to the VCO web interface and a valid login, although the lowest customer role (Enterprise Read Only) is sufficient. This can be used to gain superuser access to the orchestrator. The interface is exposed by default and there is no setting to prevent this. Arista has not disclosed when the attacks began or what the attackers did afterwards.
What could the consequences be?
Full control over the orchestrator and the data it holds. This is already the third VCO flaw that Arista has reported as exploited since the end of July. With the previous two, Arista warned that a compromised orchestrator could provide access to VeloCloud Edge devices. The advisory does not say whether this also applies here. Orchestrators running releases that fixed the earlier flaws are still vulnerable.
What should IT administrators do now?
Upgrade on-premises environments to the patched release and, in the meantime, restrict access to the web interface to trusted management networks. Block the IP addresses 74.82.197[.]86 and 38.54.50[.]151 and search for them in the logs. Look out for web shells, backdoors, unexpected outbound traffic and recent changes made by administrators. If you suspect a compromise, preserve the logs and timestamps first. If you are running an older, unsupported release, contact Arista TAC.
GitLab fixes critical CVSS 10.0 flaw affecting self-managed installations going back twelve years
| Vulnerability | Integer overflow when compiling a specially crafted regular expression in Onigmo, the Ruby regex engine bundled with GitLab. Enables unauthenticated code execution on self-managed GitLab servers, in all releases from 7.0 onwards |
| CVE number | CVE-2026-110264 |
| CVSS score | 10.0 |
| Actively exploited | No, GitLab has seen no indications of attacks and the flaw was not listed in the CISA KEV catalogue as of 22 October 2026 |
| Patch available | Yes, since 21 October 2026: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13. No workaround |
How can the vulnerability be exploited?
According to The Hacker News, an attacker without an account can cause a specially crafted regex to be compiled, after which the integer overflow enables code execution. GitLab has not said under what conditions this works. The flaw was reported by a researcher going by the name ‘joaxcar’, who has reported four code execution flaws in the same regex engine within a single month. Earlier fixes, such as the one from 12 October, only covered version 19.2 and later, so even updated instances may be vulnerable.
What could the consequences be?
A GitLab server holds source code, CI/CD secrets and access to production environments, so a takeover is a stepping stone to customer environments. GitLab.com and GitLab Dedicated are already covered; the risk lies with self-managed installations, which MSPs often run for themselves or for customers.
What should IT administrators do now?
Upgrade to the patched release for your branch. There is no workaround. On a single-node server, 19.4.3 and 19.3.6 cause downtime due to database changes; for multi-node set-ups, you can follow the zero-downtime procedure. GitLab has published two Sigma rules (‘Onigmo native worker crash’ and ‘Org mode render error burst’) for searching the application logs. The same release fixes ten other vulnerabilities, including an account takeover and a cache poisoning flaw in OAuth/OpenID Connect.
This article was originally published in Dutch on MSP Business. Read the original →
