Introduction

A vulnerability does not become dangerous only because it receives a critical CVSS score. It becomes significantly more urgent when attackers are already exploiting it.

In September 2026, the U.S. Cybersecurity and Infrastructure Security Agency added seven vulnerabilities to its Known Exploited Vulnerabilities, or KEV, catalogue after evidence showed that they had entered active attacker operations. The affected technologies span remote-access infrastructure, communications platforms, software repositories, web frameworks, workflow orchestration systems and AI infrastructure.

The vulnerabilities include:

CISA’s decision to include a vulnerability in KEV changes the operational question.

Security teams should no longer be asking only:

“Is this vulnerability present?”

They also need to determine:

“Has someone already attempted to exploit it in our environment, what could they have accessed, and can we prove that remediation was successful?”

This requires vulnerability management, patch management, monitoring, SIEM, SOAR and governance processes to operate as one connected security lifecycle.

Active Exploitation Changes Vulnerability Management

Enterprise vulnerability scanners may identify thousands or even hundreds of thousands of findings. Treating every finding equally is impossible. For this reason, vulnerability-management programmes traditionally use factors such as:

• CVSS severity
• Asset criticality
• Internet exposure
• Data sensitivity
• Exploit availability
• Business function
• Patch availability
• Existing compensating controls

However, confirmed exploitation introduces another important signal:

Threat activity is no longer theoretical.

An organisation may have several CVSS 10.0 vulnerabilities that have never been observed under active exploitation while simultaneously operating a lower-scoring vulnerability that attackers are actively chaining into a larger compromise. CVE-2026-48710 is a useful example. Its reported CVSS score of 6.5 appears relatively moderate compared with several critical vulnerabilities in the same KEV update. However, public reporting linked the Starlette weakness with another LiteLLM vulnerability in an attack path capable of weakening authentication controls and contributing to remote code execution against vulnerable deployments.

This demonstrates an important vulnerability-management principle:

Risk should not be prioritised by CVSS score alone.

Exploit intelligence, asset exposure, attacker behaviour and business context must also influence remediation priority.

What Happens After Initial Exploitation?

Patching the vulnerable application is essential. However, once exploitation has occurred, patching alone may not remove the attacker. Recent activity associated with several of the vulnerabilities demonstrates why. Microsoft investigated compromises involving AI infrastructure and orchestration platforms where attackers moved beyond initial access into credential theft, environment discovery, persistence and resource hijacking. In a Kestra environment, observed activity included workflow-originated shell execution followed by Docker environment discovery, cryptominer deployment and follow-on data collection. The compromised orchestration environment could inspect container metadata and environment variables accessible through the Docker runtime. This is significant because orchestration platforms frequently operate close to:

• Cloud credentials
• Database passwords
• API tokens
• Automation secrets
• Internal service endpoints
• Container infrastructure
• Production workflows

The attacker therefore does not necessarily see the compromised application as the final objective.

The application may simply provide the first trusted position from which the wider environment can be explored.

AI Infrastructure Is Becoming High-Value Infrastructure

Several of the vulnerabilities in the CISA update also highlight an emerging security challenge. AI infrastructure increasingly sits between applications, data, identities, APIs and external model providers. LiteLLM gateways, RAG platforms, MCP servers, workflow engines and agent orchestration systems may handle extremely sensitive information. Depending on architecture, these systems can have access to:

• LLM provider API keys
• Internal databases
• Application secrets
• Model configurations
• Proxy-issued credentials
• Vector databases
• Cloud infrastructure
• Service accounts
• Container runtimes
• Automation workflows

Microsoft observed attackers harvesting credential-related values from compromised AI gateway environments and accessing database-backed configuration data. Attackers also established persistent access using mechanisms such as SSH authorised keys and deployed cryptocurrency miners to monetise compromised computing resources. Consequently, AI platforms should not be monitored only as applications. They should be treated as part of the enterprise control plane.

The Vulnerability-to-Incident Gap

Many organisations still operate vulnerability management and security operations as separate processes. The vulnerability-management team discovers a CVE. A ticket is created. Another team schedules a patch. Meanwhile, the SOC monitors authentication events, endpoint alerts, firewall logs and network activity. These workflows often remain disconnected.  That creates an important visibility gap.

Imagine the following sequence:

• An internet-facing application is identified as vulnerable.
• The vulnerability appears in CISA’s KEV catalogue.
• An external source sends unusual requests to the application.
• The application process launches a shell.
• The shell executes curl, wget, Python or another interpreter.
• Environment variables and credentials are accessed.
• A new outbound network connection appears.
• CPU consumption rises dramatically.
• An SSH authorised-key file is modified.
• A patch is deployed several hours later.

A vulnerability-management dashboard may show:

Remediated.

The attacker may still have persistence. The SOC therefore needs to connect vulnerability state with runtime behaviour.

Connecting Vulnerability Management with Logstail SIEM

SIEM provides the monitoring layer required to determine whether a vulnerable system has also demonstrated suspicious behaviour. Rather than examining individual events independently, security teams should correlate telemetry across the entire affected environment.

Relevant telemetry may include:

• Operating-system logs
• Process execution
• Authentication events
• Application logs
• API gateway logs
• Container activity
• Docker events
• Kubernetes audit logs
• File-integrity events
• Network connections
• DNS activity
• Firewall telemetry
• Cloud audit events
• Database access
• Resource utilisation
• Identity-provider events

The objective is not simply to alert whenever a vulnerable application exists. The objective is to identify when vulnerability + exposure + suspicious behaviour form a probable attack chain.

Example: Vulnerable Application Spawns a Shell

Consider an internet-facing application that is affected by a KEV-listed vulnerability. Shortly after suspicious inbound requests, the application process launches:

• bash
• sh
• python
• curl
• wget

This behaviour may be legitimate in some environments. However, the security context changes dramatically when Logstail can correlate:

Instead of five unrelated alerts, the SOC receives one investigation with meaningful context.

High-Value Detection Scenarios

Security teams reviewing systems affected by currently exploited vulnerabilities should focus on post-exploitation behaviour in addition to exploit signatures.

Application Process Launching Command Interpreters

Trigger when a normally server-side application unexpectedly launches:

• Bash
• Shell
• PowerShell
• Python
• Perl
• Curl
• Wget
• Netcat
• Other system utilities

Increase severity when the affected application is associated with a KEV vulnerability.

Unexpected Reverse-Shell Behaviour

Monitor for:

• New outbound connections following application execution
• Shell processes associated with server applications
• Connections to previously unseen destinations
• Unusual high-numbered destination ports
• Long-running outbound sessions
• Interactive shell behaviour from service accounts

Credential and Secret Discovery

Monitor for unusual access to:

• Environment variables
• .env files
• Application configuration files
• Secret stores
• Database connection strings
• API keys
• Access tokens
• Cloud credentials
• Service-account credentials

A vulnerable application reading sensitive configuration may be normal.

The same application spawning a shell that searches those files is not.

Container and Docker Discovery

Containerised applications deserve additional visibility.

Monitor for:

• Access to /var/run/docker.sock
• Docker environment enumeration
• Container inspection
• Unexpected container creation
• Privileged container execution
• New image downloads
• Cross-container access
• Access to secrets mounted inside containers

Docker socket exposure can transform the compromise of one application into a wider container-infrastructure incident.

Cryptomining and Resource Hijacking

Cryptominers remain a common post-exploitation payload because compromised compute resources can be monetised immediately.

Detection opportunities include:

• Unexpected CPU utilisation
• XMRig execution
• Connections to mining pools
• RandomX-related activity
• New scheduled jobs
• Process termination targeting competing miners
• Suspicious binaries running from temporary directories

Persistence

Security teams should also monitor:

• ~/.ssh/authorized_keys modifications
• New cron entries
• New systemd services
• Unexpected startup scripts
• New local accounts
• Changes to privileged groups
• Hidden executable files
• Immutable file attributes

These behaviours matter because remediation of the original CVE does not remove persistence that was established before the patch.

Turning Detection into Response with Logstail SOAR

Detection is only part of the workflow. Once exploitation is suspected, response needs to be coordinated quickly and consistently. Logstail SOAR can help security teams build response processes around high-risk vulnerability events. Depending on the organisation’s integrations and response policies, a workflow may:

• Create a high-priority incident.
• Enrich it with CVE and asset information.
• Identify whether the vulnerability appears in CISA KEV.
• Retrieve asset criticality and ownership information.
• Check current patch status.
• Collect associated SIEM events.
• Notify the SOC and infrastructure owner.
• Preserve relevant logs and evidence.
• Request containment approval.
• Isolate an affected workload or system where appropriate.
• Revoke compromised credentials or sessions.
• Trigger or assign remediation activity.
• Track patch deployment.
• Validate system behaviour after remediation.
• Maintain the complete incident timeline.

Automation should reduce repetitive analyst work. It should not eliminate human judgement. Actions capable of affecting production availability should use approvals, role separation and rollback procedures appropriate to the environment.

Vulnerability Management Should Start with Exposure

A vulnerability becomes considerably more dangerous when the affected system is reachable by an attacker. Security teams therefore need to understand not only which vulnerabilities exist, but which assets are visible from the internet, what services they expose, and how that external attack surface changes over time. This is where Logstail External Attack Surface Management (EASM) adds critical context.

Logstail EASM gives security teams an attacker-view of their public infrastructure by discovering internet-facing domains, subdomains, public IPs, cloud assets, technologies and exposed services associated with the organisation. It can also identify potentially vulnerable services, risky configurations and previously unknown entry points before they become part of an attack path. For a newly published CISA KEV entry, this allows defenders to move beyond asking:

“Do we have this CVE?”

and instead ask:

“Is the affected technology actually exposed to the internet, where is it running, and how quickly do we need to act?”

Logstail EASM can help identify and monitor external exposure such as:

• Domains and subdomains
• Public IP addresses
• Internet-facing services
• Open ports
• Cloud endpoints
• Technology fingerprints
• Vulnerable services
• Risky configurations
• TLS and certificate changes
• DNS changes
• Newly discovered public assets
• Unknown or unmanaged infrastructure
• Potential shadow IT

The platform also monitors changes across the external attack surface, including new services, DNS changes, certificates and newly appearing assets. This matters because an organisation’s external footprint is not static; infrastructure can become publicly reachable without necessarily passing through the normal security-review process.

Questions the defenders must answer

For every KEV entry, defenders should therefore be able to answer:

• Do we run the affected technology?
• Which versions are deployed?
• Which assets are affected?
• Does Logstail EASM identify the asset as externally visible?
• Are any affected systems internet-facing?
• Which ports and services are publicly exposed?
• Has a new or previously unknown asset appeared?
• Is the asset production-critical?
• What identities can access it?
• What data does the application hold?
• What internal services can it reach?
• Does it have access to container infrastructure?
• Does it contain API keys or other secrets?
• Is a vendor patch available?
• Has suspicious activity already occurred?

This changes vulnerability management from a flat list of CVEs into contextual exposure management. Instead of prioritising remediation only by severity score, teams can combine vulnerability intelligence with external visibility, exploitability, asset criticality and business impact. The resulting workflow becomes:

That is particularly important for CISA KEV vulnerabilities. Once exploitation has been confirmed in the wild, an unknown or forgotten internet-facing system is no longer simply an asset-management problem. It can become an initial-access path. Logstail EASM is designed around this discovery-to-remediation model: Discover → Detect → Monitor → Prioritise, helping teams turn external reconnaissance data into actionable remediation decisions.

Prioritising What Gets Patched First

A practical remediation model can combine several signals. For example:

Remediation Priority = Active Exploitation × External Exposure × Asset Criticality × Technical Impact × Detection Evidence

The formula does not need to be mathematically complex.

Its purpose is to make prioritisation defensible.

Consider three systems:

A risk-based workflow may correctly move System B immediately to the top of the remediation queue.

Patch Management Is Not Complete Until the Fix Is Verified

One of the most dangerous assumptions in vulnerability management is:

Patch deployed = risk removed.

Several things may still go wrong.

The patch may:

• Fail to install
• Require a reboot
• Be applied to only part of a cluster
• Leave another vulnerable instance online
• Break a dependency and be rolled back
• Fail because of configuration drift
• Leave an exposed container unchanged
• Leave attacker persistence behind
• Leave stolen credentials valid

Patch management therefore needs a validation phase.

After remediation, security teams should confirm:

• The vulnerable version is no longer running.
• Every affected instance has been addressed.
• The service restarted successfully where required.
• Vulnerability scanning confirms the finding is closed.
• Monitoring confirms expected service behaviour.
• No exploitation indicators remain.
• No persistence mechanisms were established.
• Potentially exposed credentials have been rotated.
• Detection remains active after the change.
• The remediation evidence has been preserved.

The operational lifecycle therefore becomes:

Continuous Monitoring After Remediation

Monitoring should continue after the patch window. This is especially important when exploitation may have occurred before remediation. Post-remediation monitoring can look for:

• Continued outbound connections
• Persistence mechanisms
• Suspicious service-account activity
• Unexpected privileged authentication
• Reappearing malicious files
• Recreated scheduled tasks
• Abnormal resource usage
• Connections to known malicious infrastructure
• New credential use from unfamiliar systems
• Repeated exploitation attempts

A successful patch removes the vulnerability. A successful incident response also confirms that the attacker no longer has access. Those are different outcomes.

A Practical KEV Response Workflow

When a new vulnerability enters the CISA KEV catalogue, organisations can follow a repeatable workflow.

From Vulnerability Lists to Continuous Cyber Defence

The latest CISA KEV additions reinforce a wider lesson. Vulnerability management cannot end with discovering a CVE. The organisation needs to determine whether the affected system exists, whether it is exposed, whether attackers have already interacted with it, whether suspicious post-exploitation behaviour occurred, whether remediation succeeded and whether the complete process can be demonstrated later. Recent attacks against infrastructure such as Kestra and LiteLLM show how quickly initial access can progress into shell execution, credential harvesting, container discovery, persistence and resource hijacking. This requires several security capabilities to operate together.

Logstail connects:

• Vulnerability management to identify and prioritise affected systems.
• Patch management to coordinate and track remediation.
• SIEM to correlate exploitation and post-exploitation telemetry.
• SOAR to orchestrate investigation and response.
• Continuous monitoring to validate security before and after remediation.
• GRC to preserve ownership, decisions, evidence and risk treatment.

The goal is not to patch every vulnerability faster. The goal is to understand which vulnerabilities create real exposure, detect when that exposure becomes an incident, remediate it quickly and prove that the risk has actually been removed. Because once a vulnerability reaches the Known Exploited Vulnerabilities catalogue, the discussion has already moved beyond theoretical risk. Attackers are using it. Defenders need to move just as quickly.

Contact Our Experts or Sign Up for Free