October 2026 has one day left and it has already been a bad month for security teams.
Earlier this week I wrote about Black October: the concentration of vulnerabilities, breaches, compromised trusted infrastructure and incidents in critical business systems. More reports have arrived since.
AI is speeding up vulnerability research and improving offensive tooling. Autonomous and semi-autonomous agents are now reported in reconnaissance, credential harvesting and exploitation. Meanwhile many enterprise processes still run at a pace set years ago. A vulnerability is found, a report generated, a ticket assigned, a maintenance window negotiated. That can take days or weeks for a weakness everyone already knows about.
The two clocks no longer match.
I welcome AI-assisted security research. Tools that help researchers find vulnerabilities earlier are good for the industry. The same advances raise a hard question for anyone defending enterprise infrastructure. How do we keep a defensible posture when attackers can examine our exposure continuously, revisit failed attempts and adjust at machine speed?
At Elytra Security we are building two capabilities for this problem: Argus, our Continuous Threat Exposure Management (CTEM) platform, and Venus, our cyber deception platform. October reinforced our view that enterprises need to understand their exploitable exposure continuously, and to watch how adversaries interact with what they find.
Argus · exposure
Elytra’s on-premises Continuous Threat Exposure Management platform. It maps what an adversary could reach, ranks findings by what an attacker could actually exploit, and tracks each fix to validated closure, without exploiting anything.
Venus · behaviour
Elytra’s cyber deception platform. It exposes controlled decoy services that have no legitimate users and records every unsolicited interaction as behavioural evidence.
Black October: the scale
The incidents below involve different technologies, organisations and methods of compromise. They are not one attack technique, and not all of them involve AI. The certificate incident goes to the strength of assurance processes. The supply-chain compromises expose privileged identities and trusted distribution systems. The banking case raises questions of transaction integrity and independent verification. The refrigeration attacks disrupted physical business operations.
According to the CVE Programme’s published metrics, 72,812 CVE records were published in the first three quarters of 2026, against 48,244 in all of 2025. The third quarter alone accounted for 36,962. A separate monthly tracker counted more than 15,700 records in October, with about 1,367 classified as critical, against 4,235 in October 2025.
I would not attribute the rise mainly to AI yet. Changes in vulnerability assignment, disclosure practice, research activity and publication processes all move these numbers. We are examining those factors separately in our CVE forecasting research.
The operational effect is already visible. Security teams must triage a much larger body of vulnerability intelligence to find what affects their own estate. When exploitation starts before the patch exists, patch management alone cannot close the gap.
When exploitation starts before the patch exists, patch management alone cannot close the gap.
The attack window is shrinking
PHP2Shell is the clearest example. On 21 October the PHP project released emergency fixes for CVE-2026-109618 and CVE-2026-109619, two critical vulnerabilities that can allow unauthenticated remote code execution under affected conditions. Amazon Threat Intelligence later reported that MadPot had recorded an exploitation attempt on 17 October. On 26 October, researchers reported code execution against an intentionally vulnerable PHP installation in a controlled honeypot.
Take an enterprise running hundreds of applications on thousands of servers. Even with a mature vulnerability management programme, the team has to identify the affected systems, establish whether they are reachable, rank their business importance, find mitigations, coordinate deployment and verify the result. Four days before disclosure there was no patch to deploy. A programme built only on reacting to announcements had little to act on in that period.
Four days before disclosure there was no patch to deploy.
Exposure management can reduce the number of reachable, poorly controlled systems before a disclosure like this. Deception may show suspicious probing, including unfamiliar techniques, when it reaches an instrumented decoy. Neither guarantees advance knowledge of a zero-day. Their value lies in what defenders know about their own environment and the extra chance to see suspicious activity.
Agentic AI changes the economics of reconnaissance
On 15 October, CERT-In issued a critical advisory on unauthorised activity by AI agents under evaluation and deliberate misuse of open-source agentic tools against Indian ICT assets. On 21 October, Microsoft reported that the Storm-0940 actor used the ARTEX agentic penetration-testing framework to automate offensive activity. In some cases the time from initial targeting to privileged cloud access was under three hours.
One password-spraying operation produced more than 151,000 failed sign-ins against 327 accounts at eight organisations, peaking near 2,900 failed attempts per minute. Microsoft reported no successful authentication in that dataset. In a separate phase tied to the ConnectWise compromise, the actor attempted sign-ins to more than 2,250 downstream tenants. Google Threat Intelligence reported in September that adversaries compromised a cloud resource and went on to plan, build and run an agent-enabled mass credential-harvesting campaign in under six hours.
An attacker can use automation to enumerate systems, evaluate responses, test credentials, probe reachable services and repeat all of it across many targets. Agentic systems may add the ability to adjust the next action based on what an earlier step returned. A conventional scanner, a scripted framework, an AI-assisted operator and an autonomous agent are different things, and the difference matters when reading telemetry. For a defender the practical problem is the same. The time to recognise, investigate and respond may be much shorter than established workflows assume. I expect that to force changes in how enterprises run vulnerability management, exposure assessment and threat detection.
Argus: what an adversary could exploit
Traditional vulnerability management finds known weaknesses and supports remediation. That remains essential, but a vulnerability’s importance depends on where it sits. An exposed application server may carry a moderate score and still reach an identity with wide privileges elsewhere. A management interface may have no exploitable CVE and still be reachable from networks where it should never be. Several manageable weaknesses can combine into a path to a critical business system. A systematic attacker looks for exactly these relationships.
Argus examines enterprise exposure in context. It runs on a single on-premises appliance and takes a non-exploitation approach, which matters for critical infrastructure and sensitive environments where aggressive testing of production systems carries unacceptable operational risk. It correlates exposure, identity and security telemetry into attack paths and ranks findings by what an attacker could actually exploit (Attacker Feasibility Scoring), not by raw severity alone. Scoring is deterministic, and each finding rests on a hash-chained evidence trail.
The console starts with two views. The Recon Resistance Score gives a 0 to 100 reading of how hard the estate is to reconnoitre, with the factors that move it. Beside it, the likely next steps for an adversary are each tied to evidence and, where one exists, to the Fix Pack that closes them. The figures in this section are mockups based on the Argus console running against our lab estate, not a customer or production environment.
Choke points. For each network segment, Argus finds the hosts that sit on every route to a crown jewel, using dominator analysis over the stored reachability graph. In the example below, every route from one segment to all nine crown jewels passes through a single gateway. Fixing it closes all of those routes at once, which a severity list will not show you. The lines are potential paths deduced from the graph. Argus does not watch traffic, and no movement has been observed. Choke points sit alongside the Fix Pack ranking and do not change it.
Fixing one choke point closes several routes at once, which a severity list will not show you.
Threat scenarios. For each technique in a threat catalogue, grouped by class of campaign such as ransomware or credential-led account takeover, Argus reports what the estate’s own evidence says. A technique is present, absent, or unassessed, and the reason for anything unassessed is named. In this run, 47 techniques were present, 26 absent and 780 unassessed, out of 853. Argus gives no score or grade and attributes nothing to a named actor. The 780 are reported as plainly as the 47.
Auditable reporting. Each finding becomes a Fix Pack with an owner, a recurrence count, evidence and a validation state. Underneath sits a remediation record: a hash-chained ledger with signed checkpoints, so a reader can check how an exposure was found and how it closed. The connector panel shows what Argus was reading. In this run that was one log source, Wazuh, with Microsoft 365 configured but quiet and AWS and GCP not configured.
Take PHP2Shell again. With several affected PHP applications, finding the vulnerable versions is the smaller part of the job. The team needs to know which instances are externally accessible, how they connect to the rest of the infrastructure and whether they lead to more sensitive environments. Argus could potentially help identify reachable systems, choke points and risky relationships within its assessment scope, so teams can prioritise the exposures with the largest consequences. Before a new CVE is even published, removing unnecessary exposure, excess privilege and unsafe access relationships reduces what an adversary has to work with. Argus also looks for agentic reconnaissance in the log sources an organisation already runs, which gives a second view of the same adversary behaviour Venus sees on decoys.
This is why exposure management should be continuous. An enterprise changes every day. Services are deployed, permissions accumulate and temporary access becomes permanent. The attack paths open today may differ from those examined in the last assessment.
Venus: what adversaries are actually doing
Venus approaches the problem from the other side. It is a deception platform that exposes controlled decoy services and records unsolicited interactions. The services have no legitimate business users, so reconnaissance and probing can be studied without first separating them from ordinary application traffic.
We have run Venus since June with several deliberately constructed internet-facing services. As of 29 October it had recorded about 7.7 million external events from more than 45,000 distinct source IP addresses. Over the preceding 30 days our analytics identified 19,160 source entities, 6,376 of them returning. Of these, 378 were classified as showing multi-stage activity beyond initial reconnaissance.
Reporting for 19 to 25 October recorded about 963,000 external events. In that period the decoys received 23,036 requests for sensitive files and configuration, including attempts to retrieve environment files and Git configuration. We also saw 109 requests classified as Langflow exploit attempts, up 45.3% on the previous reporting period, along with more probing of AI workflow interfaces. These are requests against our deception environment. They are not confirmed compromises of production systems. They do show how persistently sources look for credentials, configuration files, exposed services and recently disclosed weaknesses.
What interests us now is whether sequences of interactions reveal something about the decision-making behind them. One area of current research is AI cadence. Venus surfaces known AI bot identifiers, source addresses associated with AI service egress infrastructure, and potential Systemic AI-assisted Reconnaissance (SAR) identified by our own behavioural algorithms. We examine timing, repeat sessions, movement between deception surfaces and changes in request order. Between 19 and 25 October, Venus classified 32 sessions as suspected agentic reconnaissance.
Those are heuristic findings and need further investigation. An AI-associated egress address does not establish that a request came from an autonomous agent, and conventional automation can produce timing patterns that resemble adaptive behaviour. The more useful test is whether activity changes in response to something found earlier. We look for a source that returns to a different service after an initial response, reorders its requests, or follows up a credential or configuration detail a decoy exposed. That needs controlled experiments and careful interpretation.
An AI-associated egress address does not establish that a request came from an autonomous agent.
Research on Context Bombs points to a related test. If an autonomous agent decides its next step from what it finds during reconnaissance, a carefully built decoy might influence that step. We have not established from current Venus observations that attacking agents have been redirected this way. Deception still lets us examine behaviour that would otherwise stay invisible until an attacker reaches a production system.
An operating model
What could Argus and Venus have changed?
What this article claims
- The October incidents are reported with dates and sources.
- Exposure and adversary behaviour can be understood continuously.
- Argus and Venus could potentially help with the kinds of exposure and behaviour these incidents involve, subject to deployment coverage.
What it does not claim
- That Argus or Venus would have prevented any October incident.
- That an AI-associated address proves an autonomous agent.
- That CVE growth is mainly caused by AI.
- That the Argus figures show a customer or production estate. They are mockups from a lab estate.
I cannot claim that Argus and Venus would have prevented any of October’s incidents. We do not know the full technical circumstances of each one, and no single architecture covers every kind of compromise. Several of these incidents do fall into the categories of exposure and adversary behaviour these platforms are built for. The figure separates what the sources report from what could potentially follow. The middle line of each card is hypothetical, depends on deployment coverage, and is not a demonstrated detection.
Each platform has limits. The aim is to combine controls so that a weakness in one does not leave the organisation depending on it alone.
An enterprise strategy against adversarial AI
Exposure is continuous, adversarial reconnaissance is persistent, and AI is changing the speed at which researchers and attackers both work.
An enterprise should keep a current picture of its reachable infrastructure, privileged access relationships and potential attack paths, and a practical way to rank which exposures could lead to consequential outcomes, including the choke points where one fix closes several paths. It needs threat scenarios built from its own infrastructure and reports an auditor can follow. That is the job of a CTEM capability such as Argus. Alongside that it needs behavioural intelligence: a chance to see reconnaissance, credential probing and suspicious interaction before an incident reaches critical production systems. That is where deception, including platforms like Venus, contributes.
Together they support one operating loop. Identify the consequential exposures, watch for relevant adversary behaviour, investigate the evidence, prioritise corrective action and verify that the exposure went down. Deployment of two products does not create that loop by itself. It needs integration, shared processes and clear ownership.
The loop also needs measuring. On the exposure side: how long it takes to identify a critical exposure and assign responsibility, how quickly access can be restricted when an urgent vulnerability is disclosed, how many high-risk findings sit past their agreed remediation period, and how often closure is independently revalidated. On the detection side: how quickly suspicious interactions are reviewed, how much useful behavioural evidence is collected, how many classifications survive investigation, and whether recurring patterns change decisions. These deserve the same management attention as vulnerability counts and incident statistics.
I also want to say something for AI on the defensive side, because this article has spent most of its time on attackers. AI can help defenders read a long findings queue, summarise evidence for an analyst, draft remediation guidance, spot patterns across logs that no one rule describes and test whether a conclusion holds up. It is a good assistant. I would not make it the main engine. A deterministic engine gives the same answer for the same evidence, and that is what lets a finding be reproduced, challenged and audited. AI works best as a second reader on top of that foundation, where a person can check what it says against the evidence underneath. That is how we think about Argus and Venus. The scoring and the evidence trail are deterministic, and AI-assisted analysis belongs around them.
Organisations also need specific controls for their own authorised AI agents: tool permissions, service identities, credential management, approval boundaries and auditing. Exposure management and deception contribute to the wider defence. They do not replace governance of the agents an enterprise chooses to deploy.
There will always be new vulnerabilities and techniques that bypass an individual control. The objective is to give attackers fewer opportunities, recognise suspicious behaviour earlier and limit the damage when an attacker succeeds.
Conclusion
Black October reinforced something I have believed for years. An enterprise cannot judge its security posture by counting the controls it has implemented or the vulnerabilities it has reported. It needs evidence that its infrastructure is understood, its exposure is shrinking and its defensive processes can keep pace with the threats.
Agentic offensive tools make that more urgent. When attackers can run reconnaissance, evaluate responses and repeat operations at machine speed, incomplete asset knowledge, excess privilege and slow remediation cost more.
That is the environment we are building Argus and Venus for. Argus examines enterprise exposure and potentially exploitable relationships. Venus supplies behavioural evidence from controlled deception environments. Each addresses a different part of the problem. We cannot promise that either would have prevented the incidents of October 2026, and the evidence does not support saying so. Enterprises that run continuous exposure management alongside well-designed deception and established controls will be better placed to recognise emerging threats and reduce attack opportunities.
Can your organisation discover and reduce its exposure faster than an adversary can turn that exposure into an incident?
That is where I think the next stage of enterprise security needs to focus.
Sources and further reading
CVE Programme: Published CVE Record Metrics · CRACI: CVE Publication Trends · AWS: PHP2Shell Exploitation Before Disclosure · PHP Security Releases · Microsoft: Storm-0940 and ARTEX · CERT-In Advisory CIAD-2026-0049 · Google Threat Intelligence: From Prompting to Autonomy · LiteLLM: Incident Investigation · OVHcloud: Security Advisory · eMudhra: Certificate Security Incident · CNBC: French supermarket fridge attack · MediaNama: Central Bank of India · Elytra: Black October · Elytra: Venus Research · Elytra: Four Days Before the Patch