Loading vulnerability…
Spring MVC controller methods that accept request bodies through an @RequestBody byte[] parameter are susceptible to denial of service through resource exhaustion when processing a malicious request.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
2 valid exploits after Mallory filtered fakes, detection scripts, and README-only repos (2 hidden).
This repository is a Java Spring Boot web application demonstrating a potential Denial of Service (DoS) vulnerability related to handling large Content-Length headers in HTTP POST requests. The main application exposes a single endpoint, /upload, which accepts raw byte[] data. A custom HTTP message converter (SafeByteArrayHttpMessageConverter) is used in place of the default ByteArrayHttpMessageConverter. The test file ByteArrayDoSTest.java attempts to send a POST request to /upload with a Content-Length of Integer.MAX_VALUE, expecting the application to throw a NestedServletException, which simulates a DoS scenario. The repository structure includes standard Gradle build files, application source code, configuration, and a focused test case for the DoS condition. No external network endpoints or hardcoded IPs/domains are present; the only fingerprintable endpoint is the /upload HTTP path.
This repository is a proof-of-concept (PoC) for CVE-2024-38828, a Denial of Service (DoS) vulnerability in Spring Framework 5.3.x. The vulnerability arises when a controller accepts byte[] via HTTP POST, and the Content-Length header is set to a very large value (2^31-1), causing the server to allocate excessive memory regardless of the actual body size. The repository contains a minimal Spring Boot application with a vulnerable endpoint (/upload), a custom HttpMessageConverter fix (SafeByteArrayHttpMessageConverter), and a Python load testing script (tests/load_test.py) that automates sending malicious requests and measures the application's memory usage and responsiveness. The exploit is network-based, targeting the /upload HTTP endpoint, and demonstrates both the vulnerable and fixed scenarios. The repository structure is clean, with Java source code for the application, configuration for the fix, and a comprehensive Python test harness for automated exploitation and metric collection.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
5 sources tracked across advisories and community write-ups. News coverage will land here when it surfaces.
No news coverage yet. Advisories and community discussion only.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.