CVE-2024-27268 Overview
CVE-2024-27268 is a denial of service vulnerability affecting IBM WebSphere Application Server Liberty versions 18.0.0.2 through 24.0.0.4. A remote, unauthenticated attacker can send a specially crafted request that forces the server to consume excessive memory resources. The flaw is tracked as IBM X-Force ID 284574 and maps to [CWE-770] (Allocation of Resources Without Limits or Throttling).
The vulnerability is exploitable across the network without privileges or user interaction. While availability impact is high, confidentiality and integrity are not affected. The current EPSS probability is 1.278% (66.2 percentile), indicating measurable interest from the threat community.
Critical Impact
Unauthenticated remote attackers can exhaust server memory and disrupt availability of WebSphere Liberty workloads with a single crafted HTTP request.
Affected Products
- IBM WebSphere Application Server Liberty 18.0.0.2 through 24.0.0.4
- Open Liberty runtimes packaged with the affected Liberty versions
- Applications and containers built on the vulnerable Liberty base images
Discovery Timeline
- 2024-04-04 - CVE-2024-27268 published to the National Vulnerability Database
- 2026-06-17 - Last updated in NVD database
Technical Details for CVE-2024-27268
Vulnerability Analysis
The defect resides in how IBM WebSphere Application Server Liberty processes incoming HTTP requests. The server does not enforce sufficient limits on resource allocation when handling certain malformed or oversized request structures. An attacker who repeatedly sends crafted requests can drive the Java Virtual Machine heap toward exhaustion. Application threads stall, garbage collection pressure rises, and the Liberty runtime stops servicing legitimate traffic.
Because Liberty often fronts microservices, REST APIs, and enterprise workloads, a successful attack can cascade across dependent systems. The issue requires no authentication and no user interaction, which lowers the bar for opportunistic exploitation against internet-exposed instances.
Root Cause
The root cause is improper resource throttling, classified under [CWE-770]. The request handler accepts input that triggers unbounded internal allocations before validation completes. Without a ceiling on per-request memory usage or on the number of concurrent allocations attributable to a single client, attackers can amplify a small network payload into a large server-side memory footprint.
Attack Vector
An attacker reaches the vulnerable handler over the network by issuing crafted HTTP requests to any exposed Liberty endpoint. No credentials are required. Repeated requests, or a single highly amplified request, force the server to allocate memory until the JVM throws OutOfMemoryError or becomes unresponsive. The vulnerability does not yield code execution, data theft, or tampering, but it does interrupt service availability.
No public proof-of-concept exploit and no CISA Known Exploited Vulnerabilities listing exist at the time of writing. Technical details are documented in the IBM X-Force Vulnerability #284574 and CERT Vulnerability Note #421644 advisories.
Detection Methods for CVE-2024-27268
Indicators of Compromise
- Sustained or sudden growth of JVM heap usage and frequent full garbage collection cycles on Liberty servers
- OutOfMemoryError entries or thread dumps in messages.log and console.log correlated with bursts of inbound HTTP traffic
- Unusual request patterns featuring oversized headers, abnormal content lengths, or repeated identical payloads from a small set of source IPs
- Liberty health endpoints reporting degraded readiness or liveness status during the traffic spike
Detection Strategies
- Monitor Liberty JVM metrics (HeapMemoryUsage, GcCount, ThreadCount) through JMX or MicroProfile Metrics and alert on sharp deviations from baseline
- Inspect HTTP access logs for elevated request rates from single sources targeting the same endpoint with unusual payload sizes
- Correlate WAF and reverse proxy telemetry with Liberty error logs to identify crafted requests that precede memory pressure events
Monitoring Recommendations
- Forward Liberty application and FFDC logs to a centralized SIEM or data lake for cross-host correlation
- Establish baselines for normal request size distributions and flag statistical outliers in real time
- Track JVM heap and thread pool saturation alongside upstream load balancer error rates to detect early signs of resource exhaustion
How to Mitigate CVE-2024-27268
Immediate Actions Required
- Inventory all WebSphere Application Server Liberty deployments and confirm versions against the affected range 18.0.0.2 through 24.0.0.4
- Apply the IBM-supplied fix referenced in the IBM Support Advisory as soon as it can be validated in non-production
- Restrict network exposure of Liberty management and application endpoints to trusted segments and authenticated reverse proxies
- Enable rate limiting and request size caps at upstream load balancers, WAFs, or API gateways
Patch Information
IBM has published remediation guidance in the IBM Support Advisory for this issue. Administrators should upgrade Liberty to a fixed iFix or service release as identified in that advisory. Container-based deployments must rebuild images on a patched Liberty base and redeploy across all clusters. After patching, verify the running version with productInfo version inside the Liberty installation directory.
Workarounds
- Place affected Liberty servers behind a WAF or reverse proxy configured to reject oversized or malformed HTTP requests
- Tune Liberty HTTP endpoint limits in server.xml to constrain header sizes, post sizes, and concurrent connections per client
- Apply connection and request rate limits at the network edge to reduce the blast radius of crafted request floods
- Increase monitoring frequency on JVM heap and thread metrics until the patch is deployed
# Example server.xml hardening for IBM WebSphere Liberty
# Constrains request sizes and connection counts to reduce DoS exposure
<server>
<httpEndpoint id="defaultHttpEndpoint"
host="*"
httpPort="9080"
httpsPort="9443">
<httpOptions maxKeepAliveRequests="100"
persistTimeout="30s"
readTimeout="30s"
writeTimeout="30s"
removeServerHeader="true"/>
<tcpOptions soReuseAddr="true"
inactivityTimeout="60s"/>
</httpEndpoint>
<webContainer deferServletLoad="false"
disallowAllFileServing="true"
maxRequestSize="1048576"
postParamSaveOnError="false"/>
</server>
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
