GeoServer exploit shows why EDR misses application-layer attacks

At a glance

What this is: This is a product-security analysis of the GeoServer exploit that argues EDR missed the decisive phase because the attack happened at the application layer.

Why it matters: It matters because IAM, NHI, and platform teams need detection and response coverage that follows application abuse, not just endpoint activity, when credentials and access paths are being used to move laterally.

👉 Read Oligo Security’s analysis of the GeoServer exploit and EDR blind spots

Context

The primary problem here is an application-layer exploit that bypassed the visibility model many teams still lean on for response. When attackers enter through an exposed application, endpoint tools can remain blind until the attacker has already established access and started moving.

For identity and security programmes, that matters because application access is often the bridge between a vulnerability and broader compromise. Once an attacker uses a service-facing application to pivot, the control question is no longer just endpoint hygiene. It becomes whether the organisation can detect abuse where the identity, the app, and the runtime meet.

Key questions

Q: How should security teams detect exploitation of internet-facing applications before EDR alerts?

A: Security teams should monitor application runtime activity, API calls, and exploit attempts directly at the service boundary. EDR can still support response, but it should not be the first or only detector for application-layer compromise. The key is to correlate application events with identity and cloud telemetry so exploitation is visible before the attacker pivots.

Q: Why do application-layer attacks create more risk than endpoint teams expect?

A: Application-layer attacks matter because they can create valid-looking access without immediately triggering host-based malware signals. Once the attacker is inside the service, the next step is often lateral movement through the environment’s own trust paths. That makes the initial application foothold far more important than a single suspicious process on an endpoint.

Q: What breaks when organisations rely on EDR alone for exposed services?

A: What breaks is the detection timeline. EDR may see the consequences of compromise, but it often misses the exploit itself when the attack happens inside a web application or other externally reachable service. By then, the attacker may already have enough access to move deeper into the environment.

Q: Who is accountable when an application exploit becomes a broader breach?

A: Accountability usually spans application security, cloud security, and incident response leadership because the failure crossed control domains. The application team owns exposure and patching, while detection and response teams own visibility and containment. Frameworks such as the NIST Cybersecurity Framework 2.0 help assign responsibility across protect, detect, and respond functions.

Technical breakdown

Why application-layer exploitation escapes EDR

EDR is designed to observe endpoints, processes, files, and suspicious host activity. It is not built to inspect the internal logic of a web application or the abuse of a vulnerable service endpoint. In the GeoServer case described by the vendor, exploitation occurred inside the application before the endpoint telemetry looked abnormal. That means the attacker could use the application itself as the access path without immediately triggering host-based signals. When the first control sees a compromise only after follow-on movement begins, the response window is already compressed.

Practical implication: add application-layer detection where externally reachable services can be exploited before host telemetry changes.

How exploitation turns into lateral movement

The article frames the exploit as more than a one-off intrusion because the vulnerability was used for access and lateral movement. That sequence matters: initial compromise gives the attacker a foothold, then the environment’s own trust relationships and reachable services become the next move. Living-off-the-land techniques and benign-looking scripts further reduce the signal EDR can rely on. In practice, the attacker does not need malware if the application and surrounding infrastructure already provide enough legitimate paths to continue operating.

Practical implication: treat application compromise as an access problem, not only a malware problem, and correlate app activity with cloud and identity signals.

Why cloud application detection changes the control point

Cloud Application Detection and Response, or CADR, shifts monitoring closer to the place where the abuse starts. Instead of waiting for endpoint anomalies, it watches application runtime behavior, API calls, and exploit attempts in context. That gives defenders a chance to see the initial misuse of the application, not just the side effects. In this kind of attack, the decisive question is whether telemetry exists at the application boundary where the exploit is delivered and the attacker’s subsequent actions are still separable from ordinary use.

Practical implication: instrument vulnerable internet-facing applications so detection starts at the service boundary, not after the host is already active.

Threat narrative

Attacker objective: The attacker objective was to gain foothold access through the application and use that access to move deeper into the target environment.

1. Entry occurred when attackers exploited CVE-2024-36401 in the GeoServer application exposed to the internet.
2. Escalation followed as the vulnerability gave the attacker access and a path to lateral movement before EDR registered suspicious host activity.
3. Impact was broader environment penetration, with the initial application compromise already deep enough to make endpoint-only response late.

Breaches seen in the wild

• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

EDR-centric detection fails when the exploit lives in the application boundary. This incident shows that host telemetry can remain quiet while an attacker is already using a vulnerable service as an entry point. The problem is not only missed alerts, but the wrong control plane for the attack. Practitioners should treat internet-facing application runtime as a primary detection surface, not an afterthought.

Application compromise is an identity and access event, not just a vulnerability event. Once the attacker uses the application to gain access, the environment’s trust relationships become the real path to movement. That means the governance problem sits across service exposure, runtime visibility, and downstream access paths. Security teams should evaluate whether their control stack can answer who or what is using the application before asking what the host did.

Identity blast radius is the right named concept for this class of failure. A vulnerable application can turn one exposed service into a much larger access surface if the organisation cannot see and contain the first exploit attempt. The blast radius is shaped by how quickly defenders can separate normal runtime behaviour from abuse. Practitioners should measure whether a single service compromise can be isolated before it becomes environment-wide movement.

Cloud application detection fills the gap between patch knowledge and operational containment. CISA can identify the flaw and list it in KEV, but that does not tell defenders where abuse is happening in real time. The article’s core lesson is that knowing about a vulnerability is not the same as seeing exploitation at the service layer. Teams should align runtime monitoring to the applications most likely to be used as initial footholds.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• Only 13% of organisations feel extremely prepared for the reality of agentic AI, which shows how thin the governance base is for systems that can act at runtime.
• For a broader view of how identity risk accumulates across compromised access paths, see The 52 NHI breaches Report.

What this signals

Identity blast radius is the better operating concept for teams modernising detection around exposed applications. With 70% of organisations granting AI systems more access than a human would get for the same job, according to the 2026 Infrastructure Identity Survey, many environments are already normalising access depth without matching containment depth.

That means vulnerability response can no longer stop at patch prioritisation. If an application can be used as the first foothold, the programme must prove it can see service abuse, connect it to identity context, and contain it before the attacker reaches lateral movement.

Teams building detection strategy should pair runtime monitoring with the NHI Lifecycle Management Guide so exposed services are governed as identities with lifecycles, not just as software endpoints.

For practitioners

• Place application-layer monitoring on externally reachable services Instrument internet-facing applications so exploit attempts, abnormal API calls, and suspicious runtime patterns are visible before host-based indicators appear.
• Correlate application events with identity and cloud telemetry Join service activity, cloud control plane logs, and identity signals so a vulnerable application is not treated as an isolated box but as part of the access chain.
• Prioritise containment playbooks for application footholds Build response steps that assume the attacker entered through the service itself and may already have moved laterally by the time endpoint alerts appear.
• Re-rank monitoring coverage around exploit-prone services Give vulnerable, externally exposed applications higher detection priority than low-value endpoints that rarely serve as initial access paths.

Key takeaways

• The GeoServer case shows that endpoint-first visibility can miss the moment an attacker enters through an application vulnerability.
• The practical risk is not just exploitation, but the speed at which an application foothold becomes lateral movement inside the environment.
• Teams need application-layer detection, identity correlation, and containment playbooks that operate before EDR would normally register a compromise.

Key terms

• Application-layer exploit: An application-layer exploit abuses the logic or interfaces of a running service rather than the operating system or endpoint itself. The attacker uses the application as the entry path, which can bypass host-based controls until the service activity is correlated with other telemetry.
• Cloud application detection and response: Cloud application detection and response is a monitoring approach focused on observing runtime behaviour inside cloud-hosted applications. It looks for exploit attempts, abnormal API use, and service-level abuse, giving defenders visibility earlier than endpoint-only tools in many application compromise scenarios.
• Identity blast radius: Identity blast radius is the amount of access and lateral movement an attacker can gain after compromising one identity or service. In application incidents, it depends on how much trust the service carries, what downstream systems it can reach, and how quickly defenders can contain it.

What's in the full article

Oligo Security's full article covers the operational detail this post intentionally leaves for the source:

• The vendor’s breakdown of how the GeoServer exploit unfolded against the CISA-disclosed vulnerability.
• Specific reasoning behind why EDR visibility lagged behind the application-layer compromise.
• The CADR capability framing and the runtime telemetry patterns the vendor says matter most.
• The article’s product-focused comparison of detection priorities for AppSec, CloudSec, and SecOps teams.

👉 Oligo Security’s full post covers the exploit sequence, detection gap, and CADR framing in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance in your organisation, it is worth exploring.