CVE-2023-2766

What it actually does

CVE-2023-2766 is a remotely exploitable information disclosure weakness in Weaver Office Automation (OA) 9.5. The issue exposes the configuration file path /building/backmgr/urlpage/mobileurl/configfile/jx2_config.ini, allowing an unauthenticated remote attacker to access files or directories that should not be publicly readable. The primary impact is confidentiality loss: exposed configuration data may include internal application settings, paths, integration details, service endpoints, or other sensitive operational information that can support follow-on compromise.

Why it matters to the business

An exposed Weaver OA system may leak sensitive configuration information to anyone on the network or internet who can reach the vulnerable endpoint. Because public exploit information is available, EPSS is elevated, and exploit maturity is weaponized, internet-facing deployments should be treated as high-priority even though the issue is not currently listed in CISA KEV. Business consequences may include disclosure of internal system details, accelerated attacker reconnaissance, loss of confidentiality, increased likelihood of chained attacks, and potential exposure of business workflow infrastructure used by employees.

How an attack unfolds

An attacker first identifies a Weaver OA 9.5 instance, commonly by scanning for exposed OA web interfaces. They then send a direct HTTP request to the vulnerable configuration file location, /building/backmgr/urlpage/mobileurl/configfile/jx2_config.ini. If the server is vulnerable and the file is accessible, the application or web server returns the contents of the configuration file without authentication. The attacker reviews the disclosed data for application paths, service addresses, credentials or credential-adjacent values, mobile integration settings, internal naming conventions, or other clues. That information can then be used to plan follow-on attacks such as credential guessing, targeting internal services, locating additional exposed files, or chaining with separate Weaver OA vulnerabilities.

How to fix it

Upgrade Weaver OA to a vendor-supported release that is not affected by this file exposure issue. No authoritative fixed version was provided in the supplied advisory data, so organizations should obtain remediation guidance directly from Weaver, apply the latest available security updates, and verify that the affected path is no longer reachable without authentication. As compensating controls, restrict external access to Weaver OA, require VPN or trusted network access for administrative and mobile configuration paths, block direct web access to /building/backmgr/urlpage/mobileurl/configfile/jx2_config.ini, review web server rules for unintended static file exposure, and ensure sensitive configuration files are stored outside the web root or protected by explicit deny rules.

How to confirm the fix worked

Confirm exposure by attempting to access the affected path from an unauthenticated context: /building/backmgr/urlpage/mobileurl/configfile/jx2_config.ini. A remediated system should return a denial or not-found response, such as HTTP 403 or 404, and must not return configuration file contents. Validate from both internal and external network perspectives if the application is internet-facing. Review web server and application routing rules to confirm .ini files and configuration directories are not publicly served. If an upgrade or mitigation was applied, repeat the test after cache clears and from a clean session with no cookies or authentication headers.

Typical attack path

1. Scan the internet or target network for exposed Weaver OA web applications.
2. Fingerprint the application version or confirm Weaver OA-specific URL structures.
3. Send an unauthenticated HTTP GET request for /building/backmgr/urlpage/mobileurl/configfile/jx2_config.ini.
4. If the request succeeds, download and inspect the exposed configuration content.
5. Extract sensitive configuration values, internal paths, service names, or integration details.
6. Use the disclosed information to support additional reconnaissance, lateral targeting, credential attacks, or exploitation of other application flaws.

How to detect it

To determine whether this was already exploited, review HTTP access logs, reverse proxy logs, WAF logs, CDN logs, and endpoint web server logs for unauthenticated requests to /building/backmgr/urlpage/mobileurl/configfile/jx2_config.ini. Prioritize events with HTTP 200 responses, nonzero response sizes, repeated requests from the same source, requests followed by additional probing of Weaver OA paths, or requests from scanners and unfamiliar geographies. Search for URL-encoded variants, case changes, and traversal-style attempts that target the same file. If the vulnerable file was exposed, inspect application logs for subsequent suspicious authentication attempts, administrative path access, mobile URL configuration probes, and requests to other configuration or backup file extensions. For forensic triage, preserve relevant access logs and compare timestamps of successful file access with later activity against services, hostnames, or paths that may have been disclosed in the configuration.

• /building/backmgr/urlpage/mobileurl/configfile/jx2_config.ini
• GET /building/backmgr/urlpage/mobileurl/configfile/jx2_config.ini
• POST /building/backmgr/urlpage/mobileurl/configfile/jx2_config.ini
• /building/backmgr/urlpage/mobileurl/configfile/
• jx2_config.ini
• %2Fbuilding%2Fbackmgr%2Furlpage%2Fmobileurl%2Fconfigfile%2Fjx2_config.ini
• /building/backmgr/urlpage/mobileurl/configfile/jx2_config.ini HTTP/1.1
• "GET /building/backmgr/urlpage/mobileurl/configfile/jx2_config.ini" 200

What your security team should do

• Prioritize assessment of all internet-facing Weaver OA deployments because exploit code is public, exploit maturity is weaponized, and EPSS indicates meaningful exploitation likelihood.
• Immediately test whether /building/backmgr/urlpage/mobileurl/configfile/jx2_config.ini is reachable without authentication on exposed Weaver OA systems.
• Apply the latest Weaver OA security updates or migrate to a supported fixed release after confirming vendor guidance.
• Until patched, restrict Weaver OA access to trusted networks, VPN users, or allowlisted source addresses.
• Add web server deny rules for the affected path and for direct access to sensitive file types such as .ini, .conf, .properties, and backup files where appropriate.
• Search historical web access logs for requests to the vulnerable path and investigate any successful 200 responses or large response bodies.
• If exploitation is suspected, rotate any secrets or credentials that may have appeared in the exposed configuration and review downstream systems referenced by the file.
• Monitor for follow-on activity against Weaver OA endpoints, authentication portals, mobile integration paths, and internal service names disclosed by the configuration file.