Eptura Archibus Authentication Bypass and Unauthenticated RCE — Detection and Remediation Guide

Rapid7’s Vector Command red-team service identified three high-impact vulnerabilities in Eptura Archibus, a platform used to centrally manage buildings, equipment, real estate, assets, maintenance work orders, leases, and room reservations. The flaws were chained through a legacy API endpoint that did not properly enforce authentication.

The public disclosure describes three distinct risks:

• Authentication bypass: an attacker can invoke sensitive functions without authenticating. CVSS 8.6 High.
• Database read: exposed functionality permits broad or full database reads. CVSS 8.5 High.
• Insecure file upload: an attacker can upload content that leads to unauthenticated remote code execution. CVSS 9.6 Critical.

The combination is severe. Archibus deployments may contain sensitive operational and organizational information, including floor plans, asset inventories, maintenance schedules, lease data, employee or tenant assignments, equipment details, and integration credentials. Successful exploitation could expose that data and allow an attacker to execute code in the context of the Archibus application service.

Eptura has released a fix. Organizations running internet-accessible, partner-accessible, or otherwise broadly reachable Archibus instances should treat remediation as urgent. If the application handles regulated data, preserve logs and assess whether incident-response and notification obligations apply.

The source disclosure excerpt does not provide CVE identifiers or a public affected-version-to-fixed-version mapping. Defenders should not invent version assumptions. Confirm the installed build and applicable fixed release directly against Eptura’s current advisory or support channel, then document the exact product build before and after remediation.

Why This Matters to Defenders

This is not merely a missing-login issue. The disclosure indicates that a legacy endpoint exposed multiple privileged functions to unauthenticated users. The critical path is straightforward:

1. An unauthenticated remote user reaches the vulnerable legacy API endpoint.
2. The application fails to require a valid authenticated session or adequate authorization.
3. The attacker invokes application functions that should be protected.
4. Depending on the function selected, the attacker reads database content or uploads a file.
5. The uploaded content is stored or processed in a manner that produces code execution.

That final step can turn a facilities-management application into an initial-access foothold. Even when Archibus itself is not considered a crown-jewel system, compromise may provide access to internal network segments, service accounts, document stores, directory integrations, or downstream systems.

The risk is especially acute where Archibus is exposed to the internet for mobile users, facilities vendors, or workplace-management integrations. A system that hosts building layouts and physical-security-adjacent information also has consequences beyond conventional data loss.

Affected Products and Platforms

The affected product is Eptura Archibus. The public summary does not enumerate affected versions, deployment architectures, operating systems, or fixed build numbers.

Archibus is commonly deployed as a web application behind an HTTP or HTTPS listener and may run alongside a Java application server, a database, scheduled services, and file-storage paths. Exact implementation varies by version and customer architecture. Defenders should inventory all of the following:

• Production Archibus web servers
• Test, staging, development, disaster-recovery, and migration instances
• Reverse proxies, load balancers, and WAFs fronting Archibus
• Application servers and service accounts used by Archibus
• Database servers and linked database accounts
• Upload, temporary, document, drawing, report, and export directories
• Internet-facing portals or alternate hostnames that proxy to the same application
• Legacy virtual directories, API routes, and compatibility endpoints retained during upgrades

Do not limit the inventory to the primary production URL. Red-team findings involving legacy APIs often persist on old hostnames, standby servers, and test systems that operators forgot were reachable.

Technical Analysis

Vulnerability chain

The disclosed weaknesses can be understood as three related authorization and input-validation failures.

1. Legacy API authentication bypass — CVSS 8.6 High

A legacy API endpoint accepted requests that should have required authentication. The precise endpoint path is not included in the provided disclosure excerpt, so defenders should avoid writing detections based on guessed URLs.

The important defensive fact is architectural: the endpoint appears to sit outside the application’s normal authenticated request flow. This can happen when an old route is registered directly with the web server or application framework and does not pass through the current session-validation filter, single sign-on integration, or centralized authorization layer.

An attacker does not need a password, session token, MFA factor, or prior foothold if they can reach the vulnerable route. Network reachability is the primary precondition described in the public summary.

2. Unauthorized database read — CVSS 8.5 High

Once the unauthenticated API is reachable, one or more exposed functions allow broad database reads. The disclosure characterizes the impact as full database read rather than an isolated record leak.

Depending on schema and permissions, this could expose:

• Employee, occupant, tenant, vendor, or contractor data
• Building, floor, room, and desk assignments
• Asset inventories and equipment records
• Maintenance work orders and safety observations
• Real-estate and lease information
• Application configuration data
• Integration settings or credential material, if stored in the database
• Internal account names, email addresses, phone numbers, and organizational relationships

The database-read issue also increases the value of any later compromise. Attackers can use exported data to identify privileged users, trusted vendors, building access patterns, network-connected equipment, and operational schedules.

3. Insecure upload and unauthenticated code execution — CVSS 9.6 Critical

The most serious function permits an unauthenticated file upload. The disclosure says the upload leads to code execution, but the excerpt does not identify the exact upload route, file type, destination path, parser, or execution mechanism.

From a defender’s perspective, likely observable patterns include:

• Unauthenticated POST or PUT requests to an Archibus API route
• Multipart form-data requests containing executable or script-like content
• Files written by the Archibus service account into upload, temporary, web-accessible, or application directories
• Unexpected changes to application configuration, templates, scripts, or scheduled tasks
• Web or application-server processes spawning command interpreters or other unusual child processes
• Outbound connections from the Archibus host following a suspicious upload

The safest assumption is that successful exploitation can execute attacker-controlled code with the privileges of the application process. If the service runs with excessive privileges, the resulting compromise may extend to the operating system, adjacent file shares, database credentials, or domain resources.

Exploitation requirements

The reported attack path does not require valid credentials. The principal requirements are:

• Network access to the vulnerable Archibus HTTP or HTTPS service
• Reachability of the legacy API endpoint
• A vulnerable, unpatched deployment
• For code execution, successful use of the exposed upload function and the application’s subsequent handling of the uploaded content

The public excerpt does not specify user interaction, so none should be assumed.

Exploitation status

The issues were found during continuous red-team testing and are reported as fixed. The supplied disclosure does not state that there is a public proof of concept, confirmed in-the-wild exploitation, or inclusion in CISA’s Known Exploited Vulnerabilities catalog.

That does not make the issue low priority. Unauthenticated database access and unauthenticated code execution are high-value targets, and internet-exposed enterprise applications are routinely scanned after public disclosure. Treat exploitation as plausible until the platform is patched and historical logs have been reviewed.

Immediate Risk Assessment

Security teams should answer these questions before closing the vulnerability ticket:

1. Where is Archibus deployed? Include production, DR, staging, development, old upgrade instances, and cloud-hosted environments.
2. Who can reach it? Determine whether it is exposed to the internet, extranet partners, VPN users, or only internal networks.
3. What build is installed? Record the exact Archibus version, application-server version, database version, and operating system.
4. Which routes are exposed? Review proxy configurations and access logs for legacy API paths and unauthenticated requests.
5. Has a fixed release been applied? Verify the fixed build through Eptura’s advisory or support portal.
6. Are uploads executable? Determine whether upload paths can execute code, are processed by risky components, or overlap with application directories.
7. What identity does Archibus use? Review the operating-system service account and database account for unnecessary privileges.
8. Was there suspicious activity before patching? Preserve web, application, database, endpoint, proxy, and authentication logs before routine retention expires.

Detection Strategy

The public excerpt does not disclose exact URLs, file names, payload extensions, or process names. Detection should therefore focus on behavior with high investigative value, not invented indicators.

Use a layered approach:

• Review successful and rejected unauthenticated requests to Archibus routes.
• Identify unusual upload requests, especially multipart requests from external IP addresses.
• Detect executable or script content written beneath Archibus-controlled paths.
• Monitor the Archibus web/application process for suspicious child processes.
• Hunt for new outbound connections from Archibus servers.
• Audit database activity associated with the application account for broad reads or unusual query volume.

The following analytics are intentionally scoped to Archibus-related paths and process lineage. Tune paths and process names to the actual deployment. A path filter that exists in your environment is more useful than a broad rule that fires on every web server.

Sigma Detection Rules

---
title: Eptura Archibus Suspicious File Upload or Executable Content Write
id: 5ed6a721-8c65-4f83-b4a8-73e32d78ac11
status: experimental
description: Detects potentially executable files written beneath common Archibus installation, upload, temporary, or web-content locations. Intended to identify malicious files introduced through an unauthenticated upload path.
references:
  - https://www.rapid7.com/blog/post/ve-authentication-bypass-remote-code-execution-and-database-read-in-eptura-archibus-fixed
  - https://attack.mitre.org/techniques/T1105/
  - https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.initial_access
  - attack.t1190
  - attack.command_and_control
  - attack.t1105
  - attack.persistence
  - attack.t1505.003
logsource:
  category: file_event
  product: windows
detection:
  selection_paths:
    TargetFilename|contains:
      - '\Archibus\'
      - '\archibus\'
      - '\WebCentral\'
      - '\webcentral\'
      - '\Tomcat\webapps\'
      - '\Program Files\Apache Software Foundation\Tomcat\'
  selection_extensions:
    TargetFilename|endswith:
      - '.jsp'
      - '.jspx'
      - '.war'
      - '.jar'
      - '.class'
      - '.exe'
      - '.dll'
      - '.ps1'
      - '.bat'
      - '.cmd'
      - '.vbs'
      - '.js'
  condition: selection_paths and selection_extensions
falsepositives:
  - Archibus upgrades, hotfixes, custom report deployment, or administrator-installed application components
level: high
---
title: Archibus Application Process Spawning Command Interpreter
id: 1f89d71a-c166-48d4-9c0e-15ca920497aa
status: experimental
description: Detects command interpreters or script engines launched by Java, Tomcat, web-server, or Archibus-related processes. This can indicate command execution following exploitation of the unauthenticated upload vulnerability.
references:
  - https://www.rapid7.com/blog/post/ve-authentication-bypass-remote-code-execution-and-database-read-in-eptura-archibus-fixed
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.execution
  - attack.t1059
  - attack.initial_access
  - attack.t1190
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith:
      - '\java.exe'
      - '\javaw.exe'
      - '\tomcat.exe'
      - '\tomcat9.exe'
      - '\tomcat10.exe'
      - '\httpd.exe'
      - '\w3wp.exe'
      - '\archibus.exe'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
      - '\regsvr32.exe'
      - '\certutil.exe'
      - '\bitsadmin.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Application maintenance jobs, vendor support scripts, or custom Archibus integrations
level: critical
---
title: Archibus Server Initiating Uncommon Outbound Network Connection
id: 9f68a67d-50d7-4b31-9bc2-a0f1a71c45b8
status: experimental
description: Detects uncommon outbound network connections from processes commonly associated with an Archibus web or application tier. Use after baseline tuning to identify command-and-control or tooling downloads following exploitation.
references:
  - https://www.rapid7.com/blog/post/ve-authentication-bypass-remote-code-execution-and-database-read-in-eptura-archibus-fixed
  - https://attack.mitre.org/techniques/T1071/
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.command_and_control
  - attack.t1071
  - attack.exfiltration
  - attack.t1041
logsource:
  category: network_connection
  product: windows
detection:
  selection_image:
    Image|endswith:
      - '\java.exe'
      - '\javaw.exe'
      - '\tomcat.exe'
      - '\tomcat9.exe'
      - '\tomcat10.exe'
      - '\httpd.exe'
      - '\w3wp.exe'
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
  selection_destination:
    DestinationPort:
      - 80
      - 443
      - 8080
      - 8443
  filter_internal:
    DestinationIp|startswith:
      - '10.'
      - '172.16.'
      - '172.17.'
      - '172.18.'
      - '172.19.'
      - '172.20.'
      - '172.21.'
      - '172.22.'
      - '172.23.'
      - '172.24.'
      - '172.25.'
      - '172.26.'
      - '172.27.'
      - '172.28.'
      - '172.29.'
      - '172.30.'
      - '172.31.'
      - '192.168.'
      - '127.'
  condition: selection_image and selection_destination and not filter_internal
falsepositives:
  - Software updates, license checks, vendor integrations, cloud APIs, and approved outbound connectors
level: medium

Microsoft Sentinel and Defender KQL

Use this query to identify suspicious child processes launched by likely Archibus web-tier processes, followed by a second query for file creations in application-controlled locations. Tune ArchibusProcessNames and ArchibusPathPrefixes to match the actual installation.

let Lookback = 14d;
let ArchibusProcessNames = dynamic(["java.exe", "javaw.exe", "tomcat.exe", "tomcat9.exe", "tomcat10.exe", "httpd.exe", "w3wp.exe", "archibus.exe"]);
let SuspiciousChildren = dynamic(["cmd.exe", "powershell.exe", "pwsh.exe", "wscript.exe", "cscript.exe", "mshta.exe", "rundll32.exe", "regsvr32.exe", "certutil.exe", "bitsadmin.exe"]);
DeviceProcessEvents
| where TimeGenerated >= ago(Lookback)
| where InitiatingProcessFileName in~ (ArchibusProcessNames)
| where FileName in~ (SuspiciousChildren)
| project TimeGenerated, DeviceName, AccountName, InitiatingProcessFileName, InitiatingProcessCommandLine, FileName, ProcessCommandLine, ProcessId, InitiatingProcessId, ReportId
| order by TimeGenerated desc;

let FileLookback = 14d;
let SuspiciousExtensions = dynamic([".jsp", ".jspx", ".war", ".jar", ".class", ".exe", ".dll", ".ps1", ".bat", ".cmd", ".vbs", ".js"]);
DeviceFileEvents
| where TimeGenerated >= ago(FileLookback)
| where FolderPath has_any ("\\Archibus\\", "\\archibus\\", "\\WebCentral\\", "\\webcentral\\", "\\Tomcat\\webapps\\")
| where FileName has_any (SuspiciousExtensions)
| project TimeGenerated, DeviceName, FolderPath, FileName, SHA256, InitiatingProcessFileName, InitiatingProcessCommandLine, InitiatingProcessAccountName, ReportId
| order by TimeGenerated desc;

For web-proxy, WAF, Apache, Tomcat, IIS, or load-balancer telemetry ingested as CommonSecurityLog, hunt for unauthenticated upload-like requests and unusually large or repeated request activity. Replace the destination host filter with the organization’s Archibus hostnames or server addresses.

let Lookback = 30d;
CommonSecurityLog
| where TimeGenerated >= ago(Lookback)
| where DestinationHostName has_any ("archibus", "webcentral") or DestinationIP in (dynamic([]))
| where RequestMethod in~ ("POST", "PUT")
| extend RequestUrl = tostring(coalesce(RequestURL, AdditionalExtensions))
| where RequestUrl has_any ("api", "upload", "file", "import", "legacy", "archibus", "webcentral")
| summarize Requests=count(), DistinctUrls=dcount(RequestUrl), DistinctUserAgents=dcount(RequestClientApplication), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), SampleUrls=make_set(RequestUrl, 10) by SourceIP, DestinationHostName, DestinationIP, RequestMethod
| order by Requests desc;

If DestinationIP in (dynamic([])) is not practical in the workspace, remove that predicate and retain the hostname filter. Do not rely on the word upload alone; legitimate Archibus integrations can use generic API routes.

Velociraptor VQL Hunt

This artifact identifies suspicious child processes spawned from likely Archibus web-tier processes. Deploy it against Windows servers hosting Archibus after confirming the actual service and executable names.

-- Hunt for command interpreters or script engines launched by Archibus web-tier processes
SELECT Pid,
       Ppid,
       Name,
       Exe,
       CommandLine,
       Username,
       CreateTime
FROM pslist()
WHERE Name =~ '(?i)^(cmd|powershell|pwsh|wscript|cscript|mshta|rundll32|regsvr32|certutil|bitsadmin)\\.exe$'
  AND Ppid IN (
        SELECT Pid
        FROM pslist()
        WHERE Name =~ '(?i)^(java|javaw|tomcat|tomcat9|tomcat10|httpd|w3wp|archibus)\\.exe$'
           OR Exe =~ '(?i)(archibus|webcentral|tomcat|apache)'
      )

Use this second artifact to inventory potentially executable files recently created beneath Archibus and web-application paths. Adjust the glob patterns to the installation root.

-- Inventory potentially executable files recently created under Archibus-related paths
LET suspicious_paths <= SELECT FullPath, Mtime, Atime, Ctime, Size
FROM glob(globs=[
  'C:/Archibus/**/*',
  'C:/Program Files/Archibus/**/*',
  'C:/Program Files (x86)/Archibus/**/*',
  'C:/Program Files/Apache Software Foundation/Tomcat*/webapps/**/*'
])
WHERE FullPath =~ '(?i)\\.(jsp|jspx|war|jar|class|exe|dll|ps1|bat|cmd|vbs|js)$'
  AND Ctime > now() - 1209600

SELECT FullPath,
       Ctime AS Created,
       Mtime AS Modified,
       Atime AS Accessed,
       Size
FROM suspicious_paths
ORDER BY Created DESC

Remediation Verification Script

The following PowerShell script does not patch Archibus. It helps administrators inventory likely installations, capture service identity, identify executable content in application paths, and record evidence for patch verification. Run it from an elevated PowerShell session after adjusting $CandidateRoots to the actual installation locations.

# Eptura Archibus exposure and remediation verification helper
# Adjust these paths to the confirmed installation and upload locations.
$OutputDirectory = Join-Path $env:TEMP ("Archibus-Security-Check-" + (Get-Date -Format "yyyyMMdd-HHmmss"))
$CandidateRoots = @(
    "C:\Archibus",
    "C:\Program Files\Archibus",
    "C:\Program Files (x86)\Archibus",
    "C:\Program Files\Apache Software Foundation"
) | Where-Object { Test-Path $_ }

New-Item -Path $OutputDirectory -ItemType Directory -Force | Out-Null

# Capture operating system and network listener context.
Get-CimInstance Win32_OperatingSystem |
    Select-Object Caption, Version, BuildNumber, InstallDate, LastBootUpTime |
    Export-Csv -NoTypeInformation -Path (Join-Path $OutputDirectory "operating-system.csv")

Get-NetTCPConnection -State Listen -ErrorAction SilentlyContinue |
    Select-Object LocalAddress, LocalPort, OwningProcess, @{Name="ProcessName";Expression={(Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue).ProcessName}} |
    Sort-Object LocalPort |
    Export-Csv -NoTypeInformation -Path (Join-Path $OutputDirectory "listening-services.csv")

# Capture candidate Archibus, Java, Tomcat, IIS, and Apache services.
$ServicePattern = "archibus|webcentral|tomcat|apache|java|iis"
Get-CimInstance Win32_Service |
    Where-Object { $_.Name -match $ServicePattern -or $_.DisplayName -match $ServicePattern -or $_.PathName -match $ServicePattern } |
    Select-Object Name, DisplayName, State, StartMode, StartName, PathName, ProcessId |
    Export-Csv -NoTypeInformation -Path (Join-Path $OutputDirectory "candidate-services.csv")

# Record installed programs whose names indicate Archibus or application-server components.
$RegistryPaths = @(
    "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*",
    "HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*"
)
Get-ItemProperty $RegistryPaths -ErrorAction SilentlyContinue |
    Where-Object { $_.DisplayName -match "Archibus|Web Central|Tomcat|Apache|Java" } |
    Select-Object DisplayName, DisplayVersion, Publisher, InstallDate, InstallLocation |
    Export-Csv -NoTypeInformation -Path (Join-Path $OutputDirectory "installed-components.csv")

# Find potentially executable content recently created in candidate paths.
$ExecutableExtensions = @(".jsp", ".jspx", ".war", ".jar", ".class", ".exe", ".dll", ".ps1", ".bat", ".cmd", ".vbs", ".js")
$RecentCutoff = (Get-Date).AddDays(-30)

$ExecutableInventory = foreach ($Root in $CandidateRoots) {
    Get-ChildItem -Path $Root -Recurse -File -ErrorAction SilentlyContinue |
        Where-Object { $ExecutableExtensions -contains $_.Extension.ToLowerInvariant() -and $_.CreationTime -ge $RecentCutoff } |
        Select-Object FullName, Extension, Length, CreationTime, LastWriteTime
}

$ExecutableInventory |
    Sort-Object CreationTime -Descending |
    Export-Csv -NoTypeInformation -Path (Join-Path $OutputDirectory "recent-executable-content.csv")

# Capture file hashes for incident triage.
$ExecutableInventory |
    ForEach-Object {
        Get-FileHash -Algorithm SHA256 -Path $_.FullName -ErrorAction SilentlyContinue |
            Select-Object Path, Hash
    } |
    Export-Csv -NoTypeInformation -Path (Join-Path $OutputDirectory "recent-executable-hashes.csv")

# Summarize current candidate service processes.
Get-Process -ErrorAction SilentlyContinue |
    Where-Object { $_.ProcessName -match "archibus|webcentral|tomcat|java|javaw|httpd|w3wp" } |
    Select-Object Id, ProcessName, Path, StartTime, Company, Product, ProductVersion |
    Export-Csv -NoTypeInformation -Path (Join-Path $OutputDirectory "candidate-processes.csv")

Write-Host "Archibus verification evidence collected at: $OutputDirectory"
Write-Host "Review candidate-services.csv, installed-components.csv, listening-services.csv, and recent-executable-content.csv."

For Linux-hosted components, collect equivalent service, listener, and recently changed executable-content evidence.

#!/usr/bin/env bash
set -euo pipefail

OUT="/tmp/archibus-security-check-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$OUT"

# Capture system, service, package, process, and listener context.
uname -a > "$OUT/uname.txt"
(systemctl list-units --type=service --all | grep -Ei 'archibus|webcentral|tomcat|apache|java|httpd' || true) > "$OUT/candidate-services.txt"
(ps auxww | grep -Ei '[a]rchibus|[w]ebcentral|[t]omcat|[j]ava|[h]ttpd' || true) > "$OUT/candidate-processes.txt"
(ss -lntup || netstat -lntup) > "$OUT/listeners.txt" 2>&1 || true

# Capture installed package evidence on common Linux families.
if command -v dpkg >/dev/null 2>&1; then
  dpkg -l | grep -Ei 'archibus|tomcat|apache|java|openjdk' > "$OUT/packages.txt" || true
elif command -v rpm >/dev/null 2>&1; then
  rpm -qa | grep -Ei 'archibus|tomcat|apache|java|openjdk' > "$OUT/packages.txt" || true
fi

# Adjust these roots to the actual Archibus, Tomcat, and upload paths.
for ROOT in /opt/archibus /usr/local/archibus /var/lib/tomcat /opt/tomcat /var/www; do
  if [ -d "$ROOT" ]; then
    find "$ROOT" -type f \
      \( -iname '*.jsp' -o -iname '*.jspx' -o -iname '*.war' -o -iname '*.jar' -o -iname '*.class' -o -iname '*.sh' -o -iname '*.py' -o -iname '*.pl' -o -iname '*.php' -o -iname '*.js' \) \
      -mtime -30 -printf '%T@ %TY-%Tm-%Td %TH:%TM:%TS %s %p\n' 2>/dev/null || true
  fi
done | sort -nr > "$OUT/recent-executable-content.txt"

awk '{ $1=""; sub(/^ /,""); print }' "$OUT/recent-executable-content.txt" > "$OUT/recent-executable-content-readable.txt"

echo "Evidence collected in $OUT"

Remediation

1. Apply Eptura’s fixed release

Apply the vendor-supplied fix to every affected Archibus deployment. The source disclosure confirms that the vulnerabilities are fixed but does not provide a public fixed-version mapping in the supplied excerpt.

Use Eptura’s official support and product-security channels to obtain:

• The exact affected product versions
• The exact fixed build or hotfix applicable to your installed version
• Upgrade prerequisites and sequencing requirements
• Configuration changes required after installation
• Guidance for legacy endpoint removal or hardening

Do not assume that a major upgrade automatically includes the fix. Verify the security build, hotfix identifier, or release note entry explicitly. Retain evidence showing the pre-patch and post-patch product build.

Official starting points:

• Rapid7 disclosure: https://www.rapid7.com/blog/post/ve-authentication-bypass-remote-code-execution-and-database-read-in-eptura-archibus-fixed
• Eptura support: https://support.eptura.com/
• Eptura security and trust information: https://www.eptura.com/trust-center/

If Eptura provides a private customer advisory, use that document as the authoritative source for affected and fixed versions.

2. Remove internet exposure

Until the fixed release is verified, remove direct internet access to the application. If remote access is required, place Archibus behind one or more of the following controls:

• VPN with device posture and MFA
• Identity-aware reverse proxy with enforced authentication
• Allowlisted source networks for facilities vendors and integrations
• A WAF or reverse proxy rule that blocks access to legacy API routes identified by Eptura
• Separate administrative and user-facing virtual hosts, with administrative routes restricted to trusted management networks

Do not rely on obscurity, an unlinked hostname, or robots exclusions as a compensating control.

3. Disable or restrict the legacy API

Where Eptura documents a supported workaround, disable the vulnerable legacy endpoint or remove its web-server mapping. If the endpoint cannot be removed without breaking operations:

• Require authentication at the proxy layer before requests reach Archibus.
• Permit only explicitly required methods and content types.
• Deny multipart uploads unless the business workflow requires them.
• Restrict the route to approved integration IP addresses.
• Add request-size and file-extension limits.
• Log complete request metadata while protecting sensitive payloads.

A proxy rule is a temporary risk-reduction measure, not a substitute for the vendor fix.

4. Constrain upload handling

Review all application and web-server upload paths:

• Store uploads outside executable web roots.
• Ensure uploaded content cannot be interpreted as server-side code.
• Enforce content-type validation based on file content, not only extension.
• Rename uploaded files and remove executable permissions.
• Scan uploads with approved malware and content-disarm tooling.
• Deny execution of scripts and binaries from upload and temporary directories.
• Apply operating-system controls such as noexec mounts on Linux upload partitions where supported.
• Prevent direct web access to raw upload storage unless required.

Validate these controls after patching. A fix for a specific endpoint does not replace secure upload architecture.

5. Reduce service and database privileges

Run the Archibus application under a dedicated, least-privilege identity. The account should not have local administrator rights, broad file-share access, domain privileges, or unnecessary database rights.

For the database account:

• Grant only the schemas and operations required by Archibus.
• Block direct use from unexpected hosts where feasible.
• Alert on large read volume, schema enumeration, backup commands, or exports.
• Rotate the database password if compromise is suspected.

For the application host:

• Restrict outbound traffic to approved update, licensing, integration, and monitoring destinations.
• Deny outbound server-to-internet traffic by default.
• Apply EDR and application-control policies.
• Prevent command interpreters from being launched by the web-tier service unless explicitly required.

6. Hunt before and after patching

Patching removes future exposure but does not establish that the system was not already compromised. Review at least the period during which the vulnerable build was exposed, subject to available log retention.

Prioritize:

• Unauthenticated POST and PUT requests to Archibus API routes
• Upload requests from unusual geographies, ASNs, hosting providers, or previously unseen IP addresses
• Requests followed by file creation or process execution
• Large database-result transfers or unusual response sizes
• New local accounts, service changes, scheduled tasks, or startup entries
• Suspicious files in upload, temporary, application, and web-content paths
• Outbound connections initiated by the Archibus process or its children

Preserve original logs and forensic images before rebuilding a potentially compromised host.

7. Respond decisively if compromise is suspected

If suspicious upload, execution, or database-read activity predates remediation:

1. Isolate the Archibus host without prematurely powering it off.
2. Preserve memory if code execution may have occurred.
3. Capture web, application, database, endpoint, proxy, WAF, DNS, and authentication logs.
4. Identify all files created or modified within the suspected window.
5. Determine whether database records were accessed or exfiltrated.
6. Rotate application, database, integration, and service-account credentials exposed to the host.
7. Rebuild from trusted media if code execution is confirmed or cannot be ruled out.
8. Restore application data only after validating it for malicious content.
9. Review legal, contractual, PCI-DSS, HIPAA, state privacy, and other notification obligations based on the data actually accessed.
10. Validate monitoring and access controls before returning the service to production.

Recommended Closure Criteria

A remediation ticket should not close merely because an upgrade completed. Require evidence for each item:

• Exact installed Archibus build before remediation
• Exact fixed build, hotfix, or vendor-approved mitigation applied
• Eptura advisory or support reference used
• Production and non-production systems included in scope
• Internet exposure removed or authenticated upstream access verified
• Legacy endpoint disabled, removed, or restricted as documented by Eptura
• Upload directories configured to prevent executable content
• Service and database accounts reviewed for least privilege
• Historical web, endpoint, and database hunts completed
• Suspicious findings escalated to incident response
• Post-patch request and process telemetry baselined
• Exceptions approved with owner, compensating control, and expiration date

Conclusion

The Eptura Archibus disclosure is critical because it combines unauthenticated access, broad database exposure, and an upload path leading to code execution. The highest-priority actions are to confirm the exact affected deployment, install Eptura’s fixed release, remove unauthenticated network access, restrict legacy API routes, and hunt for evidence of prior exploitation.

Because the supplied public summary does not disclose exact endpoint paths, CVE identifiers, or affected-version mappings, defenders should avoid guesswork. Use the observable behaviors in this guide, confirm version-specific remediation with Eptura, and preserve enough telemetry to distinguish a clean upgrade from a compromise that occurred before the patch.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub