~/f4n6 $ grep -r "Eptura Archibus auth bypass and RCE flaws expose Fortune 500 firms to critical risk" ./investigations/ --include="*.md"

Eptura Archibus auth bypass and RCE flaws expose Fortune 500 firms to critical risk

Jeff Davies 19 Oct 2026 8 min read

1. Executive summary

Rapid7 disclosed three vulnerabilities in Eptura Archibus Web Central, a facilities and real estate management platform that Eptura states was used by over 16,000 companies and 40% of the Fortune 500 in 2023. A legacy Java Direct Web Remoting (DWR) endpoint lets an unauthenticated attacker run arbitrary workflow rules (CVSS 8.6 High), which chains to full database read including usernames and password hashes (CVSS 8.5 High) and to an unauthenticated JSPX file upload that executes as NT AUTHORITY\Local Service (CVSS 9.6 Critical). No CVE in this item has a CISA KEV entry or an EPSS score in the data available to Adverse Trace, so exploitation in the wild is not confirmed; the flaws are trivially reachable over HTTP by anyone with network access to the server. EMEA financial institutions running Archibus on internet-facing or partner-reachable infrastructure should treat the file upload as a server-takeover path and patch to 2025.02 or higher.

2. Regulatory framing

Article Trigger (the fact in this item) Practical impact
DORA Art. 28 Archibus is an ICT third-party service (facilities and real estate management) supplied by Eptura, and the fix requires the client to obtain and deploy a vendor installer from the Eptura account portal. Third-party risk management must cover the vendor's patch cadence and the client's ability to deploy the 2025.02 installer; contractual patch and notification terms with Eptura fall in scope.
DORA Art. 30 The remediation depends on the client downloading the Archibus installer from its Eptura account, so the contract's patch-delivery and support-version terms determine how fast the fix can be applied. Review the Eptura contract for patch delivery obligations, supported-version commitments and notification duties; Eptura told Rapid7 the version Rapid7 first referenced was no longer supported.
NIS2 Art. 21(2)(d) The exposure sits in a third-party facilities platform, and the fix is a vendor-supplied version upgrade rather than a client-side configuration change. Supply chain security measures must include verifying the vendor's fix and tracking which Archibus instances in the estate are below 2025.02.

3. Technical analysis & attack chain

The three flaws share one root cause: the Archibus Web Central DWR endpoint processes multiple method calls in a single request on the same thread, and one pre-auth-whitelisted method sets a privileged session that a second method then reuses. Rapid7 tested the chain on a Vector Command customer's Archibus server and published working requests.

Confirmed attack chain:

  1. The attacker browses to /archibus/login.axvw and obtains a JSESSIONID.
  2. The attacker sends a DWR request to /archibus/dwr/call/plaincall/__System.generateId.dwr with c0-scriptName=__System, c0-methodName=generateId and page=%2Farchibus%2Flogin.axvw to obtain a scriptSessionId.
  3. The attacker sends a DWR request to /archibus/dwr/call/plaincall/SecurityService.getProjects.dwr with c0-scriptName=SecurityService, c0-methodName=getProjects to obtain the PROJECT_ID.
  4. The attacker sends a single POST to /archibus/dwr/call/plaincall/Multiple.2.dwr with Content-Type: text/plain, callCount=2, and two method calls. The first, c0-scriptName=SecurityService, c0-methodName=isPasswordUppercase, c0-param0=string:<PROJECT_ID>, triggers loadTableDef(), which calls context.setUserSession(coreUserSession) and places the core system user session on the thread-local ContextStore. The second, c1-scriptName=workflow, c1-methodName=runWorkflowRule, c1-param0=string:<RULE_NAME>, reads that session via ContextStore.get().getUserSession() and runs the chosen workflow rule with no credentials supplied.
  5. With the auth bypass in place, the attacker calls AbCommonResources-getDataRecords with tableName=afm_users, fieldNames=['afm_users.user_name', 'afm_users.user_pwd'], restriction=1=1 and recordLimit=10000 to read usernames and passwords from the database. Rapid7 also extracted email and role_name columns, filtering on role_name equal to SYSTEM ADMINISTRATOR (ACP).
  6. Alternatively, the attacker calls AbCommonResources-writeHTMLtoFile with html=<JSPX_WEBSHELL_CONTENT> and fileExtension=jspx. The server writes the content to File.createTempFile("DataViewReport", "." + extension, outputDir) with no validation and returns the browsable path in jsonExpression.exportFileName, of the form /archibus/schema/per-site/exportReports/DataViewReport<TIMESTAMP>.jspx.
  7. The attacker browses to that path. Rapid7 found that .jsp uploads triggered an authentication redirect but .jspx uploads did not, so the JSPX code executed without authentication. Rapid7's first proof of concept printed the server time; the same path runs system commands as NT AUTHORITY\Local Service.

The auth bypass is CVE-2026-107186 (CVSS 8.6 High), the database read is CVE-2026-107187 (CVSS 8.5 High) and the file upload leading to RCE is CVE-2026-107188 (CVSS 9.6 Critical). Rapid7 states that authenticated users may also be able to send the getDataRecords request without the auth bypass, because WorkflowRulesContainerImpl.checkPermission only checks group membership and rule active state; Rapid7 did not test whether a standard user could do so. That is an open question, not a confirmed second path.

The getDataRecords handler builds SQL from a restriction parameter passed to dataSource.formatSqlQuery(restriction, sortValues, filterValues, true, false). Rapid7's example uses restriction=1=1 to return every row. The advisory does not state whether the query is parameterised, so the SQL-injection surface beyond the documented restriction use is not established here.

Affected versions: Rapid7's disclosure timeline records that Eptura said the version Rapid7 first referenced was no longer supported, and that a fix was in development for version 2025.01. The fix is Archibus 2025.02 or higher, in which the vulnerable DWR method was moved to a REST API. Rapid7 does not list a precise lower version bound in the published text; clients should treat any Archibus Web Central build below 2025.02 as exposed and confirm the exact supported floor with Eptura.

No exploitation in the wild, no threat actor and no malware family is named in the source. The chain was demonstrated by Rapid7 during red teaming, not observed in a customer intrusion.

4. Mitigation & containment

P1 within 24 hours

  • Identify every Archibus Web Central instance in the estate and record its version. Any instance below 2025.02 is exposed. Confirm the supported floor with Eptura, since Rapid7's timeline shows Eptura considered the originally referenced version unsupported.
  • Remove internet exposure from Archibus Web Central. Restrict /archibus/dwr/ to trusted management networks at the reverse proxy or WAF, and block external access to /archibus/schema/per-site/exportReports/ entirely. The upload path is the RCE step and needs no legitimate external use.
  • Search web and proxy logs for POSTs to /archibus/dwr/call/plaincall/Multiple.2.dwr with callCount=2 and a c0-methodName=isPasswordUppercase body. Any such request from an unauthenticated source is a compromise indicator. Also search for requests to __System.generateId.dwr and SecurityService.getProjects.dwr from the same client in quick succession.
  • Search the filesystem for files matching DataViewReport*.jspx under the Archibus per-site/exportReports directory. Treat any unexpected file as a webshell and preserve it before removal.

P2 within 72 hours

  • Upgrade Archibus to 2025.02 or higher using the installer from the Eptura account portal. This is the only remediation; there is no configuration workaround in the source.
  • If upgrade cannot complete within 72 hours, disable the AbCommonResources-writeHTMLtoFile and AbCommonResources-getDataRecords workflow rules at the application level and confirm they are inactive, since checkPermission rejects inactive rules. This reduces but does not remove exposure, because the auth bypass itself remains.
  • Rotate credentials for every account stored in afm_users, and any secret reachable from the Archibus database, on the assumption that the database read was available to anyone with HTTP access before the fix. Prioritise accounts in the SYSTEM ADMINISTRATOR (ACP) role.
  • Review the service account under which Archibus runs. Rapid7 confirmed code execution as NT AUTHORITY\Local Service; check that account's local privileges and network reach.

P3 within 7 days

  • Add a WAF rule rejecting DWR batch requests where callCount exceeds 1 on the Multiple.2.dwr endpoint, as a defence-in-depth control for any instance that lags the upgrade.
  • If Rapid7 vulnerability checks are in use, apply the October 21 content release covering CVE-2026-107186, CVE-2026-107187 and CVE-2026-107188 to confirm remediation across the estate.
  • Add Archibus to the third-party register with the 2025.02 floor recorded, and set a review date tied to Eptura's next release.

5. Indicators of compromise

No atomic indicators (hashes, domains, IPs, file names of malware) are present in the source. The source describes request structure and file paths that are observable behaviours rather than fixed indicators.

Type Value Confidence Source
n/a No atomic indicators in source n/a Rapid7

Behavioural indicators

Behaviour Where to observe Confidence
POST to /archibus/dwr/call/plaincall/Multiple.2.dwr with callCount=2 and c0-methodName=isPasswordUppercase Web server access logs, reverse proxy, WAF High (documented request)
Sequential requests to __System.generateId.dwr then SecurityService.getProjects.dwr from one client Web server access logs High (documented request)
runWorkflowRule invoked with AbCommonResources-getDataRecords and tableName=afm_users Application logs, WAF body inspection High (documented request)
runWorkflowRule invoked with AbCommonResources-writeHTMLtoFile and fileExtension=jspx Application logs, WAF body inspection High (documented request)
New DataViewReport*.jspx files under /archibus/schema/per-site/exportReports/ File integrity monitoring on the Archibus host High (documented path)
Outbound HTTP requests to DataViewReport*.jspx paths returning 200 without an auth redirect Web server access logs Medium (Rapid7 observed no redirect for jspx)
url  hxxps://TARGET/archibus/dwr/call/plaincall/Multiple.2.dwr
url  hxxps://TARGET/archibus/dwr/call/plaincall/__System.generateId.dwr
url  hxxps://TARGET/archibus/dwr/call/plaincall/SecurityService.getProjects.dwr
url  hxxps://TARGET/archibus/schema/per-site/exportReports/DataViewReport<TIMESTAMP>.jspx
path  /archibus/schema/per-site/exportReports/

The TARGET placeholder is the victim host, not an attacker-controlled domain; these are request paths to hunt for in logs, not infrastructure to block.

6. Detection

The source gives exact request-body strings and the upload path, which are artefacts of the exploitation itself. The YARA rule targets the DWR batch request body and the generated file name. The Sigma rule targets the web request pattern.

rule Archibus_DWR_AuthBypass_Exploit
{
    meta:
        author = "Adverse Trace"
        date = "2026-10-19"
        reference = "https://www.rapid7.com/blog/post/ve-authentication-bypass-remote-code-execution-and-database-read-in-eptura-archibus-fixed"
        description = "Detects Archibus DWR multi-call auth bypass requests and chained workflow abuse in captured HTTP bodies or log files"
    strings:
        $dwr = "/archibus/dwr/call/plaincall/Multiple.2.dwr" ascii nocase
        $bypass = "isPasswordUppercase" ascii
        $run = "runWorkflowRule" ascii
        $read = "AbCommonResources-getDataRecords" ascii
        $write = "AbCommonResources-writeHTMLtoFile" ascii
        $users = "afm_users.user_pwd" ascii
        $ext = "fileExtension" ascii
        $jspx = "jspx" ascii
        $path = "/archibus/schema/per-site/exportReports/DataViewReport" ascii
    condition:
        $dwr and $bypass and $run or
        $read and $users or
        $write and $ext and $jspx or
        $path
}
title: Archibus DWR Authentication Bypass and Workflow Abuse
id: 8f3c2a1e-archibus-dwr-bypass
status: experimental
author: Adverse Trace
date: 2026/10/19
references:

    - https://www.rapid7.com/blog/post/ve-authentication-bypass-remote-code-execution-and-database-read-in-eptura-archibus-fixed
description: Detects POST requests to the Archibus DWR endpoint that batch isPasswordUppercase with runWorkflowRule, or that invoke the getDataRecords and writeHTMLtoFile workflows
logsource:
    category: webserver
detection:
    selection_endpoint:
        cs-uri-stem|endswith: '/archibus/dwr/call/plaincall/Multiple.2.dwr'
        cs-method: 'POST'
    selection_bypass:
        cs-uri-query|contains|all:

            - 'isPasswordUppercase'
            - 'runWorkflowRule'
    selection_read:
        cs-uri-query|contains: 'AbCommonResources-getDataRecords'
    selection_write:
        cs-uri-query|contains: 'AbCommonResources-writeHTMLtoFile'
    selection_upload_path:
        cs-uri-stem|contains: '/archibus/schema/per-site/exportReports/DataViewReport'
    condition: selection_endpoint and (selection_bypass or selection_read or selection_write) or selection_upload_path
falsepositives:

    - Legitimate Archibus clients that batch DWR calls; baseline normal callCount values before enforcing
level: high

The Sigma rule assumes the web server logs request bodies or query strings. Where bodies are not logged, enable body capture on the DWR endpoint at the WAF, or rely on the YARA rule against captured traffic.

7. Sources

  • Rapid7, "Authentication Bypass, Remote Code Execution, and Database Read in Eptura Archibus (FIXED)", https://www.rapid7.com/blog/post/ve-authentication-bypass-remote-code-execution-and-database-read-in-eptura-archibus-fixed, 2026-10-19.

All technical detail in this advisory rests on this single Rapid7 disclosure. The CVSS scores, affected-version floor and exploitation status are as stated by Rapid7; no NVD, EPSS or CISA KEV record was available to Adverse Trace for CVE-2026-107186, CVE-2026-107187 or CVE-2026-107188 at the time of issue. Verify the version floor with Eptura before relying on it for compliance reporting.

8. Adverse Trace position

Adverse Trace assesses the file upload (CVE-2026-107188, CVSS 9.6 Critical) as the priority: it gives unauthenticated code execution as NT AUTHORITY\Local Service on a platform that holds facilities, lease and workforce data, and the exploitation requests are short and published in full. The auth bypass and database read (CVSS 8.6 and 8.5 High) are lower severity but widen the impact to credential theft from afm_users. No exploitation in the wild is confirmed and no actor is attributed; the chain was demonstrated by Rapid7 during red teaming, and all detail here is single-sourced to that disclosure, so clients should verify the version floor and the absence of in-the-wild activity against their own telemetry before closing the item. We will monitor for NVD, EPSS and CISA KEV records on the three CVEs, for Eptura advisories naming affected versions, and for reports of DataViewReport*.jspx webshells in the wild, and will reissue this advisory if any of those change the assessment. Clients running Archibus below 2025.02 on internet-reachable infrastructure should treat this as an active exposure and act on the P1 steps today.


Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.

Post this to LinkedIn
Formatting is converted automatically — headings, bullets, a link back & hashtags. Paste straight in.
J
Jeff Davies