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
CVE-2026-34311 – Unauthenticated SSRF in Oracle OPERA Property Management System (PMS)
Description: An unauthenticated Server-Side Request Forgery (SSRF) vulnerability has been identified in Oracle Hospitality OPERA 5, versions at and below 5.6.19.24, 5.6.22, 5.6.25.19, 5.6.27.6, 5.6.28. Attackers can leverage the vulnerability to invoke unauthorised requests, interact with the cloud metadata service to steal credentials, and pivot to internal systems.
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:
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
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:
Bypass Validation systematically broke the blocklist.
Potential Attack Scenarios
Cloud Credential Theft: Access AWS/Azure/GCP metadata services to steal IAM credentials
Internal Network Scanning: Port scan internal infrastructure
Data Exfiltration: Access internal databases and APIs
Lateral Movement: Pivot to other internal systems
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.
Last autumn, while a typhoon hammered against the hotel windows, our offensive specialist found themselves locked into a different kind of storm – a pentest that refused to stay routine. What began as a run-of-the-mill exercise quickly spiralled into yet another thrilling adventure of vulnerability disclosure.
This writeup walks through DarkLab’s discovery of a Cross-Site Scripting (XSS) sanitization bypass and a powerful Server-Side Request Forgery (SSRF) vulnerability in Oracle’s OPERA product.[1]
Overview
CVE-2026-21966 – Reflected XSS in Oracle OPERA
CVSS v4.0: 5.1 / MEDIUM / CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N
Description: A reflected cross-site scripting (XSS) vulnerability has been identified in Oracle Hospitality OPERA 5, versions at and below 5.6.19.23, 5.6.25.17, 5.6.26.10, 5.6.27.4, 5.6.28.0. Attackers can leverage the vulnerability to deliver social engineering attacks and execute client-side code in the victim’s browser.
CVE-2026-21967 – SSRF and Credential Disclosure in Oracle OPERA
CVSS v4.0: 8.7 / HIGH / CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:L/SI:L/SA:L
Description: A server-side request forgery (SSRF) vulnerability has been identified in Oracle Hospitality OPERA 5, versions at and below 5.6.19.23, 5.6.25.17, 5.6.26.10, 5.6.27.4, 5.6.28.0. Attackers can leverage the vulnerability to disclose database credentials, invoke POST requests on arbitrary URLs, and enumerate internal networks. The compromised database accounts are used by the OPERA system for business operations and are thus configured with read/write privileges. This may lead to further disclosure of personally-identifiable information (PII) or disruption of business operations if the attacker has access to the database port.
Globally, we observed over 500 Internet-facing Oracle OPERA instances:
Background
Oracle Hospitality OPERA 5 is a Property Management System (PMS) for hotels and resorts, managing core operations like check-ins, reservations, and room allocation — while also offering tools for sales, catering, revenue management, and guest personalization. As such, you would not be surprised to see hotel receptionists and customer support at large chains using this software to handle their everyday operations.
Our testing workstation was a registered OPERA Terminal accessed through a browser. Once login is completed and a tool is selected from the menu, a Java applet pops up.
Figure 1: Sample OPERA login interface
CVE-2026-21966: Reflected XSS and Sanitization Bypass
The Road to XSS
In OPERA, HTTP requests are handled by Java servlets, which are classes with doGet and/or doPost methods. Inside OperaLogin.war, we discovered the OperaPrint servlet which accepts GET requests via a doGet method.
Listing 3: The URL query is reused and concatenated into HTML output.
This provides a trail for reflected XSS. However, the astute would notice that the code sanitizes user input using Utility.sanitizeParameterString. Some people would probably stop here, but let’s Try Harder™. What does this function actually do? Can you spot the flaw? (Please say yes.)
Notice in lines 901 and 906 that _sanitizeParameter is called on a substring. However, the string is extracted starting from the equal sign (=), up to the next ampersand (&; closeTagPosition) or until the end of the string (if closeTagPosition is not found). In other words, only the parameter value is extracted for sanitization. The parameter name is not sanitized.
This means the sanitization function could be bypassed using a query parameter such as /path?'name=value.
(Un)Fortunately, while such a payload may succeed on older or lesser-known browsers, it fails to bypass modern browser filters, which will automatically URL-encode the single quote ' to %27 before firing the HTTP request.
Despite this roadblock, we were able to bypass the sanitization function and browser protection with an alternative method.
A More Robust Sanitization Bypass
We used another trick, which is to use a HTML-entity ' instead of the single-quote literal. Normally, this trick would not work if the payload was reflected inside <script> tags. But in the context of a HTML attribute such as onload="...", the ' entity is treated as a literal quote, allowing us to escape the string context and run arbitrary JavaScript from the browser.
CVE-2026-21967: SSRF and Credential Disclosure
An SSRF is a vulnerability where an attacker tricks a web application into making unauthorized, unintended, or forged requests to internal or external resources. Attackers may exploit SSRFs to call privileged endpoints or exfiltrate sensitive data placed in cookies, headers, and parameters.
By reviewing yet another Java servlet (OperaServlet), we discovered a parameter named urladdress. This by itself is a huge code smell.
Listing 4: Servlet contains a urladdress parameter.
Following the taint trail, we arrived at the callreport function. This function opens a URL connection to an attacker-controlled address and returns any data received.
We were able to confirm the SSRF vulnerability by testing on a local port with netcat listening, then an online webhook service. Notably, we found that plaintext database credentials could be disclosed when a specific parameter is provided.
Figure 5: Left- Attacker-controlled server which receives the SSRF request. Credentials are disclosed in the dbuser/dbpswd@dbschema format. Such hospitality! Right- The crafted request was sent through curl.
Figure 6: Same demonstration but using an online webhook site to demonstrate the remote nature and exploitability.
Figure 7: We were able to enumerate and login to the database server using sqlplus.
In addition to demonstrating remote exploitability, Figure 6 also shows that the HTTP response from the target server (in this case, webhook[.]site) is reflected. An attacker can abuse this by disclosing information on subsequent systems.
We verified these credentials by enumerating the OPERA database host and connecting with sqlplus, an SQL client for Oracle Database. A few seconds later, we’re in!
Inside the database, it was possible to view room allocations, customer names, and emails, among other details.
Impact
CVE-2026-21966: Reflected XSS
Attackers can induce victims to run arbitrary client-side JavaScript, compromising confidentiality and integrity of the victims’ browser session. Attackers can exploit this to proxy through the victim’s browser and potentially perform authenticated requests to Oracle OPERA or other systems on behalf of the victim. This may allow attackers to establish a foothold on the internal network through a social engineering attack.
CVE-2026-21967: SSRF and Credential Disclosure
We have identified multiple impacts for CVE-2026-21967:
Credential Disclosure; Potential Database Access and Customer Information Disclosure. Most concerningly, successful exploitation could lead to the disclosure of database credentials which are used by OPERA for business operations, enabling unauthorized read/write access to the database and password spraying of the corporate network.
POST Request SSRF. By convention, POST requests are used to modify, create, or delete data. In general, they are used to perform more complex tasks compared to GET requests. An SSRF with the capability to send POST requests tends to be more dangerous as it may trigger these complex behaviors, which potentially include disrupting subsequent systems, modifying application data, or exploiting other vulnerabilities.
Social-Engineering Attacks. Since the HTTP output is attacker controllable, it is possible to deliver arbitrary HTML. Attackers can abuse the trust of an OPERA domain to deliver malicious payloads which run in a victim’s browser.
Enumerate Internal Network. An attacker can enumerate the internal network by port scanning or observing the HTTP response, which is reflected from the subsequent system. (This is your typical SSRF impact.) Figure 8 shows the enumeration of common Windows ports (135, 3389) in addition to various Oracle ports.
Figure 8: Sample impact: enumerate ports on the localhost machine.
Proof of Concept
During our discovery of CVE-2026-21966 and CVE-2026-21967, we successfully developed a Proof-of-Concept (POC) for both flaws. However, given the sensitivity of CVE‑2026‑21967 in particular, we have chosen not to release these POCs publicly.
Are you susceptible?
You can follow these steps to verify your Oracle Hospitality OPERA version:
Login to OPERA.
Select any tool. The version should be displayed in the window title.
For detailed version information, select the rightmost “Help” tab.
If you believe you are susceptible to CVE-2026-21966 and/or CVE-2026-21967 and are seeking additional details, please do not hesitate to contact us directly for further guidance.
Remediations
Upgrade to the latest versions of Oracle Hospitality OPERA.
Apply network segmentation between the internal network and Oracle Hospitality OPERA services.
Limit outbound traffic to suspicious sites and domains. Ideally, whitelist allowed destinations.
Do not expose Oracle Hospitality OPERA to the public internet.
Detection Opportunities
In addition, we strongly recommend continuous monitoring of Oracle Hospitality OPERA instances for potential indicators of attack, such as unusual incoming HTTP requests containing Cross-Site Scripting (XSS) payloads or unauthorized data modification. Further, we advise Web Application Firewall (WAF) coverage for Oracle Hospitality OPERA 5 deployments exposed to the internet to detect/block common XSS payloads.
YARA Rule:
rule CVE_2026_21966
{
meta:
description = "Detection of CVE-2026-21966"
author = "PwC DarkLab"
date = "2026-02"
reference = "CVE-2026-21966"
severity = "medium"
strings:
$path = "OperaPrint" ascii nocase
$apos_entity = "&apos" ascii nocase
condition:
$path and $apos_entity
}
rule CVE_2026_21967
{
meta:
description = "Detection of CVE-2026-21967"
author = "PwC DarkLab"
date = "2026-02"
reference = "CVE-2026-21967"
severity = "high"
strings:
$path = "OperaServlet" ascii nocase
$status = " 200 " ascii
$a = /o.*?p.*?e.*?r.*?a.*?d.*?s/i
$b = /urladdress\s*?=.*?h.*?t.*?t.*?p.*?.*?:/i
condition:
$path and
$status and
$a and $b
}
Save the above file as rules.yar and run the following on your Oracle Application Server. By default, the logs are stored in D:\ORA\user_projects\domains\OperaOHSDomain\servers\ohs1\logs.
We hope you enjoyed this walk through of our team’s discovery of CVE-2026-21966 and CVE-2026-21967 in Oracle Hospitality OPERA 5 – a widely deployed property management system essential to hotel operations. As earlier mentioned, to protect our clients and the broader hospitality industry, we intentionally omitted the Proof-of-Concept and highly technical information that could otherwise be abused by malicious actors to weaponize these vulnerabilities.
The most severe, a Server-Side Request Forgery (SSRF) with a high CVSS v4.0 score of 8.7, allows attackers to disclose sensitive database credentials, potentially leading to unauthorized access to vast amounts of guest Personally Identifiable Information (PII) like names, emails, and room allocations. This could also enable internal network enumeration and operational disruption.
This risk is profoundly amplified in the hospitality sector, where open Wi-Fi networks potentially introduce avenues to infiltrate the internal network; therefore, merely restricting public internet access for OPERA systems is insufficient. Robust network segmentation, immediate patching, and comprehensive security controls are absolutely critical to safeguard customer data, maintain business continuity, and protect brand reputation.
General Best Practices
To effectively safeguard critical systems like Oracle Hospitality OPERA and the sensitive data they manage, organizations must adopt a comprehensive, multi-layered security strategy. Beyond specific vulnerability patches and remediation advice, the following best practices are crucial for maintaining a strong security posture:
Robust Patch and Vulnerability Management:
Timely Updates: Establish and enforce a rigorous process for promptly applying security patches and updates to all operating systems, applications (including Property Management Systems), databases, and network devices.
Active Attack Surface Management (ASM): Continuously discover, inventory, and assess all internet-facing assets and their potential vulnerabilities. This should include regular penetration testing and security audits by independent third parties to identify weaknesses before attackers do.
Network Segmentation and Isolation:
Isolate Critical Systems: Implement strict network segmentation to logically separate critical systems (e.g., OPERA servers, database servers) from less trusted networks, such as guest Wi-Fi, corporate office networks, and other non-essential segments.
Zero Trust Principles: Apply Zero Trust principles, ensuring that no user, device, or application is inherently trusted, regardless of its location. All access requests must be authenticated, authorized, and continuously validated.
Strict Egress Filtering: Implement outbound firewall rules to limit critical systems’ ability to connect to arbitrary external or internal destinations. Whitelist only absolutely necessary connections to prevent data exfiltration and command-and-control communications.
Enhanced Security Monitoring and Incident Response:
24×7 Security Operations Centre (SOC): Leverage a 24×7 Security Operations Center (SOC) for continuous monitoring of security logs, network traffic, and system behaviour. This enables rapid detection of anomalous behaviour and indicators of compromise (IOCs).
Advanced Threat Detection: Deploy Intrusion Detection/Prevention Systems (IDS/IPS), Security Information and Event Management (SIEM) systems, and Endpoint Detection and Response (EDR) solutions to provide deep visibility and automated threat response capabilities.
Incident Response Plan: Develop, regularly test through tabletop exercises and simulations, and refine a comprehensive incident response plan to ensure rapid detection, containment, eradication, and recovery from security breaches.
Principle of Least Privilege and Strong Authentication:
Role-Based Access Control (RBAC): Implement granular Role-Based Access Control (RBAC) to ensure that users and system accounts only have the minimum necessary permissions to perform their assigned functions.
Multi-Factor Authentication (MFA): Enforce Multi-Factor Authentication (MFA) for all administrative access, remote access, and privileged user accounts across all critical systems to significantly reduce the risk of credential compromise.
Credential Management: Implement strong password policies, regularly rotate credentials, and securely manage secrets, avoiding hardcoded or easily discoverable credentials within code or configuration files.
Secure Development and Configuration:
Secure Coding Practices: For custom applications or integrations, ensure developers adhere to secure coding guidelines, including robust input validation and output encoding to prevent common web vulnerabilities like Cross-Site Scripting (XSS) and Server-Side Request Forgery (SSRF).
Hardening Baselines: Apply secure configuration baselines to all operating systems, databases, and applications, disabling unnecessary services, features, and default accounts.
Data Protection and Resilience:
Encryption: Encrypt sensitive data at rest (e.g., database encryption, disk encryption) and in transit (e.g., TLS for all communications) to protect it from unauthorized access.
Regular Backups: Implement a robust, tested, and isolated backup and recovery strategy for all critical data and system configurations to ensure business continuity and data availability in the event of a compromise or disaster.
Timeline
Sept. 19, 2025. Discovered first issue (Reflected XSS, now tracked as CVE-2026-21966).
Oct. 12, 2025. Discovered second issue (SSRF and Credential Disclosure, now tracked as CVE-2026-21967).
Oct. 20, 2025. Vulnerability report sent to Oracle Security Alerts.
Jan. 15, 2026. Pre-release announcement by Oracle.
Jan. 20, 2026. Public disclosure by Oracle.
Feb. 13, 2026. Technical writeup and disclosure by 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/cpujan2026.html.
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.
