Three chained CVEs in Eptura Archibus deliver unauthenticated RCE and full database read, affecting a platform used by 16,000 organizations including 40% of the Fortune 500. Key findings: - CVE-2026-107186 (CVSS 8.6) is the root cause: a Java Direct Web Remoting (DWR) batch-call race condition lets an unauthenticated attacker chain two methods in a single POST to /archibus/dwr/call/plaincall/Multiple.2.dwr. The whitelisted SecurityService.isPasswordUppercase() method internally calls loadTableDef(), which writes a privileged core user session into the thread-local ContextStore. Because DWR processes batch calls sequentially on the same thread, the immediately following DWRWorkflowService.runWorkflowRule() call inherits that session and executes as authenticated. The only prerequisites are a JSESSIONID (obtained by browsing to /archibus/login.axvw) and a PROJECT_ID (obtained via an unauthenticated call to SecurityService.getProjects). - CVE-2026-107187 (CVSS 8.5) chains directly off the auth bypass to invoke the AbCommonResources-getDataRecords workflow, which passes a caller-controlled restriction parameter directly into a SQL query against any Archibus-managed table. The PoC queries the afm_users table for user_name, user_pwd, email, and role_name with restriction set to 1=1, dumping all credentials in plaintext in the JSON response. - CVE-2026-107188 (CVSS 9.6 Critical) is the RCE path: the AbCommonResources-writeHTMLtoFile workflow writes attacker-controlled content to disk using an attacker-controlled file extension with no validation (ViewHandlers.writeHTMLtoFile in the source). The server returns the browsable output path under /archibus/schema/per-site/exportReports/. Uploading with a .jspx extension bypasses the authentication redirect that .jsp files trigger, so browsing to the file executes the embedded Java code. Rapid7 confirmed RCE on a live Vector Command customer server, with code running as NT AUTHORITY/Local Service. - For responders: the attack surface is HTTP-reachable Archibus Web Central with no credentials required. The upload lands in a predictable path (/archibus/schema/per-site/exportReports/) with a DataViewReport prefix and a timestamp before the .jspx extension. Hunting starts there: check that directory for unexpected .jspx or .jsp files, review web server access logs for POST requests to /archibus/dwr/call/plaincall/Multiple.2.dwr with callCount=2 where one parameter references isPasswordUppercase and another references writeHTMLtoFile or getDataRecords, and treat any outbound activity from the Java application server process as post-exploitation. Takeaway: patch to Archibus 2025.02 or higher, which moves the vulnerable DWR method to a REST API, closing the batch-call chaining primitive entirely. If you cannot patch immediately, audit the exportReports directory for webshells and pull DWR access logs for callCount=2 batch requests hitting SecurityService.isPasswordUppercase. This was found during a red team engagement on an active customer environment, meaning opportunistic exploitation of internet-exposed instances is a realistic near-term threat given the Fortune 500 footprint. The disclosure timeline in Rapid7's report shows repeated non-response from Eptura before a fix was confirmed, so verify your version is actually patched and not just recently released. #DFIR_Radar