When the relentless pwn.ai encounters a target with nothing interesting except an upload box, most seasoned pentesters test the known attack classes and move on. pwn doesn't. We taught it not to. You may know Octagon Networks' research from many bugs, for example, a bug where, when the PHP pattern is too secure, instead of giving up, we reversed the PHP function, fuzzed the method, and found a zero-day in the underlying language, which we wrote about here . As pwn's teachers, and as seasoned hackers, we wanted to teach it our ways, and how real, determined attackers research. For this reason, pwn knows it's a matter of time until it breaks in, even if all there is is an empty upload box. In this case, pwn ended up discovering multiple file write and file read issues affecting millions of servers by default by targeting ImageMagick, across multiple configurations: file leaks, remote code execution, and security policy bypasses. The pentesting capabilities of pwn are, frankly, quite scary. It is clearly up to par with world class hackers. The level of depth and breadth we get to cover in a matter of days is absolutely incredible and is not typical of any other pentest. This is the story of how pwn.ai spent nearly five days autonomously researching ImageMagick internals in an attempt to break into a customer site: probing every coder, delegate, protocol handler, and format detection mechanism to chain together a series of vulnerabilities that achieve highest impact imaginable through a single image upload. On the default configuration. On the recommended "production-safe" configuration. On the maintainer's own suggested mitigation. And on their most restrictive "secure" configuration. What started as a single client engagement turned into the discovery of multiple zero-day vulnerabilities affecting every major Linux distribution, WordPress installations worldwide, and the entire ImageMagick security policy architecture. We'll let you enjoy the following heavily redacted almost a week long trace and zerodays ;) The Target The client was running a web application with a minimal attack surface. No APIs or interesting fields, it is used to process invoices and there is no client-side JavaScript of interest. The most interesting functionality appears to be an upload box. Uploaded files were processed by ImageMagick; the ubiquitous image processing library installed on millions of servers. The system was up to date running Ubuntu 22.04 (#1 server setup right now). No known CVEs applied. No obvious misconfiguration. pwn.ai identified ImageMagick as the primary attack vector. Given there was nothing else on the application, the agent did something unusual: it downloaded ImageMagick into its own sandboxed environment and began a multi-day, systematic audit of the entire processing pipeline. The Research [00:42:02] new objective : achieve zeroday RCE through ImageMagick file upload pwn.ai thought → The target processes uploaded images with convert . The attack surface is whatever ImageMagick does with attacker-controlled file content. I need to understand format detection, coder selection, delegate invocation, and policy enforcement as there are no known CVEs for this version. Day 1 — Format Detection Bypass The agent's first discovery was fundamental: ImageMagick doesn't trust file extensions. [04:12:33] action : test format detection across extensions [04:12:41] obs : file named photo.jpg containing <?xml at byte 0 → IM detects as SVG, ignores .jpg extension [04:13:02] confirm : tested across 13 extensions (.jpg .png .gif .mov .mp4 .docx ...) ALL detected as SVG when content starts with <?xml [04:13:15] finding : extension-based upload filtering is completely bypassed by content-based magic byte detection pwn.ai thought → This is an interesting behavior. Any upload filter that checks file extensions is irrelevant. I can deliver SVG payloads disguised as any file type. Now I need to find what SVG processing can reach. Day 1-2 — Mapping the MSVG Renderer Attack Surface [08:44:12] action : audit SVG <image xlink:href="..."> handler [08:44:30] obs : MSVG renderer passes href values through ReadImage() which supports IM's internal coder prefix syntax [08:45:01] test : <image xlink:href="text:/etc/passwd"/> [08:45:03] result : /etc/passwd content rendered as text in output image [08:45:07] finding : ARBITRARY FILE READ — any file readable by the IM process is rendered into the output image via text: coder pwn.ai thought → File read confirmed. The output image that gets returned to the user contains the target file's content rendered as visible text. This is already critical vulnerability in my customer's server. AWS credentials in /proc/self/environ, SSH keys, .env files, application secrets. But I need to focus on more impactful escalations. [12:31:44] action : enumerate PostScript-related coders [12:31:52] obs : Ubuntu 22.04 default policy blocks: PS, PS2, PS3, EPS, PDF, XPS [12:32:08] obs : policy does NOT block: EPSI, E...