Everyone is obsessing over which model powers their security agent. Is it the largest? The most expensive? The one topping the benchmarks?

We took a different bet. We ran with GLM-4.7 and uncovered CVE-2026-34311, a critical   unauthenticated SSRF in Oracle OPERA PMS (again!). GLM-4.7 is certainly not the flashiest model on the market, but instead it strikes a balance between cost and efficiency.

Our takeaway?

While the models do matter, a well-designed workflow or harness allows a lower-tier model to match the performance of a higher-tier one.

Large language models are capable of performing a multitude of complex tasks. But on their own, the models suffer from setbacks we’re well familiar with: limited context windows and a high signal-to-noise ratio (many false positives!). Human effort is wasted in the effort of plumbing prompts and validating nonsensical reports. A well-designed workflow mitigates these limitations and unlocks the full potential of an LLM — even with mid-tier models.

Here is our structured approach.

The Audit Workflow

We don’t just run tools; we use a multi-agent communication and supervision pipeline. By having agents cross-review and supervise each other, we minimize hallucinations, maintain a high completion rate, and ensure zero blind spots.

Why this works:

• Parallel auditing: Specialized perspectives independently audit the   entire   codebase.
• Mutual supervision: Agents cross-review each other’s findings. If one perspective misses a bypass, another catches it.
• Strict evidence rules: A finding is rejected unless it points to a real file, a real line number, and a reproducible path.

CVE-2026-34311: Unauthenticated SSRF in Oracle OPERA PMS

Where is the Bug?

The flaw exists in the HXInterfaceProxy &nb  sp;servlet (WebClientProxy.java). Our workflow identified two critical failures:

1. No Authentication Required. The web.xml explicitly disables authorization:

<context-param>
<param-name>requireAuthorization</param-name>
<param-value>N</param-value> <!-- Anyone can access -->
</context-param>

2. Trivial Blocklist Bypass. The server reads the MF-WSCP-DESTINATION-URL header and makes a request to that URL. The “protection” is just a weak string-contains check:

if (var13 == null || !var13.toLowerCase().contains("//localhost:") 
    && !var13.contains("//127.0.0.1:")) {
    // Request allowed! Insufficient validation.
}

No IP resolution. No private range blocking. No cloud metadata protection.

By following the code flow, the agent determined that the destination URL is extracted from the request and later used to create an outbound HTTP connection. The validation in WebClientProxy.java only checks a limited set of localhost string patterns before forwarding the request.

// WebRequest.java:74 - Extracts the user-controlled destination URL from the request
this.destinationURL = this.removePIValue("DESTINATION-URL", var8);
// WebRequest.java:154-157 - Uses the extracted destination URL to create an outbound request
HTTPResponse forwardRequest(String var1) {
    URL var3 = new URL(this.destinationURL);
    HTTPConnection var4 = new HTTPConnection(var3);
    // ...
}
// WebClientProxy.java:60 - Performs only limited localhost string checks before forwarding
if (var13 == null || !var13.toLowerCase().contains("//localhost:".toLowerCase())
    && !var13.contains("//127.0.0.1:")) {
    HTTPResponse var15 = var12.forwardRequest(var10);
}

Impact and Validation Summary

The vulnerable servlet accepts a user-controlled destination URL through the MF-WSCP-DESTINATION-URL header and initiates outbound requests on behalf of the server. Due to insufficient validation and the absence of effective restrictions on internal or sensitive network destinations, the application may be coerced into accessing unintended resources.

The issue was validated in a controlled testing environment. Detailed exploit commands, request headers, and bypass payloads have been intentionally omitted from this public write-up.

The URL validation mechanism relies on a limited string-based blocklist and does not perform comprehensive hostname resolution or network destination validation. As a result, alternative address representations may not be adequately restricted.

How the Workflow Caught This

A single model might have seen the blocklist and concluded the risk was limited. Our workflow caught this by correlating separate findings into a single critical attack chain:

1. Authentication Review caught requireAuthorization=N.
2. SSRF Analysis caught the user-controlled URL header.
3. Cross-Review combined them: Unauthenticated + SSRF + weak blocklist = Critical.
4. Bypass Validation systematically broke the blocklist.

Potential Attack Scenarios

1. Cloud Credential Theft: Access AWS/Azure/GCP metadata services to steal IAM credentials
2. Internal Network Scanning: Port scan internal infrastructure
3. Data Exfiltration: Access internal databases and APIs
4. Lateral Movement: Pivot to other internal systems
5. Chained RCE: Combine with other vulnerabilities for remote code execution

Timeline

• Mar. 05, 2026:   Discovered Unauthenticated Server-Side Request Forgery (SSRF) (now tracked as CVE-2026-34311).
• Mar. 07, 2026:   Vulnerability report sent to Oracle Security Alerts.
• May. 22, 2026:   Pre-release announcement by Oracle.
• May. 28, 2026:   Public disclosure by Oracle.
• May. 29, 2026:   Technical writeup and disclosure by Alex Lee @PwC DarkLab HK.

Acknowledgements

Special thanks to the Oracle Security Alerts team for coordinated disclosure. For more information about recent vulnerabilities affecting Oracle Hospitality, please read the advisory published by Oracle: https://www.oracle.com/security-alerts/cspumay2026.html.

CVE-2026-34311 was discovered by Alex Lee.

Further Information

We are committed to protecting our clients and the wider community against the latest threats through our dedicated research and the integrated efforts of our red team, blue team, incident response, and threat intelligence capabilities. Feel free to contact us at [darklab dot cti at hk dot pwc dot com] for any further information.