CVE-2023-32315 Openfire: Am I Vulnerable? Version Check, Log IOCs, and Shodan
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
CVE-2023-32315 is on CISA's Known Exploited Vulnerabilities catalog, which means CISA has confirmed that threat actors are actively exploiting it against real organizations -- not just in proof-of-concept demonstrations. The vulnerability requires zero prior authentication to exploit, and successful exploitation yields admin console access that can be converted to full remote code execution by installing a malicious plugin.
If you run Openfire anywhere in your environment (on-premises team chat, IoT messaging, or as part of a third-party product stack), this page gives you everything needed to determine exposure in under 10 minutes and remediate immediately if vulnerable.
Affected Openfire versions
CVE-2023-32315 affects Openfire versions from 3.10.0 through 4.7.4, and versions 4.6.0 through 4.6.7 in the older 4.6.x branch. The vulnerability was introduced in Openfire 3.10.0 when the authentication filter was refactored.
Patched versions:
- Openfire 4.7.5 and later (current 4.7.x branch)
- Openfire 4.6.8 and later (4.6.x LTS branch)
Any Openfire instance running a version below 4.7.5 (or below 4.6.8 on the 4.6.x branch) is vulnerable to unauthenticated admin console access if the admin console is network-reachable.
Version check: Am I running a vulnerable version?
Run the appropriate check for your deployment environment. The version check takes under 30 seconds.
Linux: Check installed package version
For DEB-based systems (Ubuntu, Debian): run 'dpkg -l openfire' and check the Version column. For RPM-based systems (RHEL, CentOS): run 'rpm -qa | grep openfire'. If the version shown is below 4.7.5 (or below 4.6.8 on the 4.6.x branch), the instance is vulnerable.
Windows: Check the admin console version page
If the Openfire admin console is accessible, navigate to http://localhost:9090/index.jsp (or the configured admin port) and look for the version number displayed in the top-right corner of the admin dashboard. Alternatively, check the Openfire installation directory for the openfire.jar file and run: 'java -jar openfire.jar --version' or check the lib directory version from the installer manifest.
Check via the admin console without credentials (proof of vulnerability)
If your Openfire admin console is on port 9090 or 9091, and you can access the URL: http://your-server:9090/setup/setup-s/%u002e%u002e/%u002e%u002e/user-groups.jsp -- and it returns admin console content without prompting for login -- your instance is actively exploitable. This path traversal test confirms the vulnerability without requiring credentials. Do not test against production systems you do not own.
Check via Shodan for externally exposed instances
Shodan query: product:"Openfire" to find internet-exposed instances. Add 'org:"Your Organization Name"' or 'net:YOUR.IP.RANGE/24' to scope to your infrastructure. Any result showing your organization's Openfire admin console on port 9090 or 9091 is both vulnerable and internet-exposed -- the highest urgency combination.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Log IOCs: evidence of exploitation in your Openfire logs
If your Openfire instance was reachable from the internet or from compromised internal network segments, check Openfire's access logs for path traversal patterns consistent with CVE-2023-32315 exploitation. Openfire stores logs in the logs/ directory under the installation path (default: /opt/openfire/logs/ on Linux).
Search the access log (openfire.log or http.log) for these patterns:
- Path traversal strings in admin console requests: grep -E '%u002e|%u002f|../|.%2e' /opt/openfire/logs/*.log
Exploitation attempts use URL-encoded path traversal to bypass the authentication filter. Common patterns: %u002e%u002e (Unicode-encoded double dot), ../ sequences in admin console paths, and requests to /setup/setup-s/ paths that should not be externally accessible.
- Plugin installation activity: grep -i 'plugin.install|uploadplugin' /opt/openfire/logs/.log
Successful exploitation is typically followed immediately by plugin installation to establish persistence. Any plugin installation from an unexpected source IP or outside a known administrative change window is a high-fidelity compromise indicator.
- New admin user creation: Grep the admin console audit log for user creation events from IPs outside your known administrator IP ranges. Attackers who achieve admin console access commonly create a new admin account for persistence before escalating further.
Remediation: patch and post-compromise verification
If your Openfire instance is on a vulnerable version, patch immediately. If exploitation evidence is found in logs, treat the instance as compromised and follow the post-compromise steps.
Upgrade Openfire to 4.7.5 or later
Download the current release from igniterealtime.org/downloads. For Linux package installs, stop the Openfire service ('systemctl stop openfire'), upgrade the package, and restart. For Windows installs, use the installer. Verify the version in the admin console after upgrade. The upgrade preserves your existing configuration, user database, and message archive.
Restrict admin console network access immediately
The Openfire admin console (port 9090 for HTTP, 9091 for HTTPS) should never be internet-accessible. If your network perimeter allows inbound connections to these ports, block them at the firewall immediately -- before patching if necessary, as a temporary compensating control. Admin console access should be restricted to a management network or VPN-authenticated administrative workstations.
Audit installed plugins for unauthorized additions
In the Openfire admin console, navigate to Plugins and audit every installed plugin. Any plugin not recognized from your change management records should be treated as a malicious persistence mechanism. Remove unrecognized plugins and record their names for forensic investigation.
Audit admin user accounts for unauthorized additions
Navigate to Users/Groups in the Openfire admin console and audit every account with admin-level permissions. Remove any account not corresponding to a known administrator. Check the account creation dates -- accounts created within the exploitation window with unusual names are strong indicators of post-exploitation persistence.
Check for Openfire service account privilege on the host
If the Openfire service runs under a privileged Windows service account or as root/sudo on Linux, successful plugin installation may have provided system-level code execution beyond the Openfire application. Audit the host system for new scheduled tasks (Windows) or cron jobs (Linux), new user accounts, new SSH authorized keys, and network connections to external IPs from the Openfire process. Engage your IR process if host-level compromise indicators are found.
The bottom line
CVE-2023-32315 is unauthenticated, publicly exploited, and on the CISA KEV list. Any internet-exposed Openfire admin console on a vulnerable version is a high-probability compromise waiting to happen, if it has not happened already.
The version check and log audit take under 15 minutes. Upgrade takes under 30 minutes for most deployments. The firewall rule restricting admin console access takes under 5 minutes. There is no acceptable reason to defer this remediation.
For complete technical analysis of the CVE-2023-32315 authentication bypass and how path traversal is used to bypass the authentication filter, see the CVE-2023-32315 Openfire vulnerability analysis.
Frequently asked questions
Is CVE-2023-32315 still being actively exploited in 2026?
Yes. CVE-2023-32315 remains on CISA's Known Exploited Vulnerabilities catalog, confirming continued active exploitation. Shodan scanning data shows thousands of internet-exposed Openfire instances, many still running vulnerable versions years after the patch was released. The vulnerability requires zero authentication to exploit, making it consistently attractive to automated exploitation tools that scan for Openfire instances and attempt the path traversal attack automatically.
What is the CVE-2023-32315 CVSS score and severity?
CVE-2023-32315 has a CVSS 3.1 Base Score of 7.5 (High), but for internet-facing Openfire deployments the practical severity is effectively Critical. The 7.5 score reflects the lack of a user interaction requirement but does not fully account for the post-exploitation impact: admin console access enables plugin installation, which provides full RCE on the host. CISA's KEV listing and confirmed exploitation at scale makes this a remediation priority regardless of the numeric CVSS score.
Which Openfire versions are vulnerable to CVE-2023-32315?
Vulnerable versions: Openfire 3.10.0 through 4.7.4, and the 4.6.x branch from 4.6.0 through 4.6.7. Patched versions: Openfire 4.7.5 and later, and Openfire 4.6.8 and later on the 4.6.x branch. Any version below these thresholds is vulnerable to unauthenticated admin console access via path traversal.
How can I check if my Openfire server was already compromised?
Search your Openfire access logs (/opt/openfire/logs/ on Linux) for path traversal strings including %u002e, %u002f, and requests containing /setup/setup-s/ paths. Check the Openfire admin console Plugins section for any installed plugin not recorded in your change management history. Audit admin user accounts for any additions outside known administrative changes. Check the host system for new scheduled tasks, cron jobs, and network connections from the Openfire process to external IPs.
What is the Shodan dork to find exposed Openfire servers?
Shodan query: product:"Openfire" -- this returns internet-exposed Openfire admin consoles on the default ports (9090 HTTP, 9091 HTTPS). To scope to your organization: product:"Openfire" org:"Your Organization Name" or product:"Openfire" net:YOUR.IP.RANGE/24. Any Openfire admin console exposed on these ports is a vulnerability target. Admin console ports should be firewall-blocked at the network perimeter.
Does restricting the admin console port fully mitigate CVE-2023-32315?
Yes, as a temporary compensating control. Blocking inbound access to Openfire admin console ports (9090 and 9091) at the network perimeter prevents external exploitation of the authentication bypass. However, if the admin console is accessible from internal networks to compromised internal hosts, internal exploitation remains possible. The correct long-term remediation is upgrading to Openfire 4.7.5 or later, with the firewall restriction as an immediate compensating control applied before the upgrade completes.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.