Loading story…
Researchers demonstrated that common upload-validation controls can be bypassed by crafting JSON payloads that retain JSON.parse compatibility while presenting signatures or structures accepted as PDF or WEBP files. The techniques affect validation approaches including Node.js mmmagic, pdflib, the Unix file utility, and the file-type library, potentially allowing malicious gadget files to be uploaded and later consumed in client-side path traversal (CSPT), CSPT-to-CSRF, or XSS exploit chains.
A related libmagic inconsistency can cause deeply nested JSON to be classified as generic ASCII text after its JSON-recursion guard is reached, while embedded PDF-signature content near the file beginning may lead to PDF classification instead. Reported recursion limits vary substantially—about 500 nesting levels in upstream libmagic 5.46 and roughly 10 in default file 5.41 deployments on Ubuntu and macOS—requiring organizations to test their deployed validators and ensure upload checks validate both file structure and the application's downstream parsing behavior.
See affected versions and whether adversaries are exploiting it.
2 events from the most recent confirmed update back to the earliest known activity.
Maxence Schmitt published research showing how JSON-based CSPT gadgets can be crafted to bypass PDF and WEBP upload validation while remaining parseable by browsers. The write-up demonstrated bypasses affecting mmmagic, pdflib, the Unix file command, and file-type, enabling CSPT-to-CSRF and potentially XSS chains.
Research described how deeply nested JSON can exceed libmagic/file JSON parsing recursion limits and be classified as ASCII text or, when PDF signatures are embedded near the start, as a PDF. The behavior could bypass upload validation based on libmagic-derived MIME detection and route JSON content to PDF-processing components.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
2 references tracked. Mallory keeps watching after this page renders.
Map indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Researchers described how weak image-upload controls can let attackers submit files with benign-looking extensions such as `.jpg` while embedding active content that browsers may execute under the victim site’s origin context. One technique abuses browser content handling with tags such as `OBJECT` to force interpretation of uploaded content as Flash or other active formats, allowing a malicious file hosted on a trusted site to send authenticated requests with the victim’s cookies and read sensitive responses such as profile data or CSRF tokens. The same class of issue can also support follow-on CSRF-style actions when a logged-in user is lured to an attacker-controlled page. Separate analysis of web applications using ImageMagick and CarrierWave showed that insecure defaults can widen the exposure by storing uploaded files and temporary cache files in publicly reachable directories, sometimes without reliable access control. The research found that obscure image formats and malformed payloads can trigger browser-side script execution when servers return incorrect or missing `Content-Type` headers, and that leftover cache files after validation or conversion failures may remain accessible if their URLs are guessable. Recommended defenses include validating file content as well as extensions, restricting accepted formats, serving uploads with correct MIME types, enabling `X-Content-Type-Options: nosniff`, and moving protected uploads and caches outside public web paths.
Aug 15, 2026
Web applications that process user-uploaded images with **ImageMagick** can expose a broad attack surface when upload controls rely on file extensions or weak type checks. Research describing Rails applications using CarrierWave and MiniMagick showed that attackers may influence both the input and output formats passed to ImageMagick, enabling abuse of vulnerable coders and delegates beyond expected image types. The reports warned that ImageMagick has a long history of flaws including denial of service, memory corruption, and possible code execution, and demonstrated that output formats such as `INFO` and `EPS3` can leak absolute server paths and ImageMagick version details into generated files. The findings align with OWASP guidance on **unrestricted file upload**, which says unsafe upload handling can lead to code execution, information disclosure, client-side attacks, malware hosting, and service disruption. One proof of concept showed that a crafted JPEG of only about 5 KB, with manipulated dimensions of `64250 x 64250`, could drive ImageMagick to allocate roughly **33 GB** of pixel cache and destabilize a host. Recommended defenses included strict allow-listing of formats such as JPEG, GIF, and PNG; validating magic bytes against extensions before processing; enforcing `policy.xml` resource limits and execution timeouts; restricting upload size; using non-executable and isolated storage; sandboxing image processing; limiting concurrency; and keeping ImageMagick updated.
Aug 15, 2026
A critical vulnerability, tracked as CVE-2025-68428, was discovered in the *jsPDF* library, which is widely used for generating PDFs in JavaScript applications. The flaw allows attackers to exploit local file inclusion and path traversal in the Node.js build of jsPDF by passing unsanitized paths to the `loadFile` method, potentially enabling unauthorized access to arbitrary files on the server. Other affected methods include `addImage`, `html`, and `addFont`, with the vulnerability present in the `dist/jspdf.node.js` and `dist/jspdf.node.min.js` files. The issue has been addressed in jsPDF version 4.0.0, which restricts file system access by default. The vulnerability is remotely exploitable and poses a significant risk to applications that allow user-controlled input to these methods. jsPDF recommends updating to version 4.0.0 or later and, for older Node.js versions, sanitizing user-provided paths before use. Additionally, Node.js environments should leverage the `--permission` flag to further restrict file system access. Organizations using jsPDF in server-side environments are urged to review their implementations and apply the necessary updates or mitigations to prevent potential data breaches or unauthorized file access.
Jun 29, 2026