GitLab's second maximum-severity RCE this month: patch again, even if you patched Oct 12
GitLab released critical patches on October 21 for CVE-2026-110264, an integer overflow in its regular-expression compiler that GitLab says could allow an unauthenticated user to execute arbitrary code on a self-managed server under certain conditions. GitLab rates it CVSS 10.0, the maximum. Every self-managed release back to GitLab 7.0, from 2014, is in range. Fixed versions are 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13. The trap: the October 12 patch for the earlier regex flaw CVE-2026-97229 shipped as 19.4.2, 19.3.5 and 19.2.8, one patch below the new fixes, so a server patched nine days ago is still exposed. GitLab.com already runs the fix, and GitLab Dedicated tenants on the stated internal releases are covered, so the exposure is self-managed instances. GitLab reports no sign the flaw has been used in attacks, and it is not in CISA's Known Exploited Vulnerabilities catalog as of October 22. Reporting points to GitLab's Org-mode file renderer as the likely path, with a crafted file in a public project as the trigger, but GitLab has held back the precise conditions while operators patch.
Fortinet ships critical FortiOS patches now and withholds the details for three weeks
Fortinet shipped security updates on October 22 for FortiOS, FortiManager and FortiAnalyzer fixing critical and high-severity flaws found through AI-assisted testing, and told customers to install them before it reveals the flaws. FortiOS fixed versions are 8.0.2, 7.6.8, 7.4.13 and 7.2.14; FortiManager and FortiAnalyzer are fixed in 8.0.2, 7.6.8, 7.4.12 and 7.2.13; FortiMail fixes arrived a day earlier in 8.0.2, 7.6.7 and 7.4.9, and FortiAuthenticator in 8.0.4 and 6.6.11. No CVE identifiers or CVSS scores have been published for the October 22 flaws, and full advisories are due on Fortinet's PSIRT portal on November 10. Fortinet CISO Carl Windsor said the window between disclosure and exploitation keeps shrinking, and that patch diffing lets attackers build exploits in hours or days, which is why the company chose early patching over full disclosure. Critics, including watchTowr, warn the three-week gap gives attackers a playground to reverse-engineer the fixes. As of October 23, neither Fortinet nor the national CERTs checked in the reporting reviewed here reports exploitation of these flaws.
PHP2Shell, day three: Luxembourg's regulator joins the patch call as sites stay offline
Luxembourg's data protection commission, the CNPD, warned on October 23 that the PHP flaws CVE-2026-109618 and CVE-2026-109619 still put internet-facing systems at risk, urging controllers and processors to check exposure and apply the October 21 patches, 8.5.12, 8.4.27, 8.3.36 and 8.2.35, without delay. The warning matters because it reframes patching as a data-protection duty, not just an IT task: unpatched PHP risks the confidentiality, integrity and availability of personal data processed on those systems. If your PHP fleet is not fully patched and restarted by now, treat it as overdue, not in progress, and re-check that restarts actually happened, since a patched binary that was never restarted is still a vulnerable process.