Eptura Archibus CVE-2026-107186: Auth Bypass to RCE, Patch Now

CVE-2026-107186, CVE-2026-107187 and CVE-2026-107188 are three flaws in Eptura Archibus, the facilities and real estate platform, that chain into code execution without a login on version 2025.01 and earlier. Apply Eptura's 2025.01 hotfix or move to 2025.02 or later. Older releases need Eptura's configuration mitigation. No exploitation has been reported.

The three CVEs were published on 19 October 2026 by the security researchers who found them, and Eptura issued a customer notice dated 21 October. Archibus runs a lot of quiet but sensitive work: room and desk booking, maintenance work orders, lease records, building drawings and asset registers. It is usually owned by a facilities or real estate team, installed and run by an Eptura partner, and patched on a schedule nobody in security has looked at in a while. That is exactly the kind of system this post is for.

Below you will find what the official records say, which versions are affected and fixed according to each source, how the three bugs work in plain language without attack steps, how to find every Archibus server you own and check its version and exposure, and how to treat facilities and other business platforms so the next fix lands before anyone tries to use it.

What happened

All times are UTC. Times to the minute come from the CVE.org and NVD records. Dates without times come from Eptura's notice or from the researchers' disclosure timeline, which we cite as the original disclosure.

Two points stand out. First, the vendor fix for the oldest supported line, 2025.01, arrived around public disclosure rather than well before it. Eptura told the researchers on 9 October that the fix was still in development, and its notice is dated two days after the CVEs went public. Second, the newer lines were already safe by design: Eptura says 2025.02 and 2026.01 are not affected because the relevant legacy interface had been replaced by a REST call starting with 2025.02.

What the official records say

The CVE records

The CVE records were written by the CVE Numbering Authority (CNA) attached to the research team, so every score in them comes from the finders, not from NVD. Each record lists the same affected range: Eptura Archibus from version 0 up to, but not including, 2025.02, with every other version marked unaffected by default.

The record titles describe the three bugs clearly enough:

• CVE-2026-107186: an authentication bypass in the Direct Web Remoting (DWR) API "via Privileged Session Reuse".
• CVE-2026-107187: a workflow rule that enables an unauthenticated database read of sensitive tables.
• CVE-2026-107188: a workflow rule that enables an unauthenticated arbitrary file upload leading to remote code execution.

Eptura's notice

Eptura's notice, linked from a banner across its Archibus Knowledge Center, is the most important document for anyone who runs the product. In summary:

• The three CVEs describe a chain that ends in remote code execution with no authentication, affecting Archibus v2025.01 and earlier.
• Archibus v2025.02 and v2026.01 need no further action for these CVEs, because the relevant DWR SecurityService was replaced by a REST call beginning with v2025.02.
• For v2025.01, Eptura has released one consolidated patch for all three CVEs, distributed to partners through its partner portal under the name WebCv2025.01.01.128_Hotfix-for-AD-24576.
• For v2024.04 and earlier, no equivalent patch exists. Eptura has provided web.xml configuration changes that block the authentication bypass path and stop the server from creating .jspx files, and says these mitigate the chain "and known variants". Customers must contact Archibus Support for the exact guidance.

Eptura's support policy

Eptura's support policy page, updated 9 July 2026, says the supported versions are V.2026.01, V.2025.02 and V.2025.01. Eptura supports the current release plus any release shipped within 18 months of it. V.2026.01 shipped in July 2026, so support reaches back to versions released since January 2025. Anything older, including every 2024 release, is out of support. That is why the only patch is for 2025.01.

Exploitation status

No source we read reports exploitation of these flaws by attackers. CISA's coordinator SSVC entry records exploitation as "none" for all three as of 20 October, and none of the three appears in the KEV catalog released on 21 October. The researchers did use the flaws during an authorised engagement, which is how they were found; that is testing, not an attack. Treat the status as "not known to be exploited yet", not as "safe to wait".

Where sources differ

Technical details

Identifiers and scores

A quick note on reading the vectors. All three are network reachable with low attack complexity and no user interaction. All three are "Scope: Changed", meaning the finders judged that the impact reaches beyond the vulnerable component itself, in this case into the database and the host. The 107186 score has no integrity impact on its own: the bypass by itself only runs things, and it is what those things do that causes harm. The FIRST CVSS 3.1 specification explains each metric if you want to rescore for your own environment.

Affected and fixed versions

The classes of bug, conceptually

This section explains the mechanism at the level the official records already describe it. It does not include requests, parameters or anything you could replay.

CVE-2026-107186: state leaking between calls in a batch. Archibus Web Central uses Direct Web Remoting (DWR), an older Java library that lets browser JavaScript call server-side Java methods. DWR can carry several method calls in one HTTP request and runs them one after another on the same server thread. Most methods require a logged-in user. A few are allowed before login because the login page needs them. According to the NVD description and the original disclosure, one of those pre-login methods, a small helper about password formatting, set a privileged system session on the thread's context as a side effect while it loaded table metadata. The next call in the same batch, a method that runs workflow rules, then looked at the thread's context, found a valid session, and carried on. The result is that a request with no credentials could run workflow rules.

The pattern is worth naming because it is not unique to Archibus: authorisation that trusts ambient, thread-local state instead of the caller's own verified identity, combined with a transport that runs several operations in one context. Every framework that batches calls, pools threads or caches a "current user" object can produce the same shape of bug.

CVE-2026-107187: a general data reader exposed as a workflow rule. Workflow rules are Archibus's server-side business logic. One built-in rule returns records from a data source. According to the CVE description, it could be pointed at any table, including the tables that hold usernames and passwords. On its own it needs a logged-in user; chained with 107186 it does not. The record notes that write and delete operations may also have been possible but were not tested.

CVE-2026-107188: a report export that wrote executable files. Another built-in rule writes report content to disk for export. According to the CVE description, the caller controlled both the content and the file extension, and the file landed somewhere the web server would serve it. Choosing a server-side template extension (.jspx) meant the server would execute the file when someone browsed to it. The original disclosure adds that .jsp files triggered a login redirect but .jspx files did not, and that the resulting commands ran under the Windows Local Service account on the tested server. This is the classic unrestricted upload pattern that the OWASP File Upload Cheat Sheet warns about: allowlist extensions, generate file names on the server, and store uploads outside the web root.

Why the chain matters. 107186 removes the login. 107187 turns that into reading credentials and business data. 107188 turns it into running code on the server, and from there into everything the server can reach: the database, file shares holding drawings, mail or calendar connectors, and whatever service accounts the Archibus host uses. Each step is ordinary on its own. Together they are a full compromise from a single reachable URL.

What the fixes change

Eptura has not published code, so this is what the notice and release notes say:

• 2025.02 and later: the DWR SecurityService involved in the bypass was replaced by a REST call. The 2025.02 revision history records the change as "Replace many DWR endpoints with REST" and, separately under its Security heading, hardened access controls around user sessions (AD-21220). We do not know which internal ticket maps to which CVE.
• 2025.01 hotfix: one consolidated patch for all three CVEs, tracked as AD-24576.
• 2024.04 and earlier: web.xml changes that block the bypass path and prevent .jspx file creation. Eptura distributes these through support rather than publicly.

Indicators and artefacts

Eptura's notice does not publish indicators of compromise, and neither CVE record does. The original disclosure's technical notes give defenders three useful artefacts to look for, which we repeat here for hunting only:

None of these is proof of compromise on its own. A .jspx file in a vendor folder may be legitimate. Compare against a clean install or ask your partner.

Who is affected

Archibus deployments are often more exposed than people assume. Eptura's own deployment guide describes Web Central as a Tomcat web application that remote users reach through a browser, and the Smart Client and CAD extensions connect to the same server from regional offices, architects and outsourced CAD providers. Kiosk and mobile use also push Web Central toward the internet. If your building staff can book a room from home, there is a fair chance the server is reachable from outside.

Patch before it is exploited: facilities and enterprise apps

Facilities, real estate and workplace platforms sit in an awkward place. Security teams do not think of them as crown jewels, and facilities teams do not think of them as attack surface. Yet they hold floor plans, badge and occupancy data, contractor records, lease terms and, in this case, credentials. They are typically installed by a partner, customised heavily, and upgraded once a year if that. When three chained flaws are published with scores of 8.5 to 9.6 and no exploitation yet, the gap between "published" and "someone tries it" is where you win or lose.

Here is a playbook for this incident and for the next one in the same category.

1. Set a clock that matches the bug, not the owner. The SSVC data says 107186 is "automatable: yes". Unauthenticated, automatable and network reachable is the profile that gets scanned for at scale soon after disclosure. For internet-facing instances, aim for mitigation within 24 to 72 hours of disclosure, even if the full upgrade takes longer. Internal-only instances can follow within a week.

2. Find the real owner in the first hour. For partner-run Archibus, the person who can apply a hotfix is often outside your company. Your contract or statement of work should name a security contact at the partner and a response time. If it does not, today's job is to call them, ask for the version and hotfix status, and write the answers down.

3. Mitigate first, upgrade second. Applying hotfix AD-24576 or Eptura's web.xml change is a small, testable change. Upgrading from 2024 to 2026 is a project with database schema changes and customisation migration. Do the small change now and schedule the project. Do not let the project hold the mitigation hostage.

4. Cut exposure while you wait. If the server does not need to be on the internet, take it off. If it does, put it behind a VPN or an identity-aware proxy, or restrict the legacy /archibus/dwr/ path to authenticated sessions at the reverse proxy, after testing that your Archibus views still work. Eptura's hardening guide already recommends a reverse proxy, HTTPS, and keeping search engines away from the deployment.

5. Patch the platform under the platform. Archibus runs on Tomcat and a JDK, and Eptura's hardening guide recommends checking the application server and JDK for known security issues and running the latest supported Tomcat version. Check them while you have the change window open.

6. Treat unsupported versions as a risk decision, not an accident. Eptura's policy supports releases from the last 18 months. If you run anything from 2024 or earlier, this incident is your evidence for the upgrade budget. Record the risk acceptance with a named owner and an end date if you cannot upgrade this quarter.

7. Assume someone may have looked, and check. The flaws existed for a long time before disclosure and were found by researchers during routine testing. No exploitation is reported, but you should still review logs and the file system for the artefacts above, and rotate credentials if anything looks wrong.

What to do now

1. Find every Archibus instance you own

Start with what you already know: your CMDB, your partner contracts, and your licence records. Then check what the network says. Run these only against hosts and domains you own or are authorised to test.

Search your DNS zone exports and reverse proxy configs for the application path:

# Reverse proxy and load balancer configs (adjust paths for your estate)
grep -RIl --include='*.conf' -e 'archibus' /etc/nginx /etc/httpd /etc/apache2 2>/dev/null

# Exported DNS zones or inventory files
grep -RIi -e 'archibus' -e 'facilities' -e 'iwms' ./dns-exports ./inventory 2>/dev/null

Check whether a known hostname serves the Web Central login page and the legacy DWR client script. A 200 on the second URL tells you the DWR interface is reachable from where you ran the command. It does not tell you the version, because DWR is still present in patched releases.

HOST=facilities.example.com   # one of your own hosts
curl -s -o /dev/null -w "login: %{http_code}\n" "https://$HOST/archibus/login.axvw"
curl -s -o /dev/null -w "dwr:   %{http_code}\n" "https://$HOST/archibus/dwr/engine.js"

Run the same two commands from outside your network, for example from a cloud shell, to learn whether the path is internet facing.

On Windows servers, find the Web Central deployment folder under Tomcat:

Get-ChildItem -Path 'C:\','D:\' -Recurse -Directory -Filter 'archibus' -ErrorAction SilentlyContinue |
  Where-Object { $_.FullName -match 'webapps' } |
  Select-Object FullName, LastWriteTime

On Linux servers:

find / -type d -name archibus -path '*webapps*' 2>/dev/null

2. Check the version and hotfix status

Eptura's public pages we read do not document a single command that prints the Web Central build number, so use more than one source and make them agree:

• Ask your Eptura partner or Archibus Support for the installed version and whether WebCv2025.01.01.128_Hotfix-for-AD-24576 is applied, with the date.
• Check your change records and installer archive for the version of the last install or upgrade.
• On Windows hosts, look for installed product entries:

Get-ItemProperty 'HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*',
                 'HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*' |
  Where-Object { $_.DisplayName -match 'Archibus' } |
  Select-Object DisplayName, DisplayVersion, InstallDate

• Look at the modification dates of the deployment folder against your known patch dates; a 2025.01 server with no files changed since before 21 October has almost certainly not received the hotfix.

Record the answer per server in a table: hostname, environment, version, hotfix yes or no, internet facing yes or no, owner, partner contact.

3. Apply the fix for your line

Before you change anything, back up the Web Central deployment folder and WEB-INF configuration, so you can compare files afterwards and roll back if a view breaks.

$src = 'D:\Tomcat\webapps\archibus'       # your path
$dst = "D:\backup\archibus-$(Get-Date -Format yyyyMMdd-HHmm)"
Copy-Item -Path $src -Destination $dst -Recurse

4. Hunt for signs of earlier use

Search Tomcat access logs for DWR calls. On a busy server most of these are normal browser traffic, so focus on client addresses that never requested the login page, unusual hours, and addresses outside your user base.

cd /opt/tomcat/logs    # or your Tomcat logs folder
grep -h 'POST /archibus/dwr/call/' localhost_access_log.*.txt \
  | awk '{print $1}' | sort | uniq -c | sort -rn | head -30

Select-String -Path 'D:\Tomcat\logs\localhost_access_log.*.txt' -Pattern 'POST /archibus/dwr/call/' |
  ForEach-Object { ($_.Line -split ' ')[0] } |
  Group-Object | Sort-Object Count -Descending | Select-Object -First 30 Count, Name

Look for server-side template files and export files that should not be there:

find /opt/tomcat/webapps/archibus -type f \( -name '*.jspx' -o -name 'DataViewReport*' \) \
  -newermt 2026-01-01 -printf '%TY-%Tm-%Td %TH:%TM  %p\n' 2>/dev/null | sort

Get-ChildItem -Path 'D:\Tomcat\webapps\archibus' -Recurse -File -Include '*.jspx','DataViewReport*' |
  Where-Object LastWriteTime -gt (Get-Date '2026-01-01') |
  Select-Object LastWriteTime, FullName | Sort-Object LastWriteTime

If you collect process creation events (Windows Security event 4688 with command line logging, or Sysmon event 1), look for shells started by the Tomcat process:

Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 4688; StartTime = (Get-Date).AddDays(-180) } |
  Where-Object { $_.Message -match 'Creator Process Name:.*(tomcat|java)' -and
                 $_.Message -match 'New Process Name:.*(cmd|powershell|pwsh)\.exe' } |
  Select-Object TimeCreated, Id -First 50

Keep copies of anything you find before you delete it. If you find a file you cannot explain, treat the server as compromised and bring in your incident response process.

5. Rotate what the database read could have exposed

If you find any sign of misuse, or if an internet-facing affected server ran for a long time without logs you can trust, rotate:

• Archibus user passwords, especially for administrator and system accounts in afm_users, and disable the GUEST account as Eptura's hardening guide recommends.
• Database connection credentials configured for Web Central.
• Service account passwords used by the Tomcat service and by connectors.
• SSO client secrets and any API tokens stored in Archibus configuration.
• Credentials for integrations such as mail, calendar or ERP connectors.

Eptura's guide also recommends encrypting passwords in configuration files and using SAML or OIDC instead of Archibus's own user table for production. Both reduce what a database read can give away.

6. Harden while the window is open

From Eptura's own "Securing Web Central for Production Deployment" guide, the items that matter most for this chain:

• Restrict file system access so the Web Central deployment is read-only except for the specific folders the guide lists. A deployment that cannot write executable files into served folders limits the upload class of bug.
• Remove default accounts and review security.properties so system accounts do not use common names.
• Disable unused services and workflow rules; the guide calls out the compatibility executeSQL rule and a list of optional services.
• Put Web Central behind HTTPS and a reverse proxy, add the recommended response headers, and stop the servers disclosing version numbers.
• Consider a separate Web Central instance for scheduled workflow rules and another for interactive users, as the guide suggests.

7. Verify and document

After patching, repeat the inventory checks, confirm the version and hotfix with your partner in writing, and file the evidence with your vulnerability management records. Expect your scanner to keep flagging a hotfixed 2025.01 because the CVE range says "below 2025.02". Mark it with the hotfix reference rather than suppressing it blindly.

What would have helped

Practices any team can use

An inventory that includes business platforms. Most vulnerability programmes track operating systems, browsers and the company's own code well. Facilities, HR, finance and other line-of-business platforms often live in a separate world owned by a business team and a partner. A single list of every web application you run, with owner, version, partner, exposure and support status, turns a disclosure like this into a ten-minute lookup instead of a two-day hunt.

Support status as a tracked control. Eptura's support window is 18 months. Every vendor has one. If a product line falls out of support, nobody will ship you a patch when the next CVE lands, as owners of 2024 releases are now finding. Track end-of-support dates next to versions, and start upgrade projects before the date, not after the CVE.

Partner contracts with security terms. When a partner runs a platform for you, the contract should say how fast they apply vendor security fixes, how they notify you, and who to call out of hours. This incident needed a hotfix from a partner portal applied by a partner. Without terms, you are hoping.

Exposure by default set to private. Many Archibus features need a browser, but not every browser on the internet. A VPN or identity-aware proxy in front of facilities platforms removes the "unauthenticated, network reachable" part of the risk for most of the user base.

Read release notes for security changes hiding as features. The 2025.02 release that made customers safe did so through a change listed as a modernisation, not a security fix. Teams that stayed on the current release were protected months before disclosure. Staying current on vendor releases is a security control, not just a feature decision.

Least privilege for the service account. The original disclosure reports commands running as the Windows Local Service account on the tested server. Whatever account your Tomcat runs as, make sure it cannot reach more than it needs: no domain admin rights, no broad file share access, no stored credentials for unrelated systems.

Logs you can trust. Several of the hunting steps above depend on access logs and process creation logs that many Tomcat servers do not keep for long. Ship them to central storage with a retention that covers at least a few months.

Where Safeguard fits

Safeguard does not patch Archibus, does not hold Eptura's hotfix, and nothing in it would have prevented these bugs in a closed-source commercial product. Archibus is Eptura's code, delivered as a vendor installer and, for SaaS customers, run by Eptura. The fix has to come from Eptura, and for partner-run installs it has to be applied by the partner.

What Safeguard does help with is the software around it and the software you build:

• Inventory and matching for what you build and receive. Safeguard scans repositories, container images and SBOM files (safeguard scan --dir ., safeguard scan --image <name>, safeguard scan --sbom <file>, with JSON results under ./output) and matches components against vulnerability databases. If your vendor or partner supplies an SBOM for a product like Archibus, you can scan it and the platform shows which projects contain a given component and version. Eptura's 2025.02 revision history lists third-party Java components such as Spring Framework 6.1.18, Spring Security 6.3.8 and a DWR 3.0.2 build, which is exactly the kind of list an SBOM makes machine readable.
• Prioritisation and policy for your own code. Reachability analysis ranks findings by whether your code calls the vulnerable paths, and policies and gates evaluated in the platform stop known vulnerable versions shipping in the integrations, plugins and custom services you build around platforms like this.
• Fixes with approval. The Safeguard CLI's assistant can edit code and run commands with your approval, for example the inventory and log searches in this post, run across a list of servers from an administration host, with each command shown before it runs. Autonomous remediation opens fix pull requests for your own dependencies, and ships switched off by default.

Where Safeguard does not help: it cannot see inside a vendor installer that ships without an SBOM, it does not tell you whether a partner applied a hotfix, it does not detect exploitation on your Archibus server, and it does not replace web application firewalls, endpoint detection or your incident response process.

Zero-Day Discovery and Gold

Safeguard's Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode, and issues findings as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems of open source code. Archibus is a closed-source commercial application, outside that scope. These flaws were found by independent security researchers during authorised testing.

Gold Open Source at gold.safeguard.sh is free and needs no login; it shows CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version for a CVE, through the site, a free read API and a CI gate GitHub Action. We have not confirmed that it holds records for these three CVEs, so check the site rather than relying on this post. Gold Registry at registry.safeguard.sh provides hardened, signed open source components and container images held to zero exploitable critical or high CVEs; it does not distribute Archibus and we make no claim about it here. The habit both are built for applies to everything you build around platforms like this: pull patched, signed components from a curated source and rebuild fast.

Common mistakes

Trusting the scanner's "fixed in" field alone. The CVE range says affected below 2025.02, which will mark a correctly hotfixed 2025.01 as vulnerable and could push a team into an unnecessary emergency upgrade. The reverse mistake is worse: assuming 2025.01 is fine because it is "supported". Check for the hotfix.

Waiting for NVD. NVD's status for all three is "Deferred". If your process waits for an NVD score before acting, it may wait indefinitely. The CNA scores and Eptura's notice are enough to act on.

Checking only production. Staging, training and demonstration servers often run older versions, use default accounts, and sit on the same network. Eptura's own guide warns that out-of-the-box Web Central is configured for demonstration and is not secure.

Blocking DWR blindly. Archibus views rely on DWR in many releases. Blocking the whole path at a proxy can break the application. Use Eptura's web.xml mitigation for old releases, test any proxy rule, and prefer restricting exposure over breaking functionality.

Forgetting the partner. For many customers, the partner holds the installer, the hotfix and the admin credentials. A ticket to your own IT team will not patch the server.

Patching and not looking back. A patch closes the door. It does not tell you whether someone came in earlier. Spend an hour on the log and file system checks.

Treating "not exploited" as "not urgent". Exploitation status is a snapshot. The bypass is rated automatable and the chain is unauthenticated.

Open questions

• SaaS coverage. Eptura's notice does not mention Archibus SaaS. Which release do SaaS tenants run, and when were they covered?
• The exact mitigation for older releases. The web.xml changes are available only through support. We cannot say how they interact with customisations.
• Write access through the database flaw. The CVE record for 107187 says writes and deletes "may also be possible" but were untested.
• Older lines. The CVE range starts at version 0. How far back the vulnerable code goes is not stated.
• Scanner coverage. Whether vulnerability scanners will recognise a hotfixed 2025.01 as fixed, rather than flagging it by version alone, is not documented.
• Ticket mapping. Which 2025.02 change actually closed each flaw is not published.

FAQ

Are CVE-2026-107186, CVE-2026-107187 and CVE-2026-107188 being exploited?

No exploitation has been reported. CISA's SSVC entries from 20 October record exploitation as "none" for all three, and none is in the KEV catalog released on 21 October. That can change, so check the KEV catalog and Eptura's notice again before you close the ticket.

Which Archibus versions are affected?

According to the CVE records, every version below 2025.02. According to Eptura, 2025.01 is fixed once hotfix WebCv2025.01.01.128_Hotfix-for-AD-24576 is applied, and 2025.02 and 2026.01 need no action. 2024.04 and older have no patch and need Eptura's web.xml mitigation.

Do I need a login to exploit the chain?

According to the CVE descriptions, no. CVE-2026-107186 removes the authentication requirement, and the other two can be reached through it. The individual scores for 107187 and 107188 assume a low privileged user because each is rated on its own.

Is a CVSS of 9.6 the official NVD score?

NVD displays it, but it comes from the CNA attached to the researchers and is marked "Secondary". NVD's status is "Deferred", so it may never add its own score.

We are on Archibus SaaS. What should we do?

Eptura's public notice does not mention SaaS. Ask Eptura which release your tenant runs and whether it is covered, and keep the written answer for your records.

Our partner runs Archibus for us. What should we ask them?

Ask for the version on each server, whether hotfix AD-24576 or the web.xml mitigation is applied and when, whether the server is internet facing, and whether they reviewed logs for unusual DWR traffic and unexpected .jspx files.

Can a web application firewall protect us instead of patching?

A firewall or reverse proxy rule can reduce exposure while you patch, especially by keeping the server off the internet. It is not a substitute for Eptura's fix, because the application relies on the same legacy interface for normal work and a rule broad enough to block every variant may break views.

We patched. Do we still need to rotate credentials?

If you find any sign of misuse, yes. If the server was internet facing and unpatched for a long time and you lack logs to rule out access, rotating administrator, database and service account credentials is a reasonable precaution.

Why was only 2025.01 patched?

Eptura's support policy covers the current release and anything released in the previous 18 months, which today means 2026.01, 2025.02 and 2025.01. Older releases are out of support, so Eptura offers a configuration mitigation instead of a patch.

Did Safeguard find these vulnerabilities?

No. Independent security researchers found them during authorised testing and reported them to Eptura. Safeguard's Zero-Day Discovery covers open source package ecosystems, and Archibus is closed-source commercial software.

Fix it without waiting for upstream

For Archibus itself, the "upstream" is Eptura, and because it is commercial software, the fix has to come from Eptura and your partner: the hotfix, the upgrade or the web.xml mitigation. The approach below applies to everything you build around it, from integrations and custom services to the container images and open source libraries in your own products.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

These are real product sessions on other examples; none of them shows this Archibus incident, and none of them patches Archibus. They show how the same approval-based workflow applies to the inventory, hunting and hardening work around it.

The CLI demo shows the assistant fixing a lodash CVE: it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, and pushes nothing. For this incident, you would open the CLI on an administration host and ask it to run the inventory and log checks from this post against your list of Archibus servers, approving each command before it runs and getting a summary table at the end.

Click through it at your own pace, or open it full screen.

The desktop app demo shows a CLI session in the conversation list, a request for work on the computer, a folder choice, and Approve or Deny on each command and file edit, ending with an upgrade done and tests passing. Here you would pick the folder that holds your reverse proxy configuration, ask for a rule that keeps Archibus off the public internet, and approve each file edit and config test before anything is reloaded.

Click through it at your own pace, or open it full screen.

The mobile app demo shows a real Android session sending work to a computer running the CLI and approving a command on the phone with Allow once, Allow for turn or Deny. Facilities change windows often run at night or at weekends; this is how the on-call engineer approves the backup, the log search and the verification step from a phone while the partner applies the hotfix.

Click through it at your own pace, or open it full screen.

To try it on your own projects, download Safeguard and read the CLI documentation. For finding affected systems quickly, see using SBOMs to find affected products fast; for other edge and enterprise flaws this month, see edge device zero-days in October 2026, what a provider incident teaches about third-party risk and our October 2026 roundup.

Quick check

Sources

• NVD: CVE-2026-107186
• NVD: CVE-2026-107187
• NVD: CVE-2026-107188
• CVE.org record: CVE-2026-107186
• CVE.org record: CVE-2026-107187
• CVE.org record: CVE-2026-107188
• Eptura: Notice on Archibus CVE-2026-107186, CVE-2026-107187 and CVE-2026-107188 (21 October 2026)
• Eptura Knowledge Center: Revision History for Archibus V.2025.02
• Eptura Knowledge Center: Revision History Overview
• Eptura Knowledge Center: Archibus Support Policy
• Eptura Knowledge Center: Securing Web Central for Production Deployment
• Eptura Knowledge Center: Unused Web Central Services to Disable
• Eptura Knowledge Center: Types of Archibus Deployments
• CISA: Known Exploited Vulnerabilities catalog (JSON feed)
• CISA Vulnrichment: CVE-2026-107188 record
• FIRST: CVSS v3.1 Specification Document
• OWASP: File Upload Cheat Sheet
• Original disclosure

Last reviewed: 23 October 2026. This is a developing story; check the linked advisories for the latest status.