Another Byte Bites the Dust - How XBOW Turned a Blind SSRF into a File Reading Oracle

After announcing that XBOW was the top bug bounty hunter in the US, we were flooded with requests to share some of its most intriguing discoveries. The one I’m about to share is probably my favorite (and I have seen a lot of really interesting and mind blowing exploits). Unfortunately, we are not able to share the name of the Hacker One program XBOW found this vulnerability in, but since it’s an OSS project and the issue has been fixed, we will be sharing the details of how XBOW found this bug redacting any mentions to the vulnerable servers. We're excited to reveal how XBOW successfully exploited an application designed for rendering map tiles from various geospatial data formats. The result? A complete arbitrary local file read vulnerability achieved through an ingenious byte-by-byte exfiltration technique.

The vulnerable application is called TiTiler, an application designed for rendering map tiles from various geospatial data formats. XBOW’s assessment of the application led to a complete arbitrary local file read vulnerability, achieved through an ingenious byte-by-byte exfiltration technique.

From URL to Arbitrary File Read in 48 Steps

The Journey Begins

XBOW started its reconnaissance by exploring the target application, immediately hitting a 403 Forbidden response. Rather than being deterred, it used concurrent Python requests to test common API paths. This systematic approach quickly paid off with two critical discoveries:

The OpenAPI documentation was a goldmine. Since XBOW was specifically tasked with finding SSRF vulnerabilities, it immediately began scanning for endpoints that accepted URL parameters. The search revealed multiple promising candidates, all related to geospatial data processing:

• COG (Cloud Optimized GeoTIFF) endpoints
• STAC (SpatioTemporal Asset Catalog) handlers
• MosaicJSON processors

These endpoints typically allow users to specify remote dataset URLs for server-side processing - a classic SSRF scenario waiting to be exploited.

First Contact: Confirming the SSRF

XBOW's initial test was straightforward: it attempted to access a controlled interactsh server through the /cog/info endpoint. The test confirmed the vulnerability immediately:

The interactsh server received both HEAD and GET requests from the target, with the GET request including a Range header attempting to read bytes 0-71.

However, the server responded with an error that revealed crucial information:

{"detail":"'/vsicurl/http://d12gh236h0ste95n4j40tyeko35ipgg8z.xfil.xbow.ltd/test_ssrf' not recognized as a supported file format."}

This error was incredibly valuable - it revealed that the application was using GDAL's Virtual File System (VSI) with the cURL driver (/vsicurl/) to access remote files, expecting them to be in geospatial formats like GeoTIFF.

When XBOW attempted to directly access the flag at http://ssrf.xd9.wf/, it encountered its first major hurdle:

{"detail":"Failed to find <imageAttributes> in document."}

This response indicated that while the HTTP request succeeded, the server expected XML data with specific <imageAttributes> tags. The flag content didn't conform to the expected XML schema, so the server refused to process it further.

The Breakthrough: VRT Files to the Rescue

Faced with this formatting constraint, XBOW had a brilliant insight: if direct flag access wasn't possible, perhaps it could use an indirect approach. Enter VRT (Virtual Raster Format) files - XML-based GDAL files that can define datasets by referencing other files, including remote ones.

XBOW crafted its first VRT file:

This VRT file was successfully recognized by the server (receiving a 200 OK response), confirming that GDAL could process VRT files and had likely attempted to access the referenced flag URL.

Exploring the GDAL Ecosystem

XBOW was on step 21 at this point. At this point, XBOW started using its deep knowledge of GDAL's capabilities and systematically tested various Virtual File System (VFS) modules such as:

• /vsihttp/: An alternative to /vsicurl/ without cURL dependencies
• /vsicurl_streaming/: A streaming variant that might handle SSL differently
• /vsizip/ and /vsitar/: For compressed archive handling
• /vsimem/: For in-memory file operations
• /vsiwebhdfs/ and /vsistdin/: Additional specialized handlers

During the following steps XBOW also experimented with embedding Python code within VRT files:

And attempted XXE (XML External Entity) attacks:

But let's fast forward to step 41 where XBOW had a major breakthrough.

The Eureka Moment: Raw Pixel Data

At step 41, XBOW had its breakthrough insight. If the server was interpreting file contents as pixel data, why not leverage this behavior? The idea was elegant: create a VRT that treats the flag content as raw pixel data, then extract it from the resulting image.

The /cog/preview.png endpoint successfully processed this VRT, returning a 64x1 pixel PNG image where each pixel's value corresponded to a byte from the flag URL!

This is the image that XBOW got:

Figure/Alt Text: The 'image' that held the secret: A visual representation of the raw pixel data containing the flag.

Decoding the Hidden Message

The returned PNG contained the flag data compressed within its IDAT chunk. XBOW's analysis revealed:

• Image dimensions: 64x1 pixels, 8-bit gray+alpha
• IDAT chunk: 100 bytes of compressed data
• Decompressed 129 bytes (1 filter byte + 128 pixel bytes)

The first attempt to decompress the IDAT chunk failed:

The crucial insight was that PNG scanlines use filtering algorithms. The data wasn't raw - it was filtered using the Sub filter (type 1), where each byte represents the difference from the previous pixel. XBOW implemented the unfiltering algorithm:

After unfiltering and extracting the gray channel values, XBOW successfully decoded:

The candidate flag was promising, we just need more of it! With the technique proven, XBOW expanded the VRT to read larger amounts of

This successfully extracted the complete flag:

From Network to Local: File System Access

With SSRF-to-file-read proven, XBOW's coordinator agent decided to test local file access. The transition was simple but powerful - replacing the network URL with a local file path:

This opened the door to arbitrary local file reading using the same pixel-data extraction technique.

Creative Alternatives: Statistical Analysis

This vulnerability was discovered not once, but twice by XBOW! In a parallel run, XBOW took a similar but particularly creative approach, XBOW discovered that the /cog/statistics endpoint could be used to analyze the histogram of byte values in files:

The /statistics endpoint returned a 200 OK response with the following JSON:

The histogram revealed character frequencies and could be used to reconstruct file contents. Converting the byte values to ASCII revealed characters like '/', '<', '>', 'a', 'b', 'd', 'e', 'h', 'l', 'm', 'o', 't', 'y' - clearly indicating XML content structure (The real content of http://ssrf.xd9.wf/METADATA.DIM was just <html><head></head><body></body></html>)

This was pretty cool but not very practical. Let’s let XBOW explain why and plot a different approach.

That last idea was simple but brilliant; try different endpoints such as /cog/crop and /cog/point to try to fetch individual pixels:

First attempt failed, but XBOW motto is to try harder:

Precision Reading: Byte-by-Byte Exfiltration

XBOW hit a wall again, but then its creative problem-solving kicked in. What about combining the two approaches? Let's try a VRT that reads a single byte but instead of fetching the image, let's fetch the histogram of the byte values. This will reveal the flag bytes.

For the ultimate precision, XBOW developed a technique to read files one byte at a time by adjusting the ImageOffset parameter:

This technique could systematically extract any file, one byte at a time, with perfect accuracy.

Having read the first 64 bytes of http://ssrf.xd9.wf/METADATA.DIM using the VRT byte-by-byte technique with /cog/statistics, all its left to do is to point the script to the flag:

This time, it took 32 iterations to find and exploit a complex arbitrary file read/SSRF involving little-known formats and standards, hats off!

I loved this bug so much that I wrote a small TUI for it to watch it develop:

Impact

While the technical details of this exploit are fascinating, it's crucial to understand the potential real-world impact of such a vulnerability. We assessed the impact by reading critical files such as /proc/self/environ and shared them via HackerOne which assigned a Critical (9.3) severity to the finding.

The Remarkable Achievement

In just 32 steps and under 14 minutes, XBOW transformed a simple blind SSRF vulnerability into a complete arbitrary file read capability. The attack chain demonstrated:

1. Reconnaissance: Systematic API discovery and documentation analysis
2. Vulnerability Identification: SSRF confirmation through controlled testing
3. Constraint Analysis: Understanding GDAL's format expectations
4. Creative Problem Solving: Leveraging VRT files as an intermediary
5. Deep Technical Knowledge: Understanding PNG compression, filtering, and GDAL internals
6. Iterative Refinement: Multiple approaches from bulk reading to byte-by-byte precision
7. Horizontal Expansion: Pivoting from network SSRF to local file access

What makes this particularly impressive is how XBOW seamlessly navigated complex technical domains - from web application security to geospatial data processing, from PNG image formats to GDAL virtual file systems. XBOW demonstrated not just technical knowledge but creative problem-solving that would challenge even experienced security researchers.

The elegance of the final solution - embedding arbitrary file contents as pixel data in generated images - showcases the kind of lateral thinking that makes XBOW such a formidable security testing tool. It didn't just find a vulnerability; it crafted a complete data exfiltration framework that could be adapted for various scenarios.

This case study perfectly illustrates why XBOW has become the top bug bounty hunter in the US - it combines comprehensive technical knowledge with creative problem-solving and relentless persistence, all wrapped in an automated system that can work around the clock.

Stay tuned for our next post where we'll dive into how XBOW escaped the Python sandbox to achieve remote code execution in the same application.