Recent Security Bugs and the Pace of AI Attacks
Several urgent security warnings arriving together can make it feel as though something has changed overnight. There is another update to install, another service to investigate, and another post suggesting that AI is making the whole situation move faster.
The reports from October 21, 2026, deserve that attention. GitLab and Node.js published serious vulnerability fixes, while Microsoft described attackers using AI agents against organizations around the world. Taken together, they show AI contributing to vulnerability discovery and helping attackers carry out operations. The details matter, because those are different developments with different consequences.
What concerns me most is the time available to respond. Finding a dangerous bug helps everyone who can install the fix. An organization that takes days to identify its affected systems may still be exposed while it works out where to start.
GitLab’s critical fix
GitLab’s critical advisory concerns CVE-2026-110264, an integer overflow in its regular expression compiler. Under certain conditions, someone without an account could cause the GitLab server to execute arbitrary code. GitLab assigned it a CVSS severity score of 10.0 and identified affected releases going back to version 7.0. Its advisory credits the researcher joaxcar through the HackerOne bug bounty program; it does not establish that AI discovered the flaw. GitLab’s critical patch announcement.
For self-managed GitLab, the fixed releases announced were 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, and 18.11.13. Follow GitLab’s upgrade path for your installation. GitLab said its managed infrastructure, including GitLab.com and GitLab Dedicated, was already patched, and supplied two detections to help self-managed customers investigate exploitation attempts. GitLab’s affected versions and detection guidance.
The long affected history is a reminder that old software can contain flaws that have not yet been identified. Age alone cannot tell you whether a component has been examined closely enough, or whether a newly discovered way of reaching it changes its risk.
Node.js and the Brotli decoder
Node.js’s October 21 release addressed CVE-2026-111497, a high-severity flaw in its Brotli decoder that can permit remote code execution. Brotli is a compression format; decoding restores the compressed data. The bug affects the 22.x, 24.x, and 26.x release lines. The Node.js project explicitly credits OpenAI Codex Security, naming Khai Tran and Sylvie Mayer, for reporting it. That gives this disclosure a documented connection to AI security research, although the acknowledgement alone does not tell us which parts of the investigation were automated. Node.js’s security release.
The first patched releases in those lines were:
| Node.js release line | Patched version |
|---|---|
| 22.x | 22.23.4 |
| 24.x | 24.22.1 |
| 26.x | 26.12.1 |
Use these versions or a later patched release in the appropriate supported line. Older, end-of-life lines require a move to a supported release. The same release addressed other security issues, including TLS hostname verification bypasses. Node.js’s release details.
Exposure depends on an application or its libraries decoding Brotli data controlled by an attacker. That can happen through incoming requests or responses fetched from another server. Vercel said it deployed automatic web application firewall rules for all projects and was rolling out patched managed runtimes. Its firewall covers traffic through Vercel’s network; it does not inspect the responses a function fetches elsewhere. The runtime still needs the fix. Vercel also advised customers to update Node.js in environments they operate, including external backends, containers, and CI runners. Vercel’s Node.js advisory.
That distinction is easy to lose in a reassuring social post. A protection can be useful while covering only part of the route by which dangerous input reaches an application. When a provider announces a mitigation, the useful next step is to check its scope and the remaining upgrade instructions.
Microsoft’s ARTEX campaign
Microsoft said Storm-0940, a China-state-aligned actor, used ARTEX, an AI penetration testing framework, to target hundreds of organizations. In multiple cases, privileged cloud access followed initial targeting by less than three hours. Most targeting failed. Microsoft’s ARTEX investigation.
Microsoft assessed that the actor was responsible for the ConnectWise supply chain compromise. It described abuse of previously authorized applications without interactive sign-in, followed by credential changes and attempted privilege changes. The activity did not exploit a Microsoft product vulnerability, it said, and successful authentication alone did not establish data theft. Microsoft’s findings and investigation guidance.
Those three hours measure targeting to access in this campaign. They do not establish how quickly either newly disclosed vulnerability could be exploited. The report does not connect the campaign to either flaw.
What one day can and cannot show
My reading is that these reports expose pressure at several points in the security process. Researchers can find another serious flaw in software people already depend on. Operators then need to find the affected copies, test an update, and deploy it. Attackers may use automation to pursue opportunities while that work is underway. The cost of delays between those steps deserves as much attention as the number of new advisories.
A single crowded day cannot establish a long-term increase in severe vulnerabilities or demonstrate an AI takeoff. To support that claim, we would need evidence across time: comparable discovery rates, the role AI played, how much human work remained, and whether attacks became more successful. These examples do establish that AI belongs in the discussion of both discovery and attacks.
What I would check
For someone responsible for an application or business, I would turn that concern into a few concrete checks:
- Know where the software runs. Keep an inventory that includes production services, container images, build systems, and the person responsible for each. An advisory is easier to act on when it can be matched to a running system.
- Verify the deployed fix. Updating a dependency or base image is one step. Rebuild and redeploy the affected application, then confirm the version actually running.
- Review application access. Include connected services in access reviews. Microsoft’s ConnectWise guidance calls for checking service principal sign-ins and unexpected credential or privilege changes, while preserving evidence. Microsoft’s response guidance.
- Use AI review with evidence. Ask what code was examined, how a finding was validated, and what remains uncertain. OpenAI’s Codex Security documentation distinguishes source evidence from runtime reproduction and warns that a scan with no findings can still miss vulnerabilities. Codex Security’s validation guidance.
There is room for optimism in a serious bug being found and patched. That is the outcome we want from security research. The challenge is getting the benefit to every affected deployment quickly enough.
For my own projects, the practical question is how quickly I could answer an urgent advisory with evidence: which systems are affected, who owns them, and which are now running the fix. Improving those answers is useful today, whatever the next round of AI capabilities brings.