Skip to content
Log inStart free trial

GHSA-gw42-f939-fhvm BIT-openfire-2023-32315 CVE-2023-32315

Administration Console authentication bypass in openfire xmppserver

High Known exploited Maven
Severity
8.6 / 10
High · CVSS 3.1
Exploit chance (EPSS)
100.00%
Chance of exploitation in the next 30 days. Higher than 99.99% of scored vulnerabilities.
Known exploited
Yes
In CISA's catalog since Aug 24, 2023
Weakness
CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Fix
4.6.8
Upgrade org.igniterealtime.openfire:xmppserver to this version or later
Exploited in the wild. Ignite Realtime Openfire Path Traversal Vulnerability (Ignite Realtime Openfire). Required action: Apply mitigations per vendor instructions or discontinue use of the product if mitigations are unavailable. Due for U.S. federal agencies by Sep 14, 2023.

Description

An important security issue affects a range of versions of Openfire, the cross-platform real-time collaboration server based on the XMPP protocol that is created by the Ignite Realtime community.

Impact

Openfire's administrative console (the Admin Console), a web-based application, was found to be vulnerable to a path traversal attack via the setup environment. This permitted an unauthenticated user to use the unauthenticated Openfire Setup Environment in an already configured Openfire environment to access restricted pages in the Openfire Admin Console reserved for administrative users.

Cause

Path traversal protections were already in place to protect against exactly this kind of attack, but didn’t defend against certain non-standard URL encoding for UTF-16 characters, that were not supported by the embedded webserver that was in use at the time.

A later upgrade of the embedded webserver included support for non-standard URL encoding of UTF-16 characters. The path traversal protections in place in Openfire were not updated to include protection against this new encoding.

Openfire's API defines a mechanism for certain URLs to be excluded from web authentication (this, for example, is used for the login page). This mechanism allows for wildcards to be used, to allow for flexible URL pattern matching.

The combination of the wildcard pattern matching and path traversal vulnerability allows a malicious user to bypass authentication requirements for Admin Console pages.

Affected versions

This vulnerability affects all versions of Openfire that have been released since April 2015, starting with version 3.10.0. The problem has been patched in Openfire release 4.7.5 and 4.6.8, and further improvements will be included in the yet-to-be released first version on the 4.8 branch (which is expected to be version 4.8.0).

Problem Reproduction

To test if an instance of Openfire is affected, follow these steps. Open a browser in incognito mode, or otherwise ensure that there is no authenticated session with the Openfire admin console. Open the following URL (possibly modified for the hostname of the server that is running Openfire):

http://localhost:9090/setup/setup-s/%u002e%u002e/%u002e%u002e/log.jsp

If this shows part of the openfire logfiles, then the instance of Openfire is affected by this vulnerability. Note that different versions of Openfire will show a different layout. Newer versions of Openfire can be expected to show log files on a dark background, while older versions will show a largely white page. (Depending on the content of the log file, this page might be empty, apart from a header!)

If there's a redirect to the login page, the instance is likely unaffected.

Problem Resolution

The problem has been patched in Openfire release 4.7.5 and 4.6.8, and further improvements will be included in the yet-to-be released first version on the 4.8 branch (which is expected to be version 4.8.0).

  • In Openfire 4.6.8, 4.7.5 and 4.8.0, Path Traversal pattern detection has been improved to include detection of non-standard URL encodings, preventing any non UTF-8 characters.
  • In Openfire 4.6.8, 4.7.5 and 4.8.0, a new configuration property (adminConsole.access.allow-wildcards-in-excludes) is introduced that controls the permissibility of using wildcards in URL-patterns that define exclusions to authentication.
  • In Openfire 4.6.8, 4.7.5 and 4.8.0, the existing value that uses a wildcard in URL-patterns that define exclusions to authentication has been replaced by values that do not depend on a wildcard.
  • In Openfire 4.6.8, 4.7.5 and 4.8.0, Setup-specific URL-patterns that define exclusions to authentication are no longer active after the setup process has finished.
  • In Openfire 4.8.0, the embedded webserver will be updated to a version that no longer supports the non-standard URL encoding of UTF-16 characters.
  • In Openfire 4.8.0, the embedded webserver that serves the Openfire administrative console will bind to the loopback network interface by default.

Be aware that the new configuration properties can interfere with the functionality of certain Openfire plugins. This is especially true for plugins that bind a (web)endpoint to the embedded webserver that serves the Openfire administrative console, like current versions of the REST API plugin do. For these plugins to remain functional and/or reachable, it might be required to toggle the property adminConsole.access.allow-wildcards-in-excludes to true, and to avoid binding the embedded webserver to the loopback network interface only.

When your server uses older versions of the following plugins, make sure to upgrade them:

Mitigation

If an Openfire upgrade isn’t available for your release, or isn’t quickly actionable, you can take any of the following steps to mitigate the risk for your Openfire environment.

Be aware: through Openfire plugins, the effectiveness of some mitigations listed below can be reduced, while other mitigations might affect the functionality of plugins. Particular care should be taken when using the Monitoring Service plugin, REST API plugin, User Service plugin and/or Random Avatar plugin.

Restrict network access

Use network security measures (network ACLs and/or firewalls, VPNs) to ensure only trusted members of your community have access to the Openfire Admin Console. As a general rule, never expose the Openfire Admin Console to the general internet.

Examples:

  • On a linux machine running ufw, deny ports 9090 and 9091 on non-loopback interfaces
  • On a Windows machine, restrict the rules that open ports 9090 and 9091 to only allow traffic from the IPv4 and/or IPv6 loopback addresses
  • On AWS cloud infrastructure, use EC2 Security Groups to restrict ports 9090 and 9091 to trusted IP addresses. If the trusted range is necessarily too broad, consider opening and closing the ports only as necessary
  • If using Docker, instead of docker run ... -p 5222:5222 -p 9090:9090 -p 9091:9091 openfire prevent remote access to the Admin Console with docker run ... -p 5222:5222 -p 127.0.0.1:9090:9090 -p 127.0.0.1:9091:9091 openfire

Modify runtime configuration file

To close the avenue of potential attack, a runtime configuration file of Openfire can be modified.

In Openfire's installation directory, find the file plugins/admin/webapp/WEB-INF/web.xml. After creating a backup of this file, edit the original file.

The content of this file is XML. Find a <filter> element, that contains the <filter-name>AuthCheck</filter-name> child element. Depending on your version of Openfire, it will look similar to this:

<filter>
    <filter-name>AuthCheck</filter-name>
    <filter-class>org.jivesoftware.admin.AuthCheckFilter</filter-class>
    <init-param>
        <param-name>excludes</param-name>
        <param-value>
            login.jsp,index.jsp?logout=true,setup/index.jsp,setup/setup-*,.gif,.png,error-serverdown.jsp,loginToken.jsp
        </param-value>
    </init-param>
</filter>

The value inside of the param-value element is a comma-separated list of values. From this list, remove all * (asterisk) characters.

Save the file, and restart Openfire for the change to take effect.

Note that no guarantees can be given that this runtime configuration change persists over time. Ensure to monitor the presence of the fix. It is recommended to upgrade to a safe version of Openfire as soon as possible.

A side-effect of this change is that the Openfire web-based setup wizard will not function properly (functionality can be restored by reverting the change). This wizard is typically used only when initially installing Openfire.

Bind admin console to loopback interface

The Openfire admin console is a web-based application. By default, the corresponding webserver (that is embedded in Openfire) binds to all network interfaces of the host that it is running on.

The admin console can be configured to bind to a specific network interface. This will prevent it from being accessed through other network interfaces. By configuring the admin console to bind to the local loopback interface, it is accessible only to users on the server itself. This reduces the avenue of attack.

Note that several Openfire plugins expose part or all of their functionality through the admin console webserver. The REST API plugin, for example, serves its endpoints via this webserver. Availability of this functionality will be affected by binding the webserver to a specific network interface.

To bind the webserver of the Openfire admin console to a specific network interface, the 'openfire.xml' configuration file can be used.

In Openfire's installation directory, locate the file conf/openfire.xml. After creating a backup of this file, edit the original file.

The content of this file is XML. Find the <adminConsole> element that is a direct child element of the root <jive> element. Add a new element, named <interface> as a child element of <adminConsole>. The value of the <interface> element should be the name of the loopback interface or interface address. Setting value to 127.0.0.1 works on all tested environments (using values like lo on most Linux systems or lo0 on macOS will have the same effect).

The resulting fragment of the openfire.xml file will look similar to this:

<?xml version="1.0" encoding="UTF-8"?>
<jive>
  <adminConsole>
      <interface>127.0.0.1</interface>
      <port>9090</port>
      <securePort>9091</securePort>
  </adminConsole>

  ...

Save the file, and restart Openfire for the change to take effect.

Use AuthFilterSanitizer plugin

The Ignite Realtime community has made available a new plugin, called the AuthFilterSanitizer plugin. The plugin can be installed from the Openfire admin console, or can be downloaded from the plugin's archive page on the IgniteRealtime.org community website.

This plugin periodically removes entries for Openfire's authentication filter that are susceptible to abuse, closing the avenue of potential attack.

Note that this plugin might interfere with functionality that depends on the abuse-susceptible entries in the authentication filter that might be provided by plugins.

Credit

This issue was originally reported by Siebene@ who has our gratitude for the responsible and detailed disclosure of the issue!

We are grateful for the resources made available by Surevine ltd. They were instrumental in addressing the issue listed in this advisory.

References

Affected versions

Maven

PackageVulnerableFixed in
org.igniterealtime.openfire:xmppserver
>= 3.10.0, < 4.6.8
4.6.8
org.igniterealtime.openfire:xmppserver
>= 4.7.0, < 4.7.5
4.7.5
org.igniterealtime.openfire:xmppserver
>= 3.10.0, < 4.6.8
4.6.8

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

org.igniterealtime.openfire:xmppserver Maven → 4.6.8

maven
<dependency><groupId>org.igniterealtime.openfire</groupId><artifactId>xmppserver</artifactId><version>4.6.8</version></dependency>
gradle
implementation("org.igniterealtime.openfire:xmppserver:4.6.8")

Severity breakdown

CVSS 3.1 8.6

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L/E:H

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
Low
Availability
Low
Exploit maturity
H

Weakness

CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.

How to prevent it
  • Implementation: Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single "." character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as "/" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434. Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering "/" is insufficient protection if the filesystem also supports the use of "\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if "../" sequences are removed from the ".../...//" string in a sequential fashion, two instances of "../" would b
  • Architecture and Design: For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
  • Implementation: Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked. Use a built-in path canonicalization function (such as realpath() in C) that produces the canonical version of the pathname, which effectively removes ".." sequences and symbolic links (CWE-23, CWE-59). This includes: realpath() in C getCanonicalPath() in Java GetFullPath() in ASP.NET realpath() or abs_path() in Perl realpath() in PHP
  • Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482].
  • Operation: Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth [REF-1481].
  • Architecture and Design, Operation: Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
  • Architecture and Design: When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs. For example, ID 1 could map to "inbox.txt" and ID 2 could map to "profile.txt". Features such as the ESAPI AccessReferenceMap [REF-185] provide this capability.
  • Architecture and Design, Operation: Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software. OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.
  • Architecture and Design, Operation: Store library, include, and utility files outside of the web document root, if possible. Otherwise, store them in a separate directory and use the web server's access control capabilities to prevent attackers from directly requesting them. One common practice is to define a fixed constant in each calling program, then check for the existence of the constant in the library/include file; if the constant does not exist, then the file was directly requested, and it can exit immediately. This significantly reduces the chance of an attacker being able to bypass any protection mechanisms that are in the base program but not in the include files. It will also reduce the attack surface.
  • Implementation: Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success. If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files. Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not. In the context of path traversal, error messages which disclose path information can help attackers craft the appropriate attack strings to move through the file system hierarchy.
  • Operation, Implementation: When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.

References

Advisories

Fixes and patches

Packages

Other links

Timeline

  1. Published
  2. Added to CISA's Known Exploited Vulnerabilities catalog
  3. Remediation due for U.S. federal agencies
  4. Last updated by the source
  5. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-hjqx-j4rw-g7xv
zip: Arbitrary file write outside the extraction directory, because ZipArchive::extract validates symlink targets lexically.
High Same weakness, CWE-22
GHSA-9jrw-8xf7-xqhq
Keycloak vulnerable to information disclosure through arbitrary filesystem path probing
Medium Same weakness, CWE-22
GHSA-4vjg-vx72-qq4g
systeminformation has path traversal in Linux networkStats() that allows symlink-based file disclosure outside /sys/class/net
Low Same weakness, CWE-22
GHSA-m65p-9j7q-6w33
MLflow vulnerable to arbitrary file read on unauthenticated servers via prompt model version source
High Same weakness, CWE-22
GHSA-g5ff-637f-6q2m
LiteLLM: internal_user_viewer arbitrary local file read via `vertex_ai_credentials`
High Same weakness, CWE-22
CVE-2026-113672
Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes.
Critical Same weakness, CWE-22
GHSA-xp26-3454-mjgp
Vitest: Windows backslash traversal bypasses the @vitest/mocker redirect allowlist fix
Medium Same weakness, CWE-22
GHSA-vfpm-58rq-9qcg
Vite: First 4 bytes of files outside of `server.fs` setting is exposed by `?vite-wasm-instance`
Medium Same weakness, CWE-22

Credits: Fishbowler, Siebene, akrherz, guusdk

Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor